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

[Noel Kuntze]

-----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-----