[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
Mon Jun 1 15:57:36 CEST 2015
-----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 <noel at familie-kuntze.de> 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 <noel at familie-kuntze.de> 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 <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
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-----
More information about the Users
mailing list