Hi, On Tue, Nov 5, 2019 at 6:05 PM Tom Eastep <teas...@shorewall.net> wrote: > > > Do you mean I should use rpfilter in the "interfaces" file (I've never > > used routefilter)? Which interface? The one I'm seeing the martian > > source messages for? Incidentally, adding the rpfilter option to > > enp8s5 yields a 0 in /proc/sys/net/ipv4/conf/enp8s5/rp_filter. > > Which is exactly what you want. I suspect that your sysconf > configuration is setting that option to 1.
# sysctl -a | grep '\.rp_filter' net.ipv4.conf.all.rp_filter = 0 net.ipv4.conf.blan.rp_filter = 0 net.ipv4.conf.blan/1.rp_filter = 0 net.ipv4.conf.blan/12.rp_filter = 0 net.ipv4.conf.blan/13.rp_filter = 0 net.ipv4.conf.blan/14.rp_filter = 0 net.ipv4.conf.blan/15.rp_filter = 0 net.ipv4.conf.blan/16.rp_filter = 0 net.ipv4.conf.blan/17.rp_filter = 0 net.ipv4.conf.blan/18.rp_filter = 0 net.ipv4.conf.bond0.rp_filter = 0 net.ipv4.conf.default.rp_filter = 0 net.ipv4.conf.enp10s0.rp_filter = 0 net.ipv4.conf.enp5s0.rp_filter = 0 net.ipv4.conf.enp5s0/1.rp_filter = 0 net.ipv4.conf.enp5s0/11.rp_filter = 0 net.ipv4.conf.enp5s0/12.rp_filter = 0 net.ipv4.conf.enp5s0/13.rp_filter = 0 net.ipv4.conf.enp5s0/14.rp_filter = 0 net.ipv4.conf.enp5s0/15.rp_filter = 0 net.ipv4.conf.enp5s0/16.rp_filter = 0 net.ipv4.conf.enp6s0.rp_filter = 0 net.ipv4.conf.enp7s0f0.rp_filter = 0 net.ipv4.conf.enp7s0f1.rp_filter = 0 net.ipv4.conf.enp7s0f2.rp_filter = 0 net.ipv4.conf.enp7s0f3.rp_filter = 0 net.ipv4.conf.enp8s5.rp_filter = 0 net.ipv4.conf.enp8s5/100.rp_filter = 0 net.ipv4.conf.lo.rp_filter = 0 net.ipv4.conf.tun146.rp_filter = 0 net.ipv4.conf.tun147.rp_filter = 0 net.ipv4.conf.tun148.rp_filter = 0 > A martian packet is one that is received on an interface from a host > that is routed out of a different interface. As I mentioned before, it > does not take policy routing into account. > > > > Nov 5 13:40:15 kernel: net_ratelimit: 137 callbacks suppressed > > Nov 5 13:40:15 kernel: IPv4: martian source 10.215.248.9 from > > 10.215.144.91, on dev enp8s5 > > Nov 5 13:40:15 kernel: ll header: 00000000: ff ff ff ff ff ff e8 ea > > 6a 0c 4c 1c 08 06 ........j.L... > > Nov 5 13:40:15 kernel: IPv4: martian source 10.215.241.221 from > > 10.215.144.35, on dev enp8s5 > > Nov 5 13:40:15 kernel: ll header: 00000000: ff ff ff ff ff ff 00 50 > > 56 92 5b 09 08 06 .......PV.[... > > Nov 5 13:40:15 kernel: IPv4: martian source 10.215.246.124 from > > 10.215.144.91, on dev enp8s5 > > Nov 5 13:40:15 kernel: ll header: 00000000: ff ff ff ff ff ff e8 ea > > 6a 0c 4c 1c 08 06 ........j.L... > > Nov 5 13:40:15 kernel: IPv4: martian source 10.215.144.89 from > > 10.215.144.91, on dev enp8s5 > > Nov 5 13:40:15 kernel: ll header: 00000000: ff ff ff ff ff ff e8 ea > > 6a 0c 4c 1c 08 06 ........j.L... > > Nov 5 13:40:15 kernel: IPv4: martian source 10.215.146.23 from > > 10.215.144.47, on dev enp8s5 > > Nov 5 13:40:15 kernel: ll header: 00000000: ff ff ff ff ff ff 18 60 > > 24 ef b9 09 08 06 .......`$..... > > Nov 5 13:40:15 kernel: IPv4: martian source 10.215.144.31 from > > 10.215.144.67, on dev enp8s5 > > Nov 5 13:40:15 kernel: ll header: 00000000: ff ff ff ff ff ff 00 50 > > 56 b6 05 90 08 06 .......PV..... > > Nov 5 13:40:15 kernel: IPv4: martian source 10.215.247.134 from > > 10.215.144.91, on dev enp8s5 > > Nov 5 13:40:15 kernel: ll header: 00000000: ff ff ff ff ff ff e8 ea > > 6a 0c 4c 1c 08 06 ........j.L... > > Nov 5 13:40:15 kernel: IPv4: martian source 10.215.147.32 from > > 10.215.144.23, on dev enp8s5 > > Nov 5 13:40:15 kernel: ll header: 00000000: ff ff ff ff ff ff 52 54 > > 00 de a6 34 08 06 ......RT...4.. > > Nov 5 13:40:15 kernel: IPv4: martian source 10.215.147.13 from > > 10.215.144.91, on dev enp8s5 > > Nov 5 13:40:15 kernel: ll header: 00000000: ff ff ff ff ff ff e8 ea > > 6a 0c 4c 1c 08 06 ........j.L... > > Nov 5 13:40:15 kernel: IPv4: martian source 10.215.246.40 from > > 10.215.247.70, on dev enp8s5 > > Nov 5 13:40:15 kernel: ll header: 00000000: ff ff ff ff ff ff c4 34 > > 6b 61 b7 bb 08 06 .......4ka.... > > > > In fact, I should not be seeing traffic between hosts with IP > > addresses in the 10.215.* range on this enp8s5 interface. This could > > be a loopback on the main switch since there's another NIC on the > > Shorewall router connecting to the same switch. However, enp8s5 is > > connected to a switch port with a specific VLAN ID. If the VLAN > > implementation on this switch is correct, it should be impossible for > > traffic for the 10.215.* hosts to reach the enp8s5 interface. > > Does the martians log prove that there's something wrong on the main switch? > > > > Seems like it. I dumped some traffic on that interface (enp8s5), and I can see that it's mostly ARP requests, DHCPv6, etc., but there's also SMB2. I presume ARP requests can flow through different VLANs, but layer-3 traffic shouldn't. The dump is available here if you'd like to take a look at it: https://drive.google.com/file/d/1v0KiMCBrqSdsn3Z-VTIsZAT1dj3zG90O/view?usp=sharing During the dump, the VLAN was supposedly empty (no on-line hosts). Vieri _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
