On 06/08/2014 07:44 PM, Paul Wouters wrote:
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
Paul,
Thanks for the reply.
Yes I'm using libreswan-3.8-1.fc20.i686 on the box with the problem.
WIth the tunnel up and working, my route output looks like: (the right host)
[root@windward ~]# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
default 66.43.233.126 0.0.0.0 UG 1024 0 0 enp0s4
10.20.0.0 66.43.233.126 255.255.255.0 UG 0 0 0 enp0s4
10.20.1.0 0.0.0.0 255.255.255.0 U 0 0 0 p9p1
10.20.128.0 0.0.0.0 255.255.255.0 U 0 0 0 p9p1
66.43.233.0 0.0.0.0 255.255.255.128 U 0 0 0 enp0s4
dhcp.netins.net 66.43.233.126 255.255.255.255 UGH 1 0 0 enp0s4
But Trace path shows the MTU is correct:
tracepath -n 10.20.0.1
1?: [LOCALHOST] pmtu 1500
1?: [LOCALHOST] pmtu 1422
1: 10.20.0.1 130.652ms reached
1: 10.20.0.1 139.447ms reached
As for the clamp MTU, I'm using the Shorewall config line:
CLAMPMSS=Yes
Which is adding a rule of this:
iptables-save|grep -i clamp
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -m policy --dir out
--pol none -j TCPMSS --clamp-mss-to-pmtu
At this point, I believe the MTU issue is just a relic of the past.
I found the logging directive, but didn't find any interesting content
in it when the connection drops.
Your point about DHCP could definately be the problem. The Right
(problem) host is DHCP driven, even tho the it never changes. I found
the lease file, its dhcp-lease-time = 21600 (6 hrs). I signed up to get
cc's of that bug report.
Thanks,
Brian
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
