Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 1 subscriber
  • Views 4716 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,

    trying to make a few things a little bit clearer:

    At boot time it's always a race condition. Certain activity must be permitted that the client can connect to the network at all. Only when the connection is available certain decisions can be made. Until then it does not really matter which settings are used. Keep in mind that primary goal is to detect the primary location (bad pun), that is as the Configure popup says: If any of ... via/on any of the network adapters. To be manageable a firewall can't go into block-all mode. Some firewalls have a panic button to cut all traffic but while this is ok for a personal firewall it's not suitable for a centrally managed environment. And therefore the primary (and less restrictive) location is given precedence (but this doesn't explain all your findings).

    Detection will be re-triggered when an(other) adapter connects (but not when it disconnects). The idea is that you use cable and  block bridging when in your primary network. Disconnecting the cable "frees" the other adapters as as one of them might connect the secondary location is then detected. If a second connection is already active when you disconnect the cable the location stays primary even though you are now perhaps outside your network. I agree that this is not desirable - although it doesn' t matter if you disconnect the only adapter (as there can't be any traffic which needs to be controlled) - because the connection to your network could be WLAN and you can't use block bridging in this case and nowadays it's not uncommon to have multiple wireless adapters.

    Detection using DNS means that a (at least one of several) FQDN(s) resolves to the corresponding configured address. It does not require that this address can be reached or that a device with this address exists.

    I wouldn't trust NSLOOKUP as it's unreliable when multiple adapters are active. You have to check which nameserver it queries. I've connected to our "guest" WLAN (secondary detected), checked that NSLOOKUP didn't resolve the name used for location detection and connected the cable. SCF immediately select primary. NSLOOKUP - using the nameserver from the first connection - still returned non-existent domain.  As Window's network stacks are - to put it mildly - a tangle it's no surprise that you don't always get the expected results.

    The question remains, why Sophos thinks it gets a valid response when you connect the cable. Using wireshark I can see the request and subsequent response. And - wireshark will also show you all available interfaces including virtual adapters and their status.

    Christian

    :1945
Reply
  • 0

    Hello Paul,

    trying to make a few things a little bit clearer:

    At boot time it's always a race condition. Certain activity must be permitted that the client can connect to the network at all. Only when the connection is available certain decisions can be made. Until then it does not really matter which settings are used. Keep in mind that primary goal is to detect the primary location (bad pun), that is as the Configure popup says: If any of ... via/on any of the network adapters. To be manageable a firewall can't go into block-all mode. Some firewalls have a panic button to cut all traffic but while this is ok for a personal firewall it's not suitable for a centrally managed environment. And therefore the primary (and less restrictive) location is given precedence (but this doesn't explain all your findings).

    Detection will be re-triggered when an(other) adapter connects (but not when it disconnects). The idea is that you use cable and  block bridging when in your primary network. Disconnecting the cable "frees" the other adapters as as one of them might connect the secondary location is then detected. If a second connection is already active when you disconnect the cable the location stays primary even though you are now perhaps outside your network. I agree that this is not desirable - although it doesn' t matter if you disconnect the only adapter (as there can't be any traffic which needs to be controlled) - because the connection to your network could be WLAN and you can't use block bridging in this case and nowadays it's not uncommon to have multiple wireless adapters.

    Detection using DNS means that a (at least one of several) FQDN(s) resolves to the corresponding configured address. It does not require that this address can be reached or that a device with this address exists.

    I wouldn't trust NSLOOKUP as it's unreliable when multiple adapters are active. You have to check which nameserver it queries. I've connected to our "guest" WLAN (secondary detected), checked that NSLOOKUP didn't resolve the name used for location detection and connected the cable. SCF immediately select primary. NSLOOKUP - using the nameserver from the first connection - still returned non-existent domain.  As Window's network stacks are - to put it mildly - a tangle it's no surprise that you don't always get the expected results.

    The question remains, why Sophos thinks it gets a valid response when you connect the cable. Using wireshark I can see the request and subsequent response. And - wireshark will also show you all available interfaces including virtual adapters and their status.

    Christian

    :1945
Children
No Data
Unfiltered HTML