topic PIX & Domain Controller Conflict in Network Security

PIX & Domain Controller Conflict

peterlebaige — Fri, 21 Feb 2020 07:19:49 GMT

Help! We have a PIX firewall, an HP server running Windows 2000 Terminal server & several PCs connected to a 3Com switch. A router is connected on the PIX¡¯s outside interface.

Problem: When users log in from their PCs (Windows XP Service Pack 1) to the domain, the first time each day, the login is extremely slow & their error logs all show they could not find the DC. Checking the the PC's ARP cache now you find there are two entries: 192.168.100.1 (PIX gateway) & 192.168.100.2 (Server)

Both these IPs are resolved to the PIX¡¯s MAC address If you now open a webpage & check the ARP cache again the PIX & server now are resolved to their respective MAC addresses. Logging out now (not rebooting) & logging back in is error-free.

Removing the NAT entry for the server & reloading the PIX stops the problem. Restoring the NAT entry again to allow external access brings the problem back again.

Any suggestions where the problem lies? The firewall configuration is attached.

Re: PIX & Domain Controller Conflict

mostiguy — Tue, 06 Apr 2004 10:36:21 GMT

static (outside,inside) 192.168.100.2 219.235.192.10

netmask 255.255.255.255 0 0

do you need this command? I don't think it can possibly help matters. It would probably force the pix to expect 192.168.100.2 to be on the outside interface of the pix, and the pix might proxy arp for it, creating the problematic arp entries.

it appears that you otherwise have a fairly simply network with nat.

trying removing that command, clear xlate, and see if the problem persists

Re: PIX & Domain Controller Conflict

peterlebaige — Fri, 09 Apr 2004 03:07:16 GMT

Thanks. We haven't had a chance to try the fix yet, but it seems from looking at some other PIX configs we've found that the entry you mentioned is superfluous, & may be causing the problem.

Will let you know the result.

Re: PIX & Domain Controller Conflict

peterlebaige — Fri, 16 Apr 2004 01:48:56 GMT

Thanks very much for your help, the command you identified was indeed the one causing the problem. As soon as it was erased, logging in was normal for the PCs again.