As an example let us create a VPN between the 10.44.57.0 network (My network) and the following networks and hosts at a client called ACME. The access will also be limited by ports and flow direction.
- From 10.44.57.0/24 (My Network) to 10.3.4.0/24 (ACME) on TCP 445
- From 10.1.0.0/23 (ACME) to 10.44.57.0/24 (My Network) on TCP 5000-TCP5500
- From host 192.168.10.50 (ACME) to 10.44.57.192/26 on UDP 100
- Ping allowed from 10.44.57.0 to all client networks
The IPSEC engine must be seen as an additional layer of networking added to the firewall. The engine is bound to an interface and only encrypts/decrypts matching traffic when the packet leaves/arrives at that interface. For traffic to pass through the firewall to and from other interfaces it must be configured to using normal access lists, NAT-control and routing.
If a packet arrives at the VPN interface and does not match an SPD session in the Policy Manager it will not be encrypted and is passed in the clear to the interface to be routed as required. Care must be taken that sensitive data is not allowed to flow through the firewall and not be encrypted as it will then try to route to the destination over the public Internet. Using private network ranges for source and destination addresses ensures that this does not happen.
Address translation for an interface will take place before the packet is examined by the Policy Manager.
SPD Encryption Domain
First we define the “encryption domain” for the SPD session. This special access list is only used by the IPSEC engine to determine if a packet arriving at the interface matches a unique SPD. Since this access list is only used to match destination VPN traffic it can be fairly simple and does not require specific protocol and port values.
Be careful that the VPN match access list is not matching traffic that you do not want encrypted. Name the access list so that it is easily identifiable as a VPN access list and mention the client name so that it is easy to track configuration related to this VPN.
access-list acl-vpn-ACME permit ip 10.44.57.0 255.255.255.0 10.3.4.0 255.255.255.0 access-list acl-vpn-ACME permit ip 10.44.57.0 255.255.255.0 10.1.0.0 255.255.252.0 access-list acl-vpn-ACME permit ip 10.44.57.192 255.255.255.192 host 192.168.10.50
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 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 10.1.0.0 255.255.255.0 10.44.57.0 255.255.255.0 range 5000 5500 access-list acl-outside permit udp host 192.168.10.50 10.44.57.192 255.255.255.192 eq 100 access-list acl-outside permit icmp 10.1.0.0 255.255.255.0 10.44.57.0 255.255.255.0 access-list acl-outside permit icmp 10.3.4.0 255.255.255.0 10.44.57.0 255.255.255.0 access-list acl-outside permit icmp host 192.168.10.50 10.44.57.192 255.255.255.192
access-list acl-web permit tcp 10.44.57.0 255.255.255.128 10.3.4.0 255.255.255.0 eq 445 access-list acl-web permit icmp 10.44.57.0 255.255.255.128 10.3.4.0 255.255.255.0 access-list acl-web permit icmp 10.44.57.0 255.255.255.128 10.1.0.0 255.255.255.0 access-list acl-web permit icmp 10.44.57.0 255.255.255.128 host 192.168.10.50
access-list acl-app permit tcp 10.44.57.128 255.255.255.192 10.3.4.0 255.255.255.0 eq 445 access-list acl-app permit icmp 10.44.57.128 255.255.255.192 10.3.4.0 255.255.255.0 access-list acl-app permit icmp 10.44.57.128 255.255.255.192 10.1.0.0 255.255.255.0 access-list acl-app permit icmp 10.44.57.128 255.255.255.192 host 192.168.10.50
access-list acl-sql permit tcp 10.44.57.192 255.255.255.192 10.3.4.0 255.255.255.0 eq 445 access-list acl-sql permit icmp 10.44.57.192 255.255.255.192 10.3.4.0 255.255.255.0 access-list acl-sql permit icmp 10.44.57.192 255.255.255.192 10.1.0.0 255.255.255.0 access-list acl-sql permit icmp 10.44.57.192 255.255.255.192 host 192.168.10.50
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.
Note that ICMP is not stateful and must therefore exist on both inbound and outbound ACL’s for ICMP to work correctly.
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 10.3.4.0 255.255.255.0 access-list acl-nonat-web permit ip 10.44.57.0 255.255.255.128 10.1.0.0 255.255.252.0 access-list acl-nonat-web permit ip 10.44.57.192 255.255.255.192 host 192.168.10.50
access-list acl-nonat-app permit ip 10.44.57.128 255.255.255.192 10.3.4.0 255.255.255.0 access-list acl-nonat-app permit ip 10.44.57.128 255.255.255.192 10.1.0.0 255.255.252.0 access-list acl-nonat-app permit ip 10.44.57.192 255.255.255.192 host 192.168.10.50
access-list acl-nonat-sql permit ip 10.44.57.192 255.255.255.192 10.3.4.0 255.255.255.0 access-list acl-nonat-sql permit ip 10.44.57.192 255.255.255.192 10.1.0.0 255.255.252.0 access-list acl-nonat-sql permit ip 10.44.57.192 255.255.255.192 host 192.168.10.50
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 must be defined on each peer. The proposals are valid for all VPN connections and both endpoints need to be able to match one common proposal before they can proceed past the first part of Phase 1. If a proposal is found then Diffie Hellman (DH) public/private keys are exchanged. There are four different DH groups each with increasing mathematical bit lengths. The groups levels are 1,2,5 and 7 and must exactly match across peer proposals. Finally the pre-shared key (PSK) is used to hash the data that is used to integrity check the Phase 1 process. If all three parts are matched then IKE Phase 1 will complete.
Depending on the operating system version the commands will differ.
isakmp identity address isakmp enable outside isakmp policy 10 authentication pre-share isakmp policy 10 encryption aes isakmp policy 10 hash sha isakmp policy 10 group 2 isakmp policy 10 lifetime 86400 isakmp policy 20 authentication pre-share isakmp policy 20 encryption 3des isakmp policy 20 hash md5 isakmp policy 20 group 1 isakmp policy 20 lifetime 9000 isakmp key abc123 address 188.8.131.52 netmask 255.255.255.255
crypto isakmp identity address crypto isakmp enable outside crypto isakmp policy 10 authentication pre-share encryption aes hash sha group 2 lifetime 86400 crypto isakmp policy 20 authentication pre-share encryption 3des hash md5 group 1 lifetime 9000 tunnel-group 184.108.40.206 type ipsec-l2l tunnel-group 220.127.116.11 ipsec-attributes pre-shared-key abc123
Each Phase 1 proposal is assigned a preference number and these are evaluated in order starting from lowest number first. In this example the “10” policy is evaluated first and uses AES symmetric encryption, SHA hashing and a Diffie Hellman Group 2 asymmetric key exchange. The resulting Security Association (SA) has a lifetime of 86400 seconds which is the minimum time required before another renegotiation of the IKE Phase 1 SA is forced. In the newer operating systems the connection must also be designated as a “l2l” (LAN to LAN) type.
Included in Phase 1 hashing is host identification information that can either be the peer’s IP address or its hostname. Hostname identification is only really required for certificate based Phase 1 authentication however whatever value is used it must match with the peer. The identity command designates whether to use “address” or “hostname”
The pre-shared key is defined using the “key” command. The PSK can be shared across multiple VPN’s but this is not recommended.
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. It is referred to as “quick mode” as it relies on the established Phase 1 keys to quickly setup a new, faster changing, key that is used for data encryption. By default many Phase 2 SA negotiations will take place in the same period as a single Phase 1 SA. Phase 2 configuration parameters are also unique for each VPN tunnel unlike Phase 1 which could have any proposal matched to any VPN.
crypto ipsec transform-set AES-SHA esp-aes esp-sha-hmac crypto map ClientFW 10 ipsec-isakmp crypto map ClientFW 10 match address acl-vpn-ACME crypto map ClientFW 10 set peer 18.104.22.168 crypto map ClientFW 10 set transform-set AES-SHA crypto map ClientFW 10 set security-association lifetime seconds 3600 crypto map ClientFW interface outside
The crypto map command is used to populate the SPD database with encryption and domain details for each VPN connection handled by the gateway. Only a single map can be bound to each interface so care must be taken that all VPN are properly described within the map. The map should be named so that it described the local peer and is case sensitive. Each new map entry should be a number starting at 10 and incrementing by 10 for each new entry. Each entry requires the following information
- The peers IP address
- The encryption domain. (defined by an access-list)
- The strength of the symmetric encryption. (DES, 3DES or AES)
- The hashing method (MD5 or SHA) used for data integrity checking.
- Additional timeout and data flow settings.
Settings have to exactly match the peer settings for Phase 2 to complete. If additional VPN’s are required on the gateway then additional map entries are required. VPN encryption and hashing settings can be duplicated on additional VPN’s but the encryption domains have to be unique or else the policy manager will not be able to match an SPD entry to an established VPN
crypto ipsec transform-set DES-MD5 esp-des esp-md5-hmac crypto ipsec transform-set AES-SHA esp-aes esp-sha-hmac crypto map ClientFW 10 ipsec-isakmp crypto map ClientFW 10 match address acl-vpn-ACME crypto map ClientFW 10 set peer 22.214.171.124 crypto map ClientFW 10 set transform-set AES-SHA crypto map ClientFW 20 ipsec-isakmp crypto map ClientFW 20 match address acl-vpn-TOON crypto map ClientFW 20 set peer 126.96.36.199 crypto map ClientFW 20 set transform-set DES-MD5 crypto map ClientFW interface outside
Additional IKE Settings
In Phase 1 and Phase 2 there are many parameters that can be tweaked. Some commands however may not be available in older operating systems.
In most cases the default settings as shown in the two previous sections will be sufficient to setup a secure and stable VPN. Listed below are the additional settings that can be changed if required by a third party.
On later operating systems (7.x) IKE Phase 1 handshake can be shortened by enabling “Aggressive Mode”. In this mode the typical 6 message exchange is shortened to only 3 messages. Although quicker the reduced trust setup can expose some Phase 2 information during negotiation. This should only be enabled if the peer is unable to operate in “Main mode” and is set individually for each SPD map entry.
crypto map ClientFW 10 set phase1-mode aggressive
IPSEC uses UDP 500 for IKE negotiation and Protocol 50 and 51 for ESP/AH communication of the encrypted data. Protocols are not NAT aware and cause VPN setup to fail in NAT environments. NAT traversal makes use of the IKE communications channel on UDP 500 and an additional UDP 4500 port to encapsulate the Protocol 50/51 traffic and enable correct functioning through NAT firewalls and routers. To enable this globally use the following command.
crypto isakmp nat-traversal 30
The 30 designates the keep-alive timeout in seconds for the tunnel. In some cases having NAT traversal enabled can cause problems if the terminating device does not know how to handle the encapsulated traffic. To disable NAT traversal for a single SPD entry use the following map command.
crypto map ClientFW 10 set nat-t-disable
Match the map name and entry number to the VPN.
Perfect Forward Secrecy
Perfect Forward Secrecy (PFS) breaks “quick mode” by not allowing IKE Phase 2 keys to be derived from Phase 1 keys. This slows down the Phase 2 renegotiation considerably but improves security by not linking encryption keys from previous packets with current keys. This is achieved by having Phase 2 essentially do a Diffie Hellman negotiation for each new Phase 2 SA. PFS is therefore defined with a Diffie-Hellman group as follows.
crypto map ClientFW 10 set pfs group2
PFS must again match peer DH group and be configured for each SPD map entry.
VPN configuration is primarily about matching settings, especially with IKE Phase 2. Use the following checklist to aid troubleshooting problems.
- Check that the peer IP addresses are defined correctly. If required add “icmp” rules to permit ping between the two peers to help eliminate routing/network issues.
- Check that IKE Phase 1 proposals match a proposal on the client system. If no match is found then an error message will be logged in the debug logs saying this.
- Check that the correct transform set (encryption/hash) has been bound to the PDS map entry for the VPN. Also check the following…
- Diffie Helman group.
- PFS settings
- NAT traversal settings.
- Change the timeout values to match the peer’s settings.
If no debug logs are displayed then the problem is network/routing related. Use “icmp” rules to check connectivity.
Failure of IKE Phase 1 or Phase 2 is almost always a settings mismatch. It is recommended to not use MD5 hashing with 3DES and AES encryption as some combinations are not supported on all peers and will show as un unmatched Phase 1 proposal.
If IKE Phase 1 and Phase 2 are completing but no data can be exchanged then look at the following areas.
- Access Lists and NAT rules on the firewall. Check for “xlate” and “access denied” logs.
- NAT traversal settings – It might need to be enabled or disabled depending on the peer.
If the VPN can be established but periodically stops working for no reason then the problem is timeout related. If the VPN tends to stay “dead” for a long time then the problem is IKE Phase 1 related. It may be that the VPN is matching a similar Phase 1 proposal that has the wrong timeout settings which the peer does not object to. In any case try and standardise on a common timeout for all the VPN’s that are matching that proposal.
If the VPN is experiencing short periods of “outage” then the cause is a Phase 2 timeout mismatch. This is usually more common and easy to remedy. Adjust the security association timeout to match the peer.
Security Association Management
Both peers of a VPN have to have fully established IKE Phase 1 and Phase 2 security associations (SA) before the VPN will transfer encrypted data. IKE Phase 1 and Phase 2 SA settings are all aged by timeouts. When the timeout is reached the SA settings are flushed from the system and new ones generated with the peer. If however a VPN gateway looses its SA credentials then it will fall out-of-sync with its peer and stop transmitting data. This can happen if a device is rebooted or crashes.
To restore data flow the “out-of-sync” SA credentials will need to be deleted from the peers.
To clear a single IKE Phase 2 map entry from the SPD
clear crypto ipsec sa peer 188.8.131.52
To clear all Phase 1 peer proposal SA entries.
clear crypto isakmp sa
Debugging the VPN
Cisco firewalls have the ability to display additional information about the VPN using the debug commands. These can prove to be useful if connection problems are encountered.
To troubleshoot IKE problems
debug crypto isakmp
In addition the later operating systems will also allow debug messages about the SA timers if timeout problems are suspected.
debug crypto isakmp timers
To troubleshoot IPSEC data encryption problems such as NAT traversal use the following command
debug crypto ipsec
The information returned by these commands is always displayed on the console or telnet session and cannot be sent to the syslog server. The debug logs are technically very detailed and an entry-by-entry explanation is beyond the scope of this document.
The debug command should always be disabled when not required anymore. This is achieved by the following command.
no debug all
VPN Status Commands
The status of a VPN can be displayed by using one of the following commands.
show crypto map
IKE Phase 1
show crypto isakmp sa detail
IKE Phase 2
show crypto ipsec sa detail
show vpn-sessiondb l2l show vpn-sessiondb summary
IKE Phase 1
show crypto isakmp sa detail show crypto isakmp stats
IKE Phase 2
show crypto ipsec sa detail show crypto ipsec sa stats
Almost all configuration and runtime information can be shown with one of these commands.