"Darryl Hoar" <[EMAIL PROTECTED]> writes: > I am running 4.7-stable on a box. It is my firewall, nat box. > ep0 is connected to my ISP's dsl. ep1 is connected to > my internal private LAN. My internal lan uses the private > ip addresses 192.168.1.x. I have two machines on my > internal lan, not including the firewall box. > > I am getting > /kernel arplookup failure: 10.1.1.1 not on local network. > > my ISP assigns a real IP to my ep0 interface usings dhcp. > > what is causing this and how do I stop it ? I have added a > rule to block 10.x.x.x in, but it has not stopped the messages.
That kind of makes sense, because ARP isn't IP, and ipfw doesn't, so far as I can see, have a way to filter it specifically. I don't think that ARP packets even get to it, but I'm too lazy to go check right now. > I can ping 10.1.1.1, and if I down ep0, I cannot ping 10.1.1.1. That's ICMP, which *also* isn't -- exactly -- IP (but it's tied tightly enough to it that ipfw has special provisions for it). > I have alerted my ISP to this problem (thought 10.x.x.x weren't > suppose to be routed). Unfortunately, it's not clear that they're doing anything wrong. They can route RFC 1918 addresses all they want, as long as they stay within their own network. One thing you could do that I *think* would stop those messages is to put an alias on your outside network on the 10.1.x.x network. As long as you keep the IP block on those addresses, it shouldn't open up any vulnerabilities. Incidentally, I think that these comments apply as well to ipfilter as to ipfw. On the other hand, I've got to be overlooking something, because running multiple subnets on the same wire is a pretty common thing to do. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
