Wednesday, March 12, 2008

IPSEC Checklist and Best Practices

Basic Checklist for VPN Configuration:
- IP address of the static VPN peers

- IP addresses/networks that will be tunneled
--> networks behind each VPN peer (site-to-site)
--> network behind VPN and pool (remote access)

- PHASE I / ISAKMP parameters
--> authentication (pre-shared key/certificate)
--> encryption (DES, 3DES, AES)
--> hash (SHA, MD5)
--> group (2, 5)

- PHASE II / IPSEC Parameters
--> transform set

- VPN Group (remote access only)
--> VPN Group Name
--> VPN Group Password


Best Practices:

* MIRROR TRAFFIC: The traffic (IP addresses/networks) defined on the two VPN peers should be mirror images of each other. That is, the source and destination on one end becomes the destination and source on the other end, respectively. Example: ---- PIX1 ======== PIX2 ----

access-list PIX1_TUNNEL permit ip
access-list PIX2_TUNNEL permit ip

* SEPARATE ACLS for NAT and CRYPTO: (For Cisco PIX/ASA): To facilitate expansion, define the same traffic twice; one used for defining the tunnel traffic (in the crypto map match statement), and another for preventing the translation of this traffic (nat (inside) 0 or similar statement). Here's a scenario showing the advantage of having separate access-lists:

(Note: The ASCII drawing below best viewed using Courier New)

PIX2 ---
PIX1 ---

PIX3 ---

PIX1 Configuration
access-list NONAT permit ip
access-list NONAT permit ip
nat (inside) 0 access-list NONAT

access-list TUNNEL1-2 permit ip
access-list TUNNEL1-3 permit ip

crypto map MYMAP 10 match address TUNNEL1-2
crypto map MYMAP 20 match address TUNNEL1-3

What if you need to form another tunnel to a new network,, behind another device, PIX4?

* CHANGES to LIVE VPN TUNNELS: When crypto and/or isakmp statements are changed while a VPN tunnel exists, chances are, the device where the change was made will hang. To avoid this, (1) disable the tunnel on the interface and (2) tear down existing tunnels before doing any changes.

* PRE-SHARED KEY FIRST, BEFORE CERTIFICATES: When configuring IPSEC tunnels using digital certificates, it is best to configure first using pre-shared keys. This way, you can eliminate all the errors which does not involve certificates. Later, when errors occur after placing certificates, you only need to deal with the certificate-part of the configuration. (Unless, of course, if you messed up the basic configurations somehow while adding the certificates.)

* ORDER of CRYPTO MAP POLICIES: For devices with both static and dynamic crypto map configurations, ensure that the static ones are evaluated first (usually, by specifying a lower sequence number) before the dynamic ones. Otherwise, all static tunnel configurations are useless as they will NEVER be used.

* NO XAUTH for SITE-TO-SITE with REMOTE ACCESS: For devices with both Site-to-Site and Remote Access VPN, ensure that extended authentication (XAUTH) is disabled for the site-to-site configuration. This is a common issue: a working VPN device cannot form L2L tunnel after adding remote access configurations.

No comments: