4

I have an issue that I could use some help with.

Our company has a main location and a remote location. Previously, the remote location was connected to the main location through an internet connection VPN tunnel. The connection was pitifully slow at 1.5Mbps, so we upgraded it with a 75Mbps direct link. That meant the remote location lost it's internet access, so we routed their access through the main office internet connection.

Everything works perfect except for one thing. The website we host is not accessible from the remote location unless the IP address is used.

If I do NSLOOKUP on our website address from a machine connected to the main location network, it resolves correctly to the inside IP address. However, if I do the same from a remote location machine, it resolves to the website's outside IP address.

Our internal DNS server(s) have a pointer and CNAME records set up, and everything was working perfectly before the connection was upgraded. In addition, the remote location has a domain controller, DNS server and DHCP server to service these requests at the remote location and prevent these requests from getting routed back and forth over the link.

So I think was it happening is that for some reason the DNS server at the remote location is not resolving our website name correctly and passing the requests on to the routers, which then push the request out to the internet DNS system. That resolves the name to our external IP.

This is purely a DNS issue, everything else works just fine. I am just stumped on this one.

Any ideas on how to fix this?

Edit: I forgot to mention that at the remote side of the link is a Cisco ASA-5505 and at the main office there is a Cisco ASA-5510. The link is connected between these 2 devices and the routing is handled in the 5510.

Thanks, Michael

Michael Paul
  • 41
  • 1
  • 5
  • So when you access the website from the remote location via the internal IP address it works correctly? But if you use the public URL (IP or Domain name) it fails? Sounds like you might need a static route. – unhappyCrackers1 Jul 02 '12 at 17:40
  • Could it be an issue with the search suffix for the DNS configuration at the remote location? – cjc Jul 02 '12 at 18:10
  • Somantra: Correct. There is a static route already set up. The remote location has an IP network of 10.3.0.0/16 while the main office is set up as 10.0.0.0/16. The remote office can access the internet just fine, as well as internal SQL servers, etc, located in the main office on the 10.0.0.0/16 network. ALL other name resolution works perfectly. It's only our website public URL that is not working properly on the remote side internal network. – Michael Paul Jul 02 '12 at 18:21
  • cjc: No idea. The DNS and AD controllers all replicate, so the entries are the same no matter what server. But, just for fun, I reset one of the remote machines to use the main locations DNS servers and I still end up with the same result. Again, until the link and routing between the 2 locations was changed there was no issue. How would I check to see if there is an issue with the search suffix for the DNS configuration? – Michael Paul Jul 02 '12 at 18:23
  • Thanks for the suggestions.. The problem is solved. We have an older W2K3 machine at the main location that is scheduled to be decomissioned. Turns out the previous admin had set up a forward lookup zone on this machine. The problem was that he didn't integrate it with AD so it doesn't replicate. Which is why DNS for our website was resolving at the main location and not the remote. – Michael Paul Jul 03 '12 at 17:20
  • If you solved the problem yourself, please [answer your own question](http://serverfault.com/help/self-answer). – Michael Hampton Mar 21 '14 at 19:33

3 Answers3

2

This is either

  • a DNS configuration problem (at remote location)
  • a DNS server problem (wrong views)
  • a translating firewall problem

Scenario 1:

Make sure the remote location accesses the same (internal) DNS server that the main location uses. Test with

dig @internal-DNS-ip internal.website.com

and make sure that the ending ";; SERVER:" output repeats that IP. Does the answer contain the private IP address?

Possible scenario: the hosts at your remote location are instructed to contact a DNS server other than the internal one.

Fix: configure the remote location computers (or the DHCP server for them) to use the internal DNS.

Scenario 2:

Make the same "dig" query from a computer at main location. Do you get the private IP addresses?

Possible scenario: views instruct the internal DNS server to respond X to some clients and Y to the rest. The new link entailed new IP addresses for the remote location, and the view mask on the internal DNS server has not been updated.

Fix: update the address mask for the view @ internal DNS.

Scenario 3:

Some routers snoop into DNS responses and, when they find your public IP address matching an internal NAT, they replace it to the local address.

Possible scenario: the DNS replies always with the public address (no views), but queries from main location go through such router and queries from remote location do not.

Fix: configure views @ internal DNS so that all internal hosts receive the internal website IP natively.

michele
  • 585
  • 3
  • 7
0

I am not sure if this is relevant but who knows.

It does sound like routing and DNS (or DNSMasq). What I use that works like a charm for me is that after binding static ip to host as machine and everything works when I connect directly to host and I see it working.

I specificed the routing to forward external connection to a specific internal ip address; by using port forwarding.

Key for example:

111.222.333.444 = external

192.168.1.5 as host machine hosting website

192.168.1.1 as gateway that manages routing

http port = 80 (always is a default # for httpd / apache2 - so dont change it)

On your 192.168.1.1 machine (or router as gateway mode):

port forward: http port 80 --> 192.168.1.5:80

this means any external connection via http to your domain, it'll forward http traffic to your host machine.

On your 192.168.1.5 machine

identify 192.168.1.1 (255.255.255.0) as your default gateway / DNS / DNS resolver (whichever is managing the routing).
Faron
  • 107
  • 6
0

Thanks for the suggestions.. The problem is solved. We have an older W2K3 machine at the main location that is scheduled to be decomissioned. Turns out the previous admin had set up a forward lookup zone on this machine. The problem was that he didn't integrate it with AD so it doesn't replicate. Which is why DNS for our website was resolving at the main location and not the remote.

Michael Paul
  • 41
  • 1
  • 5