[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 21:14:00 CEST 2015
-----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