Forwarding and Split-Tunneling

In remote access situations clients will usually send all their traffic to the gateway. Below we explain how this traffic can be forwarded and properly routed back to the roadwarriors.

In some situations it might be more desirable to send only specific traffic via the gateway, for instance, to unburden it from forwarding web or even worse, file sharing traffic. Therefore, we also explain how to enable so-called split-tunneling for different clients.

In order to forward traffic to hosts behind the gateway (or hosts on the Internet if split-tunneling is not used), the following option has to be enabled on Linux gateways

This can be added to /etc/sysctl.conf to enable it permanently.

If the firewall on the gateway is rather restrictive, then

will automatically cause the default _updown script to add rules that allow traffic to be forwarded.

In remote access setups, VPN clients will be assigned a virtual IP address from a configured address pool. The important thing on the gateway side is that all hosts to which the gateway forwards traffic to, have to know that they must route packets to be tunneled back to the remote access clients via the VPN gateway.

Please note that there might be additional considerations when hosting on cloud platforms (e.g. src/dst address checks).

Local firewall stacks generally don’t treat packets with a matching IPsec policy any different from unprotected packets. That means NAT rules also apply to traffic that is supposed to be tunneled.

This often leads to problems, because many hosts have SNAT or MASQUERADE rules set up which change the source IP of the packets, making them not match the negotiated IPsec policies when IPsec processing of outgoing packets happens in the Netfilter packet flow xfrm lookup node. To fix this problem, packets with a matching IPsec policy should skip NAT rules in the POSTROUTING chain of the nat table. This is achieved by inserting a rule that accepts packets with a matching IPsec policy before any NAT rule in the POSTROUTING chain

With split-tunneling the clients will only send traffic for specific destination subnets to the gateway. For both protocol versions split-tunneling is easy to deploy f traffic selectors (TS) can freely be configured on both peers. In that case you’d simply use specific values for the local_ts and remote_ts options.

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 (Path MTU Discovery). You can work around these issues 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 (e.g. 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 options may be used, too, but the values set there apply to the routes that the kernel-netlink plugin 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 is used in the example here):

Alternatively you can add the same rules in PREROUTING and POSTROUTING (also in the mangle table). Additionally set net.ipv4.ip_no_pmtu_disc=1 on the server.

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.