1. Home
  2. Cisco Systems
  3. PIX ,and Domain Controller errors to the DMZ

PIX ,and Domain Controller errors to the DMZ

I have a PIX 515e running 7.0(4)2, and for the most part, it works great.

We're putting a file server into the DMZ so that outside users will be able log in to our Windows network and access files there, a NAS. This means we have a Windows server in the DMZ, and when it boots, (and in the future authenticates clients that login) will contact a domain controller on the INSIDE of the PIX.

I've set up the configuration to allow the server in the DMZ to communicate with the domain controller in the INSIDE, with the the usual steps for access from a lower to higher security system. That is:

static (inside,dmz) dmz_ip inside_ip netmask 255.255.255.255

And set up the global NAT so this works. I've done this lots of times, configuring access to our servers from the OUTSIDE. And so I'm sure that I've gotten basic access from the DMZ to the domain controller on the INSIDE.

However, there is still an error in the Windows Event log when the NAS server in the DMZ boots up, which is Windows error / Event 1054:

Windows cannot obtain the domain controller name for your computer. (The specified domain either does no exist, or could not be contacted) Group Policy processing aborted.

I looked up the error on the Microsoft site, and it suggests that the NIC connection is fluctuating up and down. And suggests, among other things, a different NIC card. I tried a new card, to no avail. It appears that the PIX slows down the data exchange between the NAS sever and the domain controller just enough to make the connection look bogus. There are a couple of other errors, but they all stem from not being able to connect up with the domain controller. And these errors are critical, since they block user authentication, and thus access to the files on the NAS.

Technically, this is really a Windows problem, since the PIX is passing the packets between interfaces, (albeit slowly?) But I'm sure someone out there has seen this error, because the obvious strategy is to put a Web server in the DMZ that relies on a domain controller on the INSIDE. And that creates exactly the same problem.

Thanks in advance for any help.

B Squared

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When legendary Pop Warner coached the Carlisle Indians - a university for native Americans - he'd try anything to motivate his players. Minutes before a 1917 game with Army at West Point, Warner offered his shortest and cleverest pep talk: "Just remember. These are the boys who took your land." Carlisle went on to massacre Army 28-0.

Reply to
"B Squared"
Loading thread data ...

you do not need global and NAT statements when you have a static NAT ...

What does your DMZ binded-ACL looks like ? Are there any deny logs when you boot ?

My guess is that some ports are being blocked.

HTH Martin

Reply to
Martin Bilgrav

Good point. The global and NAT statements are for other outbound traffic, and aren't relevant to this problem.

Excellent question... I'm using this:

access_list dmz_inside permit ip any any access_list dmz_inside permit icmp any any

access_group dmz_inside in interface dmz

It turns out Windows actually uses icmp to boot from a domain controller, so I've openned it as well.

What deny logs are you thinking of? And where do I read them?

This was my guess as well. Which is why I openned up the access list to be permit any any. Later on, I'll use a more restrictive list, but for testing, I didn't want to worry about blocked ports.

B Squared

Reply to
"B Squared"

permit IP any any ... includes ICMP aswell ...

show access-l will not show any hits on the ICMP acl line 2.

logg mon deb (CR) term mon (CR) will show you EVERYTHING going on in the firewall. depending upon your traffic rates this could be a extra load on your firewall. use with caution before apply.

do a logg mon war term mon will show you only warning - hence all the denied log entries.

My sec. guess: What sort of switch is the DMZ server's NIC connecting to ? If fx its a Cisco or other managed switch running STP the ports might not be set to spanningtree portfast, causeing a huge delay in AD bound traffic, which interms might cause timeout, hence your eventlog. Or the switch and NIC could have speed/duplex mismatch, resulting in poor performance. Check and then check again your Layer 1+2 connection. When you are done, get someone to verify your findings.

8) Regards Martin Bilgrav
Reply to
Martin Bilgrav

Might be stating the obvious, but can the server in the DMZ locate the DC's using DNS?

Maybe run dcdiag or netdiag on the problem server.

formatting link
dcdiag /test:registerindns /dnsdomain dcdiag /test:connectivity

Hope this helps.

Reply to
jnez367

Might be stating the obvious, but can the server in the DMZ locate the DC's using DNS?

Maybe run dcdiag or netdiag on the problem server.

formatting link
dcdiag /test:registerindns /dnsdomain dcdiag /test:connectivity

Hope this helps.

Reply to
jnez367

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.