Although IKE and IPsec are IETF standards, there are often still interoperability issues between different vendors. Below we list known issues with certain vendors, as well as known networking issues of services and cloud providers.
The Amazon cloud has two interoperability concerns. The first issue is that your instance has a temporary RFC1918 IP address. The Amazon cloud NATs this to your permanent public IP address, called "elastic IP". This means that technically speaking, the IPsec server "behind NAT". Some Microsoft Windows operating systems need to set the AssumeUDPEncapsulationContextOnSendRul registry value. When using IPsec, In some configurations, Linux needs to use the elastic IP as source address for packets to be encrypted, but it can only do this properly if the IP is actually configured on the host. In such cases, configure the elastic IP on the loopback device:
ip addr add 220.127.116.11/32 dev lo
The second issue at Amazon is that their internal cloud network does not route IPsec ESP or AH packets. These packets need to be encapsulated in UDP. While normally the NAT detection takes care of this ESPinUDP encapsulation, if NAT is not detected (for instance because this is an IPsec connection between two instances in the Amazon cloud), you can force encapsulation by setting forceencaps=yes.
Below is an example ipsec.conf file for use in the Amazon EC2 cloud
# /etc/ipsec.conf on Amazon EC2 instance version 2.0 config setup nat_traversal=yes # we should exclude ourselves, but that's dynamic. # The other end should not be behind NAT anyway. If it is via port forward, avoid 10/8 that Amazon uses virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:18.104.22.168/8,%v4:100.64.0.0/10,%v6:fd00: :/8,%v6:fe80::/10 protostack=netkey conn amazonec2 # preshared key authby=secret # load connection and initiate it on startup auto=start # Amazon does not route ESP/AH packets, so these must be encapsulated in UDP forceencaps=yes # use %defaultroute to find our local IP, since it is dynamic left=%defaultroute # set our ID to your (static) elastic IP leftid=22.214.171.124 # set the desired source IP to the Elastic IP. Libreswan will create interface address and route. # Configure the elastic IP on loopback, eg: ip addr add 126.96.36.199/32 dev lo leftsourceip=188.8.131.52 # remote endpoint IP right=184.108.40.206
Although technically not an interop problem, Ryan Waldron <email@example.com> contributed a working Juniper configuration that is compatible with libreswan
set ike gateway "GW-01" address <Your SM IP Here> Main outgoing-zone "V1-Untrust" preshare "Your PSK Here" proposal "pre-g2-3des-md5" set ike respond-bad-spi 1 set ike ikev2 ike-sa-soft-lifetime 60 unset ike ikeid-enumeration unset ike dos-protection unset ipsec access-session enable set ipsec access-session maximum 5000 set ipsec access-session upper-threshold 0 set ipsec access-session lower-threshold 0 set ipsec access-session dead-p2-sa-timeout 0 unset ipsec access-session log-error unset ipsec access-session info-exch-connected unset ipsec access-session use-error-log set vpn "VPN-01" gateway "GW-01" no-replay tunnel idletime 0 proposal "g2-esp-3des-md5" set vrouter "untrust-vr" exit set vrouter "trust-vr" exit set url protocol websense exit set policy id 58 from "V1-Trust" to "V1-Untrust" "10.10.0.0/24" "172.16.0.0/16-VPN-01" "ANY" tunnel vpn "VPN-01" id 0x23 pair-policy 57 log set policy id 58 set log session-init exit set policy id 57 from "V1-Untrust" to "V1-Trust" "172.16.0.0/16-VPN-01" "10.10.0.0/24" "ANY" tunnel vpn "VPN-01" id 0x23 pair-policy 58 log set policy id 57 set log session-init exit
And the corresponding libreswan endpoint:
conn NetScreen ike=3des-md5 esp=3des-md5 authby=secret keyingtries=0 left=<Juniper IP Here> leftsubnet=<Remote Subnet Here> leftnexthop=%defaultroute right=<SW IP Here> rightsubnet=<Local Subnet Here> rightnexthop=%defaultroute compress=no auto=start