Building the client profiles is easy enough, in ASDM you just select the Remote Access VPN tab and drill down to AnyConnect Client Profile under Network (client) Access. Select Add, give the profile a name, and configure your policy.

Once the XML file is created on the ASA you can set your policy options:

The Always on piece is set on the Preferences(Cont) page. Here you can get really restrictive by having the AnyConnect client detect the PC’s network state and apply actions based on it. If the client detects a trusted network (defined in the profile), VPN will disconnect, if the network is untrusted it will connect (Trusted Network Detection/TND). You can allow or disallow disconnection of the VPN session by the user and set a connect failure policy. When the connect failure policy is set to closed the user will be unable to even browse the internet from their home network unless VPN is established. Setting to Open reverses this behavior. If you build split tunnels into your group policy then only traffic destined to the specified corporate resources will flow over the VPN tunnel. Anything internet related can go out whatever internet connection they are connected to. You can, of course, force all traffic over the VPN tunnel.

The part where this breaks is when you attempt to assign the profile to a group policy via ASDM[unless, as someone pointed out in the comments, you are running ASA 8.3(1)]. This screenshot actually shows the correct sequence of commands being executed although I have seen it try to apply the profile from the global webvpn sub menu. In any case this has not worked for me through ASDM after multiple attempts with different profiles and group policies [because I am on ASA version 8.2(1)].

Assigning your ASDM-configured client profile via the ASA CLI works fine. ADSM is essentially trying to do the same thing but it just doesn’t work [for me].

Once the user logs into the appropriate group on their AnyConnect client they will pull down the profile XML which gets stored in c:\ProgramData\Cisco\Cisco AnyConnect VPN Client\Profile. Per the enabled settings above this is what the client state looks like in a trusted and untrusted network:

As you can see the result of the closed Connect Failure Policy on the right, the user will have to establish VPN before being allowed to even get out to the internet on a home or public network.

Microsoft has a similar solution with their DirectAccess implementation. DirectAccess abilities are built into Windows 7 Enterprise and Ultimate so require no additional clients. I started to go down that road first but got scared away by the list of requirements and infrastructure changes I would have to make on the backend to implement. AnyConnect is an excellent alternative that comes with the peace of mind of Cisco security plus there is no additional infrastructure to set up. SSL VPN is not free, however, and comes in two flavors: premium and essentials. The essentials license for my 5510 cluster, which supports a max of 250 VPN peers, was under $100. Premium lics are several times more expensive.

*It should be noted that if you intend to upgrade your ASA to 8.3(1) then you may need to also increase the amount of DRAM in your appliance. Cisco upped the default amount in all devices purchased after Feb 2010. Link.

*A quick note about TND, it can indeed be spoofed. The 2 criteria that the AC client is looking for is the trusted domain name and DNS server address list. If you configure these 2 items to match what is expected in the AC client profile, the AC client will think the network is trusted. If you change or add DNS servers to your corporate DHCP server scopes, this will break TND. The AC client profile must match what is given to the client via DHCP (or statically) for this to work.

7 comments:

I have tried to configure the "always on" feature, but it doesn´t work for me. If I configure the actions for trusted networks, it doesn´t working in no way. I tried all options. I think the client doesn´t recognize the trusted network. Do you know how the client checks this. I think the client would reach the DNS Servers, but I don´t know this. So if the client is in the private LAN the policy should be "disconnect", and in untrusted network "connect". But if the SSL connection is etablished, the client will reach the DNS Servers so it thinks to be in the trusted network, and the policy is "diconnect". The recognition of the trusted or untrusted network could only works prior the connection. I´m a little confused about this. Is it possible to get your XML profile?

Well at first I wanted to say that it is because of the connection-specific DNS suffix passed to the client via DHCP, but that is too easy to spoof. To prove I set the domain name in my DSL router to make the trust network name configured in my AnyConnect Profile. AnyConnect was not fooled and still came up network restricted. I haven't yet found any solid documentation explaining how the trusted network detection mechanism actually works. If anyone has any please share. I'll put my XML up here tomorrow.

Something else I've noticed...When you plug a PC with the AnyConnect client into the "trusted" network, the client makes several attempts to contact the external gateway. Being that the PC is routed through the inside interface of the ASA these attempts get denied. This must be how the AC client is able to determine trusted vs untrusted networks. I haven't sniffed the traffic to say definitively but there is probably something in the denial packet that lets the AC client know it is on a trusted network. Connecting to trusted DNS servers is not enough to prove to the AC client that a network is trusted.

You will need ASA 8.3.1 to edit AnyConnect profile using ASM 6.3, otherwise you will get the GUI, but not able apply it. Also, if you apply those commands presented by ASM on CLI you might end-up with ugly situations, such as it takes some of the commands, but unable to undo it if you attempt.

After further testing, TND is determined solely by the trusted domain name, delivered via DHCP as tje Connection-specific DNS Suffix, and the DNS server IPs, also delivered via DHCP. This can be very easily spoofed but as long as your users do not have administrator rights you'll be ok.