Investigating the "A bad packet was received from a DNS server. Potentially the requested address does not exist." domain join error

Products

• ProxySG Software - SGOS

Issue/Introduction

Environment

Release : 6.7.4.17

Resolution

Attempts made to join the reported ProxySG appliance to the Windows domain results in the error: "A bad packet was received from a DNS server. Potentially the requested address does not exist." and this Is consistently received.

Typically, this errors is due to connectivity issues, either physical (firewall blocking or DC unreachable) or logical errors such as DNS issues or ProxySG configuration issues, among other causes. See the following article with URL below, for the details.

https://knowledge.broadcom.com/external/article/175348/troubleshooting-steps-for-failed-authent.html

Just like a typical client computer joining to a Windows domain, specific prerequisites must be met, to be able to join the ProxySG appliance to a Windows domain, two of which are:

• The ProxySG appliance must be able to resolve the IP address for a domain controller. For this to happen, it is required, as a first step in implementing authentication on the ProxySG appliance, to have a Host "A" record created on the AD-referenced DNS server. See the following article: https://knowledge.broadcom.com/external/article/166031/implement-integrated-windows-authenticat.html, for reference. 

 

• The ProxySG appliance must be able to exchange traffic with the domain controller on several different TCP and UDP ports These ports include:
  • TCP port 389 and UDP port 389 for LDAP traffic
  • TCP port 53 and UDP port 53 for DNS traffic
  • TCP port 88 and UDP port 88 for Kerberos traffic
  • TCP port 445 for SMB (also known as CIFS) traffic

Further investigation confirms that it isn't mandatory to have a Host "A" record created for the ProxySG appliance, to have the appliance joined to the domain. It's actually recommended to use the default hostname to guarantee that each appliance's hostname is unique.

Also, please, ensure to join the appliance to the domain, using the primary domain. See example below. The hostname should not be included.

Primary domain: domain.local

Not primary domain: DR.domain.local

Not using the primary domain would trigger a bad DNS packet.

For the detailed step-by-step guidance for joining the ProxySG appliance to a Windows domain, please refer to article below. The previous article shared would apply to Kerberos Authentication setup. That wouldn't be required, with NTLM.

https://knowledge.broadcom.com/external/article/166420/steps-to-join-a-windows-domain.html

Please implement and do let us known if further technical intervention would be required. We are happy to investigate further, remotely, if required.

From a use case, customer returned to confirm that this was, indeed, a DNS issue, as was identified. Customer also confirmed the resolution of the DNS issue. 

A PCAP should be collected with the filter ip host <IP address of the DC> or port 389 or port 88 or port 445 or port 53. This capture, taken in a use case, we confirmed that there were only back and forth packets between the ProxySG appliance and the referenced DNS servers and there were no packet to the DC. For all the referenced, requisite authentication ports, there were no packets seen, and that includes LDAP. This confirmed that the appliance could not be joined to the Windows domain because of connectivity/communication issues and not an appliance-related challenge. We had requested for the PCAP to be uploaded to the ticket. Consequently, you committed to investigating this internally and will update the case, if required. 

The resolution would be to investigate and fix the network/communication issue within the customer's environment, with reference to the requisite ports and also ensure the "A" record is created on the AD-referenced DNS server.