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

* [Bug?] Linux ignore ICMP Redirect for TCP packets get discharged silently
@ 2022-11-17  4:46 Daniele Palumbo
  0 siblings, 0 replies; 2+ messages in thread
From: Daniele Palumbo @ 2022-11-17  4:46 UTC (permalink / raw)
  To: netdev

[-- Attachment #1: Type: text/plain, Size: 2874 bytes --]

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)

[-- Attachment #2: sarin-replicate.pcap --]
[-- Type: application/octet-stream, Size: 9567 bytes --]

[-- Attachment #3: Linux-ignoring-ICMP_Redirect.drawio.png --]
[-- Type: image/png, Size: 73689 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread