Release : 126.96.36.199
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 Tech. Article with URL below, for the details.
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, tow of which are:
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 on 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 the Tech. Article with URL below. The previous article shared would apply to Kerberos Authentication setup. That wouldn't be required, with NTLM.
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.