www.routermonkey.org

Cisco PIX Remote Access VPN PIX v7.2(2)

Cisco PIX Remote Access VPN

PIX v7.2(2)

Barney Gaumer – 10/24/2007

 
This howto is written for intermediate Pix users who intend to implement VPN Remote Access to their Cisco PIX without using Certificates and/or other secure authentication methods for tunnel negotiation.

For the VPN Client I recommend you use a 5.x version of the Cisco VPN client.

My example is base on pre-shared keys using xauth which will be explained later in this paper.  Additionally, Post IKE authentication is offloaded to Microsoft AD via Kerberos which will also be discussed later.

Let’s get started!

You should already have a management IP on “INSIDE” interface on the PIX device and have ASDM 5.x or better and have ASDM open.  Now click on the “Configuration” button!

Click on “Properties” on the left pane of your ASDM window and choose AAA Setup.

We need to define AAA Server Groups by clicking on “Add” for groups (the top box) and servers (bottom box) see the example in figure 1.0.

 

Figure 1.0

 

Figure 1.1 shows an example of the AAA Server detail being added.

 

Figure 1.1

 

 

Let’s keep working backwards! Still on the configuration tab, click on VPN on the left control pane.  Go all the way down to IP Address Management and select IP Pools as you will need to have an address pool for your VPN users during tunnel group setup.

Figure 1.2 shows the basic IP Pool configuration

 

Figure 1.2

 

 

Now lets move to IKE/Global Parameters and enable NAT-T for RA clients that are behind a firewall and enable IKE on the interface your users will attempt connections to on your PIX (outside for most of us).

See the example in Figure 1.3

 

Figure 1.3

 

 

Next we’ll take a look at the IKE policies.  Click on IKE/Policies, in my example in figure 1.4 I’ve setup the crypto as “3des” and “md5” for the hash, “diffie-hellman group 2” for key exchange.  Our authentication will be set to “pres-share” and the default lifetime is used. 

Note: I have setup 3des/md5/D-H 2/pre-share with priority value of 20 for l2l-tunnels. 
Additionally, I have setup 3des/sha/D-H 2/pre-share with a priority value of 65,535 for RA-tunnels.

 

Figure 1.4

 

Now its time to configure IPSec rules for remote access.  In figure 1.5 I have both static and dynamic crypto-maps defined.  The dynamic crypto-map will be used for remote access.

 

Figure 1.5

 

 

Under IPSec Rules if you click “ADD” the type needs to be dynamic; you should see the screen shown in figure 1.6.  Here you will select your transform sets (default Transform Set already exists).  You want encapsulated services protocol (ESP) so Add ESP-3DES-SHA and ESP-3DES-MD5.

Check the box for Perfect Forward Secrecy and use Group 2.

 

Figure 1.6

 

 

Figure 1.7 shows the Crypto Map Advanced Tab, click on this to set SA lifetime and enable NAT-T as well as reverse route injection.  You want reverse route injection if you use a dynamic process as it will create /32 routes for each tunnel session and inject them into your dynamic process so your VPN users will be able to access resources specified in remote access design specification.

 

 

Figure 1.7

 

 

Next we will define our traffic selection.

This segment can be a bit confusing for many.  The confusion seems to be regarding what traffic should be protected.  For RA on using a PIX you need to need to specify the interface (outside for most of us) then the source address for the tunnel.  We are using “any” because this is a dynamic map and the source address for the clients will be different depending on their location and ISP.

The Destination address will be the subnet that you used when you created your address pool back in figure 1.2.  You will want to use IP as the protocol unless there are security related objectives the require being more restrictive.

Note: Most security related issues are better handled via Security Policy and will be covered later.

 

Figure 1.8

 

 

Now let’s walk back up the tree to General/Group Policy.  I will click “ADD” and name my group “lab-vpn”

 

 

Figure 1.9 

 

Figure 2.0 shows the edit detail for the Internal Group Policy “lab-vpn”. On the “general tab” just make sure that IPSec is checked for the Cisco VPN Client.  L2TP over IPSec is not needed for this exercise and typically will require you to use “certificates” during IKE phases which is not covered in this document.

 

Figure 2.0

 

 

Next, click on the IPSec tab for lab-vpn.  Enable PFS (perfect forward secrecy) this will use the Diffie-Hellman Group 2 which was setup when you defined your crypto-map.  We will come back to this section to specify Tunnel Group Lock later after we setup the Tunnel Group for lab-vpn.  Lets move on for now.

 

 

