View Sidebar

Post Tagged with: ipsec

IPSEC S2S VPN via AWS Openswan and Cisco IPSEC Router

IPSEC S2S VPN via AWS Openswan and Cisco IPSEC Router

I was asked to assist on setting up a Site-to-Site (S2S) VPN between an Amazon Web Service AC2 environment and a Cisco IPSEC router.  Instead of working on the customer’s production environment, I decided to setup my Cisco 2821 router as an IPSEC endpoint and try to do it from home.  There is a fair amount of instructions on the internet on how to do this.  But, it seems no matter what I tried, I wasn’t able to get it to work.  The biggest hurdle was the fact that my Cisco IPSEC router was behind a NATing firewall.  Please note, the IP addresses have been changed on my example to some randoms.

I relied heavily on this post titled CONNECTING TO A CISCO ASA VPN VIA AMAZON EC2/VPC to get the basis on how to do this.  It took me about two days to get everything the way I wanted it, so I’m going to tackle the instructions on my own as well.

Here is a quick and dirty diagram:

IPSEC-EC2

Start a Amazon VPC Instance

  1. Go to the VPC tab.
  2. I chose a Ubuntu 64 Bit AMD64 server, micro instance.
  3. Click Network & Security –> Elastic IPs
  4. Allocate New Address, associate the new address to the new micro instance.
  5. I didn’t setup the Amazon firewall initially.
  6. Test SSH into your instance, you should get a UNIX prompt.

Before you begin installing and configuring your Cisco device or Openswan, you need to gather some information:

EC2 Side

Private IP: 10.96.42.55
Elastic IP: 54.235.135.80

Home Side

Private Network: 1.1.1.0/24
Router Public IP: 192.168.1.5
Firewall Public IP: 71.162.211.111

Install and Configure Openswan

  • From the command prompt, run sudo apt-get install openswan openswan-doc ipsec-tools
  • Edit /etc/sysctl.conf:

net.ipv4.ip_forward = 1

  • Run sudo ipsec verify (note any issues)
  • Edit /etc/ipsec.conf

nat_traversal=yes

protostack=netkey

include /etc/ipsec.d/*.conf

  • Run sudo ipsec verify (all issues should be resolved or have N/A,WARNING)
  • Run sudo service ipsec restart

 

Edit /etc/ipsec.d/home.conf (new file)

conn home

left=%defaultroute
leftsubnet=10.96.42.55/32
leftid=54.235.135.80
right=71.162.211.111
rightid=192.168.1.5
rightsubnet=1.1.1.0/24
authby=secret
ike=3des-md5
esp=3des-md5
keyexchange=ike
auto=start

Edit /etc/ipsec.d/home.secrets (new file)

192.168.1.5 54.235.135.80 : PSK “cisco123”

 

Configure the Cisco Router

crypto isakmp policy 10
 encr 3des
 hash md5
 authentication pre-share
 group 5
 lifetime 3600
crypto isakmp key cisco123 address 54.235.135.80
crypto ipsec security-association lifetime seconds 28800
crypto ipsec transform-set AMAZON-TRANSFORM-SET esp-3des esp-md5-hmac
crypto map INTERNET-CRYPTO 11 ipsec-isakmp
 description Amazon EC2 instance
 set peer 54.235.135.80
 set transform-set AMAZON-TRANSFORM-SET
 match address 111
interface GigabitEthernet0/0
 ip address 192.168.1.5 255.255.255.0
 no ip route-cache cef
 no ip route-cache
 duplex auto
 speed auto
 crypto map INTERNET-CRYPTO
interface GigabitEthernet0/1
 ip address 1.1.1.1 255.255.255.0
 duplex auto
 speed auto
ip route 0.0.0.0 0.0.0.0 192.168.1.1
access-list 111 permit ip 1.1.1.0 0.0.0.255 host 10.96.42.55

 

Important Notes:

  • I setup my home router/firewall to create the 192.168.1.5 IP address as a DMZ.  This means that I didn’t need to setup any type of port forwarding or firewall rules, it was forwarding all traffic from my external IP address to the internal IP address.  Your mileage may vary.
  • Note the “right” and “rightid” calls in the home.conf file.  right=external IP at home, rightid=actual Cisco router IP. This is important.  Because I was behind a NATing firewall, these settings came into play.  IPSEC doesn’t play very well in NAT and even though I was using NAT-traversal, those settings were key.
  • This was just a simple IP to network test.  You’ll need to modify the ACLs as appropriate to access your devices.
  • I had a devil of a time matching the isakmp policies and transform-set settings on the Cisco with the Openswan.  Both platforms use different terms for the same thing.  Some commands to know and love:
    • Openswan — sudo ipsec auto –status
    • Openswan — sudo ipsec whack –status
    • Ubuntu Logs — /var/log/auth.log
    • Cisco — debug crypto isakmp
    • Cisco — debug crypto ipsec
    • Cisco — debug crypto isakmp error
    • Cisco — debug crypto ipsec error

 

 

Cisco Router to Checkpoint FW-1 — IPSEC VPN Headaches with Supernetting

Cisco Router to Checkpoint FW-1 — IPSEC VPN Headaches with Supernetting

I setup quite a few IPSEC site-to-site VPNs.  Hundreds maybe.  Most go fine.  10 minutes on the line, bing, bam boom, we have a working IPSEC tunnel.

My company uses Cisco router/ASRs for our termination points for IPSEC VPNs.  We also have Checkpoint firewalls doing the filtering.  Why the separation?  Because we love a good headache.

My biggest headache comes from when a third party is using a Checkpoint firewall as the VPN termination point and I am using my Cisco router.  Checkpoint firewalls, often by default, will super-net the encryption domain.  So, I might be using a /32 host ACL on my Cisco, the Checkpoint is sending a /24 or larger ACL.  This does not play well in Cisco land and Phase 2 usually fails.

The hard part with this is figuring out this is happening, because it’s not obvious.  What I have found is turning on a single debug command makes all the difference in the world.

debug crypto ipsec

This shows all kinds of nasty IPSEC messages when a tunnel is negotiating.  You try finding the error on a box that has 75 tunnels terminating on it.  It is not easy! But, as the debug messages are scrolling by, one little entry can give you all the help you need:

Feb 1 17:20:39: Crypto mapdb : proxy_match
src addr : 142.184.211.75
dst addr : 121.98.112.0/25
protocol : 0
src port : 0
dst port : 0

On this particular tunnel (IPs changed to protect the innocent) the third party was supposed to be NATing behind a /32 address on the 121.98.112.0 network.  But, his Checkpoint box was super-netting behind the /25 network.  Bad Checkpoint.

I was able to pick it up from that debug message and let him know to change his config.  Five minutes later, IPSEC tunnel was up, Phase 1 and Phase 2 setup and communication was clean.