[strongSwan] Problem with transport mode and xfrm selector restricting traffic

[Noel Kuntze]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello Brad,

You can change the traffic selectors wih rightsubnet and leftsubnet.
Preventing StrongSwan from installing policies/states with traffic selectors
 is not possible, because that's how the kernel knows what packets to do IPsec processing on.
However, you can make your configuration work by including your public and private IP spaces in left/rightsubnet.
That way the policies will protect the traffic from the hosts in the configured subnets. See [1].
If that does not solve your problem, please provide a packet dump and possibly a log/trace of the packets, when they hit *nat postrouting.
See [2] for the packet flow in the Linux kernel.

[1] http://www.strongswan.org/uml/testresults/ikev2/net2net-psk/
[2] http://inai.de/images/nf-packet-flow.png

Regards,
Noel Kuntze

Am 13.05.2014 20:47, schrieb Brad Johnson:
> Thanks for the speedy reply. I have tried using tunnel mode, which gives us other problems. Also, we are in the process of switching from openswan to strongswan, and this same transport mode configuration worked fine in openswan, because it did not add those traffic selectors to the xfrm states. Also, with strongswan if I manually delete and re-add the xfrm states without the selectors it works fine. So I was wondering if there was any way to configure strongswan so it does not add the traffic selectors.
>
> Regards,
> Brad Johnson
>
> On 05/13/2014 01:37 PM, Noel Kuntze wrote:
> Replied off list.
>
> ------------
>
> Hello Brad,
>
> Transport mode is only for host-to-host tunnels. If you want to create tunnels between networks, you have to use tunnel mode. You also have to use tunnel mode, if the IP addresses the traffic comes from are not the ones between the connection exists.
> e.g. two hosts, which both have two IP addresses (One public, one private each): With transport mode, you can only ping between the public ones. For the private ones or a mix of the two types, you need to use tunnel mode.
> That's caused by the packet structure that is used in transport mode.
>
> Regards,
> Noel Kuntze
>
> Am 13.05.2014 20:09, schrieb Brad Johnson:
> >>> We use a transport type connection to send PPP traffic (so a ppp tunnel inside the VPN). The problem we are having is the xfrm states that get created have selectors restricting the traffic to the left and right IP addresses. So for example, a ping from one ppp tunnel endpoint to the other tunnel endpoint gets dropped on the receiving end. After some kernel debugging it appears the problem is related to the incoming packet being decoded multiple times, first handling the GRE protocol and then the ESP decoding, then finally the IP packet (ping) itself. At that point it appears to match xfrm policies and states when it shouldn't and gets dropped. It seems the packet retains some state from when it first came in as GRE.
> >>> My question is, how can I configure strongswan to create transport type xfrm states without the additional traffic selectors?
> >>>
> >>> Here's the configs at the two sites:
> >>>
> >>> conn Site1
> >>>      left=10.1.1.2
> >>>      right=10.1.3.2
> >>>      auto=start
> >>>      type=transport
> >>>      keyingtries=%forever
> >>>      leftauth=psk
> >>>      rightauth=psk
> >>>      ikelifetime=8h
> >>>      ike=aes256-sha1-modp1536
> >>>      esp=aes256-sha1
> >>>
> >>> conn Site2
> >>>      left=10.1.3.2
> >>>      right=10.1.1.2
> >>>      auto=start
> >>>      type=transport
> >>>      keyingtries=%forever
> >>>      leftauth=psk
> >>>      rightauth=psk
> >>>      ikelifetime=8h
> >>>      ike=aes256-sha1-modp1536
> >>>      esp=aes256-sha1
> >>>
> >>> And it results in the following xfrm states (notice the selectors):
> >>> # ip x s
> >>> src 10.1.3.2 dst 10.1.1.2
> >>>      proto esp spi 0xc30c3862 reqid 5 mode transport
> >>>      replay-window 32
> >>>      auth-trunc hmac(sha1) 0x437e81338a9b43361dd42c51485050b5f4d88fa9 96
> >>>      enc cbc(aes) 0x172d25628008facaa7361830d114215fb9fab8043219b3d49f0aca1c91c24aba
> >>>      sel src 10.1.3.2/32 dst 10.1.1.2/32
> >>> src 10.1.1.2 dst 10.1.3.2
> >>>      proto esp spi 0xc957f846 reqid 5 mode transport
> >>>      replay-window 32
> >>>      auth-trunc hmac(sha1) 0x3d6b0f4041d7e564ce3bef44ce1281e43d4b5825 96
> >>>      enc cbc(aes) 0x7c4753f75e2a96c6fb1e7b75826c37a551900dd2e53b52971ea9319e3b620944
> >>>      sel src 10.1.1.2/32 dst 10.1.3.2/32
> >>>
> >>>
> >>> Thanks in advance for the help,
> >>> Brad Johnson
> >>>
> >>>
> >>> _______________________________________________
> >>> 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.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTcmpoAAoJEDg5KY9j7GZYImQP/1rxVqdyvwzUmZ+9DB53EVKo
XO/2iPlherNmE3ruAvp3mRIgVwo0MmW2JXqcWvLd8YeRXgTJxBE+UeJPGTB7G9p8
ggPVDcZI7auUdgKssV4eQ2+zpqDNJHVUrbQVy/dmnUsg2Z5jSHH6gtf6PY9lBUVf
7cw52Dw0FGSCy05JEf/80Xk4XUZQMjgUEH3Nl0Q3j0GfuWDz/mMIDLcz8cQF5NA2
cmeJixGUSWFWV0LSHOnfSk6qAQiJ4364JBaMnWS2MTThJBOiIW82eYEwLUdWQ0Hv
cgQzUzqaqNRXN27IePxQoqh1aoMjunkQe+Q1BFr0yAMtdAKpFlp0adLkyQaiWDmk
4mCmB/JMDrRVV7WCbcjf9Zyhv2d49DbtKtlRgKqq4juY8Bbgn6AC7N8IB45cySte
SxcFt7CW4b+w3cS4goTQE2xyPTacygzYr2msftOnMD6rZz6mPiGhMYmiD07zJA24
SGqCKnGTxuX7b8Mtw2qe0rxk/61fQdUK2uJsZAyal1OOt6Q0dpd7X2AR5CzHwVM7
/SHYP5xNDW4zwqRK/Cv79+eUlfgl69GN5QseBbZB0Z+Z2S3iMsaP2jmG6qVm0Hgt
S6y4teK6HB6JcHsRi86Q3auQJCgQQ35GLXjY8qQlngs4JjeXXdYoSGxs2Z/f7GGM
aVm0eyO9/xdL/nOkr7BP
=xAhh
-----END PGP SIGNATURE-----