Unable to connect via CEM mode. Error note: Failed to resolve host name to IP address
search cancel

Unable to connect via CEM mode. Error note: Failed to resolve host name to IP address

book

Article ID: 191076

calendar_today

Updated On:

Products

IT Management Suite

Issue/Introduction

The customer is trying to connect his client machines using Cloud-enabled Management (CEM). However, when the client machines try to switch from their internal network to the external one, the client machines fail to make the proper CEM connection.

The Agent log shows a message like this one:

Operation 'CEM: Connect' failed. 
Protocol: HTTPS 
Original host: <SMPserver>.<yourdomain>.com:443
Real host: <yourgatewayserver>:443
Path: / 
Connection id: 50.5772 
Communication profile id: {xxxxxxxx-DE80-4753-966E-566F747ED5CC} 
Throttling: 0 0 0 
Error type: DNS error 
Error code: No such host is known (11001) 
Error note: Failed to resolve host name to IP address
-----------------------------------------------------------------------------------------------------
Date: 5/14/2020 9:41:17 AM, Tick Count: 41363468 (11:29:23.4680000), Size: 609 B
Process: AeXNSAgent.exe (5772), Thread ID: 5168, Module: AeXNetComms.dll
Priority: 1, Source: NetworkOperation

Environment

ITMS 8.x

Cause

The customer was using the internal name of his gateway rather than the external one. In this example, the Internet Gateway internal name was "<yourgatewayserver>", however, the external one was "<gatewayext>.<yourdomain>.com".
The client machine was not able to resolved the internal name from its external connection. That is why the agent log message referred to:
Error type: DNS error 
Error code: No such host is known (11001) 
Error note: Failed to resolve host name to IP address

If we enable verbose logging on the agent logs, you should see also some entries like these:

Entry 1:
Operation 'Direct: Connect' failed. 
Protocol: HTTPS 
Host: <SMPserver>.<yourdomain>.com:443
Path: / 
Connection Id: 50.5772 
Communication profile Id: {xxxxxxxx-DE80-4753-966E-566F747ED5CC} 
Throttling: 0 0 0 
Error type: DNS error 
Error code: No such host is known  (11001) 
Error note: Failed to resolve FQDN and short host name to IP address
-----------------------------------------------------------------------------------------------------
Date: 5/14/2020 9:41:14 AM, Tick Count: 41360125 (11:29:20.1250000), Size: 592 B
Process: AeXNSAgent.exe (5772), Thread ID: 5168, Module: AeXNetComms.dll
Priority: 8, Source: NetworkOperation


Entry 2:
Unable to resolve a host name <yourgateway> to IP address, error: No such host is known (11001)
-----------------------------------------------------------------------------------------------------
Date: 5/14/2020 9:41:17 AM, Tick Count: 41363468 (11:29:23.4680000), Size: 331 B
Process: AeXNSAgent.exe (5772), Thread ID: 5168, Module: AeXNetComms.dll
Priority: 8, Source: HttpConnection

if you use Microsoft "PSPing" tool (https://docs.microsoft.com/en-us/sysinternals/downloads/psping), you can try and see if from your client machine you can have access to your gateway.

If you run PSPing.exe from the command prompt on your client machine, you should see something like this where your gateway name is not responding with the appropriate IP references if the internal name is used:

C:\Desktop\PSTools>psping.exe <YOURINTERNALGATEWAYname>.<yourdomain>.com:443

PsPing v2.01 - PsPing - ping, latency, bandwidth measurement utility
Copyright (C) 2012-2014 Mark Russinovich
Sysinternals - www.sysinternals.com

TCP connect to 1.1.1.1:443:
5 iterations (warmup 1) ping test:
Connecting to 1.1.1.1:443: (warmup): from 0.0.0.0:60072:
The remote computer refused the network connection.
Connecting to 1.1.1.1:443:: from 0.0.0.0:60073:
The remote computer refused the network connection.
Connecting to 1.1.1.1:443:: from 0.0.0.0:60074:
The remote computer refused the network connection.
Connecting to 1.1.1.1:443:: from 0.0.0.0:60075:
The remote computer refused the network connection.
Connecting to 1.1.1.1:443:: from 0.0.0.0:60076:
The remote computer refused the network connection.

TCP connect statistics for 172.16.109.78:443:
  Sent = 4, Received = 0, Lost = 4 (100% loss),
  Minimum = 0.00ms, Maximum = 0.00ms, Average = 0.00ms

Now, if you use the proper external Internet Gateway name and it is open to external communications, you should see something like this while using PSPing:

C:\Desktop\PSTools>psping.exe <YOUREXTERNALGATEWAYname>.<yourdomain>.com:443

PsPing v2.01 - PsPing - ping, latency, bandwidth measurement utility
Copyright (C) 2012-2014 Mark Russinovich
Sysinternals - www.sysinternals.com

TCP connect to 1.1.1.1:443::
5 iterations (warmup 1) connecting test:
Connecting to 1.1.1.1:443: (warmup): 79.11ms
Connecting to 1.1.1.1:443:: 79.48ms
Connecting to 1.1.1.1:443:: 80.64ms
Connecting to 1.1.1.1:443:: 81.26ms
Connecting to 1.1.1.1:443:: 81.11ms

TCP connect statistics for 172.16.239.220:443:
  Sent = 4, Received = 4, Lost = 0 (0% loss),
  Minimum = 79.48ms, Maximum = 81.26ms, Average = 80.62ms

 

You can also use Powershell Command Test-NetConnection <ipaddress> -port <port> to get similar results to PSPing:

ComputerName     : ServerName
RemoteAddress    : 1.1.1.1
RemotePort       : 443
InterfaceAlias   : tap06c3eff7-b0
SourceAddress    : 1.1.1.2
TcpTestSucceeded : True

More information on Test-NetConnection: https://docs.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection?view=windowsserver2022-ps

Resolution

For the purpose of this article, we will use the troubleshooting steps that we followed. So in that way, you can validate in which area the issue may be occurring.
We will use the following names as examples:


SMP Name: <SMPserver>.<yourdomain>.com:443
Internal Gateway name: <GATEWAYserver>
External Gateway name: <GATEWAYEXT>.<YOURDOMAIN>.COM

  1. Go to the Internet Gateway and check its configuration. Open the Internet Gateway UI. Check the certificate in use. The customer was using a certificate called "SMPserver CEM" with thumbprint "08 95 dc 19..."
  2. Go to the SMP Server. Open IIS Manager. Check the Default Web Site binding for port 443. The Default Web Site was using a certificate called "SMPserver" with thumbprint "b9 2e 62 29..."
  3. Check the Symantec Agent Site and its binding as well in IIS Manager. The Symantec Agent Site was using a certificate called "Gatewayserver" with thumbprint "08 95 dc 19..."
  4. Go to the SMP Console. Go to Settings>Notification Server>Cloud-enable Management. Check the "Cloud-enabled Management Settings"  policy and notice the name of the gateway is listed. In this example, it appeared as "GATEWAYserver" with thumbprint of "08 95 dc 19..."
  5. In the same Cloud-enabled Management tree, Go to the "Cloud-enabled Management Agent IIS Website Settings". In this example, it had the FQDN as "Altiris02" instead of the actual SMP name of "SMPserver".
  6. Since they shouldn't be using the gateway certificate for the Symantec Agent Site (because the certificate should match the SMP name so the client machines can actually talk back to it), we decided to use the certificate that the Default Website is already using (only if the original CEM certificate is no longer available).
  7. We also had to change the "FQDN" and "Certificate" registry under "HKLM\Software\Altiris\NS Agent Site" to match the SMP name on the certificate and the thumbprint of it.
  8. After that, we created a CEM package and installed it on that client machine. Still failed to connect via CEM.
  9. We checked the agent logs and we saw this again:
    Operation 'CEM: Connect' failed. 
    Protocol: HTTPS 
    Original host: <SMPserver>.<yourdomain>.com:443
    Real host: <yourgatewayserver>:443
    Path: / 
    Connection id: 50.5772 
    Communication profile id: {CE93F603-DE80-4753-966E-566F747ED5CC} 
    Throttling: 0 0 0 
    Error type: DNS error 
    Error code: No such host is known (11001) 
    Error note: Failed to resolve host name to IP address

    and 

    Unable to resolve a host name <yourgatewayserver> to IP address, error: No such host is known (11001)

    <gatewayserver> is the physical name of the gateway but the Symantec management agent should be actually using its external name: GATEWAYEXT>.<YOURDOMAIN>.COM.
  10. So we went back to the "Cloud-enabled Management Settings"  policy and changed the name of the gateway that was listed as "GATEWAYSERVER" to "<GATEWAYEXT>.<YOURDOMAIN>.COM".
  11. Then we created a new CEM package and try on ones of those CEM Client machines that were not able to connect internally to get the changes done. It worked.


    Note:
    Additional ideas:

    The log entry with DNS error is the last connection attempt that failed for a particular network operation.

    -Check if there were previous attempts to connect to the same server, which also failed.
    -Look for other Operation 'CEM Connect' failed records, there could be many of them, each going a slightly different connection path (directly or through gateway or proxy, using different local and remote IP, different FQDNs or short names, etc).

    The agent tries different connection paths according to restrictions and priorities, if all of them fail, then the last error is reported as the final network operation error,

Powered by Wolken Software