Remote access (RA) VPN is made possible by installing a software component onto the connecting computer. This software installs an IPSEC engine into the local IP stack and uses that to mimic an IPSEC gateway. Workstations and laptops are, however, inherently insecure so additional features have been added to ensure that VPN connections can be made safely. This type of VPN access is typically used by modem, ISDN and Broadband users.
In a LAN to LAN VPN authentication takes place as part of IKE and users of the encryption domains are not required to be aware it. With the RA VPN the remote network cannot be deemed secure so use is made of additional authentication to ensure that the VPN connection and encryption domain can be trusted. With the Cisco VPN client software this takes place as dual factor authentication.
- Group Level. This takes the form of a VPN group name and password. The group level password is the equivalent of the IKE Phase 1 pre-shared key and is used to integrity check Phase 1. The group name is passed to the gateway and during IKE Phase 2 is used to determine the appropriate SPD. This authentication is mandatory.
- User Level. This takes the form of a user account and password and can either be local accounts on the gateway or an external authentication service such as TACACS+ or Radius. As part of IKE further authentication information can be passed as “X-Auth” data in the headers. Although not needed to complete IKE it is used to provide user level authentication before encrypted data is allowed across the tunnel. User authentication is optional on PIX 6.x but mandatory on VPN concentrators and PIX/ASA 7.x or later.
Access Lists and Pools
As an example let us create a remote access VPN from an ACME laptop that accesses the internet from an ISP that assigns dynamic addresses to its users. In order to define the encryption domain we will assign the laptop users a virtual network address from a pool defined for all remote access users. This pool will be defined as 192.168.1.0/24 which will allow for up to 254 simultaneous remote access connections. The access will also be limited by ports and flow direction.
- From 10.44.57.0/24 (My Network) to 192.168.1.0/24 (ACME Pool) on UDP 100
- From 192.168.1.0/24 (ACME Pool) to 10.44.57.0/24 (My Network) on TCP 5000
As with a LAN to LAN VPN the normal access lists defined on the firewall will control the traffic flow across the VPN and any NAT rules will also be applied. Since we will be defining the “virtual” source network from the remote user there is seldom any need to NAT in this case.
Care must still be taken however to utilise RFC1918 addresses to prevent unencrypted traffic from bypassing the IPSEC policy manager.
SPD Encryption Domain
A remote access client will typically obtain a random IP address from a local ISP and locking down the encryption domain using this IP address as a source will be difficult if not impossible. Since the publicly assigned IP address is only required for IKE negotiation and Protocol 50/51 communication the VPN client software will also assign a fixed “virtual” IP address from an available pool on the gateway that is then used as the source IP for all encrypted communication that travels down the VPN. The encryption domain is therefore setup using this known “virtual” address and can be access controlled more easily.
ip local pool ACME-Pool 192.168.1.1-192.168.1.254 access-list acl-vpn-ACME permit ip 10.44.57.0 255.255.255.0 192.168.1.0 255.255.255.0
Note how this simple access list does not mention any of the port and protocol requirements. This is because it only indicates which traffic arriving at the interface must be encrypted, not “what” traffic. To limit the traffic to specific ports we need to manipulate the access lists bound to the interfaces as we do for normal traffic. Also note how this is a uni-directional access list that only lists the traffic we would be encrypting for. Decrypted traffic is automatically allowed if it matches an existing SPD entry.
Traffic Access Lists
In this example the RA VPN is bound to the outside interface so we need to use “acl-outside” to control access from the client networks and use the internal access-lists to control access from our networks
access-list acl-outside permit tcp 192.168.1.0 255.255.255.0 10.44.57.0 255.255.255.0 eq 5000
access-list acl-web permit udp 10.44.57.0 255.255.255.128 192.168.1.0 255.255.255.0 eq 100 access-list acl-app permit udp 10.44.57.128 255.255.255.192 192.168.1.0 255.255.255.0 eq 100 access-list acl-sql permit udp 10.44.57.192 255.255.255.192 192.168.1.0 255.255.255.0 eq 100
These access lists will now control the “unencrypted” traffic flow though the firewall and the VPN match access list will determine if traffic arriving at the outside interface needs to be encrypted.
NAT Access Lists
The final requirement is to ensure that the traffic flowing through the firewall is not address translated before it needs to be encrypted by the IPSEC engine. By default all traffic from tiers is either port address translated (PAT) or static network address translated (Static NAT) to public IP addresses. Left this way the traffic would never match traffic for encryption.
A simple way to ensure that both NAT-control requirements are met and that traffic is not translated is to setup “nat 0” rules for all traffic destined to the VPN.
access-list acl-nonat-web permit ip 10.44.57.0 255.255.255.128 192.168.1.0 255.255.255.0 access-list acl-nonat-app permit ip 10.44.57.128 255.255.255.192 192.168.1.0 255.255.255.0 access-list acl-nonat-sql permit ip 10.44.57.192 255.255.255.192 192.168.1.0 255.255.255.0
nat (web) 0 access-list acl-nonat-web nat (app) 0 access-list acl-nonat-app nat (sql) 0 access-list acl-nonat-sql
IKE Phase 1
The list of encryption proposals available to IKE Phase 1 only need be defined on the gateway. The VPN client software is hard-coded with a large combination of Phase 1 proposals and will try each in order until a match is found with the gateway. Since the VPN client could match a relatively insecure proposal it is recommended that the highest available strength Phase 1 (AES 256 – SHA) proposal be defined on the gateway to ensure that the VPN is secure.
The pre-shared key (PSK) for Phase 1 is defined as part of the VPN group authentication and must be designated as of type “ipsec-ra” for later operating systems.
Depending on the operating system version the commands will differ.
isakmp identity address isakmp policy 10 authentication pre-share isakmp policy 10 encryption aes-256 isakmp policy 10 hash sha isakmp policy 10 group 2 isakmp policy 10 lifetime 86400 isakmp enable outside vpngroup Support password S3cure
crypto isakmp identity address crypto isakmp policy 10 authentication pre-share encryption aes-256 hash sha group 2 lifetime 86400 crypto isakmp enable outside tunnel-group Support type ipsec-ra tunnel-group Support ipsec-attributes pre-shared-key S3cure
Phase 1 proposals are shared between LAN to LAN and RA VPN configurations however the PSK values have to be defined explicitly for each type
IKE Phase 2
After successful Phase 1 completion the IPSEC engine will negotiate Phase 2. This negotiation is used to setup an additional security association that will then be used to encrypt the data being passed between encryption domains. Unlike in the case of LAN to LAN VPN configuration, the peer IP address and encryption domain cannot be predicted so SPD entries in the map need to be added dynamically by the policy manager using the completed IKE Phase 1 group information.
Using the IKE Phase 1 verified peer IP address and VPN group the policy manager will check the address pool defined for that group and allocate a spare address to this connection. It will then use the confirmed peer IP address and setup a map entry using these values. The client VPN software will during Phase 2 negotiation accept the gateways choice of encryption domain by setting up a “virtual” source IP address to match it.
crypto ipsec transform-set AES256-SHA esp-aes-256 esp-sha-hmac crypto dynamic-map SPD-Map 10 set transform-set AES256-SHA crypto map ClientFW 10 ipsec-isakmp dynamic SPD-Map crypto map ClientFW interface outside vpngroup Support address-pool ACME-Pool
crypto ipsec transform-set AES256-SHA esp-aes-256 esp-sha-hmac crypto dynamic-map SPD-Map 10 set transform-set AES256-SHA crypto map ClientFW 10 ipsec-isakmp dynamic SPD-Map crypto map ClientFW interface outside tunnel-group Support general-attributes address-pool ACME-Pool
VPN Group Configuration
Although the dynamic mapping of the policy manager during IKE Phase 2 will be sufficient to setup a RA VPN the group command can be used to setup additional configuration for the remote peer. These settings are primarily to configure DHCP like parameters on the client side and can also be used to set up access rights. The options are discussed below
DNS and WINS
DNS and SMB settings can be configured for this “virtual” connection. These settings will only apply when the VPN is established.
vpngroup Support dns-server 10.44.57.20 vpngroup Support wins-server 10.44.57.100 vpngroup Support default-domain acme.com
group-policy Support attributes dns-server value 10.44.57.20 wins-server value 10.44.57.100 default-domain value acme.com
When the VPN is established the default behaviour is that all traffic sourced from the client is tunnelled down the VPN regardless of destination. This can break local network connections to and from the remote device since everything is sent via the tunnel. To split the VPN traffic into VPN and non-VPN destined traffic we use the already defined encryption domain access list.
vpngroup Support split-tunnel acl-vpn-ACME
group-policy Support attributes split-tunnel-policy tunnelspecified split-tunnel-network-list value acl-vpn-ACME
Only traffic destined for networks defined in the access list will now be encrypted. All other traffic is passed to the local network interface for normal routing.
Perfect Forward Secrecy
PFS can be enabled on a group by group basis. The DH group is automatically negotiated with the client VPN software so does not need to be configured.
vpngroup Support pfs
group-policy Support attributes pfs enable
Connection Idle Time
If the RA VPN is found to be idle for this timeout value then the connection is automatically disconnected and torn down. Reconnection will require re-authentication.
vpngroup Support idle-time 1800
group-policy Support attributes vpn-idle-timeout 30
The value is in seconds on older operating systems and in minutes on later operating systems.
These options cover the most common requirements for setting up a RA VPN. There are however numerous other options that can be configured. These include
- Backup gateway support
- Login Banners
- Client firewall settings
- IP compression
- Time based restrictions
Refer to the Cisco configuration guides for specific configuration details.
To complete the setup of the RA VPN user authentication needs to be configured.
Local user accounts can be created on the firewall to authenticate VPN connections against. The VPN group then needs to be configured to query this local user database. Please note that only one local database can be configured per gateway so all RA VPN groups will share the same user database. Only the unique group names and passwords will distinguish them from each other.
username joeboy password secret crypto map ClientFW client authentication LOCAL
username joeboy password secret group-policy Support attributes authorization-server-group LOCAL
If client authentication is enabled in PIX 6.x then all VPN connections including LAN to LAN connections will have the user authentication (“X-Auth”) information inserted into the IKE headers. This can cause problems with some L2L connections. If problems are experienced then instruct all L2L VPN connections to ignore “X-Auth” by using the following commands when specifying the PSK.
isakmp key abc123 address 184.108.40.206 netmask 255.255.255.255 no-xauth
A TACACS+ or Radius user database can be used to authenticate RA VPN users. Configure the username and passwords on the database and ensure that the gateway is allowed to query the database for auth information. Different external databases can be configured on a VPN group by group basis in later operating systems.
aaa-server ACME protocol tacacs+ aaa-server ACME (inside) host 10.44.1.2 secretkey timeout 5 crypto map ClientFW client authentication ACME
aaa-server ACME protocol tacacs+ aaa-server ACME host 10.44.1.2 timeout 5 key secretkey group-policy Support attributes authorization-server-group ACME
Using “aaa-server” commands define the TACACS+ or Radius service by specifying the connected interface, encryption key and IP address. An optional timeout can also be specified.
VPN Debugging, Maintenance and Status
The commands used for debugging, maintenance and status are the same as with LAN to LAN VPN configuration. Please refer to the previous chapter for information.