Re: Fw: [Bug 213669] New: PMTU dicovery not working for IPsec
From: David Ahern <hidden>
Date: 2021-07-07 16:06:11
On 7/7/21 9:52 AM, Vadim Fedorenko wrote:
On 07.07.2021 15:07, Stephen Hemminger wrote:quoted
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 MarekLooks 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.