Wednesday, March 19, 2008

More Issues

Naturally, the turning off of DNS doctoring has created more issues. This was, to a certain extent, to be expected. But with our public website being down, it was the surefire way to fix it, so we went with that solution.

The issue now lies on the inside network. Anyone who accesses a site via its public FQDN now must use the outside public IP rather than the inside private IP. As long as sites resided in the DMZ, this was taken care of by reconfiguring the static translation to use the outside public instead of the inside private.

There are two issues where this could not be resolved, however. First, if the server resides on the private network, instead of the DMZ. Unfortunately I inherited a bunch of these. I'm trying to get them removed, but still have a ways to go. Fortunately, I haven't found one that was a show stopper yet. If I do, I'll probably have to NAT it on our inside core switch. But I'd like to avoid that if possible.

The second issue is for people who accesses our DMZ services from remote sites across the VPN. Since they now reference a public instead of private address, they traverse the public Internet. This has created issues for people trying to do things like edit the public website remotely. Naturally the firewall doesn't allow this from the public internet.

We've been able to survive the little issues thus far. We also discovered the reason for the problem. Sever static NAT translations that I inherited were applied backwards. This was causing DNS doctoring to occur to the public internet! I'm not sure why this wasn't broken before.

So we know the fix, now I just have to convince my VP that we won't break the public website again. It's looking like it will be at least 2 weeks before we can put the change through. I just hope we don't put in too many band-aids between now and then that we can't go back to the correct way.

No comments: