Linux IPSec Site-to-Site VPN: AWS VPC & Cisco Router

In this tutorial, we will use the Site-to-Site VPN scenario with the modification and one of the customer site that is using Cisco router, which is also acting as gateway for LAN plus the vpn gateway while from the AWS side, we are using the exact same Ubuntu Linux router.

Please review the previous tutorial before starting this tutorial, as I’ll use the previous tutorial as the base for this one.

topologyNote: Please don’t waste your time in hacking, all these public devices and IP(s) are Temporary, I have destroyed them after finished this tutorial.

VPN Configuration on Cisco Site:

First step is to configure an ISAKMP Phase 1 policy:

crypto isakmp policy 1
encryption aes 128
hash sha
authentication pre-share
group 2

1

Next, we need to set the pre-shared key for authentication with the AWS peer:

crypto isakmp key $VER_SEC_PSK address 54.219.146.242

2

Next step is to create the transform set (We have named it AWSTrans), which will be used to protect the data:

crypto ipsec transform-set AWSTrans esp-aes esp-sha-hmac

3

After that we have to define the Traffic to be protected through the VPN Tunnel using the access-list:

ip access-list extended VPN-TRAFFIC
permit ip 192.168.168.0 0.0.0.255 10.100.0.0 0.0.255.255

5

Now, we need to define the Crypto Map which will connect the ISAKMP and IPSec configuration together, that we have defined above:

crypto map AWSMAP 10 ipsec-isakmp
 set peer 54.219.146.242
 set transform-set AWSTrans
 match address VPN-TRAFFIC

4

Apply the Crypto Map to the outgoing interface of the router (In our case, it is FastEthernet 0/0)

interface FastEthernet0/0
crypto map AWSMAP

7

Check the NAT access-list before proceeding:

NAT Show

Add the NAT Bypass entry inside the NAT access-list before the NAT entry, to exclude the AWS VPC Private Subnet(s) to be NAT’d:

ip access-list extended NAT-TRAFFIC
5 deny ip 192.168.168.0 0.0.0.255 10.100.0.0 0.0.255.255

6

NAT access-list after modification:

NAT after Change

VPN Configuration on AWS VPC:

Also allow the ICMP packet on internal subnet security group from the remote LAN for testing purpose:

0

Edit the ipsec.conf file:

vi /etc/ipsec.conf

Here is the addition to the ipsec.conf file (please refer to the ipsec.conf file from previous tutorial):

conn AWS2CiscoConnection
 left=10.100.10.10
 leftsubnets=10.100.0.0/16
 leftid=54.219.146.242
 leftsourceip=10.100.10.10
 right=25.109.210.75
 rightsubnets=192.168.168.0/24
 rightid=25.109.210.75
 pfs=no
 forceencaps=yes
 authby=secret
 auto=start

2

Edit the shared secret file:

vi /etc/ipsec.secrets

3

Mine ipsec.secrets file as an example:

4

Restart the IPSec Service & verify the Tunnel status on both Sides:

Restart the IPSec service on Ubuntu at AWS VPC:

service ipsec restart

6

Verify the status of IPSec service on Ubuntu at AWS VPC:

service ipsec status

5Note: Please don’t panic, just restart the service one more time if it didn’t come up.

Verify the status of IPSec Tunnel on Cisco:

show crypto isakmp sa

8

Verify that the Traffic is passing through the Tunnel:

Ping from the AWS vpn gateway to the Cisco LAN IP:

7

Ping from AWS VPC private Subnet to Cisco’s LAN for verification:

8

Ping from the Local machine to the machine on VPC Private subnet:

9

10

Linux IPSec Site-to-Site VPN: AWS VPC & Vyatta Firewall

In this tutorial, we will use the Site-to-Site VPN scenario with the modification and one of the customer site that is using Vyatta firewall, which is also acting as gateway for LAN plus the vpn gateway while from the AWS side, we are using the exact same Ubuntu Linux router.

Please review the previous tutorial before starting this tutorial, as I’ll use the previous tutorial as the base for this one.

vyatta-vpn-sNote: Please don’t waste your time in hacking, all these public devices and IP(s) are Temporary, I have destroyed them after finished this tutorial.

VPN Configuration on Vyatta Site:

First, we need to configure 2 NAT rules, to exclude the traffic between AWS VPC Private Subnet(s) and LAN to be NAT’d, Please place these rules above all other NAT rules:

set nat source rule 5 destination address '172.30.30.0/24'
set nat source rule 5 source address '10.100.0.0/16'
set nat source rule 5 outbound-interface 'eth0'
set nat source rule 5 'exclude'

1

set nat source rule 7 source address '172.30.30.0/24'
set nat source rule 7 destination address '10.100.0.0/16'
set nat source rule 7 outbound-interface 'eth0'
set nat source rule 7 'exclude'

2

In the next step, we need to define the Phase 1 and 2 policies:

set vpn ipsec ike-group IKE-AWS-POLICY lifetime '28800'
set vpn ipsec ike-group IKE-AWS-POLICY proposal 1 encryption 'aes128'
set vpn ipsec ike-group IKE-AWS-POLICY proposal 1 hash 'sha1'
set vpn ipsec ike-group IKE-AWS-POLICY proposal 1 dh-group '2'

3

set vpn ipsec esp-group ESP-AWS-POLICY lifetime '3600'
set vpn ipsec esp-group ESP-AWS-POLICY pfs disable
set vpn ipsec esp-group ESP-AWS-POLICY proposal 1 encryption 'aes128'
set vpn ipsec esp-group ESP-AWS-POLICY proposal 1 hash 'sha1'

4

Next step is VPN configuration, i.e assignment of previously created policies and shared secret etc.

set vpn ipsec ipsec-interfaces interface 'eth0'
set vpn ipsec site-to-site peer 54.219.146.242 authentication mode 'pre-shared-secret'
set vpn ipsec site-to-site peer 54.219.146.242 authentication pre-shared-secret '$VER_SEC_PSK'
set vpn ipsec site-to-site peer 54.219.146.242 default-esp-group 'ESP-AWS-POLICY'
set vpn ipsec site-to-site peer 54.219.146.242 ike-group 'IKE-AWS-POLICY'
set vpn ipsec site-to-site peer 54.219.146.242 local-address '102.162.166.94'
set vpn ipsec site-to-site peer 54.219.146.242 tunnel 1 local prefix '172.30.30.0/24'
set vpn ipsec site-to-site peer 54.219.146.242 tunnel 1 remote prefix '10.100.0.0/16'

5

Finally, don’t forget to adjust your firewall rules as per your requirement:

set firewall name INSIDE-FW rule 10 action 'accept'
set firewall name INSIDE -FW rule 10 destination address '10.100.0.0/16'
set firewall name INSIDE-FW rule 10 source address '172.30.30.0/24'

6

set firewall name OUTSIDE-FW rule 10 action 'accept'
set firewall name OUTSIDE-FW rule 10 ipsec 'match-ipsec'

7

VPN Configuration on AWS VPC:

Also allow the ICMP packet on internal subnet security group from the remote LAN for testing purpose:

1

Edit the ipsec.conf file:

vi /etc/ipsec.conf

2

Here is the addition to the ipsec.conf file (please refer to the ipsec.conf file from previous tutorial):

conn AWS2VyattaConnection
 left=10.100.10.10
 leftsubnets=10.100.0.0/16
 leftid=54.219.146.242
 leftsourceip=10.100.10.10
 right=102.162.166.94
 rightsubnets=172.30.30.0/24
 rightid=102.162.166.94
 pfs=no
 forceencaps=yes
 authby=secret
 auto=start

3

Edit the shared secret file:

vi /etc/ipsec.secrets

4

Mine ipsec.secrets file as an example:

5

Restart the IPSec Service & verify the Tunnel status on both Sides:

Restart the IPSec service on Ubuntu at AWS VPC:

service ipsec restart

6

Reset the vpn tunnel on Vyatta:

reset vpn ipsec-peer 54.219.146.242

9

Verify the status of IPSec Tunnel on Ubuntu at AWS VPC:

service ipsec status

7

Verify the status of IPSec Tunnel on Vyatta:

show vpn ipsec sa

8

Verify the Route Table on both servers:

route -n

8

show ip route

12

Verify that the Traffic is passing through the Tunnel:

