locked
Directaccess port unreachable RRS feed

  • Question

  • My remote users who connect through Directaccess have not been able to get connected to our Symantec Endpoint Protection Server over port 8014 and therefore cannot get new virus definitions or be managed by the server. I can sucessfully telnet to my exchange server on port 25, but if I try to telnet to the symantec server over 8014 it fails. I have update the firewall policies to allow 8014, even checked my cable modem and gateway firewall/router. I don't know what else could be blocking this. Any ideas? -Thanks

    Mike Pietrorazio

    Friday, March 23, 2012 12:06 PM

All replies

  • The only firewalls that would potentially get in the way are the firewall on the Symantec server or if you had a firewall sitting between the internal NIC of the DA server and the corporate network. Otherwise all of the traffic between the client and the DA server is IPsec encrypted, your modem/home router can't touch the traffic to firewall it.

    With DirectAccess, when a particular resource is unavailable it usually comes down to one of two things:

    1. Name resolution - Can you confirm that the name of the Symantec server is included in the NRPT? When you ping the name of that server from a DA client does it resolve to an IPv6 address correctly?

    2. Routing - Because a DA server only has a Default Gateway defined on the External NIC, any subnets inside your network that you are trying to contact other than the one that you are physically connected to need to be manually defined in the routing table. Is it possible that the Symantec server is sitting in a subnet that is currently not routable from the DA server? In addition to adding the route for each subnet, you also need to run the "Network Interfaces" wizard from the Admin menu inside UAG (I assume you're using UAG since you posted your question in this forum) and include the IP address range for all subnets that you have routes for.

    Try connecting to the Symantec server from the UAG/DA server's console. If you cannot get what you need from here, then the clients won't be able to either.

    Friday, March 23, 2012 6:23 PM
  • Thanks for the good information. Yes, I can sucessfully ping the Symantec server from the client by name. We have other services, such as intranet running on that same server. This all works. It only seems to be the traffic on port 8014 that is not getting across. From the DA server I can connect the Symantec server fine. This leads me to believe that the issue lies between the client and the DA server. But considering the tunnel works fine, and traffic flows within the tunnel, I'm stumped as to where the problem may be.

    Mike Pietrorazio

    Friday, March 23, 2012 6:32 PM
  • Is it possible the Symantec service is configured to only allow traffic from certain sources and the DA clients IPv6 prefixes are not included in that scope?
    Friday, March 23, 2012 6:39 PM
  • I've checked, and I don't even think it's possible to restrict IPV6. I'v also been working with Symantec support and they haven't mentioned such restrictions. At this point they can offer no further help until I can get conectivity on the required port.

    Mike Pietrorazio

    Friday, March 23, 2012 6:48 PM
  • I have exactly the same problem.  I also cannot connect to my Cisco call manager admin page.  It is on port 8443  (https://callmanger:8443/ccmadmin).  When I connect via my Cisco VPN client, the SEP 12.1 client connects to the SEPM server fine and I can access the call manager admin page just fine.

    Please keep posting on this issue and if I find a solution, I will post back again too


    - Ryechz

    Monday, March 26, 2012 4:59 AM
  • Hey Mike and Ryechz, I have a couple of questions for you that I would like to ask directly about this situation. If you're comfortable with that, feel free to shoot me a message directly: jordan.krause@ivonetworks.com

    Thanks!

    Monday, March 26, 2012 1:04 PM
  • Hello,

    What version and build of SEP are you running? Have you tried running a packet capture from the client side to see where this traffic may be getting blocked?

    For reference, here is the list of all communication ports used by SEP.

    http://www.symantec.com/business/support/index?page=content&id=TECH163787&actp=search&viewlocale=en_US&searchid=1310681755196

    Thomas


    Monday, March 26, 2012 1:42 PM
  • SEP Ver: 12.1 RU1 / Have not tried a packet capture yet.

    Mike Pietrorazio

    Monday, March 26, 2012 1:44 PM
  • 12.1.1000.157.105.

    Not only does 8014 get blocked but so does other ports like 9090 for instance.  I know, it's weird.  My directaccess configuration uses UAG and is setup in a NLB configuration consisting of 2 servers.  Any suggestions would be greatly appreciated.

    I have 2 SEPM servers, one legacy (the upgrade had issues) and a new one I built.  Both work fine internally (clients communicate over 8014 and I can access 9090), but both also don't work when connecting through DirectAccess.  One server is in the management servers group and the other is not.  Both have the same issue so it is unrelated to that.

    Ryan.


    - Ryechz

    Monday, March 26, 2012 11:58 PM
  • Thanks Jordan for referring me to the below Symantec article. As it turns out, SEP 12.1 will not fully communicate over IPV6.

    http://www.symantec.com/business/support/index?page=content&id=TECH174897 


    Mike Pietrorazio

    Wednesday, March 28, 2012 1:15 PM
  • Hi

    How did you solve this problem?

    Are your SEP Clients communicate your SEP Manager server thru Direct Access connection when they are outside your internal LAN?

    Are you just allow all IPv6 rules on SEP firewall and problem is solved like is proposed in next link http://www.symantec.com/business/support/index?page=content&id=tech134869 ?

    Dragan Kukeski

    Tuesday, November 6, 2012 9:24 PM
  • I ended up having to change my policy in SEP manager to allow clients to get updates either from the management server, or, if unavailable, from Symantec servers. Apparently, in the current release, the clients will not update using IPV6. Once I made these changes, I used a manual VPN to allow the remote clients to get the policy change. Now they update defs directly from Symantec.

    Mike Pietrorazio

    Wednesday, November 7, 2012 12:43 PM