Cisco PIX/ASA Remote Access Configuration

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.

Authentication

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

and

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.

PIX 6.x

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

PIX 7.0/ASA

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.

PIX 6.x

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

PIX 7.x/ASA

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.

PIX 6.x

vpngroup Support dns-server 10.44.57.20
vpngroup Support wins-server 10.44.57.100
vpngroup Support default-domain acme.com

PIX 7.0/ASA

group-policy Support attributes
   dns-server value 10.44.57.20
   wins-server value 10.44.57.100
   default-domain value acme.com

Split Tunnelling

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.

PIX 6.0

vpngroup Support split-tunnel acl-vpn-ACME

PIX 7.0/ASA

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.

PIX 6.0

vpngroup Support pfs

PIX 7.0/ASA

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.

PIX 6.0

vpngroup Support idle-time 1800

PIX 7.0/ASA

group-policy Support attributes
   vpn-idle-timeout 30

The value is in seconds on older operating systems and in minutes on later operating systems.

Additional Settings

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.

User Authentication

To complete the setup of the RA VPN user authentication needs to be configured.

Local Authentication

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.

PIX 6.0

username joeboy password secret
crypto map ClientFW client authentication LOCAL

PIX 7.0/ASA

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 213.38.192.42 netmask 255.255.255.255 no-xauth

External Authentication

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.

PIX 6.0

aaa-server ACME protocol tacacs+
aaa-server ACME (inside) host 10.44.1.2  secretkey timeout 5
crypto map ClientFW client authentication ACME

PIX 7.0/ASA

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.