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

[Noel Kuntze]

-----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-----