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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 7 Jul 2021 10:06:00 -0600
From:   David Ahern <dsahern@...il.com>
To:     Vadim Fedorenko <vfedorenko@...ek.ru>,
        Stephen Hemminger <stephen@...workplumber.org>,
        netdev@...r.kernel.org
Cc:     David Ahern <dsahern@...nel.org>, Jakub Kicinski <kuba@...nel.org>
Subject: Re: Fw: [Bug 213669] New: PMTU dicovery not working for IPsec

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@...zilla.kernel.org
>> To: stephen@...workplumber.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@...workplumber.org
>>            Reporter: marek.gresko@...tonmail.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.