-----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 <[email protected]> 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 <[email protected]> wrote: > >>>> > >>> Hello Alan, > >>> > >>> Your configuration makes no sense. > >>> You request configuration options (dns servers, IP address) > >>> from the remote peer, but you then you override the sensical > >>> traffic selector of $virtualIP == 10.0.0.0/8 > >>> with a nonsensical traffic selector of > >>> 10.0.0.0/8 == 10.0.0.0/8. > >>> Remove leftsubnet and I figure it will work. > >>> Furthermore, your configuration for the IKE and ESP ciphers is > >>> wrong. > >>> Read the man page for ipsec.conf for a correct format of those lines. > >>> > >>> Furthermore, IKev1 in aggressive mode with PSK authentication is a > >>> horrible idea, as it allows an attacker to perform an offline dictionary > >>> attack on the PSK! > >>> You are strongly encouraged to switch to a safer combination. > >>> > >>> Mit freundlichen Grüßen/Kind Regards, > >>> Noel Kuntze > >>> > >>> GPG Key ID: 0x63EC6658 > >>> Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 > >>> > >>> Am 31.05.2015 um 23:39 schrieb Alan Tu: > >>>>>> Noel, Starting from a working tunnel, the only remaining issue was to > >>>>>> not send Internet packets to the VPN. You state I need to write > >>>>>> passthrough connections for all combinations of IP addresses that I > >>>>>> don't want to route to the VPN. Those combinations are literally > >>>>>> everything, except destination 10/8. I would rather write the one > >>>>>> combination that I do want to route to the VPN. > >>>>>> > >>>>>> I just don't know how to do that, besides modifying routing table > >>>>>> 220. > >>>>>> I said I tried different combinations of leftsubnet and rightsubnet. > >>>>>> Eventually the daemon reports > >>>>>> establishing connection 'vpn' failed > >>>>>> > >>>>>> Here is my ipsec.conf file [1], basically I specify leftsubnet and > >>>>>> rightsubnet to be the VPN subnet, 10/8. This version of ipsec.conf > >>>>>> fails, here are the syslog messages [2]. > >>>>>> > >>>>>> Alan > >>>>>> > >>>>>> [1] ipsec.conf > >>>>>> conn %default > >>>>>> ikelifetime=20 > >>>>>> reauth=yes > >>>>>> rekey=yes > >>>>>> keylife=10m > >>>>>> rekeymargin=3m > >>>>>> rekeyfuzz=0% > >>>>>> keyingtries=1 > >>>>>> type=tunnel > >>>>>> > >>>>>> conn vpn > >>>>>> keyexchange=ikev1 > >>>>>> ikelifetime=1440m > >>>>>> keylife=60m > >>>>>> aggressive=yes > >>>>>> ike=aes-sha1-modp1024,aes256 > >>>>>> esp=aes-sha1 > >>>>>> xauth=client > >>>>>> left=%any > >>>>>> leftid=keyid:[redacted] > >>>>>> leftsourceip=%modeconfig > >>>>>> leftauth=psk > >>>>>> rightauth=psk > >>>>>> leftauth2=xauth > >>>>>> right=[redacted gateway public IP] > >>>>>> leftsubnet=10.0.0.0/8 > >>>>>> rightsubnet=10.0.0.0/8 > >>>>>> xauth_identity=[redacted] > >>>>>> auto=add > >>>>>> > >>>>>> conn lan > >>>>>> leftsubnet=172.31.0.0/16 > >>>>>> rightsubnet=172.31.0.0/16 > >>>>>> authby=never > >>>>>> type=passthrough > >>>>>> auto=route > >>>>>> > >>>>>> [2] syslog: > >>>>>> May 31 20:46:24 ip-172-31-37-117 charon: 10[CFG] received stroke: add > >>>>>> connection 'corporate' > >>>>>> May 31 20:46:24 ip-172-31-37-117 charon: 10[CFG] left nor right host > >>>>>> is our side, assuming left=local > >>>>>> May 31 20:46:24 ip-172-31-37-117 charon: 10[CFG] added configuration > >>>>>> 'corporate' > >>>>>> May 31 20:46:24 ip-172-31-37-117 charon: 05[CFG] received stroke: add > >>>>>> connection 'lan' > >>>>>> May 31 20:46:24 ip-172-31-37-117 charon: 05[CFG] left nor right host > >>>>>> is our side, assuming left=local > >>>>>> May 31 20:46:24 ip-172-31-37-117 charon: 05[CFG] added configuration > >>>>>> 'lan' > >>>>>> May 31 20:46:24 ip-172-31-37-117 charon: 13[CFG] received stroke: > >>>>>> route > >>>>>> 'lan' > >>>>>> May 31 20:46:30 ip-172-31-37-117 cloud-init[964]: Starting strongSwan > >>>>>> 5.3.0 IPsec [starter]... > >>>>>> May 31 20:51:10 ip-172-31-37-117 charon: 04[CFG] received stroke: > >>>>>> initiate 'corporate' > >>>>>> May 31 20:51:10 ip-172-31-37-117 charon: 03[IKE] initiating > >>>>>> Aggressive > >>>>>> Mode IKE_SA corporate[1] to [VPN public gateway] > >>>>>> May 31 20:51:10 ip-172-31-37-117 charon: 03[ENC] generating > >>>>>> AGGRESSIVE > >>>>>> request 0 [ SA KE No ID V V V V ] > >>>>>> May 31 20:51:10 ip-172-31-37-117 charon: 03[NET] sending packet: from > >>>>>> 172.31.50.238[500] to [VPN public gateway][500] (416 bytes) > >>>>>> May 31 20:51:10 ip-172-31-37-117 charon: 02[NET] received packet: > >>>>>> from > >>>>>> [VPN public gateway][500] to 172.31.50.238[500] (396 bytes) > >>>>>> May 31 20:51:10 ip-172-31-37-117 charon: 02[ENC] parsed AGGRESSIVE > >>>>>> response 0 [ SA KE No ID HASH V V NAT-D NAT-D V V ] > >>>>>> May 31 20:51:10 ip-172-31-37-117 charon: 02[IKE] received XAuth vendor > >>>>>> ID > >>>>>> May 31 20:51:10 ip-172-31-37-117 charon: 02[IKE] received NAT-T (RFC > >>>>>> 3947) vendor ID > >>>>>> May 31 20:51:10 ip-172-31-37-117 charon: 02[IKE] received DPD vendor > >>>>>> ID > >>>>>> May 31 20:51:10 ip-172-31-37-117 charon: 02[ENC] received unknown > >>>>>> vendor ID: a9:b9:b1:03:4f:7e:50:a2:51:3b:47:b1:00:bb:85:a9 > >>>>>> May 31 20:51:10 ip-172-31-37-117 charon: 02[IKE] local host is behind > >>>>>> NAT, sending keep alives > >>>>>> May 31 20:51:10 ip-172-31-37-117 charon: 02[ENC] generating > >>>>>> AGGRESSIVE > >>>>>> request 0 [ NAT-D NAT-D HASH ] > >>>>>> May 31 20:51:10 ip-172-31-37-117 charon: 02[NET] sending packet: from > >>>>>> 172.31.50.238[4500] to [VPN public gateway][4500] (108 bytes) > >>>>>> May 31 20:51:11 ip-172-31-37-117 charon: 01[NET] received packet: > >>>>>> from > >>>>>> [VPN public gateway][4500] to 172.31.50.238[4500] (76 bytes) > >>>>>> May 31 20:51:11 ip-172-31-37-117 charon: 01[ENC] parsed TRANSACTION > >>>>>> request 1621027542 [ HASH CPRQ(X_TYPE X_USER X_PWD) ] > >>>>>> May 31 20:51:11 ip-172-31-37-117 charon: 01[ENC] generating > >>>>>> TRANSACTION response 1621027542 [ HASH CPRP(X_USER X_PWD) ] > >>>>>> May 31 20:51:11 ip-172-31-37-117 charon: 01[NET] sending packet: from > >>>>>> 172.31.50.238[4500] to [VPN public gateway][4500] (108 bytes) > >>>>>> May 31 20:51:19 ip-172-31-37-117 charon: 10[NET] received packet: > >>>>>> from > >>>>>> [VPN public gateway][4500] to 172.31.50.238[4500] (76 bytes) > >>>>>> May 31 20:51:19 ip-172-31-37-117 charon: 10[ENC] parsed TRANSACTION > >>>>>> request 582705483 [ HASH CPS(X_STATUS) ] > >>>>>> May 31 20:51:19 ip-172-31-37-117 charon: 10[IKE] XAuth authentication > >>>>>> of 'user' (myself) successful > >>>>>> May 31 20:51:19 ip-172-31-37-117 charon: 10[IKE] IKE_SA corporate[1] > >>>>>> established between 172.31.50.238[cs-users]...[VPN public > >>>>>> gateway][[VPN public gateway]] > >>>>>> May 31 20:51:19 ip-172-31-37-117 charon: 10[IKE] scheduling > >>>>>> reauthentication in 86220s > >>>>>> May 31 20:51:19 ip-172-31-37-117 charon: 10[IKE] maximum IKE_SA > >>>>>> lifetime > >>>>>> 86400s > >>>>>> May 31 20:51:19 ip-172-31-37-117 charon: 10[ENC] generating > >>>>>> TRANSACTION response 582705483 [ HASH CPA(X_STATUS) ] > >>>>>> May 31 20:51:19 ip-172-31-37-117 charon: 10[NET] sending packet: from > >>>>>> 172.31.50.238[4500] to [VPN public gateway][4500] (76 bytes) > >>>>>> May 31 20:51:19 ip-172-31-37-117 charon: 10[ENC] generating > >>>>>> TRANSACTION request 1981149928 [ HASH CPRQ(ADDR DNS) ] > >>>>>> May 31 20:51:19 ip-172-31-37-117 charon: 10[NET] sending packet: from > >>>>>> 172.31.50.238[4500] to [VPN public gateway][4500] (76 bytes) > >>>>>> May 31 20:51:19 ip-172-31-37-117 charon: 12[NET] received packet: > >>>>>> from > >>>>>> [VPN public gateway][4500] to 172.31.50.238[4500] (92 bytes) > >>>>>> May 31 20:51:19 ip-172-31-37-117 charon: 12[ENC] parsed TRANSACTION > >>>>>> response 1981149928 [ HASH CPRP(ADDR DNS DNS) ] > >>>>>> May 31 20:51:19 ip-172-31-37-117 charon: 12[IKE] installing DNS > >>>>>> server > >>>>>> 10.100.15.5 via resolvconf > >>>>>> May 31 20:51:19 ip-172-31-37-117 charon: 12[IKE] installing DNS > >>>>>> server > >>>>>> 10.100.24.250 via resolvconf > >>>>>> May 31 20:51:19 ip-172-31-37-117 charon: 12[IKE] installing new > >>>>>> virtual IP 10.100.4.69 > >>>>>> May 31 20:51:19 ip-172-31-37-117 charon: 12[ENC] generating > >>>>>> QUICK_MODE > >>>>>> request 2857000903 [ HASH SA No ID ID ] > >>>>>> May 31 20:51:19 ip-172-31-37-117 charon: 12[NET] sending packet: from > >>>>>> 172.31.50.238[4500] to [VPN public gateway][4500] (204 bytes) > >>>>>> May 31 20:51:23 ip-172-31-37-117 charon: 16[IKE] sending retransmit 1 > >>>>>> of request message ID 2857000903, seq 4 > >>>>>> May 31 20:51:23 ip-172-31-37-117 charon: 16[NET] sending packet: from > >>>>>> 172.31.50.238[4500] to [VPN public gateway][4500] (204 bytes) > >>>>>> May 31 20:51:30 ip-172-31-37-117 charon: 03[IKE] sending retransmit 2 > >>>>>> of request message ID 2857000903, seq 4 > >>>>>> May 31 20:51:30 ip-172-31-37-117 charon: 03[NET] sending packet: from > >>>>>> 172.31.50.238[4500] to [VPN public gateway][4500] (204 bytes) > >>>>>> May 31 20:51:43 ip-172-31-37-117 charon: 11[IKE] sending retransmit 3 > >>>>>> of request message ID 2857000903, seq 4 > >>>>>> May 31 20:51:43 ip-172-31-37-117 charon: 11[NET] sending packet: from > >>>>>> 172.31.50.238[4500] to [VPN public gateway][4500] (204 bytes) > >>>>>> May 31 20:52:03 ip-172-31-37-117 charon: 05[IKE] sending keep alive > >>>>>> to > >>>>>> [VPN public gateway][4500] > >>>>>> May 31 20:52:07 ip-172-31-37-117 charon: 14[IKE] sending retransmit 4 > >>>>>> of request message ID 2857000903, seq 4 > >>>>>> May 31 20:52:07 ip-172-31-37-117 charon: 14[NET] sending packet: from > >>>>>> 172.31.50.238[4500] to [VPN public gateway][4500] (204 bytes) > >>>>>> May 31 20:52:26 ip-172-31-37-117 charon: 13[IKE] sending keep alive > >>>>>> to > >>>>>> [VPN public gateway][4500] > >>>>>> May 31 20:52:46 ip-172-31-37-117 charon: 15[IKE] sending keep alive > >>>>>> to > >>>>>> [VPN public gateway][4500] > >>>>>> May 31 20:52:49 ip-172-31-37-117 charon: 16[IKE] sending retransmit 5 > >>>>>> of request message ID 2857000903, seq 4 > >>>>>> May 31 20:52:49 ip-172-31-37-117 charon: 16[NET] sending packet: from > >>>>>> 172.31.50.238[4500] to [VPN public gateway][4500] (204 bytes) > >>>>>> May 31 20:53:08 ip-172-31-37-117 charon: 02[IKE] sending keep alive > >>>>>> to > >>>>>> [VPN public gateway][4500] > >>>>>> May 31 20:53:28 ip-172-31-37-117 charon: 01[IKE] sending keep alive > >>>>>> to > >>>>>> [VPN public gateway][4500] > >>>>>> May 31 20:53:48 ip-172-31-37-117 charon: 11[IKE] sending keep alive > >>>>>> to > >>>>>> [VPN public gateway][4500] > >>>>>> May 31 20:54:04 ip-172-31-37-117 charon: 10[KNL] creating delete job > >>>>>> for CHILD_SA ESP/0xcf4ca247/172.31.50.238 > >>>>>> May 31 20:54:04 ip-172-31-37-117 charon: 10[JOB] CHILD_SA > >>>>>> ESP/0xcf4ca247/172.31.50.238 not found for delete > >>>>>> May 31 20:54:04 ip-172-31-37-117 charon: 14[IKE] giving up after 5 > >>>>>> retransmits > >>>>>> May 31 20:54:04 ip-172-31-37-117 charon: 14[IKE] installing new > >>>>>> virtual IP 10.100.4.69 > >>>>>> May 31 20:54:04 ip-172-31-37-117 charon: 14[IKE] initiating > >>>>>> Aggressive > >>>>>> Mode IKE_SA corporate[2] to [VPN public gateway] > >>>>>> May 31 20:54:04 ip-172-31-37-117 charon: 14[ENC] generating > >>>>>> AGGRESSIVE > >>>>>> request 0 [ SA KE No ID V V V V ] > >>>>>> May 31 20:54:04 ip-172-31-37-117 charon: 14[NET] sending packet: from > >>>>>> 172.31.50.238[500] to [VPN public gateway][500] (416 bytes) > >>>>>> May 31 20:54:04 ip-172-31-37-117 charon: 12[NET] received packet: > >>>>>> from > >>>>>> [VPN public gateway][500] to 172.31.50.238[500] (396 bytes) > >>>>>> May 31 20:54:04 ip-172-31-37-117 charon: 12[ENC] parsed AGGRESSIVE > >>>>>> response 0 [ SA KE No ID HASH V V NAT-D NAT-D V V ] > >>>>>> May 31 20:54:04 ip-172-31-37-117 charon: 12[IKE] received XAuth vendor > >>>>>> ID > >>>>>> May 31 20:54:04 ip-172-31-37-117 charon: 12[IKE] received NAT-T (RFC > >>>>>> 3947) vendor ID > >>>>>> May 31 20:54:04 ip-172-31-37-117 charon: 12[IKE] received DPD vendor > >>>>>> ID > >>>>>> May 31 20:54:04 ip-172-31-37-117 charon: 12[ENC] received unknown > >>>>>> vendor ID: a9:b9:b1:03:4f:7e:50:a2:51:3b:47:b1:00:bb:85:a9 > >>>>>> May 31 20:54:04 ip-172-31-37-117 charon: 12[IKE] local host is behind > >>>>>> NAT, sending keep alives > >>>>>> May 31 20:54:04 ip-172-31-37-117 charon: 12[ENC] generating > >>>>>> AGGRESSIVE > >>>>>> request 0 [ NAT-D NAT-D HASH ] > >>>>>> May 31 20:54:04 ip-172-31-37-117 charon: 12[NET] sending packet: from > >>>>>> 172.31.50.238[4500] to [VPN public gateway][4500] (108 bytes) > >>>>>> May 31 20:54:05 ip-172-31-37-117 charon: 13[NET] received packet: > >>>>>> from > >>>>>> [VPN public gateway][4500] to 172.31.50.238[4500] (76 bytes) > >>>>>> May 31 20:54:05 ip-172-31-37-117 charon: 13[ENC] parsed TRANSACTION > >>>>>> request 2330652074 [ HASH CPRQ(X_TYPE X_USER X_PWD) ] > >>>>>> May 31 20:54:05 ip-172-31-37-117 charon: 13[ENC] generating > >>>>>> TRANSACTION response 2330652074 [ HASH CPRP(X_USER X_PWD) ] > >>>>>> May 31 20:54:05 ip-172-31-37-117 charon: 13[NET] sending packet: from > >>>>>> 172.31.50.238[4500] to [VPN public gateway][4500] (108 bytes) > >>>>>> May 31 20:54:28 ip-172-31-37-117 charon: 02[IKE] sending keep alive > >>>>>> to > >>>>>> [VPN public gateway][4500] > >>>>>> May 31 20:54:34 ip-172-31-37-117 charon: 01[JOB] peer did not > >>>>>> initiate > >>>>>> expected exchange, reestablishing IKE_SA > >>>>>> May 31 20:54:34 ip-172-31-37-117 charon: 01[IKE] reinitiating IKE_SA > >>>>>> corporate[2] > >>>>>> May 31 20:54:34 ip-172-31-37-117 charon: 01[IKE] initiating > >>>>>> Aggressive > >>>>>> Mode IKE_SA corporate[2] to [VPN public gateway] > >>>>>> May 31 20:54:34 ip-172-31-37-117 charon: 01[ENC] generating > >>>>>> AGGRESSIVE > >>>>>> request 0 [ SA KE No ID V V V V ] > >>>>>> May 31 20:54:34 ip-172-31-37-117 charon: 01[NET] sending packet: from > >>>>>> 172.31.50.238[4500] to [VPN public gateway][4500] (416 bytes) > >>>>>> > >>>>>> > >>>>>> On 5/31/15, Noel Kuntze <[email protected]> wrote: > >>>>>>> > >>>>>> Hello Alan, > >>>>>> > >>>>>> You need to write a passthrough/bypass > >>>>>> policy for all source and destination combinations > >>>>>> which should not get handled by IPsec. > >>>>>> Might that be non-LAN traffic, but traffic to google, or any other > >>>>>> traffic. > >>>>>> > >>>>>> "tunnel doesn't come up" is a very generic error. > >>>>>> What error did you encounter? > >>>>>> What is your complete ipsec.conf? > >>>>>> Also, you always need to specify leftsubnet and rightsubnet in a > >>>>>> passthrough/bypass policy! > >>>>>> > >>>>>> Mit freundlichen Grüßen/Kind Regards, > >>>>>> Noel Kuntze > >>>>>> > >>>>>> GPG Key ID: 0x63EC6658 > >>>>>> Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 > >>>>>> > >>>>>> Am 31.05.2015 um 20:59 schrieb Alan Tu: > >>>>>>>>> Hi Noel, I'm trying really hard to learn, please bare with me. > >>>>>>>>> Specifying passthrough for the local network does work, I solved > >>>>>>>>> that > >>>>>>>>> problem thanks to your tip. My question is about non-LAN, non-VPN > >>>>>>>>> traffic going to the Internet, such as to Google. The examples > >>>>>>>>> don't > >>>>>>>>> seem to cover this, and in fact the Strongswan split tunneling > >>>>>>>>> page > >>>>>>>>> states IKE v1 support for specifying one's subnets is, basically, > >>>>>>>>> hit > >>>>>>>>> or miss. Nevertheless I do try to learn from the configurations. > >>>>>>>>> > >>>>>>>>> Is the idea to use some combination of leftsubnet and rightsubnet > >>>>>>>>> in > >>>>>>>>> ipsec.conf? Or, is the idea to modify the XFRM policy (or state) > >>>>>>>>> tables? If the former, I have in fact tried several combinations, > >>>>>>>>> none > >>>>>>>>> work [1]. > >>>>>>>>> > >>>>>>>>> To abbreviate, I'm setting aside the XFRM policies related to > >>>>>>>>> local > >>>>>>>>> LAN passthrough. They work. > >>>>>>>>> # ip xfrm policy show > >>>>>>>>> # Policy 1 > >>>>>>>>> src 0.0.0.0/0 dst [VPN_virtual_private_IP]/32 > >>>>>>>>> dir fwd priority 2947 > >>>>>>>>> tmpl src [public_VPN_gateway] dst [LAN_IP] > >>>>>>>>> proto esp reqid 1 mode tunnel > >>>>>>>>> > >>>>>>>>> # Policy 2 > >>>>>>>>> src 0.0.0.0/0 dst [VPN_virtual_private_IP]/32 > >>>>>>>>> dir in priority 2947 > >>>>>>>>> tmpl src [public_VPN_gateway] dst [LAN_IP] > >>>>>>>>> proto esp reqid 1 mode tunnel > >>>>>>>>> > >>>>>>>>> # Policy 3 > >>>>>>>>> src [VPN_virtual_private_IP]/32 dst 0.0.0.0/0 > >>>>>>>>> dir out priority 2947 > >>>>>>>>> tmpl src [LAN_IP] dst [public_VPN_gateway] > >>>>>>>>> proto esp reqid 1 mode tunnel > >>>>>>>>> > >>>>>>>>> Let me focus on policy 3. I think it says any traffic starting > >>>>>>>>> with > >>>>>>>>> my > >>>>>>>>> VPN private IP (in the 10/8 net), going to anywhere, re-assign it > >>>>>>>>> to > >>>>>>>>> the ipsec tunnel with my physical LAN IP and the VPN gateway > >>>>>>>>> Internet > >>>>>>>>> IP as the endpoint. This makes sense. > >>>>>>>>> > >>>>>>>>> But if I claim that as it stands, all the local -> Internet > >>>>>>>>> traffic > >>>>>>>>> is > >>>>>>>>> going through the VPN, the only way I can explain that is if the > >>>>>>>>> local > >>>>>>>>> -> Internet traffic was already rewritten to source from the VPN > >>>>>>>>> virtual address. That's the only way I can see the local -> > >>>>>>>>> Internet > >>>>>>>>> traffic hitting this policy. > >>>>>>>>> > >>>>>>>>> If that is the case, would not the routing table modification be > >>>>>>>>> better, to prevent this "rewriting", to avoid hitting this tunnel > >>>>>>>>> policy? > >>>>>>>>> > >>>>>>>>> What I think you are telling me is to rewrite XFRM policy 3 so > >>>>>>>>> that > >>>>>>>>> it > >>>>>>>>> reads something like: > >>>>>>>>> src [VPN_virtual_private_IP]/32 dst [VPN_subnet]/8 > >>>>>>>>> dir out priority 2947 > >>>>>>>>> tmpl src [LAN_IP] dst [public_VPN_gateway] > >>>>>>>>> proto esp reqid 1 mode tunnel > >>>>>>>>> > >>>>>>>>> Is that right? > >>>>>>>>> > >>>>>>>>> Alan > >>>>>>>>> > >>>>>>>>> Note: > >>>>>>>>> [1] Combinations attempted: > >>>>>>>>> leftsubnet not specified > >>>>>>>>> rightsubnet=0.0.0.0/0 > >>>>>>>>> Result: connection works, but Internet traffic is routed through > >>>>>>>>> the > >>>>>>>>> VPN > >>>>>>>>> gateway > >>>>>>>>> > >>>>>>>>> leftsubnet not specified > >>>>>>>>> rightsubnet=10.0.0.0/8 > >>>>>>>>> Result: tunnel doesn't come up > >>>>>>>>> > >>>>>>>>> leftsubnet=10.0.0.0/8 > >>>>>>>>> rightsubnet=10.0.0.0/8 > >>>>>>>>> Result: tunnel doesn't come up > >>>>>>>>> > >>>>>>>>> leftsubnet=172.31.0.0/16 > >>>>>>>>> rightsubnet=10.0.0.0/8 > >>>>>>>>> Result: tunnel doesn't come up > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On 5/31/15, Noel Kuntze <[email protected]> wrote: > >>>>>>>>>> > >>>>>>>>> Hello Alan, > >>>>>>>>> > >>>>>>>>> IPsec on Linux nowadays is policy based, not route based. > >>>>>>>>> You need to write bypass/passthrough policies that define what > >>>>>>>>> traffic should not be subject to IPsec processing > >>>>>>>>> > >>>>>>>>> Look at the test scenarios[1][2] for that to get an idea on > >>>>>>>>> how to define it. > >>>>>>>>> > >>>>>>>>> [1]https://www.strongswan.org/uml/testresults/ikev2/shunt-policies-nat-rw/index.html > >>>>>>>>> [2]https://www.strongswan.org/uml/testresults/sql/shunt-policies-nat-rw/index.html > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Mit freundlichen Grüßen/Kind Regards, > >>>>>>>>> Noel Kuntze > >>>>>>>>> > >>>>>>>>> GPG Key ID: 0x63EC6658 > >>>>>>>>> Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 > >>>>>>>>> > >>>>>>>>> Am 31.05.2015 um 17:08 schrieb Alan Tu: > >>>>>>>>>>>> Hello, I'm still new to ipsec VPNs and Strongswan, and I'd like > >>>>>>>>>>>> to > >>>>>>>>>>>> run > >>>>>>>>>>>> the scenario by the group, with potentially a feature > >>>>>>>>>>>> suggestion. > >>>>>>>>>>>> > >>>>>>>>>>>> I'm trying to implement what seems to be called split > >>>>>>>>>>>> tunneling, > >>>>>>>>>>>> without the cooperation or configuration of the remote VPN > >>>>>>>>>>>> gateway. > >>>>>>>>>>>> > >>>>>>>>>>>> I'm a road warrior connecting to a VPN over the Internet, with > >>>>>>>>>>>> the > >>>>>>>>>>>> following pertinent configuration settings: > >>>>>>>>>>>> conn vpn > >>>>>>>>>>>> type=tunnel > >>>>>>>>>>>> keyexchange=ikev1 > >>>>>>>>>>>> aggressive=yes > >>>>>>>>>>>> left=%any > >>>>>>>>>>>> leftsourceip=%modeconfig > >>>>>>>>>>>> right=[public IP VPN gateway] > >>>>>>>>>>>> rightsubnet=0.0.0.0/0 > >>>>>>>>>>>> > >>>>>>>>>>>> Other users using proprietary VPN clients or VPNC still have > >>>>>>>>>>>> their > >>>>>>>>>>>> non-VPN-LAN traffic (browsing, etc) routed over the users' > >>>>>>>>>>>> local > >>>>>>>>>>>> WAN, > >>>>>>>>>>>> but I noticed all of my Internet traffic was going through the > >>>>>>>>>>>> VPN. > >>>>>>>>>>>> According to the Strongswan split tunneling page [1], IKE v1 > >>>>>>>>>>>> doesn't > >>>>>>>>>>>> easily support split tunneling. But after reading and thinking, > >>>>>>>>>>>> I > >>>>>>>>>>>> realized altering the routing table might achieve the effect I > >>>>>>>>>>>> want. > >>>>>>>>>>>> > >>>>>>>>>>>> Post-VPN routing table 220: > >>>>>>>>>>>> $ ip route show table 220 > >>>>>>>>>>>> default via [WAN gateway IP] dev eth0 proto static src [VPN > >>>>>>>>>>>> virtual > >>>>>>>>>>>> private IP] > >>>>>>>>>>>> > >>>>>>>>>>>> So I did: > >>>>>>>>>>>> # ip route add table 220 [VPN subnet] via [WAN gateway IP] dev > >>>>>>>>>>>> eth0 > >>>>>>>>>>>> proto static src [VPN virtual private IP] > >>>>>>>>>>>> > >>>>>>>>>>>> This told the kernel, I hoped, to direct traffic going to the > >>>>>>>>>>>> VPN > >>>>>>>>>>>> subnet to the ipsec tunnel. XFRM policies and states would then > >>>>>>>>>>>> take > >>>>>>>>>>>> over. > >>>>>>>>>>>> > >>>>>>>>>>>> Next, I wanted to change the default route so that non-VPN > >>>>>>>>>>>> traffic > >>>>>>>>>>>> would go through the local WAN/Internet connection: > >>>>>>>>>>>> # ip route change table 220 default via [WAN gateway IP] src > >>>>>>>>>>>> [original > >>>>>>>>>>>> eth0 IP] > >>>>>>>>>>>> > >>>>>>>>>>>> And so far, things seem to work the way I intend. I can still > >>>>>>>>>>>> access > >>>>>>>>>>>> the VPN subnet, but connections going to the Internet originate > >>>>>>>>>>>> from > >>>>>>>>>>>> my original network connection's address. > >>>>>>>>>>>> > >>>>>>>>>>>> Am I missing anything? And if this is a valid scenario, is > >>>>>>>>>>>> there > >>>>>>>>>>>> any > >>>>>>>>>>>> way I can set this up more intuitively in ipsec.conf? And if > >>>>>>>>>>>> not, > >>>>>>>>>>>> I'm > >>>>>>>>>>>> wondering if it might be beneficial to have the capability to > >>>>>>>>>>>> configure a connection like this in ipsec.conf. Most of the > >>>>>>>>>>>> variables > >>>>>>>>>>>> are more easily available to the Strongswan daemon when a > >>>>>>>>>>>> connection > >>>>>>>>>>>> is brought up, and it would seemingly give users an easy way to > >>>>>>>>>>>> configure a form of "split tunneling". > >>>>>>>>>>>> > >>>>>>>>>>>> Alan > >>>>>>>>>>>> > >>>>>>>>>>>> Note: > >>>>>>>>>>>> [1] > >>>>>>>>>>>> https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling > >>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>> Users mailing list > >>>>>>>>>>>> [email protected] > >>>>>>>>>>>> https://lists.strongswan.org/mailman/listinfo/users > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> Users mailing list > >>>>>>>>>> [email protected] > >>>>>>>>>> https://lists.strongswan.org/mailman/listinfo/users > >>>>>> > >>>>>>> > >>>>>>> > >>> > >>>> > >>>> > >>>> > >> >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 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----- _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
