IPv4: host X.X.X.X/if5 ignores redirects for A.A.A.A to B.B.B.B

I’m running 1.3.3 and my messages log is filled with “ignores redirects” messages but in testing, my traffic is passing and redirecting properly. This wasn’t happening in 1.3.0, 1.3.1 or 1.3.2 btw.

The messages are referring to hosts I have policy routes for that directs specific traffic over to my site to site VPN IP for passing and it’s working properly. Not sure if I should just ignore these or if there’s something to do to clean it up.

Example message:
Aug 15 20:13:28 VyOSFW1 kernel: [313751.836158] IPv4: host 10.6.16.10/if5 ignores redirects for 10.2.0.10 to 10.100.1.2

10.6.16.10 is a host at site A, 10.2.0.10 is a host at site B, and 10.100.1.2 is the VPN server that handles site to site between site A and B. If I trace back and forth, the traffic is clearly using the tunnel so the redirect is working.

Policy route config:

set policy route VPN rule 1000 destination address '10.2.0.0/16'
set policy route VPN rule 1000 set table '10'
set policy route VPN rule 1000 source address '10.6.0.0/16'
set protocols static table 10 route 0.0.0.0/0 next-hop 10.100.1.2

From some research, it could be a netmask mismatch error because my policy route is applied to 10.6.0.0/16 and 10.6.16.10 is part of a vlan that covers only 10.6.16.0/24 but I wanted to see if anyone else has run into this and if it’s anything to be concerned about since it’s not actually traffic affecting, more of an annoyance since it’s causing my logs to rotate quickly.

To me that looks like some ICMP redirect message that your kernel at VyOS is trying to send to the host 10.6.16.10.

Generally speaking ICMP redirects should be avoided.

I assume you have a setup like:

ClientA (10.6.16.10) ↔ VyOSA ↔ unknown network ↔ VyOSB ↔ ClientB (10.2.0.10)

What IP-addresses does VyOSA and VyOSB use towards their clients?

Somewhat, there’s also a L3 switch in the mix. Here’s the path traffics taking:

The log lines are from VyOSA
SiteA has multiple VLAN’s broke into /22’s, /24’s, /28’s, etc, however all that need to be routed over the site to site are covered by the 10.6.0.0/16 network.