netdev - [Bug?] Linux ignore ICMP Redirect for TCP packets get discharged silently

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>] [day] [month] [year] [list]

Date:   Thu, 17 Nov 2022 05:46:24 +0100
From:   Daniele Palumbo <daniele@...aggio.net>
To:     netdev@...r.kernel.org
Subject: [Bug?] Linux ignore ICMP Redirect for TCP packets get discharged
 silently

Hi,

I'm sorry to step in into this very highly technical mailing list with this situation...
I think that i've possibly crossed a bug.
I was trying to lookup via search engines, unfortunately with no luck.

I have the following setup:

VPN Server (site2site, 172.17.16.1) <-> VPN Client (site2site, 172.16.8.7) <-> Linux box (sarin, 172.16.8.14)
The default gw for Linux box (sarin, 172.16.8.14) is another router, Mikrotik (172.16.8.240), which is connected to internet.
All of the Linux servers runs Debian, sarin is on Debian Bullseye (5.10.0-11-arm64).

The ICMP Redirect for TCP packets get discharged silently.

Let me explain via use cases:

Use case 1 KO: ICMP Redirect of TCP connection get discharged silently
test: open a TCP connection to sarin (eg: ssh) from VPN (outside of the LAN)
1) sarin receive the SYN
2) sarin send the SYN/ACK to Mikrotik (correctly)
3) Mikrotik send back a ICMP Redirect for the TCP SYN/ACK to sarin
4) Sarin is ignoring the ICMP Redirect, as the routing cache is not updated. No logs are reported in messages/syslog/dmesg.
evidence:
sarin # ip route show cache
(empty)
sarin # ip route get 172.17.16.1
172.17.16.1 via 172.16.8.240 dev eth0 src 172.16.8.14 uid 0
   cache

Use case 2 OK: ICMP Redirect of ICMP Echo Request get properly parsed
test: send a ICMP Echo Request to sarin from VPN (outside of the LAN)
1) sarin receive the ICMP Echo Request
2) sarin send the ICMP Echo Reply to Mikrotik (correctly)
3) Mikrotik send back a ICMP Redirect for the ICMP Echo Reply to sarin
4) Sarin is acknowledging the ICMP Redirect, and change the cache routing table
sarin evidence just after the ping:
# ip route get 172.17.16.1
172.17.16.1 via 172.16.8.7 dev eth0 src 172.16.8.14 uid 0
   cache <redirected> expires 298sec
sarin # ip route show cache
172.17.16.1 via 172.16.8.7 dev eth0
   cache <redirected> expires 292sec

After that, any TCP connection from the VPN site works (as the routing cache on sarin is populated).

A more useful graph is attached, with the TCP flow.
I'm also attaching a tcpdump of the 2 use case, taken from sarin.
Use case 1: packet 19
Use case 2: packet 33

Random info:
1) this unlikely related to sysctl flags, as ICMP Redirect for ICMP Echo Request are properly parsed
1a) i've tried with/without secure_redirects = 0 on the NIC/all NICs, nothing changes.
1b) accept_redirects = 1
2) *possibly* this issue is not happening with a pfsense in place of mikrotik. Still i can't test it out -- is it a Mikrotik bug?
3) Other devices (eg HP Printer, HP switch) properly manage the ICMP Redirect -- is it a Linux bug?
4) in any case i would expect to see some kind of messages from the linux box if the ICMP redirect get discharged -- is it a Linux bug?

Feel free to ask for any log or information.

Thank you very much,
Daniel (he/him)

Download attachment "sarin-replicate.pcap" of type "application/octet-stream" (9567 bytes)

Download attachment "Linux-ignoring-ICMP_Redirect.drawio.png" of type "image/png" (73689 bytes)