Video Screencast Help

Fix the location awareness slowness on SEP 12

Created: 24 Sep 2012 • Updated: 17 Jun 2013 | 8 comments
match's picture
0 Agree
0 Disagree
0 0 Votes
Login to vote
Status: Implemented

Hi,

We've been using SEP 11 for years to protect our mobile users laptops (1000+ people). We use the location awareness feature to adapt the firewall policy to the current location of the user. For example, if the laptop is outside our network, the firewall blocks everything. If the laptop is inside our network (or connected with a VPN), the firewall allows the connections to our systems. To achieve this, we use network detection rules in SEP, based on the interface name, IP addresses or the DNS suffix.

But with SEP 12, this location awareness feature has become very slow. For example, when our users connect in VPN to the headquarters, they switch from the location "outside" to the location "connected in VPN". The VPN connection itself is very quick, about 5 seconds. However, it takes ages to SEP to detect the location switch and allow the connections, maybe 1 mn. This is a very long time for the users, as they aren't even warned about this behavior by SEP.

According to this : TECH163097, the initial behavior was modified in SEP 12.1 and introduced a 30-60s delay for every location switch. This is way too much. The workaround is to not use network-based rules. So we are stuck with regular DNS/ICMP pings to identify the current location. These protocols are not reliable and if a packet is lost (for example if connected over a WAN/in mobile broadband), the location switches to the default and the connections are dropped.

We've been told by the technical support that this is "by design". But now the feature is clearly not usable anymore.

Please fix the location awareness feature as we won't upgrade all our users to SEP v12.

Regards,

/D

Comments 8 CommentsJump to latest comment

Elisha's picture

This is resolved in SEP 12.1.2 due out later this month (October 2012).

0
Login to vote
JClomen's picture

Hi,

Not true, this issue is not solved in 12.1.2, not even in the MP1 release.

Please solve it.

 

Best regards,

Jack

0
Login to vote
Elisha's picture

Hello Jack,

We improved the checking from 30-45 seconds to about 10 seconds. Prior to SEP 12.1.2 we used windows notifications which could be delayed.  Now we can check the settings directly with Windows without waiting for the Windows notifications.

What are the exact location settings are you using?

How long are you seeing the location switching to take?

Thanks,

0
Login to vote
JClomen's picture

Hello Elisha,

We use a combination of DNS server and NSLookup.

For one location we use a combination of IP and NSLookup.

Our general problem is the same as for "match" above, a delay in location switching when connection over IPSEC VPN.

Our default location is "Outside", a location without any rules.

Switching from "Outside" to an "Inside" (internal network) location takes 30-60 secs with 12.1.2.

It seems to take less time with MP1, more like 10-20 seconds but still no 4 seconds as it used to be in SEP 11.

Best regards,

Jack

0
Login to vote
Elisha's picture

In SEP 11 the client would actively query registry keys and Windows API's for every location check (in your case every 4 seconds).  This active query caused high CPU for customers who had a larger number of location criterion.

To resolve the high CPU issue in SEP 12.1 we moved our location check to be passive and wait for Windows to tell us the information we needed for the location check.  This drastically reduced the CPU usage of SEP but made the location switch take a lot more time.

In the latest release (SEP 12.1.2 MP1) we found a way to allow Windows to notify us in a lot less time.

Is there a concern with SEP taking 10 seconds for the location switching?  What is an acceptable time frame?

Thanks,

0
Login to vote
castro's picture

Hi Elisha

Can you advise the rough time that it takes SEP 12.1.2015.2015 to determine a location based on the following location criteria.

We need the location to change within 15 seconds based on the below, this is what we saw in SEP11, is there any information on this change in location detection in release notes?

I believe that the general expectation (or at least mine) is that if I set a timer to check a property each x seconds, I expect the product to actively start to check the check every x seconds and not wait for a undisclosed amount of time to start the check in a passive mode.

Can you advise if there is a matrix or similar that i can check to see what checks would have the best response time based on the passive information that the SEP client is waiting for?

DNS Loop in 20 seconds
Location check every 10 seconds

In Office connected to Wire
 condition 1
  If client has one of the IP Addresses listed below
   xx.xx.xx.xx -- xx.xxx.xxx.xxx
 AND Condition 2
  DNS Lookup finds the IP address for servername.domain.suffex
   xx.xx.xx.xx
  OR DNS Lookup finds the IP address for servername.domain.suffex
   xx.xx.xx.xx
 AND Condition 3
  Client computer uses Ethernet

In Office connected to Wireless
 condition 1
  If client has one of the IP Addresses listed below
   xx.xx.xx.xx -- xx.xxx.xxx.xxx
 AND Condition 2
  DNS Lookup finds the IP address for servername.domain.suffex
   xx.xx.xx.xx
  OR DNS Lookup finds the IP address for servername.domain.suffex
   xx.xx.xx.xx
 AND Condition 3
  Client computer does not use Ethernet

Out Of Office
 DNS cannot find the IP address for servername.domain.suffex
   xx.xx.xx.xx

 

Many Thanks
 

0
Login to vote
Elisha's picture

This issue was released as two fixes. The initial fix went to SEP 12.1 RU2 and the final fix went to 12.1 RU3.

Our initial solution (in RU2) was to use registry hive to detect network change, when we see a change, wake up the polling mechanism to get network information.

But this solution doesn't completely solve this issue. Considering the following scenario, when the network cable is plugged in, the reg’s change triggers us to collect network information, but then the IP address hasn't been ready, we have to wait for the next polling (in 60 seconds) to get the correct IP. So, if some customer uses IP address as AutoLocation criteria, they could still see this issue.

Our final solution (in RU3) was to monitor the reg hive, when we see a network change, wake up the polling mechanism and continuously do the polling 12 times and once every 5 seconds, so that we have 1 minute to capture all changes.

As far as the DNS Lookup I would not have clients do a DNS lookup every 20 seconds.  This could bring down your DNS server if you have very many clients.  I recommend setting the DNS lookup to a value like 30 minutes.  The clients will always do a DNS lookup when the IP address changes or a NIC is plugged in or unplugged, so this DNS lookup frequency is just to handle the case where was missed by the normal check.

0
Login to vote
castro's picture

Many thanks Elisha!

0
Login to vote