netdev - Re: big ICMP requests get disrupted on IPSec tunnel activation

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]

Message-ID: <d0c8ebbb-3ed3-296f-d84a-6f88e641b404@gmail.com>
Date:   Fri, 13 Sep 2019 11:13:27 -0600
From:   David Ahern <dsahern@...il.com>
To:     "Bartschies, Thomas" <Thomas.Bartschies@....de>,
        "'netdev@...r.kernel.org'" <netdev@...r.kernel.org>
Subject: Re: big ICMP requests get disrupted on IPSec tunnel activation

On 9/13/19 9:59 AM, Bartschies, Thomas wrote:
> Hello together,
> 
> since kenel 4.20 we're observing a strange behaviour when sending big ICMP packets. An example is a packet size of 3000 bytes.
> The packets should be forwarded by a linux gateway (firewall) having multiple interfaces also acting as a vpn gateway.
> 
> Test steps:
> 1. Disabled all iptables rules
> 2. Enabled the VPN IPSec Policies.
> 3. Start a ping with packet size (e.g. 3000 bytes) from a client in the DMZ passing the machine targeting another LAN machine
> 4. Ping works
> 5. Enable a VPN policy by sending pings from the gateway to a tunnel target. System tries to create the tunnel
> 6. Ping from 3. immediately stalls. No error messages. Just stops.
> 7. Stop Ping from 3. Start another without packet size parameter. Stalls also.
> 
> Result:
> Connections from the client to other services on the LAN machine still work. Tracepath works. Only ICMP requests do not pass
> the gateway anymore. tcpdump sees them on incoming interface, but not on the outgoing LAN interface. IMCP requests to any
> other target IP address in LAN still work. Until one uses a bigger packet size. Then these alternative connections stall also.
> 
> Flushing the policy table has no effect. Flushing the conntrack table has no effect. Setting rp_filter to loose (2) has no effect.
> Flush the route cache has no effect.
> 
> Only a reboot of the gateway restores normal behavior.
> 
> What can be the cause? Is this a networking bug?
> 

some of these most likely will fail due to other reasons, but can you
run 'tools/testing/selftests/net/pmtu.sh'[1] on 4.19 and then 4.20 and
compare results. Hopefully it will shed some light on the problem and
can be used to bisect to a commit that caused the regression.


[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/net/pmtu.sh