-----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 <[email protected]> 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 > >>> [email protected] > >>> https://lists.strongswan.org/mailman/listinfo/users > >> >> _______________________________________________ >> Users mailing list >> [email protected] >> 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----- _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
