[strongSwan] separate routes for VPN and Internet traffic: can this form of "split tunneling" be configured in ipsec.conf?

Sun May 31 20:59:01 CEST 2015

Hi Noel, I'm trying really hard to learn, please bare with me.
Specifying passthrough for the local network does work, I solved that
problem thanks to your tip. My question is about non-LAN, non-VPN
traffic going to the Internet, such as to Google. The examples don't
seem to cover this, and in fact the Strongswan split tunneling page
states IKE v1 support for specifying one's subnets is, basically, hit
or miss. Nevertheless I do try to learn from the configurations.

Is the idea to use some combination of leftsubnet and rightsubnet in
ipsec.conf? Or, is the idea to modify the XFRM policy (or state)
tables? If the former, I have in fact tried several combinations, none
work [1].

To abbreviate, I'm setting aside the XFRM policies related to local
LAN passthrough. They work.
# ip xfrm policy show
# Policy 1
src 0.0.0.0/0 dst [VPN_virtual_private_IP]/32
	dir fwd priority 2947
	tmpl src [public_VPN_gateway] dst [LAN_IP]
		proto esp reqid 1 mode tunnel

# Policy 2
src 0.0.0.0/0 dst [VPN_virtual_private_IP]/32
	dir in priority 2947
	tmpl src [public_VPN_gateway] dst [LAN_IP]
		proto esp reqid 1 mode tunnel

# Policy 3
src [VPN_virtual_private_IP]/32 dst 0.0.0.0/0
	dir out priority 2947
	tmpl src [LAN_IP] dst [public_VPN_gateway]
		proto esp reqid 1 mode tunnel

Let me focus on policy 3. I think it says any traffic starting with my
VPN private IP (in the 10/8 net), going to anywhere, re-assign it to
the ipsec tunnel with my physical LAN IP and the VPN gateway Internet
IP as the endpoint. This makes sense.

But if I claim that as it stands, all the local -> Internet traffic is
going through the VPN, the only way I can explain that is if the local
-> Internet traffic was already rewritten to source from the VPN
virtual address. That's the only way I can see the local -> Internet
traffic hitting this policy.

If that is the case, would not the routing table modification be
better, to prevent this "rewriting", to avoid hitting this tunnel
policy?

What I think you are telling me is to rewrite XFRM policy 3 so that it
reads something like:
src [VPN_virtual_private_IP]/32 dst [VPN_subnet]/8
	dir out priority 2947
	tmpl src [LAN_IP] dst [public_VPN_gateway]
		proto esp reqid 1 mode tunnel

Is that right?

Alan

Note:
[1] Combinations attempted:
leftsubnet not specified
rightsubnet=0.0.0.0/0
Result: connection works, but Internet traffic is routed through the VPN gateway

leftsubnet not specified
rightsubnet=10.0.0.0/8
Result: tunnel doesn't come up

leftsubnet=10.0.0.0/8
rightsubnet=10.0.0.0/8
Result: tunnel doesn't come up

leftsubnet=172.31.0.0/16
rightsubnet=10.0.0.0/8
Result: tunnel doesn't come up

