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

[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:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> 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
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJTcmZ5AAoJEDg5KY9j7GZYd58P/ivr2yEICHnyP7qZJZkniWWx
> 6rtM7i6Z3w1tW48XWfBHKeWdDkq9k+vWbO3jTCsCIlFrZG/AGACD6iISItBrr50v
> TH/1k2Ai4Yk9A0LBQH4/CpIADPo3kjNJRsG6cp/Wp4oiEWzH4CXQ2yhNm3CcUmb+
> MKjet2zzRvlXfctuzzvD+gEVbi8yH7FFRQ2D1xeUKicpIeb7tbhO5l2uzPUF36Xa
> N60D/JI0AzyUIYeg7ue3gvCdbJyMIIJ9sfRVfHgUQsgnBCqGukZYfKTLOKCOXYCD
> /ZLHCFB+i0i+SH4RptYOuVJkZGVHhpFVHW3IMws1tCzPYaQiM1AC+yGCHcVUDWuz
> vJiQj4LMwjIFN8YlKTZipEx7PxgvIQ41C6pzQlsXWhrLZ1XiaWkiKCtQtHxJiDA5
> HWpaT34/FUTJHcudgJ63Cbcs+f+sd7c5GtFCYI0gPOdyDjoDCd/70rBGoKhh0wED
> NlETomUzM+Xy6ydBbXrw2hrKtJH8xWtHIb9qO13/z/CdJadITGe8HcDdFVS0/Us0
> izaUsr+nuDed2T9GfBu/RIGsN5xQY2jTfM21QxA1OmdfAYzSB3vBnAhZFObl+uVy
> jAlsBhtHzI9ql5ohT58Rm3gk5ujlycQAbYKnxnKB50oIgR0Uw8Y5Z0M12bNNW3iD
> STLQJUUOKquorbpK0Qov
> =pKpI
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users