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:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> 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
>
> iQIcBAEBCAAGBQJVa2a6AAoJEDg5KY9j7GZY6zoP/0NW+rxSwekc3uVtkoayiMRB
> yc+Y8ploXykIuzjI4oVMmXPi5VV6r32dVwUJuw59CTxVoCJd2G/J+GwwBjIxZA9Q
> 7g0o9y9EKYjP7yceVIWaNuuSRd7vNJXcd7nrceNd//TlsSKShZ+pm03EIG0DqXmg
> 5dDBgExeUPM02kbNH+DEg4bOxNc+0rBj6Ou+1mr7/vpbRlK0zIekvWsgjbpdPe2A
> dQr9oai+f8MpCPzmE/qXlWP4KV9nBIvanrARDgWjujQMWE7hJlc9/YNcs5ZRhqu/
> /z8jhyUicasQPiv4ngOIiIFRrknTKpWwS1kXgPrzYpFEFVdqB5egowrfI9D8Npfo
> Qgq1bf3Pj+fgcKUXOlsGewnQnPIC4SHuv86y1LW2DrmfS340oYeBG1MIhuWuQp3t
> TycrS5i/3mcfv96EA08eE0p4/n/We7n962DsFh05alYTXKwNdRoORQS0D32sDTF7
> qAlBYTmIU/a/tISXUDT5jRFUrK8/pq+2SWGRlBwdUwtUDLpyVJuM20YMn37PHNWq
> gtstqCXbAzc7H7A88U3h2rv8XVL+kFIAsyWPDgubzhlP+a3p/VmqgrJIVl6kqdOa
> G9hNIFVNyd8k6yk9qr3p9NUXZasuWCObyr1NCJGHkUSK4TmnCtSOCqpPorREx8fg
> BKWr74nlfIfpSNV7EQ/k
> =+LOG
> -----END PGP SIGNATURE-----
>
>