Improperly configured DNS causes internal mail to hairpin via firewall

Ran into a strange issue recently during an Exchange 2010 to 2016 migration. Internal mail sent from Exchange 2016 to Exchange 2010 was stuck in the mail queue. The queue viewer on Exchange 2016 reported the following error.

{LED=451 4.4.397 Error communicating with target host. -> 421 4.2.1 Unable to connect -> SocketTimedout: Socket error code 10060};{MSG=};{FQDN=<external.companyname.com>};{IP=<external IP>};

This is a fairly generic error and I have changed the FQDN and IP address in the example above. But the key here is that the Exchange 2016 server was trying to send all internal mail to the public IP of the Exchange 2010 server versus the internal IP.

For example, if a test user on Exchange 2016 tried to send an email to a test user on Exchange 2010, 2016 was routing the mail externally out of the firewall, only to try and hairpin back to one of the public-facing IPs.

This kind of hairpin attempted by Exchange was immediately blocked by the firewall which determined that internally sourced connections should not be trying to enter the public side of the firewall.

After ruling out configuration issues with the network the troubleshooting switched to DNS. The client was using split-brain DNS, which means they were using the same namespace both internally and externally for Exchange. A review of the internal DNS zone indicated all Exchange 2010 records were pointing to the correct internal IPs. We even scanned the entire internal zone for the presence of any public IPs – there were none. All records were configured with an IP on the internal network.

Using NSLOOKUP (on Exchange 2016) confirmed the correct internal IP for the Exchange 2010 server.

We then examined how DNS was configured on the new Exchange 2016 server. You can do this from the Exchange Admin Center by navigating to Servers > Servers and double-clicking on your Exchange Server. This will launch the server’s property page. From that page select DNS lookups.

These settings dictate how Exchange does DNS lookups to deliver mail. You can configure Exchange to either use the same DNS servers configured on the network adapter or, specify custom DNS servers. In our case, the DNS lookups were configured in their default settings of All Network Adapters.

We then reviewed the DNS configuration on the network adapter. The easiest way to do this is to right-click on the Start button and select Command Prompt from the context menu. From the command prompt type IPCONFIG /ALL. This will return the DNS servers configured on your network adapter.

C:\> ipconfig /all

Ethernet adapter Ethernet:

Connection-specific DNS Suffix  . :
Description . . . . . . . . . . . : Ethernet Adapter
Physical Address. . . . . . . . . : 00-00-00-00-00-00
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::181a:4d90:2a48:f2be%12
IPv4 Address. . . . . . . . . . . : 192.168.1.13
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.1.1
DNS Servers . . . . . . . . . . . :  192.168.1.10  
                                     192.168.1.15  
NetBIOS over Tcpip. . . . . . . . : Enabled 

The network adapter specified two DNS servers. Both of which were confirmed to be online and active.

We took a look at the DNS servers next. The configuration of the first server and its records were configured as expected. We then took a look at the second server and noticed it had no zones present. However, it did possess forwarders out to the internet service provider. This DNS server was effectively configured as a caching-only server.

The issue is that Exchange 2016 was querying the caching-only server for the Exchange 2010 server’s IP (1). The caching-only server did not possess a host record for the Exchange 2010 server so it forwarded the request onto the ISP (2). The ISP, in turn, found the authoritative answer for the public IP of the Exchange 2010 server (3,4). This was then returned to the caching-only DNS server, and then back to the Exchange 2016 server, which then attempted to send mail to the public IP of Exchange 2010 (5,6).

To fix the issue we modified Exchange 2016’s network adapter settings to use a different DNS server. One which hosted an internal zone for the split-brain namespace. With this fix in place, the Exchange 2016 server was able to locate the internal IP of the Exchange 2010 server and make a local connection. This removed the hairpin through the firewall. All mail queued on Exchange 2016 for Exchange 2010 was delivered successfully. (The caching-only server was later decommissioned.)

Have you seen this issue before? What did you do to fix it? Drop a comment below or join the conversation on Twitter @SuperTekBoy