Application Security

Setting up an IPSEC VPN using OpenSwan in cloud environments

This is a brief tutorial that aims to help those who are new in setting up an IPsec VPN connection with OpenSwan, hosted in cloud environments like Google Cloud and Amazon Web Services.

I imagine you have an instance, lets say on Google Cloud, and want to establish an IPSec tunnel with another client outside your infrastructure.

Follow this tutorial in order to learn how to easily achieve it!

Installing OpenSwan and its dependencies

# apt-get install openswan ipsec-tools

Let’s verify if everything is fine:

# ipsec verify

A normal configuration will look like this:

Gathering information and setting up the configuration

Before you start configuring the vpn connection, you will need some information to proceed:

  • Customer VPN Gateway: This is the public IP of the other end of the tunnel.
  • Customer Encryption Domain: This is the private network that you should access (it can be more than one)

On your end, you should supply to your customer your VPN Gateway and your encryption domain (the private network that you are going to use to access it)

In a nutshell then, let’s define these values just for the purpose of this guide:

  • Customer VPN Gateway:
  • Customer Encryption Domain:
  • Your VPN Gateway:
  • Your Encryption Domain:

Now you need to decide with your customer the phase 1 and phase 2 settings. We will assume the following for this particular guide:

Phase 1:

  • Authentication Method: PSK (Pre-Shared-Key)
  • Encryption Scheme: IKEv2
  • Diffie-Hellman Group: Group 2
  • Encryption Algorithm: AES-256
  • Hashing Algorithm: SHA-2
  • Lifetime: 86400 seconds
  • Pre-Shared-Key (PSK) a_strong_PSK_here

Phase 2:

  • Encapsulation: ESP
  • Encryption Algorithm: AES-256
  • Authentication Algorithm: SHA-2
  • Diffie-Hellman Group: Group 2
  • Perfect Forward Secrecy: No
  • Lifetime: 3600 seconds

Setting up the OpenSwan Configuration

Having this information, now it’s time to play around with OpenSwan. First you need to open the config file /etc/ipsec.conf and create a new connection at the bottom of the file:

conn client-vpn # You can use any connection name here
              # Left security gateway, subnet behind it, nexthop toward right.
              # Right security gateway, subnet behind it, nexthop toward left.
              rightsubnets={} #Separate by commas for more networks.
              # Phase 1
              keyexchange=ike # Default version is IKEv2
              # Algorithm: AES(256) / Hash: SHA2 / Group: DH 2 (1024)

              # Phase 2
              # Algorithm: AES(256) / Hash: SHA2 / Group: DH 2 (1024)
              pfs=no # Port Forward Secrecy disabled
              auto=start # Start connection everytime OpenSwan is started

Still, you need to set up the PSK within the file /etc/ipsec.secrets:  %any: PSK "a_strong_PSK_here"

Routes, iptables and global rules

As you may know, Google Cloud, AWS and almost every cloud environment out there, only provides one physical interface (eth0) per instance/server. In order to be able to set up ‘n’ different connections, you need to create a virtual interface for each one of them.
For this example it was used (a host network) as the encryption domain on your end. Besides creating the virtual interface, it’s necessary to configure specific routes, iptables rules and global rules.

I personally recommend creating a script to have all this configuration well organized.
So let’s start then!

Create a file within /etc/init.d/ and name it as you want. In my case I named it firewall.
Then paste the following:



function start() {    

   # VPN IPSEC: MyCompany x My Client
   # Creating a virtual interface eth0:1
   /sbin/ifconfig eth0:1 netmask

   # Creating a NAT IP Tables Rule
   /sbin/iptables -t nat -I POSTROUTING -d -j SNAT --to

   # Creating a route so packets are transmitted through the virtual interface
   /sbin/route add -net netmask gw


   # Using masquerading
   /sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

   # Enable IP Forwarding so packets could be transmitted between networks
   echo 1 > /proc/sys/net/ipv4/ip_forward


function stop() {


   # Disabling IP Forwarding
   echo 0 > /proc/sys/net/ipv4/ip_forward

   # Flushing iptables rules
   /sbin/iptables -F
   /sbin/iptables -F -t nat

   # VPN IPSEC: MyCompany x My Client

   # Removing route 
   /sbin/route del -net netmask gw

   #Removing the virtual interface eth0:1
   /sbin/ifconfig eth0:1 down



case $1 in















   echo "Usage: firewall {start|stop|restart|status}"




The previous script will help you persist this configuration, and the ability to turn on and off, with these simple commands:

Turn on the configuration needed for the ipsec configuration:

# /etc/init.d/firewall start

Rollback to the default configuration:

# /etc/init.d/firewall stop

Testing the IPSec Tunnel

In order to use the new configuration it’s necessary to restart the ipsec service:

#service ipsec restart

Add the new ipsec connection:

# ipsec auto --add client-vpn

Start the IPSec tunnel:

# ipsec auto --start client-vpn

A successful connection would have the following message:

"client-vpn/0x1" #16: transition from state STATE_QUICK_I1 to state 
"client-vpn/0x1" #16: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode 
{ESP/NAT=>0xaaadccc7 <0x8bcbf8a0 xfrm=AES_256-HMAC_SHA2
NATOA=none NATD= DPD=none} 

In case you don’t see a message like that, you need to verify with your customer if every configuration is the same as yours. Remember that everything must be identical for the tunnel to be established.

After the tunnel is up and running, it’s important that you test the traffic through each end of the tunnel. You can use commands like ping, curl, nmap, telnet and nc.

If you can’t receive a response, the best way to debug possible issues is using tcpdump, in order to verify in/out packets through the interface.


Related posts
Application Security

Implementing a CI/CD Pipeline: Ensuring Software Quality and Security

In the current scenario of software development, speed and quality in application delivery are…
Read more
Application Security

Security Risk Management: Best Practices and Processes

Security risk management is a strategic process that involves identifying, assessing, and…
Read more
Application SecurityCode Fighters

How to integrate Semgrep on CI/CD's and send findings to Conviso Platform

Nowadays a very common practice is to integrate security scans during the continuous integration and…
Read more


Deixe um comentário

%d bloggers like this: