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 16:52:21 +0100
From:   Vadim Fedorenko <vfedorenko@...ek.ru>
To:     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 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