Re: Fw: [Bug 213669] New: PMTU dicovery not working for IPsec

[Vadim Fedorenko <vfedorenko@novek.ru>]

On 07.07.2021 17:06, David Ahern wrote:
> On 7/7/21 9:52 AM, Vadim Fedorenko wrote:
>> On 07.07.2021 15:07, Stephen Hemminger wrote:
>>>
>>>
>>> Begin forwarded message:
>>>
>>> Date: Wed, 07 Jul 2021 09:08:07 +0000
>>> From: bugzilla-daemon@bugzilla.kernel.org
>>> To: stephen@networkplumber.org
>>> Subject: [Bug 213669] New: PMTU dicovery not working for IPsec
>>>
>>>
>>> https://bugzilla.kernel.org/show_bug.cgi?id=213669
>>>
>>>               Bug ID: 213669
>>>              Summary: PMTU dicovery not working for IPsec
>>>              Product: Networking
>>>              Version: 2.5
>>>       Kernel Version: 5.12.13
>>>             Hardware: x86-64
>>>                   OS: Linux
>>>                 Tree: Mainline
>>>               Status: NEW
>>>             Severity: high
>>>             Priority: P1
>>>            Component: IPV4
>>>             Assignee: stephen@networkplumber.org
>>>             Reporter: marek.gresko@protonmail.com
>>>           Regression: No
>>>
>>> Hello,
>>>
>>> I have two sites interconnected using ipsec (libreswan)
>>>
>>> the situation is as follows:
>>>
>>> X <=> (a) <=> (Internet) <=> (b) <=> Y
>>>
>>> So you have two gateways a and b connected to the internet and their
>>> corresponding internal subnets X and Y. The gateway a is connected to the
>>> provider p using pppoe. The ipsec tunnel is created between a and b to
>>> interconnect subnets X and Y. When gateway b with internal address y
>>> itself is
>>> communication to the gateway a using its internal address x. Addresses
>>> x and y
>>> are defined by leftsourceif and rightsourceip in the libreswan
>>> configuration,
>>> you get this behavior:
>>>
>>> b# ping -M do x -s 1392 -c 1
>>> PING x (x.x.x.x) 1392(1420) bytes of data.
>>>
>>> --- ping statistics ---
>>> 1 packets transmitted, 0 received, 100% packet loss, time 0ms
>>>
>>> b# ping -M do a -s 1460 -c 3
>>> PING a (a.a.a.a) 1460(1488) bytes of data.
>>>   From p (p.p.p.p) icmp_seq=1 Frag needed and DF set (mtu = 1480)
>>> ping: local error: message too long, mtu=1480
>>> ping: local error: message too long, mtu=1480
>>>
>>> --- ping statistics ---
>>> 3 packets transmitted, 0 received, +3 errors, 100% packet loss, time
>>> 2014ms
>>>
>>> b# ping -M do x -s 1392 -c 3
>>> PING x (x.x.x.x) 1392(1420) bytes of data.
>>> ping: local error: message too long, mtu=1418
>>> ping: local error: message too long, mtu=1418
>>> ping: local error: message too long, mtu=1418
>>>
>>> --- ping statistics ---
>>> 3 packets transmitted, 0 received, +3 errors, 100% packet loss, time
>>> 2046ms
>>>
>>>
>>> Legend:
>>> x.x.x.x is an inner ip address if the gateway (a) (or x from the inside).
>>> a.a.a.a is an outer address of the gateway (a).
>>> p.p.p.p is some address in the provider's network of the (a) side.
>>>
>>> So definitely the ipsec tunnel is aware of the mtu only when some outer
>>> communication is in progress. The inner communication itself is not
>>> aware of
>>> icmp packets using for PMTU discovery. I had also a situation when
>>> also the
>>> outer pings did not help the ipsec to be aware of the MTU and after
>>> reboot it
>>> started to behave like discribed again.
>>>
>>> Did I describe it understandably or should I clarify things?
>>>
>>> Thanks
>>>
>>> Marek
>>>
>>
>> Looks like I didn't cover one more case in my MTU patch series. I'll try
>> to look
>> deeper
> 
> 
> pmtu.sh test script covers xfrm (esp) cases with vti devices. Could add
> more ipsec test cases to it.
> 
Sure, I'll add tests too