On 5/31/15, Noel Kuntze <noel at familie-kuntze.de> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hello Alan,
>
> IPsec on Linux nowadays is policy based, not route based.
> You need to write bypass/passthrough policies that define what
> traffic should not be subject to IPsec processing
>
> Look at the test scenarios[1][2] for that to get an idea on
> how to define it.
>
> [1]https://www.strongswan.org/uml/testresults/ikev2/shunt-policies-nat-rw/index.html
> [2]https://www.strongswan.org/uml/testresults/sql/shunt-policies-nat-rw/index.html
>
>
> Mit freundlichen Grüßen/Kind Regards,
> Noel Kuntze
>
> GPG Key ID: 0x63EC6658
> Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
>
> Am 31.05.2015 um 17:08 schrieb Alan Tu:
>> Hello, I'm still new to ipsec VPNs and Strongswan, and I'd like to run
>> the scenario by the group, with potentially a feature suggestion.
>>
>> I'm trying to implement what seems to be called split tunneling,
>> without the cooperation or configuration of the remote VPN gateway.
>>
>> I'm a road warrior connecting to a VPN over the Internet, with the
>> following pertinent configuration settings:
>> conn vpn
>>     type=tunnel
>>     keyexchange=ikev1
>>     aggressive=yes
>>     left=%any
>>     leftsourceip=%modeconfig
>>     right=[public IP VPN gateway]
>>     rightsubnet=0.0.0.0/0
>>
>> Other users using proprietary VPN clients or VPNC still have their
>> non-VPN-LAN traffic (browsing, etc) routed over the users' local WAN,
>> but I noticed all of my Internet traffic was going through the VPN.
>> According to the Strongswan split tunneling page [1], IKE v1 doesn't
>> easily support split tunneling. But after reading and thinking, I
>> realized altering the routing table might achieve the effect I want.
>>
>> Post-VPN routing table 220:
>> $ ip route show table 220
>> default via [WAN gateway IP] dev eth0  proto static  src [VPN virtual
>> private IP]
>>
>> So I did:
>> # ip route add table 220 [VPN subnet] via [WAN gateway IP] dev eth0
>> proto static src [VPN virtual private IP]
>>
>> This told the kernel, I hoped, to direct traffic going to the VPN
>> subnet to the ipsec tunnel. XFRM policies and states would then take
>> over.
>>
>> Next, I wanted to change the default route so that non-VPN traffic
>> would go through the local WAN/Internet connection:
>> # ip route change table 220 default via [WAN gateway IP] src [original
>> eth0 IP]
>>
>> And so far, things seem to work the way I intend. I can still access
>> the VPN subnet, but connections going to the Internet originate from
>> my original network connection's address.
>>
>> Am I missing anything? And if this is a valid scenario, is there any
>> way I can set this up more intuitively in ipsec.conf? And if not, I'm
>> wondering if it might be beneficial to have the capability to
>> configure a connection like this in ipsec.conf. Most of the variables
>> are more easily available to the Strongswan daemon when a connection
>> is brought up, and it would seemingly give users an easy way to
>> configure a form of "split tunneling".
>>
>> Alan
>>
>> Note:
>> [1]
>> https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling
>> _______________________________________________
>> Users mailing list
>> Users at lists.strongswan.org
>> https://lists.strongswan.org/mailman/listinfo/users
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJVaylNAAoJEDg5KY9j7GZY0IUP/2ZP4DFpcnfvQoc34bEljOmW
> fWloeuL9uHv26F0MpSKIJWBLh8W5q4crAAuRPOha8ONPwUmphDyRz/2aIzwkp1F/
> MiA5XSf4kBALelZvZ3k+q6b/vwu91kmu7DbSWbtArDzAbRyeAPHND8KGBjZL6UVj
> E0A2mo0aGSVuLSp54yE87rJSyHsu8TnWA1Ljnoga5DE063/yExHszt4tRletITE8
> O9Jj3Q0640WXuRy3XRKaUvIZTOlK8e7G2T0Ay8s3PEpGbqI6bitIAWXtM5qS/1Ma
> 6o+mNg2o9uHNqI9mlmue7qBdK6fNZ/Q+LMfshBj30DpT14RG0Moj8+r3shSwy8tM
> Cnw3/Dx/wHjGuEq/pcalljISbM0D4593S+bbw2dGRBqJ6uYI5awrtRpjSAb/dvEh
> WLmvcEAptf6hhdW641/c572XFJigxQWEEBUwmkblPiDnqQoBHA0mtqMCvRqtsVYW
> Pbw2kFPgJTCadKhC/KktYrBNhd2gfHnr9/b8G1hdGZSSQQZY+yMqYIvIJiO7GFSJ
> qdbyJA8XCddIm5yjwMutLx6jrxTALFuPTFdDt4tYfxf+Kr0RmlVoAedRpqMOh8Yw
> CC8Vp4QM16PjmPk3OKttOqCgqNZwIUsZUq4qg+BVClvzjlCwO8z9jPDLPjSuYqfq
> PMSLTnkar4sKvxVeIaR7
> =SqZC
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users