Interoperability

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.

Amazon EC2

The elastic IP and the RFC1918 native IP address

Your AWS instance has a temporary RFC1918 IP address. The Amazon cloud NATs this to your permanent public IP address, called the "elastic IP". This means that technically speaking, the IPsec server "behind NAT". Some Microsoft Windows operating systems need to set the AssumeUDPEncapsulationContextOnSendRul registry value to connect to IPsec servers behind NAT. furthermore, the IP address on the AWs instance is dynamic, so it should not appear in configuration files or else those would need to be updated when the internal IP address of the machine changes after a reboot.

When using IPsec, the kernel needs to create packets with the elastic IP (eg a.b.c.d) as source address for packets to be encrypted, but it can only do this properly if the IP is actually configured on the host. It is recommended to configure the elastic IP as an additional IP on the loopback interface, for example on the amazon stock AMI create /etc/sysconfig/network-scripts/ifcfg-lo:elastic:

DEVICE=lo:elastic
# use your elastic ip here
IPADDR=a.b.c.d
NETMASK=255.255.255.255
ONBOOT=yes
NAME=elasticIP

You can manually add it without restarting using:

ip addr add a.b.c.d/32 dev lo:elastic

ESP packet filter

The Amazon 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 example because this is an IPsec connection between two instances in the Amazon cloud), you can force encapsulation by setting forceencaps=yes.

NAT exclusion

If you are using NAT or MASQUERADE to provide connectivity to a subnet behind your AWS machine, you need to exclude NAT for those source/destination combinations that need to be encrypted via IPsec. For example, if you have 10.0.2.0/24 behind your AWS server and 172.16.0.0/16 as subnet behind the remote IPsec gateway, use iptables rules similar to:

iptables -t nat -I POSTROUTING -s 10.0.2.0/24 -d 172.16.0.0/16 -j RETURN
iptables -t nat -A POSTROUTING -s 10.0.2.0/24 -d 0.0.0.0/0 -j MASQUERADE -o eth0

Example configuration

# /etc/ipsec.conf on Amazon EC2 instance
version 2.0 

config setup
     nat_traversal=yes
     # we should exclude ourselves, but that's dynamic.
     virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:25.0.0.0/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=a.b.c.d
     # remote endpoint IP
     right=1.2.3.4
     # optionally, one or more subnets on either side
     # leftsubnet=10.123.123.0/24
     # rightsubnet=192.0.1.0/24
     # leftsubnets=10.123.123.0/24,10.100.0.0/16
     # rightsubnets=192.0.1.0/24,192.0.2.0/24

# /etc/ipsec.secrets 
# If you have multiple sites with different PSKs, you need to be a bit more subtle here
# We use 0.0.0.0 for our local IP because the instance IP is dynamic and we want to avoid
# hardcoding it into configurations where possible.
193.110.157.131 0.0.0.0 %any: PSK "mysecret" 

Juniper

Juniper Example

Although technically not an interop problem, Ryan Waldron <ryanw@phxx.com> contributed a working Juniper configuration that is compatible with libreswan

Juniper endpoint:

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

There is also another example of configuring Juniper with libreswan by Pedro Kiefer

Juniper shows Bad SPI messages in the Event Log

When libreswan and juniper rekey around the same time, the Juniper can get confused. This bug is triggered especially if you have more than one tunnel defined and are trying to bring up all of them at once. A workaround for this is to increase the ike soft-lifetime-buffer on the Juniper from the default 10 to 40. See also this Juniper Knowledge Base Article

Juniper continuously rekeying

Some have reported a bug in Juniper routers where the IPsec connection is rekeying continuously. This problem is apparently caused by the vpn-monitor option in the firewall policy configuration. Disabling this option stopped the rekeying and resulted in a stable tunnel.