On 10/18/2018 05:38 PM, Grant Taylor wrote:
I can get ARP to respond. But I've not gotten ICMP to function yet. It looks like it may be, funny enough, an ARP issue. B has two ARP entries for A's IP, one from the what it learned from A's ARP request and an incomplete entry. I've not done any more investigation to see if I can make this work. Yet. }:-)
Okay. I've done some more investigating and I think it is more of a routing issue than /just/ an ARP issue. In short, the kernel doesn't quite know what to do with the traffic destined to one subnet with an ARP entry for a different interface than the subnet is on.
I think I'm going to need to reconfigure the network a bit to have B function as a router with A being on the wrong interface. Probably something like this:(A)---1---(B)---2---(C) | 3 | (D)Such that A looks like it moved from the 3 network to the 1 network. With C being something on the other side of "the router", B.
This wasn't enough.
Once I had the network namespace TCP/IP stacks set to defaults, B did in fact respond to A's ARP request for an IP on the 2nd network.
rp_filter (Reverse Path Filtering) seems to also protect ARP.The biggest issue that I can see with arp_filter is that it may disclose information about other interfaces on a router. Where as if arp_filter is enabled, then the information won't be leaked.
rp_filter vs arp_filter rp_filter will only protect incorrect routed paths. arp_filter will protect disclosure / leakage from correct routed paths.
I plan on starting to keep arp_filter enabled in addition to rp_filter on my machines. At least until I have a reason not to do so.
-- Grant. . . . unix || die
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
