Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 1 subscriber
  • Views 4714 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 Firewall active location detection failing

Starkadder

Hello,

I'm having problems getting the Client Firewall (from Endpoint Security & Control 9) to recognize the primary location. No matter how I specify this, my laptop clients always believe they are on the Primary Location, even when the user leaves the office and uses the systems at home.

We have a fairly large WAN connected by leased lines and all served by an Active Directory DNS service. On every site our DNS refers back to the server we use to distribute our Sophos Policies. That system does not have a public IP address as it is hidden behind our firewall.

In the central configuration policy for the Firewall I am setting the Location detection by DNS. My belief being that the FQDN and IP address combination I have entered is always correct when my clients are within our network and will fail to to resolve when they are on foreign networks (like their own broadband connections). I should then be able to configure the firewall to behave differently depending upon it finding the primary location or not.

Now I'm probably doing something wrong here, but no matter how I specify the policy servers IP address, my firewall clients are always showing that the active location is the Primary location. Even when used out of the bounds of our LAN/WAN.

I have made various tests to confirm that the DNS resolution is not the cause of this and this always seems to be fine.

Has anybody else seen this behavior, or can you suggest what I may be doing wrong?

Is there a comprehensive Firewall Configuration guide available? I haven't been able to locate one as yet.

Many thanks in advance,

Paul

:1881


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

    Hello Paul,

    I was hoping someone would say that I had simply forgotten a ticky-box or something

    If - then it's obviously not obvious.

    {enter debug mode}

    All of your SCF clients fail to detect the secondary location? BTW: no connectivity at all should give secondary location (but detection is not triggered when you simply unplug the cable, it's best to boot without (LAN-)connectivity).

    Tried different things and eventually managed to keep the primary location although I disconnected the cable. Had an active wireless connection although to a network segment which has no access to the DNS giving the configured response. But detection was not triggered to the rules for primary stayed. And while the setting "survived" hibernation I  think that a disconnect/reconnect due to signal loss (which for lack of a Faraday cage I could not simulate) would have triggered detection.

    So - the client might continue using the profile for the primary connection if a second connection is already active (that's why one should use block bridged ) when the LAN connection is dropped, this should be corrected. But next time detection is triggered the result should be correct.

    Christian

    :1928
Reply
  • 0

    Hello Paul,

    I was hoping someone would say that I had simply forgotten a ticky-box or something

    If - then it's obviously not obvious.

    {enter debug mode}

    All of your SCF clients fail to detect the secondary location? BTW: no connectivity at all should give secondary location (but detection is not triggered when you simply unplug the cable, it's best to boot without (LAN-)connectivity).

    Tried different things and eventually managed to keep the primary location although I disconnected the cable. Had an active wireless connection although to a network segment which has no access to the DNS giving the configured response. But detection was not triggered to the rules for primary stayed. And while the setting "survived" hibernation I  think that a disconnect/reconnect due to signal loss (which for lack of a Faraday cage I could not simulate) would have triggered detection.

    So - the client might continue using the profile for the primary connection if a second connection is already active (that's why one should use block bridged ) when the LAN connection is dropped, this should be corrected. But next time detection is triggered the result should be correct.

    Christian

    :1928
Children
No Data
Unfiltered HTML