Ping from AWS VPC private Subnet to Vyatta’s LAN for verification:

9

Ping from Vyatta’s LAN  to AWS VPC private Subnet for verification:

10

11

Linux IPSec Site-to-Site VPN: AWS VPC & Mikrotik Router

In this tutorial, we will use the Site-to-Site VPN scenario with the modification and one of the customer site that is using Mikrotik router, which is also acting as gateway for LAN plus the vpn gateway while from the AWS side, we are using the exact same Ubuntu Linux router.

Please review the previous tutorial before starting this tutorial, as I’ll use the previous tutorial as the base for this one.

mikto

Note: Please don’t waste your time in hacking, all these public devices and IP(s) are Temporary, I have destroyed them after finished this tutorial.

VPN Configuration on Mikrotik Site:

Open the IP->IPsec window in WinBox:

1

Create a new Proposal(if you don’t want to use the default) as follows:

2

Now, create a new policy as follows:

From the General Tab

Src Address: Mikrotik LAN 192.168.10.0/24 Subnet
Dst Address: AWS VPC 10.100.0.0/16 Private Subnet

3

From the Action Tab:

SA Src Address: MIkrotik WAN Address 102.162.166.90
SA Dst Address: AWS VPC Linux NAT Router WAN Address 54.219.146.242
Tick the Tunnel checkbox
For Proposal: Use LAN2AWSProposal or whatever proposal you have created in the first step.

4

Next, Move to the Peers tab and create a new peer by using the public address of AWS NAT Instance asAddress:

5

Next, create a NAT Bypass rule, to exclude the AWS VPC Private Subnet(s) to be natted:

nat1

nat2

Placed the above created rule at the top of all other NAT rule(s) and clear the connection table from existing connection or reboot the Mikrotik.

nat3

VPN Configuration on AWS VPC:

Also allow the ICMP packet on internal subnet security group from the remote LAN for testing purpose:

6a

Edit the ipsec.conf file:

vi /etc/ipsec.conf

1

Here is the addition to the ipsec.conf file (please refer to the ipsec.conf file from previous tutorial):

conn AWS2MikrotikConnection
 left=10.100.10.10
 leftsubnets=10.100.0.0/16
 leftid=54.219.146.242
 leftsourceip=10.100.10.10
 right=102.162.166.90
 rightsubnets=192.168.10.0/24
 rightid=102.162.166.90
 pfs=no
 forceencaps=yes
 authby=secret
 auto=start

2

Edit the shared secret file:

vi /etc/ipsec.secrets

3

Mine ipsec.secrets file as an example:

4

Restart the IPSec service:

service ipsec restart

5

Verify the status of IPSec service on Ubuntu at AWS VPC:

service ipsec status

6

Note: Please don’t panic, just restart the service one more time if it didn’t come up.

Verify that the Traffic is passing through the Tunnel:

Ping from the AWS vpn gateway to the Mikrotik LAN IP:

7

Ping from AWS VPC private Subnet to Mikrotik’s LAN for verification:

8

Ping from the Local machine to the machine on VPC Private subnet:

7

8

VERY Useful Tip:

If the Tunnel didn’t come up after the configuration, just restart the server and also start the ping from your LAN host to other side LAN host.

Site-to-Site VPN between AWS VPC and Customer Site using Linux

In this tutorial, we will use the previous scenario on AWS side for the creation of site-to-site vpn between AWS VPC and Local site. On Amazon side, we’ll use Ubuntu 14.04 LTS, which will act as gateway for private subnet(s) plus the vpn gateway, while on the Local site, we’ll use the CentOS 6.5, which will perform the same tasks as of Ubuntu on AWS side (gateway for LAN plus vpn gateway).

modify vpc

Note: Please don’t waste your time in hacking, all these public devices and IP(s) are Temporary, I have destroyed them after finished this tutorial.

VPN Configuration on AWS VPC:

Please add the udp ports 500 & 4500 on NAT instance security group:

1

Also allow the ICMP packet on internal subnet security group from the remote LAN for testing purpose:

2

Now, install the desired package(s) for ipsec:

apt-get install iptables openswan

1

Edit the sysctl.conf file:

vi /etc/sysctl.conf

2

Add the following parameters inside it:

