-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello Alan,
I can't figure out your problem, because your description does not fit the current state of your ipsec.conf. Did you delete leftsubnet=10.0.0.0/8 before changing rightsubnet to 10.0.0.0/8? Mit freundlichen Grüßen/Kind Regards, Noel Kuntze GPG Key ID: 0x63EC6658 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 Am 01.06.2015 um 01:45 schrieb Alan Tu: > Hi Noel, I fixed the ike and esp lines in ipsec.conf [1]. Specifying > rightsubnet=10.0.0.0/8, I think that was the suggestion, failed to > bring up the VPN tunnel. Changing that one line from > rightsubnet=10.0.0.0/8 (the line, I think, makes sense to you and me) > to rightsubnet=0.0.0.0/0 brought up the VPN where all traffic is > tunneled over. > > I'll pass the PSK comment on (I agree), I don't run the other end. In > fact its vendor software, said vendor has released a Strongswan > configuration on their website with the typo you mentioned. > > Alan > > [1] > conn %default > ikelifetime=20 > reauth=yes > rekey=yes > keylife=10m > rekeymargin=3m > rekeyfuzz=0% > keyingtries=1 > type=tunnel > > conn vpn > keyexchange=ikev1 > ikelifetime=1440m > keylife=60m > aggressive=yes > ike=aes-sha1-modp1024 > esp=aes-sha1 > xauth=client > left=%any > leftid=keyid:[redacted] > leftsourceip=%modeconfig > leftauth=psk > rightauth=psk > leftauth2=xauth > right=[redacted] > rightsubnet=10.0.0.0/8 > xauth_identity=[redacted] > auto=add > > conn lan > leftsubnet=172.31.0.0/16 > rightsubnet=172.31.0.0/16 > authby=never > type=passthrough > auto=route > > > On 5/31/15, Noel Kuntze <[email protected]> wrote: >> > Hello Alan, > > Your configuration makes no sense. > You request configuration options (dns servers, IP address) > from the remote peer, but you then you override the sensical > traffic selector of $virtualIP == 10.0.0.0/8 > with a nonsensical traffic selector of > 10.0.0.0/8 == 10.0.0.0/8. > Remove leftsubnet and I figure it will work. > Furthermore, your configuration for the IKE and ESP ciphers is > wrong. > Read the man page for ipsec.conf for a correct format of those lines. > > Furthermore, IKev1 in aggressive mode with PSK authentication is a > horrible idea, as it allows an attacker to perform an offline dictionary > attack on the PSK! > You are strongly encouraged to switch to a safer combination. > > 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 23:39 schrieb Alan Tu: > >>> Noel, Starting from a working tunnel, the only remaining issue was to > >>> not send Internet packets to the VPN. You state I need to write > >>> passthrough connections for all combinations of IP addresses that I > >>> don't want to route to the VPN. Those combinations are literally > >>> everything, except destination 10/8. I would rather write the one > >>> combination that I do want to route to the VPN. > >>> > >>> I just don't know how to do that, besides modifying routing table 220. > >>> I said I tried different combinations of leftsubnet and rightsubnet. > >>> Eventually the daemon reports > >>> establishing connection 'vpn' failed > >>> > >>> Here is my ipsec.conf file [1], basically I specify leftsubnet and > >>> rightsubnet to be the VPN subnet, 10/8. This version of ipsec.conf > >>> fails, here are the syslog messages [2]. > >>> > >>> Alan > >>> > >>> [1] ipsec.conf > >>> conn %default > >>> ikelifetime=20 > >>> reauth=yes > >>> rekey=yes > >>> keylife=10m > >>> rekeymargin=3m > >>> rekeyfuzz=0% > >>> keyingtries=1 > >>> type=tunnel > >>> > >>> conn vpn > >>> keyexchange=ikev1 > >>> ikelifetime=1440m > >>> keylife=60m > >>> aggressive=yes > >>> ike=aes-sha1-modp1024,aes256 > >>> esp=aes-sha1 > >>> xauth=client > >>> left=%any > >>> leftid=keyid:[redacted] > >>> leftsourceip=%modeconfig > >>> leftauth=psk > >>> rightauth=psk > >>> leftauth2=xauth > >>> right=[redacted gateway public IP] > >>> leftsubnet=10.0.0.0/8 > >>> rightsubnet=10.0.0.0/8 > >>> xauth_identity=[redacted] > >>> auto=add > >>> > >>> conn lan > >>> leftsubnet=172.31.0.0/16 > >>> rightsubnet=172.31.0.0/16 > >>> authby=never > >>> type=passthrough > >>> auto=route > >>> > >>> [2] syslog: > >>> May 31 20:46:24 ip-172-31-37-117 charon: 10[CFG] received stroke: add > >>> connection 'corporate' > >>> May 31 20:46:24 ip-172-31-37-117 charon: 10[CFG] left nor right host > >>> is our side, assuming left=local > >>> May 31 20:46:24 ip-172-31-37-117 charon: 10[CFG] added configuration > >>> 'corporate' > >>> May 31 20:46:24 ip-172-31-37-117 charon: 05[CFG] received stroke: add > >>> connection 'lan' > >>> May 31 20:46:24 ip-172-31-37-117 charon: 05[CFG] left nor right host > >>> is our side, assuming left=local > >>> May 31 20:46:24 ip-172-31-37-117 charon: 05[CFG] added configuration > >>> 'lan' > >>> May 31 20:46:24 ip-172-31-37-117 charon: 13[CFG] received stroke: route > >>> 'lan' > >>> May 31 20:46:30 ip-172-31-37-117 cloud-init[964]: Starting strongSwan > >>> 5.3.0 IPsec [starter]... > >>> May 31 20:51:10 ip-172-31-37-117 charon: 04[CFG] received stroke: > >>> initiate 'corporate' > >>> May 31 20:51:10 ip-172-31-37-117 charon: 03[IKE] initiating Aggressive > >>> Mode IKE_SA corporate[1] to [VPN public gateway] > >>> May 31 20:51:10 ip-172-31-37-117 charon: 03[ENC] generating AGGRESSIVE > >>> request 0 [ SA KE No ID V V V V ] > >>> May 31 20:51:10 ip-172-31-37-117 charon: 03[NET] sending packet: from > >>> 172.31.50.238[500] to [VPN public gateway][500] (416 bytes) > >>> May 31 20:51:10 ip-172-31-37-117 charon: 02[NET] received packet: from > >>> [VPN public gateway][500] to 172.31.50.238[500] (396 bytes) > >>> May 31 20:51:10 ip-172-31-37-117 charon: 02[ENC] parsed AGGRESSIVE > >>> response 0 [ SA KE No ID HASH V V NAT-D NAT-D V V ] > >>> May 31 20:51:10 ip-172-31-37-117 charon: 02[IKE] received XAuth vendor ID > >>> May 31 20:51:10 ip-172-31-37-117 charon: 02[IKE] received NAT-T (RFC > >>> 3947) vendor ID > >>> May 31 20:51:10 ip-172-31-37-117 charon: 02[IKE] received DPD vendor ID > >>> May 31 20:51:10 ip-172-31-37-117 charon: 02[ENC] received unknown > >>> vendor ID: a9:b9:b1:03:4f:7e:50:a2:51:3b:47:b1:00:bb:85:a9 > >>> May 31 20:51:10 ip-172-31-37-117 charon: 02[IKE] local host is behind > >>> NAT, sending keep alives > >>> May 31 20:51:10 ip-172-31-37-117 charon: 02[ENC] generating AGGRESSIVE > >>> request 0 [ NAT-D NAT-D HASH ] > >>> May 31 20:51:10 ip-172-31-37-117 charon: 02[NET] sending packet: from > >>> 172.31.50.238[4500] to [VPN public gateway][4500] (108 bytes) > >>> May 31 20:51:11 ip-172-31-37-117 charon: 01[NET] received packet: from > >>> [VPN public gateway][4500] to 172.31.50.238[4500] (76 bytes) > >>> May 31 20:51:11 ip-172-31-37-117 charon: 01[ENC] parsed TRANSACTION > >>> request 1621027542 [ HASH CPRQ(X_TYPE X_USER X_PWD) ] > >>> May 31 20:51:11 ip-172-31-37-117 charon: 01[ENC] generating > >>> TRANSACTION response 1621027542 [ HASH CPRP(X_USER X_PWD) ] > >>> May 31 20:51:11 ip-172-31-37-117 charon: 01[NET] sending packet: from > >>> 172.31.50.238[4500] to [VPN public gateway][4500] (108 bytes) > >>> May 31 20:51:19 ip-172-31-37-117 charon: 10[NET] received packet: from > >>> [VPN public gateway][4500] to 172.31.50.238[4500] (76 bytes) > >>> May 31 20:51:19 ip-172-31-37-117 charon: 10[ENC] parsed TRANSACTION > >>> request 582705483 [ HASH CPS(X_STATUS) ] > >>> May 31 20:51:19 ip-172-31-37-117 charon: 10[IKE] XAuth authentication > >>> of 'user' (myself) successful > >>> May 31 20:51:19 ip-172-31-37-117 charon: 10[IKE] IKE_SA corporate[1] > >>> established between 172.31.50.238[cs-users]...[VPN public > >>> gateway][[VPN public gateway]] > >>> May 31 20:51:19 ip-172-31-37-117 charon: 10[IKE] scheduling > >>> reauthentication in 86220s > >>> May 31 20:51:19 ip-172-31-37-117 charon: 10[IKE] maximum IKE_SA lifetime > >>> 86400s > >>> May 31 20:51:19 ip-172-31-37-117 charon: 10[ENC] generating > >>> TRANSACTION response 582705483 [ HASH CPA(X_STATUS) ] > >>> May 31 20:51:19 ip-172-31-37-117 charon: 10[NET] sending packet: from > >>> 172.31.50.238[4500] to [VPN public gateway][4500] (76 bytes) > >>> May 31 20:51:19 ip-172-31-37-117 charon: 10[ENC] generating > >>> TRANSACTION request 1981149928 [ HASH CPRQ(ADDR DNS) ] > >>> May 31 20:51:19 ip-172-31-37-117 charon: 10[NET] sending packet: from > >>> 172.31.50.238[4500] to [VPN public gateway][4500] (76 bytes) > >>> May 31 20:51:19 ip-172-31-37-117 charon: 12[NET] received packet: from > >>> [VPN public gateway][4500] to 172.31.50.238[4500] (92 bytes) > >>> May 31 20:51:19 ip-172-31-37-117 charon: 12[ENC] parsed TRANSACTION > >>> response 1981149928 [ HASH CPRP(ADDR DNS DNS) ] > >>> May 31 20:51:19 ip-172-31-37-117 charon: 12[IKE] installing DNS server > >>> 10.100.15.5 via resolvconf > >>> May 31 20:51:19 ip-172-31-37-117 charon: 12[IKE] installing DNS server > >>> 10.100.24.250 via resolvconf > >>> May 31 20:51:19 ip-172-31-37-117 charon: 12[IKE] installing new > >>> virtual IP 10.100.4.69 > >>> May 31 20:51:19 ip-172-31-37-117 charon: 12[ENC] generating QUICK_MODE > >>> request 2857000903 [ HASH SA No ID ID ] > >>> May 31 20:51:19 ip-172-31-37-117 charon: 12[NET] sending packet: from > >>> 172.31.50.238[4500] to [VPN public gateway][4500] (204 bytes) > >>> May 31 20:51:23 ip-172-31-37-117 charon: 16[IKE] sending retransmit 1 > >>> of request message ID 2857000903, seq 4 > >>> May 31 20:51:23 ip-172-31-37-117 charon: 16[NET] sending packet: from > >>> 172.31.50.238[4500] to [VPN public gateway][4500] (204 bytes) > >>> May 31 20:51:30 ip-172-31-37-117 charon: 03[IKE] sending retransmit 2 > >>> of request message ID 2857000903, seq 4 > >>> May 31 20:51:30 ip-172-31-37-117 charon: 03[NET] sending packet: from > >>> 172.31.50.238[4500] to [VPN public gateway][4500] (204 bytes) > >>> May 31 20:51:43 ip-172-31-37-117 charon: 11[IKE] sending retransmit 3 > >>> of request message ID 2857000903, seq 4 > >>> May 31 20:51:43 ip-172-31-37-117 charon: 11[NET] sending packet: from > >>> 172.31.50.238[4500] to [VPN public gateway][4500] (204 bytes) > >>> May 31 20:52:03 ip-172-31-37-117 charon: 05[IKE] sending keep alive to > >>> [VPN public gateway][4500] > >>> May 31 20:52:07 ip-172-31-37-117 charon: 14[IKE] sending retransmit 4 > >>> of request message ID 2857000903, seq 4 > >>> May 31 20:52:07 ip-172-31-37-117 charon: 14[NET] sending packet: from > >>> 172.31.50.238[4500] to [VPN public gateway][4500] (204 bytes) > >>> May 31 20:52:26 ip-172-31-37-117 charon: 13[IKE] sending keep alive to > >>> [VPN public gateway][4500] > >>> May 31 20:52:46 ip-172-31-37-117 charon: 15[IKE] sending keep alive to > >>> [VPN public gateway][4500] > >>> May 31 20:52:49 ip-172-31-37-117 charon: 16[IKE] sending retransmit 5 > >>> of request message ID 2857000903, seq 4 > >>> May 31 20:52:49 ip-172-31-37-117 charon: 16[NET] sending packet: from > >>> 172.31.50.238[4500] to [VPN public gateway][4500] (204 bytes) > >>> May 31 20:53:08 ip-172-31-37-117 charon: 02[IKE] sending keep alive to > >>> [VPN public gateway][4500] > >>> May 31 20:53:28 ip-172-31-37-117 charon: 01[IKE] sending keep alive to > >>> [VPN public gateway][4500] > >>> May 31 20:53:48 ip-172-31-37-117 charon: 11[IKE] sending keep alive to > >>> [VPN public gateway][4500] > >>> May 31 20:54:04 ip-172-31-37-117 charon: 10[KNL] creating delete job > >>> for CHILD_SA ESP/0xcf4ca247/172.31.50.238 > >>> May 31 20:54:04 ip-172-31-37-117 charon: 10[JOB] CHILD_SA > >>> ESP/0xcf4ca247/172.31.50.238 not found for delete > >>> May 31 20:54:04 ip-172-31-37-117 charon: 14[IKE] giving up after 5 > >>> retransmits > >>> May 31 20:54:04 ip-172-31-37-117 charon: 14[IKE] installing new > >>> virtual IP 10.100.4.69 > >>> May 31 20:54:04 ip-172-31-37-117 charon: 14[IKE] initiating Aggressive > >>> Mode IKE_SA corporate[2] to [VPN public gateway] > >>> May 31 20:54:04 ip-172-31-37-117 charon: 14[ENC] generating AGGRESSIVE > >>> request 0 [ SA KE No ID V V V V ] > >>> May 31 20:54:04 ip-172-31-37-117 charon: 14[NET] sending packet: from > >>> 172.31.50.238[500] to [VPN public gateway][500] (416 bytes) > >>> May 31 20:54:04 ip-172-31-37-117 charon: 12[NET] received packet: from > >>> [VPN public gateway][500] to 172.31.50.238[500] (396 bytes) > >>> May 31 20:54:04 ip-172-31-37-117 charon: 12[ENC] parsed AGGRESSIVE > >>> response 0 [ SA KE No ID HASH V V NAT-D NAT-D V V ] > >>> May 31 20:54:04 ip-172-31-37-117 charon: 12[IKE] received XAuth vendor ID > >>> May 31 20:54:04 ip-172-31-37-117 charon: 12[IKE] received NAT-T (RFC > >>> 3947) vendor ID > >>> May 31 20:54:04 ip-172-31-37-117 charon: 12[IKE] received DPD vendor ID > >>> May 31 20:54:04 ip-172-31-37-117 charon: 12[ENC] received unknown > >>> vendor ID: a9:b9:b1:03:4f:7e:50:a2:51:3b:47:b1:00:bb:85:a9 > >>> May 31 20:54:04 ip-172-31-37-117 charon: 12[IKE] local host is behind > >>> NAT, sending keep alives > >>> May 31 20:54:04 ip-172-31-37-117 charon: 12[ENC] generating AGGRESSIVE > >>> request 0 [ NAT-D NAT-D HASH ] > >>> May 31 20:54:04 ip-172-31-37-117 charon: 12[NET] sending packet: from > >>> 172.31.50.238[4500] to [VPN public gateway][4500] (108 bytes) > >>> May 31 20:54:05 ip-172-31-37-117 charon: 13[NET] received packet: from > >>> [VPN public gateway][4500] to 172.31.50.238[4500] (76 bytes) > >>> May 31 20:54:05 ip-172-31-37-117 charon: 13[ENC] parsed TRANSACTION > >>> request 2330652074 [ HASH CPRQ(X_TYPE X_USER X_PWD) ] > >>> May 31 20:54:05 ip-172-31-37-117 charon: 13[ENC] generating > >>> TRANSACTION response 2330652074 [ HASH CPRP(X_USER X_PWD) ] > >>> May 31 20:54:05 ip-172-31-37-117 charon: 13[NET] sending packet: from > >>> 172.31.50.238[4500] to [VPN public gateway][4500] (108 bytes) > >>> May 31 20:54:28 ip-172-31-37-117 charon: 02[IKE] sending keep alive to > >>> [VPN public gateway][4500] > >>> May 31 20:54:34 ip-172-31-37-117 charon: 01[JOB] peer did not initiate > >>> expected exchange, reestablishing IKE_SA > >>> May 31 20:54:34 ip-172-31-37-117 charon: 01[IKE] reinitiating IKE_SA > >>> corporate[2] > >>> May 31 20:54:34 ip-172-31-37-117 charon: 01[IKE] initiating Aggressive > >>> Mode IKE_SA corporate[2] to [VPN public gateway] > >>> May 31 20:54:34 ip-172-31-37-117 charon: 01[ENC] generating AGGRESSIVE > >>> request 0 [ SA KE No ID V V V V ] > >>> May 31 20:54:34 ip-172-31-37-117 charon: 01[NET] sending packet: from > >>> 172.31.50.238[4500] to [VPN public gateway][4500] (416 bytes) > >>> > >>> > >>> On 5/31/15, Noel Kuntze <[email protected]> wrote: > >>>> > >>> 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 iQIcBAEBCAAGBQJVbGTNAAoJEDg5KY9j7GZYng0P/iL+FOGj86FjOKjw6Yxgeq2Q Ean1kRkNtU63Ysn+G7npRytMdQDCTGaeigjCxISHv6bnvbyT8aurS9MFIaOdFWr7 FGw29fZvAEDOWyZIaFfxQiau/tsb7kRdisrFUG/1XqG3qnXuSzxH6bgIXeor3+Yy cLvH96ALCWIrMH+ObK/ElweXc6IPBruo6w0T93CsR3rBQU1ZbYL0FasSDdmjL9pj 2tspUTzjRKOGH32LY8jShyGDrEjY4iZZjih1hPW/XTcA6Q/DZiWGciw8+RUNNOHh KXvCaA515+nm7jilYTKMBW33bFcDm6KzFDZO6k/X1q3r5gjv/p/eK0jMvXYFDdMk lHcU8oQtwqPIr204AbPia1cpQrhz7LIZYzlO33FsRIvB/w1/PTxh2jrT1SeGnow3 8q+GStAzVpPDOlKXPg7m8UlY71JuqFSrbGMHzs2o3p4jGuOyInxRpr4hAUjFjU6J hkcwictY1CdEajle1x/U1k284ZzQmQRLuYGufMDg2UzBT202PbO88OVz2TC+ZxEL tcg+38VLfF65Oplqjv9kyy5S5RPYXZGfpnuoXPR+LYW+/Sp5k6PSSxGV2WvKqs+C JrpPM5BzrsxA3FJWdAhFYMy0JMgQXNFPjUq/09ZMbllVvcH50jBzBJTHrEVDlGx7 Q644v6cRgI94O60CUm7f =4yG/ -----END PGP SIGNATURE----- _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
