Video Screencast Help

SNAC - client is not connected

Created: 28 Aug 2012 • Updated: 30 Aug 2012 | 5 comments
This issue has been solved. See solution.


I'm just testing SNAC with DHCP enforcer but still not getting it functional. There is message in enforcer console - client log: "The Symantec client is not currently connected. We will automatically retry the connection and update the status if successful."

There are four computers in test environment on the same subnet (


DHCP with SNAC DHCP Enforcer (DC,DHCP and SEMP are configured as reachable from quarantine)

SEPM with empty HI policy

Client with SNAC client installed

When client obtain IP from DHCP it has ipconfig:

IPv4 Address. . . . . . . . . . . :
Subnet Mask . . . . . . . . . . . :
Default Gateway . . . . . . . . . :

and route print: 6  -DC 6  -DHCP 6  -SEPM

Any ideas what's wrong ?


Comments 5 CommentsJump to latest comment

Kyli's picture

I already checked it. I was thinking about:

"DHCP plug-in needs to be able to contact SEP or SNAC client on UDP/39999 whether the client is in quarantine or not"

So, there is disabled windows firewall on both computers. I think there is no other obstacle in communication over LAN.

Ashish-Sharma's picture

I recommend you open a case with Symantec support to get a quick resolution to this issue.

Thanks In Advance

Ashish Sharma

Chuck Edson's picture

99% of the time this happens is what Kyli said:  You need bidirectional port UDP 39999 open between the Enforcer and the Client.

When the client attempts to get a DHCP address, the Enforcer queries the Client on UDP 39999.  Then, the client responds on UDP 39999.  If the answer is correct, then the Enforcer hands out a production DHCP address to the client.

You can use Wireshark to verify if the UDP 39999 packets are being sent and received from both the client and the Enforcer.

Let us know if this helps.

If a post helps you, please mark it as the solution to your issue.

Kyli's picture

I think I found it ..

Problem is that DHCP and client are on the same subnet. If client wants to contact DHCP, he will go thru gateway. So router receive packet from to and doesn't route local subnet IPs, so return ICMP destination unreachable (code 13 - communication administratively filtered).

In real world there are not clients and DHCP servers in the same VLAN so it will be ok.

Solution is simple - I have to change testing environment smiley