Anyconnect 4 - ISE System Scan on WiFi

kev-matthews · ‎02-06-2015

Hi folks,

We're currently in the process of rolling out Anyconnect 4 with NAM and ISE agents to handle our 802.1x requirements. As part of this we're also interoperating with Anyconnect VPN on 5585-x firewalls to take advantage of the CoA on this platform.

Everything seems to be working really well, which is great, except for one thing. We have two VPN Profiles - one which tunnels all traffic and one which split-tunnels corporate ranges (all RFC 1918) allowing other-stuff directly out to the internet.

When we use a LAN cable to connect to the VPN, the both work ok and the system scan triggers for both profiles and the laptop is marked as compliant. When we switch over to wireless and connect the VPN only the profile that tunnels all traffic triggers the posture scan. The Split tunnel profile does not trigger the system scan and sits in "unknown" status. The module reports that "System scan is not required on current WiFi" even though the option to allow system scan on non 802.1x networks is enabled in the configuration XML.

The names of the PSN's are looked up internally and in our RFC 1918 range. and if I open a web-browser to our intranet the PSN is located by the HTTP redirect, which can't force the system scan to trigger so the laptop remains stuck in unknown state.

If I change the split tunnel to "tunnel all traffic" the PSN is located and the compliance works ok. So it's something to do specifically with the split tunnel while on WiFi not triggering the redirect.

Is there any place I should start to further my investigation (other than not using split-tunnel!) to resolve this? I would imagine that the client is attempting to call something to trigger a redirect but it's going outside of the VPN Tunnel, but wireshark is drawing a blank.

Thanks in advance

Kev

jan.nielsen · ‎02-06-2015

What have you set as discovery host in the ise posture profile ? What is in your redirect acl on the ASA ?

kev-matthews · ‎02-09-2015

Hi,

Posture redirect ACL is as follows:

access-list Posture_Redirect extended deny udp any any eq domain
access-list Posture_Redirect extended deny ip any host psn1
access-list Posture_Redirect extended deny ip any host psn2
access-list Posture_Redirect extended deny icmp any any
access-list Posture_Redirect extended permit tcp any any eq www

Posture Profile XML is configured:

DiscoveryHost>psn1.mydomain.co.uk, psn2.mydomain.co.uk</DiscoveryHost

(I removed the tags in case it did anything odd when posting)

jan.nielsen · ‎02-09-2015

Sounds odd, so when on LAN, are you talking about your internal lan, or some external internet connection ?

kev-matthews · ‎02-09-2015

Yeah, it's very odd - It's on an external connection, as we're using it for VPN functionallity.

It only impacts the split tunnel connection, all other settings are the same. It behaves as expected with a wired connection, when you go to a wireless connection (say on your home broadband or public wifi) it then doesn't try to evaluate the endpoint post connection.

jan.nielsen · ‎02-09-2015

So when you are on vpn, you xan do The following :

Dns resolve The hosts you have entered as discovery hosts ?

Get redirected to The posturr prov page of The PSN that aauthenticated your VPN session, if you put in any of Those hosts in a browser ?

kev-matthews · ‎02-09-2015

Hi,

yes we're able to look up the FQDN of the discovery hosts and if we open the web-browser and go to an internal page, this is automatically redirected to the authenticating PSN. Obviously due to the split tunnel non-internal traffic is routed directly to the Internet.

When the browser is redirected it does the active x check for Anyconnect, but then hangs on triggering the system scan element of anyconnect.

jan.nielsen · ‎02-09-2015

You say an "internal page" but did you try the fqdn that you are using as your discovery hosts,. because this is what the posture agent uses to find the ise nodes with, by being redirected when it tries to reach either of the two names you put in your discovery hosts on tcp/80 ?

kev-matthews · ‎02-10-2015

Ok, yes - I see what you mean. I have the PSN's listed as the discovery hosts, so I've now permitted http to the PSN IP's in the redirect ACL's as it just sent me to the Admin login when I went to the HTTP site. Now that change is made the browser is redirected to the posture page, but it still doesn't fix the issue with the split-tunnel profile being sent for system scan. I also tried to change the discovery host to our internal intranet and this also didn't work.

jan.nielsen · ‎02-10-2015

Does the ise posture agent complain that it can't find the policy server, or does it say something like bypassing scan for anyconnect (can't remember the exact wording)

kev-matthews · ‎02-10-2015

It basically says system scan not required on current wifi, it doesn't even try to locate the policy server (unlike when there is a cable connected)

daniel.borloz · ‎02-11-2015

Hello,

I have the same issue... Posture is not executing when connected with a Wifi connexion. It's working correclty when wired connected. I seems to be a bug or something like that.

I have the latest ISE version with any connect 4.0.00057

jan.nielsen · ‎02-11-2015

Ok, so thats a whole other problem. thats not because it can't find the ise server. Let me check my notes, i think i had the same problem recently when deploying AC 4.0 and ISE Posture.

kev-matthews · ‎03-10-2015

Interesting development during our UAT. We have engineers with 3G (mobile data) in their laptops which Anyconnect works with just fine on the NAM, but when they connect to the full tunnelled VPN they don't get posture scanned, but it works fine over wireless and wired from the same client. Slightly different from the split tunnel issue however odd nevertheless.

We've raised a TAC case for it and hopefully I've got a webex tomorrow to demo the split tunnel issue, just trying to get hold of a mobile broadband enabled laptop to do further testing with now!

kev-matthews · ‎04-10-2015

Just an update on this - bug CSCut47995 was filled for the problem off of the back of my TAC case, and the dev team has located the problem and advised that it'll be resolved in the next release of AC 4.0. This is anticipated to be around the end of the month.