Full-Tunnel AnyConnect SSL VPN

In this article, I’d like to show you my simple way to configure the full tunnel SSL VPN through the CLI (command-line interface). You may be wondering why I don’t simply use the graphical user interface like an ASDM. Yes, you can do that, but in my opinion if you want to be a professional, you should be able to configure the network devices through the CLI.

Let me say couple of words about benefits of using the full tunnel SSL VPN. It supports low-latency forwarding of delay-sensitive applications, such as IP voice, because of DTLS (Datagram Transport Layer Security) encapsulation. DTLS is a standard SSL protocol defined in RFC 4347. It improves the application performance because UDP transport does not trigger packet retransmission at the VPN layer. The UDP header is simpler than TCP, creates less overhead, and consumes fewer resources. It makes VPN connection much more quicker.

Our plan is to connect the client from the Internet to internal network. We have the Cisco ASA Firewall (software version 9) and AnyConnect VPN client (version 4).

object network inside_net
subnet 192.168.9.0 255.255.255.0
object network AnyConnect
subnet 192.168.50.0 255.255.255.0
nat (inside,outside) source static inside_net inside_net destination static AnyConnect AnyConnect
access-list AnyConnect-ACL standard permit 192.168.9.0 255.255.255.0
ip local pool AnyConnect-Pool 192.168.50.1-192.168.50.10 mask 255.255.255.0
group-policy AnyConnect-GP internal
group-policy AnyConnect-GP attributes
vpn-tunnel-protocol ssl-client
split-tunnel-policy tunnelspecified
split-tunnel-network-list value AnyConnect-ACL
tunnel-group AnyConnect-TG type remote-access
tunnel-group AnyConnect-TG general-attributes
address-pool AnyConnect-Pool
default-group-policy AnyConnect-GP
tunnel-group AnyConnect-TG webvpn-attributes
group-alias "IT staff" enable
username john password Cisco123 privilege 0
username john attributes
service-type remote-access
group-lock value AnyConnect-TG
exit
webvpn
no anyconnect-essentials
anyconnect image disk0:/anyconnect.pkg
enable outside
anyconnect enable
tunnel-group-list enable
write memory
end

Session and configuration information:
show vpn-sessiondb anyconnect
show running-config username john
show running-config tunnel-group AnyConnect-TG
show running-config group-policy AnyConnect-GP
show running-config webvpn

Troubleshooting:
(config)# logging enable
(config)# logging timestamp
(config)# logging buffered debugging
(config)# logging class auth buffered debugging
(config)# logging class webvpn buffered debugging
(config)# logging class ssl buffered debugging
(config)# logging class svc buffered debugging

OK, that may seem like a lot. So let’s break down these commands to see what these commands are actually doing.

The network objects we are going to use in NAT exception and the traffic between VPN clients and the internal network will be exempted from the normal NAT rules.
object network inside_net
subnet 192.168.9.0 255.255.255.0
object network AnyConnect
subnet 192.168.50.0 255.255.255.0
nat (inside,outside) source static inside_net inside_net destination static AnyConnect AnyConnect

ACL is going to be used in split tunnel. I should mention that by default, everything goes through the tunnel, and if you want to change this behavior you have to use split tunneling. Split tunneling provides a way to control access through a VPN connection by allowing you to specify destination networks, subnets, or host a remote user must access through the VPN tunnel.
access-list AnyConnect-ACL standard permit 192.168.9.0 255.255.255.0

To assign an IP addresses to remote clients we are going to use an address pool. I prefer to keep remote clients in different network, but if you want you can use the IP addresses from the internal network space. Just don’t forget to create an exclusion range in DHCP.
ip local pool AnyConnect-Pool 192.168.50.1-192.168.50.20 mask 255.255.255.0

For our group-policy we want to specify which VPN protocol it’s going to support and its SSL client (vpn-tunnel-protocol ssl-client), and here we need to configure the split tunnel.
group-policy AnyConnect-GP internal
group-policy AnyConnect-GP attributes
vpn-tunnel-protocol ssl-client
split-tunnel-policy tunnelspecified
split-tunnel-network-list value AnyConnect-ACL

After a group-policy we are ready to create a connection profile to allow remote users to connect into our internal network. When you work with tunnel group at the CLI, tunnel group is nothing more than connection profile.

I suggest you create a connection profile for each user group (for example, IT group, sales group and so on). If you don’t create connection profiles, the incoming connections are going to use the default connection profile, which is not a good idea. This tunnel group is tied to group-policy (default-group-policy AnyConnect-GP) and has the alias ‘IT staff’ (group-alias "IT staff" enable).
tunnel-group AnyConnect-TG type remote-access
tunnel-group AnyConnect-TG general-attributes
address-pool AnyConnect-Pool
default-group-policy AnyConnect-GP
tunnel-group AnyConnect-TG webvpn-attributes
group-alias "IT staff" enable

And last but not least we need to create a user account, because in this case we are going to use the simplest authentication method to authenticate users and it’s a local database. We also want to specify for this user that we are going to lock him into using a specific connection profile (group-lock value AnyConnect-TG).
username john password Cisco123 privilege 0
username john attributes
service-type remote-access
group-lock value AnyConnect-TG

When everything is ready we can enable SSL on the outside interface. Additionally, we want clients to be able to receive the drop down box of aliases (tunnel-group-list enable) for the connection profile.
webvpn
no anyconnect-essentials
anyconnect image disk0:/anyconnect.pkg
enable outside
anyconnect enable
tunnel-group-list enable

Now, you’re able to download the VPN client. For that you need to go to https://Public-IP.

As you noticed I’m using a simple order of rules. We created our group-policy first, we then created a tunnel group (or connection profile, if you like), we then created the user and we linked them together.

One more thing, guys. If you’re using the IKEv1 or IKEv2 for site-to-site or remote access you definitely should check this information about critical vulnerability.

That’s it. Enjoy.

Leave a Reply

Your email address will not be published. Required fields are marked *