No traffic after putting UT into production

[neiby]

It's possible that there's a negotiation issue, but we're not seeing any signs of general IP traffic loss. Pings don't seem to have any problem. I think your other suggestions are probably closer to the truth. We'll know tomorrow morning. I'll do some more testing as soon as I get to work.

[neiby]

Okay, we moved UT over to an unused interface on the ASA and connected a laptop behind it. It works perfectly. So, now we're stumped. We can't figure out why it behaves differently when connected to our main "inside" interface. We've applied the same policies to it. We did not apply any ACLs to it, but those shouldn't matter.

We're going to do some more testing after lunch to see if we can figure it out.

[sky-knight]

Try this...

Get a small unmanaged switch and put it between the ASA and the main network. Then dangle the UT off that switch with the laptop off it.

Then you're on the same interface, in deployment position. If it works there... I'd finally be stumped.

[neiby]

We have a theory about this. We think the problem is that threat detection is enabled on the ASA. Threat detection is based on the rate of particular types of events. We think UT is working now because there is only one laptop behind it. With UT inline with our main link, it has hundreds of devices behind it. I think that dramatically increases the rate of whatever is happening, which causes threat detection to kick in and start blocking stuff.

We can test this pretty easily. We can put UT back in production and then turn off threat detection. I'll let you know how it goes!

[neiby]

So, our theory was wrong. We turned off threat detection and moved UT back inline with our main connection. As before, pings work fine but all DNS was being blocked. We didn't have time to setup the packet captures. Or, I should say that we didn't configure them beforehand. We did capture the firewall logs, though, so maybe we'll figure this out from there.

[sky-knight]

Have you by chance tried to bypass outgoing UDP destination port 53?

There have been cases in the past where this was required... but for the life of me I can't figure out why.

[neiby]

I'm looking through the firewall logs and it looks like DNS requests are being sent out, so something must be breaking on the return trip. I have no idea what, though.

[sky-knight]

How do you handle DNS for that network segment?

[neiby]

Originally Posted by sky-knight

Have you by chance tried to bypass outgoing UDP destination port 53?

There have been cases in the past where this was required... but for the life of me I can't figure out why.

Okay, I just tried this. I used Policy Manager to send all port 53 traffic to "No Rack". Is that right?

It didn't work, though. Same result: no DNS. Grrr.....

[neiby]

Originally Posted by sky-knight

How do you handle DNS for that network segment?

We use Active Directory. Clients send queries to our local servers, which in turn query Internet servers. We tried setting the server to 4.2.2.1 for PCs and on UT itself. No change. They can ping it, but name resolution fails.