Cisco PIX/ASA LAN to LAN Configuration

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

 Access Lists
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

and

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.

PIX 6.x

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

PIX 7.x/ASA

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 213.38.192.42 type ipsec-l2l
tunnel-group 213.38.192.42 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 213.38.192.42
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 213.38.192.42
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 211.23.38.192
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.

Aggressive Mode

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

NAT Traversal

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.

Troubleshooting

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 213.38.192.42

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.

PIX 6.x

VPN Information

show crypto map

IKE Phase 1

show crypto isakmp sa detail

IKE Phase 2

show crypto ipsec sa detail

PIX 7.x/ASA

VPN Information

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.