[Bertmax]

OK, I've got an odd problem that hopefully someone here has heard of.

I have a domain controller, DC5, which recently stopped resolving external IP addresses. Well, mostly. I could ping www.google.com and, while it wouldn't return a response, it did resolve the IP. However, after entering that IP address into the browser of the server, it wouldn't connect. I entered that same IP into the browser of my own PC and it worked just fine. I've determined it's not a server issue, because once I changed the IP address for that server, it started connecting to the Internet and working as a DNS box again. But that's only half of it.

Because DC5 was our primary DNS server, everything with a static IP stack stopped working. So, because I wasn't aware that the problem lies with that specific address, I added it as a secondary IP to DC4, my new primary DNS box. Once I did that, DC4 stopped connecting. It's like whatever was blocking DC5's old address is going to block every other IP associated with it. Even after removing the secondary address, DC4 refuses to connect and is now useless as a DNS server.

Anyone ever heard of this before? Let me know if further information is needed.

[auglan]

Good place to start would be to check your edge firewall to see if the request is going out and to see if the response is coming back in. Check the firewall for any filtering that may have been added.

[Bertmax]

Well, I've been working with our network engineer on this, and he hasn't made any changes to the firewall (and he'd be the only one that can). Plus, that doesn't seem to explain how adding that address (let's call it 1.2.3.4) to another domain controller (DC4) as a secondary IP would cause that server's primary IP (say, 5.6.7. to also stop working. It's like 1.2.3.4 is killing any IP it comes into contact with.

Now, I've since changed DC4's IP to something other than 5.6.7.8 and it is now functioning normally again.

One thing to note would be that our ASA is working backwards. For reasons that are too long to go into right now, our network is producing an inordinate amount of network traffic, which was causing our external IP to be flagged as spam by many web sites. So, we inverted the ASA to keep that traffic to ourselves and have a separate Blue Coat (installed over a year ago) to help filter incoming traffic.

[Bertmax]

OK, well, it turns out, our firewall WAS blocking 1.2.3.4. Apparently the threat detection system is a recent feature on ASAs, and since ours is policing outward-bound traffic instead of inward-bound, our DNS servers triggered it. Is this a feature which can be turned off?

Incidentally, DC4's IP wasn't listed in a "sho shun", but I asked our engineer to remove it anyway and now it works again.

Thanks for the help. I shall never doubt you again.

[auglan]

I kind of figured it was a filtering issue. You can add an exception to your shun or you can turn it off. Threat detection isn't that new, not sure what code you are running but its been around awhile. (Think it was added in 8.0)

Also if you run an IPS sensor internally (either on the ASA or external) then the IPS can also add hosts to the shun list. You can add exceptions on the IPS as well.


threat-detection scanning-threat [shun [except {ip-address ip_address mask |

One thing to note would be that our ASA is working backwards. For reasons that are too long to go into right now, our network is producing an inordinate amount of network traffic, which was causing our external IP to be flagged as spam by many web sites. So, we inverted the ASA to keep that traffic to ourselves and have a separate Blue Coat (installed over a year ago) to help filter incoming traffic.

You need to check your filtering policies to see why this is happening. You should only let out what you need. If you have an internal mail server then only let that host outbound to port 25 etc... IF your ip is getting blacklisted then you need to address it. Adding another device really is a bandaid. Filtering outbound is just as important as filtering inbound. If you block unwanted traffic going out of your network then any infected host can't send that traffic outside. Granted it is still in issue internally but at least its contained.

[Bertmax]

Well, the reason we generate so much traffic is because we have a lot of computers on our network that shouldn't be there. We have about 3,000 computers still running Windows 2000, because they don't meet the hardware requirements for an upgrade. And a lot of these computers don't even meet the requirements for antivirus, but we are not allowed to remove them because it is a public school district. We are micro-managed from the top down and I guess they think it is better to keep as many computers on the network as they can than to take them off and have fewer computers in the classrooms. A lot of my work consists of band-aids because of this. This is why our ASA is inverted, to keep stuff from getting out, rather than in. Naturally our DNS servers are going to generate a lot of traffic as requests are forwarded.

We did add that command the other day for the subnet on which our domain controllers reside, but it's just another band-aid. Heck, before I changed the name of the domain administrator account, our domain controllers were being bombarded with login attempts. For awhile, the failed security events outnumbered the successful ones about 5 to 1, and the system even log was nothing but SAM errors. That's what I have to work with.