FAQ: Difference between revisions

From Libreswan
Jump to navigation Jump to search
(MTU FAQ)
No edit summary
Line 47: Line 47:


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''.
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''.
== When using hundreds of tunnels on a xen based cloud system like AWS, a fraction of tunnels fail regularly ==
This is a [https://bugzilla.redhat.com/show_bug.cgi?id=1085025 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.

Revision as of 21:49, 9 May 2014

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:

Not supported

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.

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.