I have a setup that I cannot make work reliably. I had one client machine working perfectly all day, while others were not. Then, the first one just stopped working later.
Namely, I would like to have Windows 10 roadwarriors connect in via IPSec, and from there connect to devices on the far side of another IPSec tunnel. The roadwarrior subnet is set to be a subset of the Green interface, such that green is 10.1.0.0/24 and the roadwarrior subnet is 10.1.0.240/28 ( I have also tried using a completely different RW subnet).
I have tried this with both Split Tunneling and when sending all traffic over the tunnel, and I am occasionally able to make it work when sending all traffic over the tunnel, but it is not reliable, and it is currently not working as-is.
I can make this work with a MacOS client, currently, with a roadwarrior subnet that is distinct from the green subnet, and by placing that subnet in the TS for the IPSec tunnels, but Windows doesn’t play along. Moreover, setting up the tunnels with the RW subnet in the local/remote subnet fields also seems to make the tunnels far less stable. I have to periodically force the tunnel down for traffic to flow.
I did find this bit on the StrongSwan site here. Does anyone have anty thoughts as to whether this might have something to do with why this sort of setup seems to work sometimes, but not others? I’m looking at you, @ms…):
MTU/MSS issues
It is possible that you encounter MSS/MTU problems when tunneling traffic. This is caused by broken routers dropping
ICMP packets and thus breaking PMTUD. You can work around it by lowering the advertised MSS value of TCP with the TCPMSS
target in iptables.
Or, if you control the router in question, fixing PMTU may be advisable – to do so you need to permit the appropriate ICMP
traffic (type 3, destination unreachable, code 4, fragmentation needed - though all of type 3 is usually allowed.)
In particular, one must pay attention to the source address of ICMP messages emitted by the VPN gateway, which will usually be
the primary IP address of the gateway’s internal interface, not that of the endpoint experiencing the issue.
The value you set with the TCPMSS target must accommodate for any other overhead introduced by the tunneling protocols
in use (for instance, UDP encapsulation of ESP).
Google the issue and read the man page of iptables and iptables-extensions if there are any questions about its usage.
The charon.plugins.kernel-netlink.mss and charon.plugins.kernel-netlink.mtu may be used, too, but the values set there apply
to the routes that kernel-netlink installs and the impact of them onto the traffic and the behavior of the kernel is currently quite unclear.
Add the following iptables rules on the IKE responder to reduce the MSS (as noted above, the actual values depend on the overhead
imposed by the tunneling protocols and the MTU, so it might have to be lower than what’s used in the example here):
iptables -t mangle -A FORWARD -m policy --pol ipsec --dir in -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360 iptables -t mangle -A FORWARD -m policy --pol ipsec --dir out -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360
Alternatively, you can add the same rules in PREROUTING/POSTROUTING (also in the mangle table).
Additionally, set net.ipv4.ip_no_pmtu_disc on the server to 1.
In newer kernels, the counter XfrmOutStateModeError in /proc/self/net/xfrm_stat is incremented if the kernel detects that a packet would be too large after encapsulation.
The bigger picture is, that the current IPsec stack is not suited for RW connections with Windows, Mac OS X, and so on. I have developed a patchset a long time ago which should fix that. Unfortunately it has been rotting on the mailing list and did not get a single review:
It changes various things and generates Apple configuration profiles that can be imported into iOS (I didn’t test OS X, but that should be possible, too) and the VPN will be up within seconds.
I did not encounter any MTU issues while testing this. Since IPsec is part of IP, fragmentation works different to for example OpenVPN.