Re: Proxy ARP with a Coyote Point equalizer

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 05/31/07 13:41, Greg Scott wrote:
I was thinking about what Grant said in his earlier reply about bridging, and the more I think about it, the more I think Grant is right. I was watching tcpdump and some firewall accounting rules when we tried this the other day and I saw all kinds of traffic that had absolutely nothing to do with my network - and I was blocking it! And I kept wondering, why was I blocking traffic that had a destination IP address nowhere near me that I should not care about?

That's not good.

Well, this is a co-location site, so an Ethernet connects this network to the Internet, not a point to point serial or any kind of WAN. No doubt lots of other folks had their networks in racks in the same room on the same extended Ethernet as my stuff.

Probably. However I have to ask, why are so many different networks sharing one broadcast domain? Or could it be that traffic was trying to be routed to the target subnet, but your system responded to the ARP for the IP of the target router??? I wonder... Either way, this is not good.

This is also why I have seriously considered statically setting some IP to MAC address mappings in some more stringent environments. If the upstream router knows the MAC address of my router, it will not need to ARP for it and thus I do not care if someone else claims to use my IP or not because the router will know which MAC address to use.

But still, why did my box care about any of this traffic at all? Why would I specifically block it - why didn't the NIC in my box just ignore it, the way most normal systems do in an Ethernet for traffic it doesn't care about? Well, duh! It's proxy ARP. Every time anyone, anywhere on this Ethernet, sends out an ARP request and I see it, I answer - yup, here is my MAC Address and it belongs to the IP Address you just asked about. I don't care what IP Address, I answer ARP requests for ALL IP Addresses! I was essentially ARP spoofing the whole world! Well, at least the whole world on that Ethernet that morning.

Oh NO! That was not a good thing. I wonder how many people you effected while doing that.

Holy moley - based on that analysis, proxy ARP should be outlawed from any co-location site, at least anything directly exposed to all the public traffic. For that few minutes, I'll bet I messed up systems belonging to who-knows-how-many customers! Fortunately, it was in the middle of the night in my corner of the world.

Just because it is the middle of the night for you does not mean that it was not 9:30 in the morning for someone else who potentially has their box co-located there. I think I would be tempted to contact your co-location provider and let them know what happened. Consider if you were there administrator trying to figure out why a bunch of clients traffic did not route correctly for a short time and then repaired its self with out any explanation at all. I know that I would want to know if such a thing happened in one of my data centers. At the very least I would want to know that it was not a bug in the router but rather something that is a valid explanation for what happened.

As far as outlawing Proxy ARP, I don't know. I do know that I see no reason to use Proxy ARP when bridging is sow much more powerful and safer. Just think, you an do any and all IPTables (layer 3 and above) firewalling ON a layer 2 device. You can be REALLY devious with this. If course there is also EBTables and ARPTables too.

For Gypsy - it's not my own ARP cache I was messing with, it was everyone else's ARP caches.

Gulp!

Anyway, lesson learned. Maybe this writeup will help somebody else out there. Definitely do bridging.

Here! HERE!



Grant. . . .
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux