Hiya, OK, it sounds like the DMZ and Internal networks are plugged into the same hub, and that the hub is then plugged twice into the PIX - once into the Internal network and once into the DMZ network. That's your problem. Back in my original email, I said that the only thing that could cause the problem in normal operation was that "your DMZ is ethernet-connected somehow to your internal network".
So, what's happening? Well, whenever the Inside interface of the PIX wants to talk to an inside box it will send an ARP request (as in "who-has IP address 10.0.0.2" or whatever). The box will then reply "10.0.0.2 is-at a070.d0c6.005b" or somesuch. The trouble is that that reply is _broadcast_ on an ethernet level. Every port on the hub will see it. Including the PIX DMZ interface. What happens now is that not only does the PIX add the address to it's Internal arp cache, but the DMZ interface also sees the reply, and adds it to its own cache, in case it needs it. Now it gets interesting. What happens _now_ is that the next time something asks for the address of one of those internal hosts (probably including the Internal NIC on the PIX) the DMZ interface will see the request (also broadcast) and think "Ahh - that's not on my subnet, but I do know where it is. I'll proxy-arp for it.". The DMZ NIC then sends an arp reply of its own, and tells a bald-faced lie - ie "10.0.0.2 is-at <mac address of PIX DMZ>". This will then replace the last entry in the arp cache of the requesting device, and all traffic for 10.0.0.2 will start getting sent to the PIX DMZ interface, and at that point everything will start going crazy. Phew. SO! When you turn off proxy-arp, the DMZ interface simply notes with polite interest that there's traffic it can see which isn't on it's own subnet, doesn't do anything, and things carry on as normal. You do, however, still have a really quite silly setup, security-wise, until you get that hub replaced by two switches (or two hubs). Your previous consultant should be tracked down, birched to within an inch of their lives, covered in honey and be put naked in a cage with an amorous baboon. As you can probably now see, there is no way to stop this which is better or easier than the no proxy arp solution you have already worked out. Now that we've finished the boring investigative wrangling (snipped), I've re-copied this to the list (hope you don't mind). Cheers! -- Ben Nagy Network Security Specialist Mb: TBA PGP Key ID: 0x1A86E304 > -----Original Message----- > From: kk downing [mailto:[EMAIL PROTECTED]] > Sent: Monday, May 13, 2002 9:58 PM > To: Ben Nagy > Subject: RE: PIX internal to DMZ problems > > > Ben. > Our company just inherited this site, which some > consultant set up and is poorly documented. I am > finding out now that the internal net and the DMZ net > are plugged into the same hub, which is then plugged > into either the DMZ or the internal interface of the > PIX. The gear is located on the other side of the > country so I am dealing with a moron on the phone for > much of this. I think the problem lies with this hub > set up. However I don't see why both NICs are arping > the same addresses. Can you give me the technical > "why" this is occuring and is there a way to remedy > this beside my "sysopt no proxy arp" statement, until > I can get a pair of switches out there? > > You understood me correctly I think. Actually the > masks are not along classful lines like that. the > 10.0.0.0 net has a class c mask as does my 172.16.0.0 > network. This is how it was set up before me. [...] _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] For Account Management (unsubscribe, get/change password, etc) Please go to: http://lists.gnac.net/mailman/listinfo/firewalls
