I have a Windows Server 2012 R2 box acting as a Domain Controller which is on a segregated LAN. It also acts as the DNS server for this LAN.

I also have a Sonicwall NSA 2600 firewall which is set as the default gateway for all machines on the LAN, including the Domain Controller.

We have an application pinhole for Windows update to come through the firewall, which works fine for the other machines on the LAN.

However, the DC seems to be playing up and the Windows Update error code


Seems that there are also connectivity issues to other external sites too, so I've been trying to diagnose the networking issue.

I've run a pcap to do this and the following occurs:

DC -> firewall : DNS request for [windows update domain]

firewall -> DC : DNS response for [windows update domain] at xxx.xxx.xxx.xxx

DC -> broadcast : ARP who has xxx.xxx.xxx.xxx

Obviously it does not receive a response as the external windows update IP address is not part of the LAN.

When running the same thing on machines with functioning windows updates, it looks as expected:

host -> firewall : DNS request for [windows update domain]

firewall -> host : DNS response for [windows update domain] at xxx.xxx.xxx.xxx

host : TCP SYN to xxx.xxx.xxx.xxx

I've checked the firewall DNS and it's set to

The DC iptables show every local/loopback to The exception is for routes it has two entries: and [ip address of firewall]

The hosts file of the DC is also just as default: - localhost ::1 - localhost

The ipv4 configuration is static as follows:

IPv4 Address: [ip of dc]

Subnet Mask:

Gateway: [ip of firewall]

DNS: [ip of dc]

I'm really at a loss - by all accounts, the networking side of things should be working and you would expect the domain controller to send a TCP SYN out to the IP address provided in the DNS response.

However it's just not even attempting to do this and jumping straight into ARP.

Anyone got any ideas on what might be causing this and what can be done to fix it?

Let me know if you want any further details.


This is not a conclusive answer but it appears to have fixed something.

So I should have added the main active interface was a Hyper-V virtual interface.

This is not confirmed however the issue APPEARS to be resolved (for now), and I suspect it was due to Hyper-Vs ARP proxy feature.

It also turns out the device driver for the physical network card on was not working correctly (would not allow me to enable ipv4, even if other interfaces were disabled), so I reinstalled, and enabled this as the main LAN interface.

To preserve Hyper-V configurations which might require the Hyper-V interface, I've created a network bridge for the two.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.