net.ipv4.ip_forward=1

net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0

net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.conf.default.log_martians = 0
net.ipv4.conf.all.log_martians = 0

net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0

net.ipv4.neigh.default.gc_thresh1 = 1024
net.ipv4.neigh.default.gc_thresh2 = 2048
net.ipv4.neigh.default.gc_thresh3 = 4096

3

Modify the rc.local file:

vi /etc/rc.local

4

Modify the MASQUERADE rule that we had added in the previous tutorial (Please adjust it according to your scenario):

iptables -t nat  -A POSTROUTING -s 10.100.0.0/16 ! -d 172.16.10.0/24 -o eth0 -j MASQUERADE

5Note: Please Reboot your machine once, so that changes will take effect.

Edit the ipsec.conf file:

vi /etc/ipsec.conf

6

Here is mine working ipsec.conf file, please adjust your’s as per your requirement:

version 2.0

config setup
 nat_traversal=yes
 protostack=netkey
 force_keepalive=yes
 keep_alive=60
 oe=off
 nhelpers=0

conn AWS2LocalConnection
 left=10.100.10.10
 leftsubnets=10.100.0.0/16
 leftid=54.219.146.242
 leftsourceip=10.100.10.10
 right=25.109.210.76
 rightsubnets=172.16.10.0/24
 rightid=25.109.210.76
 pfs=no
 forceencaps=yes
 authby=secret
 auto=start

7

Edit the shared secret file:

vi /etc/ipsec.secrets

8

Mine ipsec.secrets file as an example:

9

VPN Configuration on Local Site:

Before beginning the configuration, please verify that the selinux is disabled:

sestatus

2a

Install the openswan on CentOS, along with the desired packages:

yum install wget bind-utils openswan lsof

3

Configure the Openswan to start at boot time:

chkconfig ipsec on

4

Edit the sysctl.conf file on CentOS:

vi /etc/sysctl.conf

5

Add/Edit the following parameters:

net.ipv4.ip_forward = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0

6

Edit the iptables rule file:

vi /etc/sysconfig/iptables

7

Modify your iptables file according to your scenario, here are the desired iptables rules, please adjust them accordingly:

*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A POSTROUTING -s 172.16.10.0/24 ! -d 10.100.0.0/16 -o eth0 -j MASQUERADE
COMMIT
###########
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i eth1 -p udp -m udp --sport 67:68 --dport 67:68 -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p udp -m udp --dport 500 -j ACCEPT
-A INPUT -p udp -m udp --dport 4500 -j ACCEPT
-A INPUT -i eth0 -p esp -j ACCEPT
-A INPUT -p tcp -m tcp --dport 4500 -j ACCEPT
-A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth1 -o eth0 -j ACCEPT
COMMIT

8Note: Please Reboot your machine once, so that changes will take effect.

Edit the ipsec.conf file:

vi /etc/ipsec.conf

9

Here is mine working ipsec.conf file on Local site, please adjust your’s as per your requirement:

version 2.0

config setup
 nat_traversal=yes
 protostack=netkey
 force_keepalive=yes
 keep_alive=60
 oe=off
 nhelpers=0

conn Local2AWSConnection
 type=tunnel
 left=172.16.10.10
 leftsubnets=172.16.10.0/24
 leftid=25.109.210.76
 leftsourceip=172.16.10.10
 right=54.219.146.242
 rightsubnets=10.100.0.0/16
 rightid=54.219.146.242
 pfs=no
 forceencaps=yes
 authby=secret
 auto=start

10

Edit the shared secret file:

vi /etc/ipsec.secrets

11

Mine ipsec.secrets file as an example on Local Site:

12

Restart the IPSec Service & verify its status on both Sides:

Restart the IPSec service on Ubuntu at AWS VPC:

service ipsec restart

10

Restart the IPSec service on CentOS at Local Site:

service ipsec restart

13

Verify the status of IPSec service on Ubuntu at AWS VPC:

service ipsec status

11

Verify the status of IPSec service on CentOS at Local Site:

service ipsec status

14

Verify the IPSec Tunnel status on both servers:

ipsec whack --status | grep -i established 

11a

14aNote: established means that tunnel is up and traffic will traverse through it

