[strongSwan] XFRM fragmentation before encapsulation

[Noel Kuntze]

Hello André,

> 
> I cannot confirm that. Of course, you never know what happens with pmtu discovery on WAN side, that's a problem.
> We have a multi tenancy VPN gateway based on strongswan, kernel 4.19 and NO ipsec interfaces.
> PMTU discovery seems to work:
> ~# ping -I 100.64.0.1 -m 123455 -s 1480 -M do 1.2.3.4
> PING 1.2.3.4 (1.2.3.4) from 100.64.0.1 : 1480(1508) bytes of data.
> ping: local error: Message too long, mtu=1438
> ping: local error: Message too long, mtu=1438

That is fine and exactly what I also experience. With -M do set up, the DF bit is set in the IP packets, which prevents any fragmentation.
That the error is locally delivered is the cause of the error message. The IP packets with which I tested were ICMP packets with the DF bit
*not* set. I expect those packets to be fragmented, but they were not.

> vti is an alternative, but only nice for static setups.

Yeah. It might still work. Maybe using a netns to fragment the packets works. I'd need to test any more intricate solution first.

Kind regards

Noel

Am 22.10.19 um 13:01 schrieb André Valentin:
> Hi Noel!
> 
> Am 22.10.19 um 00:14 schrieb Noel Kuntze:
>> Hello André,
> 
> I cannot confirm that. Of course, you never know what happens with pmtu discovery on WAN side, that's a problem.
> We have a multi tenancy VPN gateway based on strongswan, kernel 4.19 and NO ipsec interfaces.
> PMTU discovery seems to work:
> ~# ping -I 100.64.0.1 -m 123455 -s 1480 -M do 1.2.3.4
> PING 1.2.3.4 (1.2.3.4) from 100.64.0.1 : 1480(1508) bytes of data.
> ping: local error: Message too long, mtu=1438
> ping: local error: Message too long, mtu=1438
> 
> 1438 fits with WAN MTU 1500 and AES128+sha1
> 
> Sometimes it is a bit problematic if you use rule based routing. In that case you have to make sure, that the
> generated ICMP can be routed to the correct target. It took me some time to notice that,
> because there seem to be several places in the kernel were this is done (and use different source addresses).
> I debugged that with tcpdump -nnfli any 'icmp[icmptype] == 3 && icmp[icmpcode] == 4'
> 
>>
>> I just did my own tests and came to the following conclusion:
>> 1) pmtu doesn't work in any of the cases.
>> 2) By default, it doesn't work at all.
>> 3) When you try to fix it by setting the MTU of the route to the remote IPsec router,
>>    you start getting fragments, but not of the inside IP packets, but the outside ESP/ESPINUDP packets
> 
> That is what I need for my special case. I did not get it working that way.
> Nevertheless, do not forget to clear route cache:
> ip ro fl cache
> And check with
> ip ro get TARGET-IP
> if the kernel has the correct PMTU remembered.
> 
> I also would create a virtual router in front of the IPsec gw. There you change PMTU and verify on the linux side.
> 
>> 4) It only works when using an XFRM interface when the MTU of it is set correctly (max link MTU - IPsec overhead).
>>    Then you get ESP encapsulated IP fragments, like you want to.
> 
> xfrm if work fine.
> 
>> This ia complete disaster.
>> It doesn't work OOTB and stops working once either of the peers moves between networks with a lower MTU.
> Perhaps that's a problem on the wan side (Not sending ICMP Fragmentation needed to IPsec gw)?
> 
>> There's currently no automatic solution for this and XFRM interfaces are too new to be a solution for setups with old kernels.
> vti is an alternative, but only nice for static setups.
> 
> Kind regards,
> 
> André
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20191022/8e8796b0/attachment.sig>