1

example.com is a registered domain name. Externally, there are nameservers associated with example.com which include an A record for subdomain.example.com which points to an externally hosted web page.

Internally, we have example.com as an ActiveDirectory domain. We wanted to utilise subdomain.example.com internally as well. We have therefore added a matching A record to the internal DNS.

Externally to the network, everything works fine.

When utilising nslookup for subdomain.example.com internally, it returns the correct IP address.

Pinging subdomain.example.com internally, results in the correct external resource responding.

When visiting the page in the browser, it provides page cannot be displayed (IE11) or ERR_CONN_RESET (Chrome).

I am looking for suggestions on what to look at next.

Chris Evans
  • 111
  • 3
  • You might want to look at firewalls in the path. Wireshark or packet sniffer of choice could be useful as a diagnostics tool. – ErikE Jun 30 '15 at 20:22
  • I did wonder re firewall - the only thing is, if I enter the IP of subdomain.example.com, the page is displayed fine so I assumed it wouldn't be interfering. I can try wireshark tomorrow to see. – Chris Evans Jun 30 '15 at 20:25
  • Thoughts then turn to host header processing, or an application level filter in a firewall. Wireshark is your friend. – ErikE Jun 30 '15 at 20:28

1 Answers1

1

Connection Reset is a server response and is not likely a firewall issue. What is occurring is during the three way handshake a reset is being sent in response instead of a SYN ACK. This is notifying you and your browser that the web server application (IIS/apache etc.) is not accepting connections. This means there is an actual issue with the web server application and not with your DNS or Web Browser.

Arlion
  • 590
  • 1
  • 4
  • 17
  • 1
    Firewalls can be configured to either blackhole or reset (send a tcp RST) unwanted connections. But as the page loads fine when called through ip it is an application level issue. That too could be firewall- or applicationserver-related. Most likely server related. – ErikE Jun 30 '15 at 20:32
  • 1
    I have never seen a firewall be able to send a RST packet, but I guess it's possible if you really wanted to. As for blackhole, you would recieve no response from the server. Unless this man is a firewall guru, it is highly unlikely that he set up his firewall to send RST packets in response. – Arlion Jun 30 '15 at 20:34
  • Oh, it is pretty simple to rst and there is generally no guruship involved. When I write blackholing I mean the firewall deciding the connection is undesirable and simply not allowing packets through to the server and not ACKing ones already sent by the client. Read more here (I do not agree with the accepted answer but just show the simplicity of doing it): http://unix.stackexchange.com/questions/109459/is-it-better-to-set-j-reject-or-j-drop-in-iptables – ErikE Jun 30 '15 at 20:41
  • 1
    Very Interesting, not practical, but very interesting. I think this is not used a lot is because the last thing you want to send back to a client is a RST packet which could indicate a service there. Neverless the extra load your firewall now does just to respond to every packet that doesn't match a firewall rule. I would rather DROP the packet and keep the load low on the server. Pretty cool, thanks. – Arlion Jun 30 '15 at 20:48
  • 1
    Just as a side - the web server is accepting connections happily externally on the subdomain.domain.com via the A record and by IP. Internally, connecting to the IP also displays the web site on the external site fine. I would be surprised therefore if it was the web server that was the issue. – Chris Evans Jun 30 '15 at 20:51
  • Giving firewall classes years ago I noted that some firewall beginners drew the conclusion that sending rst whas the desirable thing to do when given the choice. Just as you write it is rather not. – ErikE Jun 30 '15 at 20:57