ESMC unable to connect to devices connected to network via VPN

[PaulN 0]

We have several laptops that connect to our network via SonicWall Mobile connect SSL VPN. They can access network share folders, and run remote desktop connections to network PCs just fine. The devices communicate with the ESMC server when they are connected via ethernet, but not when connected over the VPN. In ESMC the "Remote Host" shows the device's Ethernet IP address. I've the a KB about needing to open ports and use a NAT rule, but that seams unnecessary with a VPN and very unsecure as the Wi-Fi IP addresses are not static. Thanks for any help. (Our patch management software server and agents work fine over the VPN). 

[MartinK 378]

Could you please provide logs (trace.log, status.html) from AGENT when it is not able to connect? There are multiple possibilities of what could be wrong and without details, we can hardly help.

Most common issues might be:

• blocked communication on ESMC/PROTECT port (default is 2222)
• missing DNS records, i.e. device might be failing to DNS-resolve hostname of your ESMC when connected via VPN
• certificate issues - especially in case SSL introspection is used

[PaulN 0]

ees_logs.zip

I think the attached files have what you need - not sure how to get the trace log or status html.

Am i correct that, since the modules are updating when there is an internet connection, the device is fully protected, and the main concern is that ESMC is unable to gather statistics and update the agent with any policy changes?

network connections.pdf Event log.txt

[MartinK 378]

Thanks for logs: it seems that issue is one of the most common -> AGENT is not connection, because it is not able to resolve DNS name of your SERVER. Hard to analyze why this happens, but I guess it is related to network infrastructure, and possibly missing DNS access when connected through VPN.

As an alternative, you might configure AGENT to use alternate DNS/IP names of management SERVER, but this would work only in case SERVER's certificate is prepared for this (i.e. it has to contain all used hostnames/IP addresses or wildcard *).

Also as you imply, broken AGENT connectivity has only impact on ability to remotely manage device, i.e. during time when AGENT is not able to connect, you won't receive any incident logs and also you won't be able to execute tasks or modify configuration of device. But all collected incidents will be still collected locally on client and synchronized once connection is active. In case AGENT and all installed ESET products do have internet connectivity, they will be updating itself and ensuring security.

[PaulN 0]

Thanks for the quick response! I feel much better knowing that the devices are secure.

I think you are correct that the agents are not resolving the DNS name - in order to make the mapped network share folders work on the VPN i need to use the IP address of the server (\\172.22.xx.xx) in the file path, instead of the \\server name\. But, from what i can see in the ESMC server settings, the ESMC server is already designated by IP address, not name. I surmise that the DNS is missing for the VPN connection, but shouldn't the agents be looking for the IP address?

Can you explain how i would configure AGENT to use alternate DNS/IP names of management SERVER? Would doing so work for all devices whether connected via VPN or direct Ethernet? 

I do see however that the devices are named as "LT01.[hostname]" - could that be related to the problem?

Thanks!

paul

 

 

 

[MartinK 378]

Please check what is your current AGENT's configuration - it can be requested from client details. When installing AGENT in a standard way, only one hostname for connection is propagated to AGENTs, but this can be changed by creating new configuration policy for AGENTs, where "Server to connect to" will contain list of hostnames/IP addresses where AGENTs are supposed to connect to - it can be used to provide alternate hostname for external devices, etc.

This is how it might be set:

but as I mentioned previously, all added hostnames has to be present in certificate in case there is no wildcard used for field "host", otherwise you risk that AGENT will no longer be able to connect. AGENT will be always using defined order, so first hostname should be primary.