[strongSwan] separate routes for VPN and Internet traffic: can this form of "split tunneling" be configured in ipsec.conf?
Noel Kuntze
noel at familie-kuntze.de
Sun May 31 21:53:32 CEST 2015
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello Alan,
You need to write a passthrough/bypass
policy for all source and destination combinations
which should not get handled by IPsec.
Might that be non-LAN traffic, but traffic to google, or any other
traffic.
"tunnel doesn't come up" is a very generic error.
What error did you encounter?
What is your complete ipsec.conf?
Also, you always need to specify leftsubnet and rightsubnet in a passthrough/bypass policy!
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 20:59 schrieb Alan Tu:
> 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:
>>
> 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
>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.strongswan.org
>> https://lists.strongswan.org/mailman/listinfo/users
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJVa2a6AAoJEDg5KY9j7GZY6zoP/0NW+rxSwekc3uVtkoayiMRB
yc+Y8ploXykIuzjI4oVMmXPi5VV6r32dVwUJuw59CTxVoCJd2G/J+GwwBjIxZA9Q
7g0o9y9EKYjP7yceVIWaNuuSRd7vNJXcd7nrceNd//TlsSKShZ+pm03EIG0DqXmg
5dDBgExeUPM02kbNH+DEg4bOxNc+0rBj6Ou+1mr7/vpbRlK0zIekvWsgjbpdPe2A
dQr9oai+f8MpCPzmE/qXlWP4KV9nBIvanrARDgWjujQMWE7hJlc9/YNcs5ZRhqu/
/z8jhyUicasQPiv4ngOIiIFRrknTKpWwS1kXgPrzYpFEFVdqB5egowrfI9D8Npfo
Qgq1bf3Pj+fgcKUXOlsGewnQnPIC4SHuv86y1LW2DrmfS340oYeBG1MIhuWuQp3t
TycrS5i/3mcfv96EA08eE0p4/n/We7n962DsFh05alYTXKwNdRoORQS0D32sDTF7
qAlBYTmIU/a/tISXUDT5jRFUrK8/pq+2SWGRlBwdUwtUDLpyVJuM20YMn37PHNWq
gtstqCXbAzc7H7A88U3h2rv8XVL+kFIAsyWPDgubzhlP+a3p/VmqgrJIVl6kqdOa
G9hNIFVNyd8k6yk9qr3p9NUXZasuWCObyr1NCJGHkUSK4TmnCtSOCqpPorREx8fg
BKWr74nlfIfpSNV7EQ/k
=+LOG
-----END PGP SIGNATURE-----
More information about the Users
mailing list