FAQ

FAQ

( we will sort this in categories once we have more )

Which IKE Exchange modes does libreswan support?

The IANA Registry lists all official Exchange Modes. There are a few IKEv1 Modes that are very common despite never gotten past the draft stage.

Supported:

• IKEv2 (PSK, raw RSA, X509)
• IKEv1 Main Mode (PSK, raw RSA, X509)
• IKEv1 Aggressive Mode (PSK, raw RSA, X509)
• IKEv1 XAUTH/RSA and XAUTH/PSK with ModeConfig (aka "Cisco IPsec mode")

Not supported

• IKEv2 CP mode (planned, not yet implemented)
• IKEv1 Revised Mode
• IKEv1 Hybrid Mode (aka "Mutual Group Authentication") although there is some unmaintained contributed code

Should I use the NETKEY or KLIPS IPsec stack with libreswan?

At this point we recommend using the NETKEY stack for most deployments. If you are using an embedded platform with a cryptographic hardware offload device, it might be better to use KLIPS.

The NETKEY IPsec stack requires no kernel recompiles on most Linux distributions, so it is the easiest stack to use in most standard deployments. It offers a larger selection of cryptographic algorithm support, including the IPsec Suite B algorithms AES CTR, AES GCM and SHA2. It does cause a little additional delay with on-demand IPsec tunnels because it does not implement first+last packet caching. NETKEY supports OCF only using the cryptosoft driver, and is lacking native driver support for most cryptographic hardware cards. NETKEY also does not distribute the load of a single IPsec SA over different CPU's. NETKEY has support for Linux VTI for IPsec SA reference tracking.

The KLIPS IPsec stack offers easier debugging with tcpdump and easier iptables firewall rules due to its use of separate ipsecX interfaces. It also plays a little nicer with on-demand tunneling as it will hold on the first+last packet sent while the tunnel is being setup, and will release those packets once the IPsec tunnel is established. KLIPS distributes the load of a single IPsec SA over multiple CPU's. It supports all OCF hardware devices when compiled with OCF support. The MAST variant of KLIPS use IPsec SAref for IPsec SA reference tracking and is also used for L2TP/IPsec deployments requiring SAref tracking. Although it is recommended to use VPN_server_for_remote_clients_using_IKEv1_XAUTH instead of L2TP/IPsec.

Is Libreswan vulnerable to the OpenSSL "Heartbleed" exploit?

No, see Libreswan_and_Heartbleed

Module unloading error on shutdown or restart: Module esp4 is in use

ERROR: Module xfrm4_mode_tunnel is in use
ERROR: Module esp4 is in use
FAILURE to unload NETKEY esp4/esp6 module

This has been fixed in libreswan-3.9. Please upgrade

My ssh sessions hang or connectivity is very slow

This could be an MTU issue. The overhead of IPsec encryption (and possibly ESPinUDP encapsulation) yields a slightly smaller packet size. This can cause problems. A good way to confirm MTU problems is if you can login remotely over the IPsec tunnel using ssh, but issuing "ls -l /usr" causes the session to hang. Try adjusting the MTU with:

iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS  --clamp-mss-to-pmtu

If that does not help, try hardcoded it yourself:

iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1460

As a last case alternative, you can try lowering the MTU on the internal interface of your IPsec server so that the PMTU discovery locally already goes back to 1460, eg using ifconfig eth1 mtu 1460.

ERROR: asynchronous network error report on eth0 (sport=4500) for message to xx.xx.xxx.xxx port 4500, complainant yy.yy.yyy.yyy: Message too long [errno 90, origin ICMP type 3 code 4 (not authenticated)]

These errors are often intermittent, it depends on your application data that is getting encrypted. Your NAT'ed IPsec tunnel is using ESPinUDP, and the additional UDP header caused some of your packets to be too big. See the previous answer and try lowing your mtu. Use an insanely small mtu like 1300 or 1200 for confirmation. Then try to bring it up higher to what seems to work reliably for you.

ERROR: asynchronous network error report on eth0 (sport=4500) for message to xx.xx.xxx.xxx port 4500, complainant yy.yy.yyy.yyy: No route to host [errno 113, origin ICMP type 3 code 1(not authenticated)]

These errors often happen 15 minutes after the tunnel successfully established. It's most likely that the tunnel was idle and the NAT router removed the nat mapping. Or the NAT router rebooted and lost state. It no longer knows which client to send the packet to. Ensure your connection uses nat-keepalive=yes. Possibly decrease the global keep-alive= value to send more frequent keep-alive packets. Alternatively, enable DPD on the connection to cause some regular traffic on idle tunnels.

When using hundreds of tunnels on a xen based cloud system like AWS, a fraction of tunnels fail regularly

This is a known issue that could be a problem of the aesni kernel module in combination with the xen hypervisor. Try unloading the aesni.ko kernel module on the xen server. If you can confirm this fixes your issue (we cannot change the AWS servers), please email the swan-dev list with a confirmation.

My XAUTH authentication via PAM always claims the password is incorrect on centos6

This is an odd bug (feature?) that shows up when you have disabled selinux in /etc/sysconfig/selinux. Running selinux in permissive (or enforcing) mode seems to resolve this.