Figure 2.1 

 

 

In Figure 2.2 we address parameters that will be passed to the Cisco VPN Client after authentication.  Add your default domain and define your split tunnel policy.  For lab-vpn I am allowing split tunnels. I am only allowing this in my Lab; otherwise you can choose to tunnel everything.

Under “Address Pools” you should see the “pix-tun-users” pool you created earlier.  Choose to add that as you pool for lab-vpn group policy.

 

 

Figure 2.2

 

 

In figure 2.2 under the split tunnel policy I have chosen to tunnel the networks in the list “isi-vpn-nets”

Below in 2.2(a) you can see the ACL that permits the networks for this group policy.

 

 

Figure 2.2(a)

 

 

In figure 2.3 I’ve chosen to explicitly allow IPSec over UDP for this group and have explicitly defined the port as 10000.

 

 

Figure 2.3

 

 

Figure 2.4, 2.5, 2.6 and 2.7 are included for review but will not be discussed as you may just accept the inherited values.

 

 

Figure 2.4

 

 

Figure 2.5

 

 

Figure 2.6

 

 

Figure 2.7

 

 

Time to create the Tunnel Group for lab-vpn.  On the screen in figure 2.8 choose add and name your Tunnel Group, I called mine “lab-vpn”

 

Figure 2.8

 

 

In figure 2.9 At the general/basic tab while editing the tunnel group “lab-vpn” explicitly select “lab-vpn” in the group policy section.

 

 

Figure 2.9

 

 

Back in figure 1.0 and 1.1 we defined our authentication server through Microsoft Windows AD via Kerberos. Tunnel Group/General/Authentication is were we will apply this. Figure 3.0 shows that “lab_authen” has been selected as the Authentication Server Group.

Note: Use LOCAL if Server Group Fails is checked in this example, this will allow authentication to default to the Pix local user database in the event that servers in the defined ASG are unavailable.

NAC is not covered in this document.

 

 

Figure 3.0

 

 

We will skip Authorization and Accounting as they are not implemented in this how-to document.

We are using a local address pool for our implementation and no DHCP scope is defined therefore the only thing needed in figure 3.1 is to add the address pool “pix-tun-users”.

 

 

Figure 3.1

 

 

In figure 3.2 Tunnel Group/General/Advanced we will assign lab_authen to the outside interface and choose “add”.  Then we will repeat this process for our address pool, assigning pix-tun-users to the outside interface and choosing “add”

 

 

Figure 3.2

 

 

In figure 3.3 we setup the IPSec parms for Tunnel Group “lab-vpn”.  We need to set a Pre-shared Key (I am using “cisco” as my key), now make sure that xauth is used as the Authentication Mode.  This is important when authentication is unidirectional or is offloaded to another device such as RADIUS or two factor like RSA.

 

 

Figure 3.3

 

Figure 3.4 shows Tunnel Group/PPP, I’ve just accepted the defaults as this will not be used in our implementation.

 

 

Figure 3.4

 

 

Now you will want to revisit figure 2.1 in the Group Policy and set your Tunnel Group Lock to “lab-vpn”.

Next if you are using NAT/PAT on your PIX, you will need to set some NAT Exemptions for the address pool and networks that participate in your VPN RA setup.  If you examine figure 3.5 you will see that there are exemptions for isi-l2l-networks and 10.2.0.0/24.  10.2.0.0/24 is our local address pool and isi-l2l-networks is defined as the networks that will be tunneled to clients in lab-vpn.

 

 

Figure 3.5

 

 

Next we need to setup policy to allow our VPN RA connected clients access to networks that are defined in isi-l2l-networks.

You can see in figure 3.6 on rule 19 that 10.2.0.0/24 is allowed to access the networks in isi-l2l-networks for protocol “IP”.

 

 

Figure 3.6

 

 

Be sure & save your config and good luck!

This document was done in a hurry and the post mortem is several months beyond the implementation date.  Additionally, I’ve used MS Paint to sanitize the information in the images :)  Therefore any questions/comments should be directed to forums.routermonkey.org

 

Regards,

Barney Gaumer

RoUtermOnKey.org

 

Here are some “Monitor Screen Shots” for VPN RA Session.

 

Exhibit A

 

 

Exhibit B