[Swan] Trouble with connection dropping

Paul Wouters paul at nohats.ca
Mon Jun 9 03:44:01 EEST 2014


On Sun, 8 Jun 2014, zip wrote:

> Using libreswan 3.8.1 between two household networks each running Fedora 20

You mean libreswan-3.8-1 ?

> Left's DSL connection must use PPPOE, so its MTU is 8 bytes less than Right's 
> MTU.  In the config below I set the MTU to 1422.  (in the old days this MTU 
> problem caused ssh untold grief, and why I stopped using it).

You might need to use TCP clamping:

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

If that does not help, try hardcoding it yourself:

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

> Back to the problem:
> When I service restart both sides, the VPN starts up fine, both networks can 
> ping / ssh both directions.  Then at some random point in time, Right stops 
> routing traffic through the VPN, but rather goes directly out the public 
> interface; so all ping/ssh traffic originating from Right and its network 
> stops.  However Left can still ping any host in Right including the firewall. 
> ssh however doesn't work in either direction after the failure.

Could it be that this coincides with your DHCP lease getting renewed
(even if it is renewed to the same IP address) ?

> Finding log output is difficult.  From Left's side, I have /var/log/secure 
> logs but there isn't an immediate entry corresponding to when the VPN drops. 
> The log on Right's side... well for what I think is an unrelated problem, 
> /var/log/secure is empty and I've opened a Fedora bug describing:
> https://bugzilla.redhat.com/show_bug.cgi?id=1105828
> so I don't know what's happening on Right's side.  (Seems like problems 
> always happen in two's and three's).

You can use plutostderrlog=/var/log/pluto.log if you get tired of all the
ways rsyslog and systemd interfere with logging....

> ipsec.conf's are below (note for unknown reasons I've had to use slightly 
> different "rightnexthop" statements).

There are some bugs in the nexthop handling we addressed that will be in
libreswan-3.9. (already commited to git master on github)

> config setup
>        protostack=netkey

>        mtu=1422

When the tunnel is up, do you see a route entry with the mtu specified?

I think you might be seeing the DHCP lease issue bug, which has also
been filed already for rhel by Patrick:

https://bugzilla.redhat.com/show_bug.cgi?id=1078593

Paul


More information about the Swan mailing list