Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 1 subscriber
  • Views 3884 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Client Communicating With Server - VPN

Tinshield

We just replaced Symantec Endpoint Protection with Sophos.  We have the 4.5 console setup and I just deployed a couple of our mobile laptops (in police cars).  I noticed fairly quickly that they could not get updates from our server so I set up a secondary update server which solved that.

I guess I am trying to figure out why SEP communiated with the server through the VPN but apparently Sophos can't?  Do I need to open up some ports on the computer firewall?  Still using windows firewalls in these machines.  Using 9.5 and see no difference between Win 7 or XP.  Any ideas?

:9039


This thread was automatically locked due to age.
Parents
  • 0

    I guess that would only help if it was a name resolution issue but you could.  

    So you're clients are trying to use an updating path of:

    \\<server>\SophosUpdate\CIDs\S000\SAVSCFXP\

    When on the LAN they are fine, it's only when the machine is connected to the network over the VPN it fails?

    Does

    \\<server>\SophosUpdate\CIDs\S000\SAVSCFXP\

    access ok when over the VPN or is it more subtle than that?  

    Is the <server> part resolvable when over the VPN, I assume by default it's the NETBIOS name of the update server rather than the FQDN?  When the client accesses the network over the VPN is the NETBIOS version resolvable or does it require the FQDN to work?  Does the DNS suffix get appened when over the VPN or need to be?

    What is in the trace logs of AutoUpdate when it attempts an update?  If you kick off an update when over the VPN and then search in:

    \ProgramData\Sophos\AutoUpdate\Logs\ (or equivalnet)

    for the most recently created/modified log file (ALUpdate<timestamp>.log)

    Navigate to the bottom and search up for:

    "ALUpdate started:"

    minus the quotes.  This is where the update procedure starts,  what is in the logs?

    Regards,

    Jak

    :9059
Reply
  • 0

    I guess that would only help if it was a name resolution issue but you could.  

    So you're clients are trying to use an updating path of:

    \\<server>\SophosUpdate\CIDs\S000\SAVSCFXP\

    When on the LAN they are fine, it's only when the machine is connected to the network over the VPN it fails?

    Does

    \\<server>\SophosUpdate\CIDs\S000\SAVSCFXP\

    access ok when over the VPN or is it more subtle than that?  

    Is the <server> part resolvable when over the VPN, I assume by default it's the NETBIOS name of the update server rather than the FQDN?  When the client accesses the network over the VPN is the NETBIOS version resolvable or does it require the FQDN to work?  Does the DNS suffix get appened when over the VPN or need to be?

    What is in the trace logs of AutoUpdate when it attempts an update?  If you kick off an update when over the VPN and then search in:

    \ProgramData\Sophos\AutoUpdate\Logs\ (or equivalnet)

    for the most recently created/modified log file (ALUpdate<timestamp>.log)

    Navigate to the bottom and search up for:

    "ALUpdate started:"

    minus the quotes.  This is where the update procedure starts,  what is in the logs?

    Regards,

    Jak

    :9059
Children
No Data