Verify the Route Table on both servers:

route -n

12

15

Verify that the Traffic is passing through the Tunnel:

Ping from the AWS vpn gateway to the machine on Local LAN (I have Win XP machine on local LAN with an ip 172.16.10.100).

14

Ping from AWS VPC private Subnet to Local LAN for verification:

15

Ping from the Local vpn gateway to the machine on VPC Private subnet (I have Webserver on private subnet with an ip 10.100.20.20).

16

Ping from Local LAN  to AWS VPC private Subnet for verification:

17

Testing Without Ping (Using the following reference)

If you don’t have a box to target that should respond to ping, you can try running a port scan to see if you can at least reach the machine.

# nmap -PN <something_on_right_subnet>

Monitoring traffic

While you’re running your ping or nmap, you can view the traffic with tcpdump.

# tcpdump -n host <RIGHT_PUBLIC_IP>

If you don’t see ESP packets in tcpdump, then they aren’t being tunneled. Try:

# tcpdump -n host <something_on_right_subnet>

If that shows ICMP (or other if using nmap) packets, then you’re sending packets around the tunnel.

VERY Useful Tip:

If the Tunnel didn’t come up after the configuration, just restart the server and also start the ping from your LAN host to other side LAN host.

Please Remember me in your prayers!

Enjoy 🙂

References:

1) http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenario2.html
2) https://gist.github.com/winhamwr/2871257
3) http://stackoverflow.com/questions/21761830/site-to-site-openswan-vpn-tunnel-issues-with-aws
4) http://clauseriksen.net/2011/02/02/ipsec-on-debianubuntu/
5) http://blog.earth-works.com/2013/02/22/how-to-set-up-openswan-l2tp-vpn-server-on-centos-6/
6)https://raymii.org/s/tutorials/IPSEC_L2TP_vpn_on_CentOS_-_Red_Hat_Enterprise_Linux_or_Scientific_-_Linux_6.html
7)http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch35_:_Configuring_Linux_VPNs#.U1tZZ-aSwuj
8) http://www.whiteboardcoder.com/2012/12/amazon-aws-vpc-iptables-and-nat-route.html

Add a Custom NAT instance in AWS VPC

In this tutorial, I am assuming that you have already created VPC with Public and Private subnets

modify vpc

In the above scenario, we’ll create a micro instance inside the public subnet with an IP 10.100.10.0/24, which will act as the gateway for all the instance(s) inside the private subnet (10.100.20.0/24).

6

Also, please create the separate Security Group for NAT instance:

7

After the creation of the NAT instance, you will notice, that it doesn’t have Public IP:

10

To Fix this, select the Elastic IPs from the VPC console and click on “Allocate New Addresses“, select the VPCfrom “EIP used in” and click on “Yes,Allocate” :

11

Assign the allocated Elastic IP to the NAT instance:

12

Now, NAT instance has also Public IP:

publicip

From the EC2 console right click on NAT instance and select “Change Source / Dest. Check”:

sd-check

Click on “Yes,Disable

Screen Shot 2014-04-23 at 10.51.21 am

Connect to the NAT instance using terminal emulation software (i.e. putty), and allow the ip forwarding on it:

nat1

Uncomment the following line:

net.ipv4.ip_forward=1

nat2Note: Please reboot the machine after enabling the ip forwarding or run this command “sysctl -p

Issue the Iptables command for MASQUERADE:

iptables -t nat -A POSTROUTING -o eth0 -s 10.100.20.0/24 -j MASQUERADE

nat3Note: Please adjust your Subnet in above iptables command.

Modify the NAT instance security group to allow all or desired inbound traffic from private subnet (In my case, 10.100.20.0/24) or desired server.

sg-1

Create a custom route, associate your private subnet(s) to it and make a default route to use the NAT instance as a gateway:

rt-1

rt-2

Testing from Server inside the Private Subnet:

ifconfig

ping

traceroute_web

Edit the /etc/rc.local file:

vi /etc/rc.local

pnat-1

Add following to the rc.local before “exit 0“, so that, MASQUERADE will automatically enable at boot time:

iptables -t nat -A POSTROUTING -o eth0 -s 10.100.20.0/24 -j MASQUERADE

pnat-2