[strongSwan] separate routes for VPN and Internet traffic: can this form of "split tunneling" be configured in ipsec.conf?
Alan Tu
8libra at gmail.com
Mon Jun 1 21:15:54 CEST 2015
Thanks Noel for repeatedly taking a look.
My workaround is to modify routing table 220, changing the default
route back to the original LAN IP and then explicitly routing the VPN
subnet over the VPN virtual IP. May not be pretty, but it works.
Alan
On 6/1/15, Noel Kuntze <noel at familie-kuntze.de> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hello Alan,
>
> Yes, looks like that vendor's implementation is borked.
>
> 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 21:12 schrieb Alan Tu:
>> Hi Noel, I have rightsubnet=10.0.0.0/8 and no leftsubnet entry.
>>
>> Fresh tested from scratch, pristine VM image, downloaded, compiled and
>> installed Strongswan. ipsec.conf [1] and syslog [2] are below. We have
>> an out of band two factor authentication mechanism, which I did
>> successfully authenticate to.
>>
>> Perhaps this VPN software/appliance vendor implementation isn't
>> compatible with what I want to do? Or at least the way I'm specifying
>> it in the client configuration.
>>
>> Alan
>>
>> Notes:
>> [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
>>
>> [2] syslog
>> Jun 1 18:53:40 ip-172-31-37-117 charon: 03[CFG] received stroke: initiate
>> 'vpn'
>> Jun 1 18:53:40 ip-172-31-37-117 charon: 01[IKE] initiating Aggressive
>> Mode IKE_SA vpn[1] to [VPN_gateway]
>> Jun 1 18:53:40 ip-172-31-37-117 charon: 01[ENC] generating AGGRESSIVE
>> request 0 [ SA KE No ID V V V V ]
>> Jun 1 18:53:40 ip-172-31-37-117 charon: 01[NET] sending packet: from
>> 172.31.36.65[500] to [VPN_gateway][500] (384 bytes)
>> Jun 1 18:53:40 ip-172-31-37-117 charon: 10[NET] received packet: from
>> [VPN_gateway][500] to 172.31.36.65[500] (396 bytes)
>> Jun 1 18:53:40 ip-172-31-37-117 charon: 10[ENC] parsed AGGRESSIVE
>> response 0 [ SA KE No ID HASH V V NAT-D NAT-D V V ]
>> Jun 1 18:53:40 ip-172-31-37-117 charon: 10[IKE] received XAuth vendor ID
>> Jun 1 18:53:40 ip-172-31-37-117 charon: 10[IKE] received NAT-T (RFC
>> 3947) vendor ID
>> Jun 1 18:53:40 ip-172-31-37-117 charon: 10[IKE] received DPD vendor ID
>> Jun 1 18:53:40 ip-172-31-37-117 charon: 10[ENC] received unknown
>> vendor ID: a9:b9:b1:03:4f:7e:50:a2:51:3b:47:b1:00:bb:85:a9
>> Jun 1 18:53:40 ip-172-31-37-117 charon: 10[IKE] local host is behind
>> NAT, sending keep alives
>> Jun 1 18:53:40 ip-172-31-37-117 charon: 10[ENC] generating AGGRESSIVE
>> request 0 [ NAT-D NAT-D HASH ]
>> Jun 1 18:53:40 ip-172-31-37-117 charon: 10[NET] sending packet: from
>> 172.31.36.65[4500] to [VPN_gateway][4500] (108 bytes)
>> Jun 1 18:53:41 ip-172-31-37-117 charon: 11[NET] received packet: from
>> [VPN_gateway][4500] to 172.31.36.65[4500] (76 bytes)
>> Jun 1 18:53:41 ip-172-31-37-117 charon: 11[ENC] parsed TRANSACTION
>> request 783318293 [ HASH CPRQ(X_TYPE X_USER X_PWD) ]
>> Jun 1 18:53:41 ip-172-31-37-117 charon: 11[ENC] generating
>> TRANSACTION response 783318293 [ HASH CPRP(X_USER X_PWD) ]
>> Jun 1 18:53:41 ip-172-31-37-117 charon: 11[NET] sending packet: from
>> 172.31.36.65[4500] to [VPN_gateway][4500] (108 bytes)
>> Jun 1 18:53:49 ip-172-31-37-117 charon: 05[NET] received packet: from
>> [VPN_gateway][4500] to 172.31.36.65[4500] (76 bytes)
>> Jun 1 18:53:49 ip-172-31-37-117 charon: 05[ENC] parsed TRANSACTION
>> request 703099895 [ HASH CPS(X_STATUS) ]
>> Jun 1 18:53:49 ip-172-31-37-117 charon: 05[IKE] XAuth authentication
>> of 'user' (myself) successful
>> Jun 1 18:53:49 ip-172-31-37-117 charon: 05[IKE] IKE_SA vpn[1]
>> established between 172.31.36.65[group]...[VPN_gateway][[VPN_gateway]]
>> Jun 1 18:53:49 ip-172-31-37-117 charon: 05[IKE] scheduling
>> reauthentication in 86220s
>> Jun 1 18:53:49 ip-172-31-37-117 charon: 05[IKE] maximum IKE_SA lifetime
>> 86400s
>> Jun 1 18:53:49 ip-172-31-37-117 charon: 05[ENC] generating
>> TRANSACTION response 703099895 [ HASH CPA(X_STATUS) ]
>> Jun 1 18:53:49 ip-172-31-37-117 charon: 05[NET] sending packet: from
>> 172.31.36.65[4500] to [VPN_gateway][4500] (76 bytes)
>> Jun 1 18:53:49 ip-172-31-37-117 charon: 05[ENC] generating
>> TRANSACTION request 4226299460 [ HASH CPRQ(ADDR DNS) ]
>> Jun 1 18:53:49 ip-172-31-37-117 charon: 05[NET] sending packet: from
>> 172.31.36.65[4500] to [VPN_gateway][4500] (76 bytes)
>> Jun 1 18:53:49 ip-172-31-37-117 charon: 13[NET] received packet: from
>> [VPN_gateway][4500] to 172.31.36.65[4500] (92 bytes)
>> Jun 1 18:53:49 ip-172-31-37-117 charon: 13[ENC] parsed TRANSACTION
>> response 4226299460 [ HASH CPRP(ADDR DNS DNS) ]
>> Jun 1 18:53:49 ip-172-31-37-117 charon: 13[IKE] installing DNS server
>> 10.100.15.5 via resolvconf
>> Jun 1 18:53:49 ip-172-31-37-117 charon: 13[IKE] installing DNS server
>> 10.100.24.250 via resolvconf
>> Jun 1 18:53:49 ip-172-31-37-117 charon: 13[IKE] installing new
>> virtual IP 10.100.4.5
>> Jun 1 18:53:49 ip-172-31-37-117 charon: 13[ENC] generating QUICK_MODE
>> request 675444149 [ HASH SA No ID ID ]
>> Jun 1 18:53:49 ip-172-31-37-117 charon: 13[NET] sending packet: from
>> 172.31.36.65[4500] to [VPN_gateway][4500] (204 bytes)
>> Jun 1 18:53:53 ip-172-31-37-117 charon: 02[IKE] sending retransmit 1
>> of request message ID 675444149, seq 4
>> Jun 1 18:53:53 ip-172-31-37-117 charon: 02[NET] sending packet: from
>> 172.31.36.65[4500] to [VPN_gateway][4500] (204 bytes)
>> Jun 1 18:54:01 ip-172-31-37-117 charon: 10[IKE] sending retransmit 2
>> of request message ID 675444149, seq 4
>> Jun 1 18:54:01 ip-172-31-37-117 charon: 10[NET] sending packet: from
>> 172.31.36.65[4500] to [VPN_gateway][4500] (204 bytes)
>> Jun 1 18:54:14 ip-172-31-37-117 charon: 05[IKE] sending retransmit 3
>> of request message ID 675444149, seq 4
>> Jun 1 18:54:14 ip-172-31-37-117 charon: 05[NET] sending packet: from
>> 172.31.36.65[4500] to [VPN_gateway][4500] (204 bytes)
>> Jun 1 18:54:33 ip-172-31-37-117 charon: 15[IKE] sending keep alive to
>> [VPN_gateway][4500]
>> Jun 1 18:54:37 ip-172-31-37-117 charon: 13[IKE] sending retransmit 4
>> of request message ID 675444149, seq 4
>> Jun 1 18:54:37 ip-172-31-37-117 charon: 13[NET] sending packet: from
>> 172.31.36.65[4500] to [VPN_gateway][4500] (204 bytes)
>> Jun 1 18:54:56 ip-172-31-37-117 charon: 16[IKE] sending keep alive to
>> [VPN_gateway][4500]
>> Jun 1 18:55:16 ip-172-31-37-117 charon: 02[IKE] sending keep alive to
>> [VPN_gateway][4500]
>> Jun 1 18:55:19 ip-172-31-37-117 charon: 01[IKE] sending retransmit 5
>> of request message ID 675444149, seq 4
>> Jun 1 18:55:19 ip-172-31-37-117 charon: 01[NET] sending packet: from
>> 172.31.36.65[4500] to [VPN_gateway][4500] (204 bytes)
>> Jun 1 18:55:38 ip-172-31-37-117 charon: 11[IKE] sending keep alive to
>> [VPN_gateway][4500]
>> Jun 1 18:55:58 ip-172-31-37-117 charon: 12[IKE] sending keep alive to
>> [VPN_gateway][4500]
>> Jun 1 18:56:18 ip-172-31-37-117 charon: 05[IKE] sending keep alive to
>> [VPN_gateway][4500]
>> Jun 1 18:56:34 ip-172-31-37-117 charon: 14[KNL] creating delete job
>> for CHILD_SA ESP/0xc6eb89db/172.31.36.65
>> Jun 1 18:56:34 ip-172-31-37-117 charon: 14[JOB] CHILD_SA
>> ESP/0xc6eb89db/172.31.36.65 not found for delete
>> Jun 1 18:56:34 ip-172-31-37-117 charon: 13[IKE] giving up after 5
>> retransmits
>> Jun 1 18:56:34 ip-172-31-37-117 charon: 13[IKE] installing new
>> virtual IP 10.100.4.5
>> Jun 1 18:56:34 ip-172-31-37-117 charon: 13[IKE] initiating Aggressive
>> Mode IKE_SA vpn[2] to [VPN_gateway]
>> Jun 1 18:56:34 ip-172-31-37-117 charon: 13[ENC] generating AGGRESSIVE
>> request 0 [ SA KE No ID V V V V ]
>> Jun 1 18:56:34 ip-172-31-37-117 charon: 13[NET] sending packet: from
>> 172.31.36.65[500] to [VPN_gateway][500] (384 bytes)
>> Jun 1 18:56:34 ip-172-31-37-117 charon: 04[NET] received packet: from
>> [VPN_gateway][500] to 172.31.36.65[500] (396 bytes)
>> Jun 1 18:56:34 ip-172-31-37-117 charon: 04[ENC] parsed AGGRESSIVE
>> response 0 [ SA KE No ID HASH V V NAT-D NAT-D V V ]
>> Jun 1 18:56:34 ip-172-31-37-117 charon: 04[IKE] received XAuth vendor ID
>> Jun 1 18:56:34 ip-172-31-37-117 charon: 04[IKE] received NAT-T (RFC
>> 3947) vendor ID
>> Jun 1 18:56:34 ip-172-31-37-117 charon: 04[IKE] received DPD vendor ID
>> Jun 1 18:56:34 ip-172-31-37-117 charon: 04[ENC] received unknown
>> vendor ID: a9:b9:b1:03:4f:7e:50:a2:51:3b:47:b1:00:bb:85:a9
>> Jun 1 18:56:34 ip-172-31-37-117 charon: 04[IKE] local host is behind
>> NAT, sending keep alives
>> Jun 1 18:56:34 ip-172-31-37-117 charon: 04[ENC] generating AGGRESSIVE
>> request 0 [ NAT-D NAT-D HASH ]
>> Jun 1 18:56:34 ip-172-31-37-117 charon: 04[NET] sending packet: from
>> 172.31.36.65[4500] to [VPN_gateway][4500] (108 bytes)
>> Jun 1 18:56:35 ip-172-31-37-117 charon: 16[NET] received packet: from
>> [VPN_gateway][4500] to 172.31.36.65[4500] (76 bytes)
>> Jun 1 18:56:35 ip-172-31-37-117 charon: 16[ENC] parsed TRANSACTION
>> request 260202080 [ HASH CPRQ(X_TYPE X_USER X_PWD) ]
>> Jun 1 18:56:35 ip-172-31-37-117 charon: 16[ENC] generating
>> TRANSACTION response 260202080 [ HASH CPRP(X_USER X_PWD) ]
>> Jun 1 18:56:35 ip-172-31-37-117 charon: 16[NET] sending packet: from
>> 172.31.36.65[4500] to [VPN_gateway][4500] (108 bytes)
>> Jun 1 18:56:45 ip-172-31-37-117 charon: 10[NET] received packet: from
>> [VPN_gateway][4500] to 172.31.36.65[4500] (76 bytes)
>> Jun 1 18:56:45 ip-172-31-37-117 charon: 10[ENC] parsed TRANSACTION
>> request 1809935207 [ HASH CPS(X_STATUS) ]
>> Jun 1 18:56:45 ip-172-31-37-117 charon: 10[IKE] XAuth authentication
>> of 'user' (myself) successful
>> Jun 1 18:56:45 ip-172-31-37-117 charon: 10[IKE] IKE_SA vpn[2]
>> established between 172.31.36.65[group]...[VPN_gateway][[VPN_gateway]]
>> Jun 1 18:56:45 ip-172-31-37-117 charon: 10[IKE] scheduling
>> reauthentication in 86220s
>> Jun 1 18:56:45 ip-172-31-37-117 charon: 10[IKE] maximum IKE_SA lifetime
>> 86400s
>> Jun 1 18:56:45 ip-172-31-37-117 charon: 10[ENC] generating
>> TRANSACTION response 1809935207 [ HASH CPA(X_STATUS) ]
>> Jun 1 18:56:45 ip-172-31-37-117 charon: 10[NET] sending packet: from
>> 172.31.36.65[4500] to [VPN_gateway][4500] (76 bytes)
>> Jun 1 18:56:45 ip-172-31-37-117 charon: 10[ENC] generating
>> TRANSACTION request 150801322 [ HASH CPRQ(ADDR DNS) ]
>> Jun 1 18:56:45 ip-172-31-37-117 charon: 10[NET] sending packet: from
>> 172.31.36.65[4500] to [VPN_gateway][4500] (76 bytes)
>> Jun 1 18:56:45 ip-172-31-37-117 charon: 11[NET] received packet: from
>> [VPN_gateway][4500] to 172.31.36.65[4500] (92 bytes)
>> Jun 1 18:56:45 ip-172-31-37-117 charon: 11[ENC] parsed TRANSACTION
>> response 150801322 [ HASH CPRP(ADDR DNS DNS) ]
>> Jun 1 18:56:45 ip-172-31-37-117 charon: 11[IKE] installing DNS server
>> 10.100.15.5 via resolvconf
>> Jun 1 18:56:45 ip-172-31-37-117 charon: 11[IKE] installing DNS server
>> 10.100.24.250 via resolvconf
>> Jun 1 18:56:45 ip-172-31-37-117 charon: 11[IKE] installing new
>> virtual IP 10.100.4.2
>> Jun 1 18:56:45 ip-172-31-37-117 charon: 11[ENC] generating QUICK_MODE
>> request 1932673650 [ HASH SA No ID ID ]
>> Jun 1 18:56:45 ip-172-31-37-117 charon: 11[NET] sending packet: from
>> 172.31.36.65[4500] to [VPN_gateway][4500] (204 bytes)
>> Jun 1 18:56:49 ip-172-31-37-117 charon: 16[IKE] sending retransmit 1
>> of request message ID 1932673650, seq 4
>> Jun 1 18:56:49 ip-172-31-37-117 charon: 16[NET] sending packet: from
>> 172.31.36.65[4500] to [VPN_gateway][4500] (204 bytes)
>> Jun 1 18:56:57 ip-172-31-37-117 charon: 01[IKE] sending retransmit 2
>> of request message ID 1932673650, seq 4
>> Jun 1 18:56:57 ip-172-31-37-117 charon: 01[NET] sending packet: from
>> 172.31.36.65[4500] to [VPN_gateway][4500] (204 bytes)
>> Jun 1 18:57:10 ip-172-31-37-117 charon: 05[IKE] sending retransmit 3
>> of request message ID 1932673650, seq 4
>> Jun 1 18:57:10 ip-172-31-37-117 charon: 05[NET] sending packet: from
>> 172.31.36.65[4500] to [VPN_gateway][4500] (204 bytes)
>> Jun 1 18:57:29 ip-172-31-37-117 charon: 15[IKE] sending keep alive to
>> [VPN_gateway][4500]
>> Jun 1 18:57:33 ip-172-31-37-117 charon: 03[IKE] sending retransmit 4
>> of request message ID 1932673650, seq 4
>> Jun 1 18:57:33 ip-172-31-37-117 charon: 03[NET] sending packet: from
>> 172.31.36.65[4500] to [VPN_gateway][4500] (204 bytes)
>>
>>
>> On 6/1/15, Noel Kuntze <noel at familie-kuntze.de> wrote:
>>>
>> 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
>
> iQIcBAEBCAAGBQJVbK74AAoJEDg5KY9j7GZYDeIP/1sCSimYvr099u0pSmBL2UO8
> EaW2e88W1DzNTr9lt5Sg3x03DkQrfa+RjyS5BhLyaqERtH7rZj2VD1TyzwbQIXLR
> AY5SMytbpN15FJZGby2vKPGC7RXK+5zzdcpZ6rlGXu5f0LZo3J4MfXMycgVG/x7R
> OjVNPYvItaVZBwE4gMuvFwDVquGldkrN7PJFEyP/Wrm9XxiQOTcilPRmrvX5VWjS
> FOT/BufMDg0S7RlDay2ecoByQP4OEpa6PS2d294c0d9f3S0UBIO5Y7KSmVKDrCpr
> lNIyXA/g/K85gPqtNqx0WRMj7rdx+4dW2z4tQUpYj/VugcOZfDAiH+NVrdYVYah4
> uNC0vybRhGcHcBY/iQJUI+QVA0np9wI+ly5hvdY0LQsxvgP4LGZNG/vxEuyGJixC
> 4s58RcTQ8faacZTerDAYN0ufSRBaTt6yxJE8AFasj9elgmyWB4KEjHABL9IYQ2un
> ZRQ4zPEdZv+TcYpPlnBO6MxlKKYNkmrVE9S7Owxnby19bEtqlmD6ZoxotPt9MUkV
> x2dLcvwGV9fsWft2EpynBn1qhqk3jr9tHfnnuc8A4PCwS5wgCjva7Yn2driFCU+S
> CSrwgZGUNiGHR0Xu0AcSvP7GhT71upLxlcfPTalctHFeZ/rbwq3jJ525gdgj2gAZ
> XYtbiscYUSW4AdpIRMvH
> =pN6y
> -----END PGP SIGNATURE-----
>
>
More information about the Users
mailing list