Over the years, I’ve gotten pretty savvy on Cisco PIX firewall configuration, especially in the area of IPsec VPNs. I’ve also had to decipher the horrible online Cisco documentation for configuring site-to-site and demand-dial VPNs of various flavors, especially for cases where there is a desire for a single PIX to support multiple scenarios for multiple client platforms and capabilities. I’m sure I share this opinion with anyone else who has tried to use a PIX for both firewall and VPN duty. Because of this, I thought I’d share the wealth and put a stop to incomplete, poorly documented examples. This example configuration for the PIX 7.x code base (also referred to as the ASA) supports all of the following concurrently (and has been tested in real-world deployments):

• Persistent IPsec tunnel from PIX at other site (site-to-site)
• Demand-dial IPsec from PIX firewall (hardware EzVpn client)
• Demand-dial IPsec from Cisco VPN software on Vista, XP, OSX, and Linux (software client)
• Demand-dial L2TP/IPsec with pre-shared key from native XP and Vista (no additional client software)
• Windows IAS (Active Directory controlled) RADIUS authentication of all demand-dial clients

I’ll provide a future post which provides the same support from the PIX 6.x code base, as well as the client-side configurations. To download the full examples in text files, logon to http://share.gabefrost.com with username: anonymous, password: anonymous.

Huge kudos to my brother Dustin who actually has these configurations deployed, and who worked tirelessly with me to figure out all the nuances of these IPsec configurations on his hardware. Check out his business Digux if you’re interested in off-site data backup, IT consulting, or document management. He wrote the software enabling you to access the configuration files.

Network Information and Topology

• Headquarters has internal network of 10.0.0.0/24 with external IP address of 192.168.10.2.
• The Los Angeles branch office has internal network of 10.0.2.0/24 with external IP address of 192.168.20.2.
• The Washington DC branch office has internal network of 10.0.3.0/24 with external IP address of 192.168.30.2.
• All demand-dial VPN clients are assigned IP address within a range from the 10.0.1.0/24 subnet.

All hosts in each branch office are able to securely communicate with all hosts in the headquarters internal network, and likewise, all hosts within the headquarters internal network can communicate securely with all hosts in both branch office internal networks. This configuration only allows demand-dial clients to communicate with all hosts on the headquarters internal network, but a few access-list changes would allow communication with branch-office internal hosts as well.

To make the configuration easier to read, all non-cisco commands are CAPITOLIZED and in blue; these are the things you would replace with your own desired naming convention, IP address/mask, or password. Comments are in green. Sorry for the wrap-around text, but download the text file for easier reading.

Headquarters PIX Example Running 7.x Code

: Begin

interface Vlan1
nameif inside
security-level 100
ip address 10.0.0.1 255.255.255.0

interface Vlan2
nameif outside
security-level 0
ip address 192.168.10.2 255.255.255.0

! L2TP uses UDP port 1701 for establishment. An access-group later in this config references this ACL for allowing inbound L2TP session establishments.
access-list INBOUND extended permit udp any host 192.168.10.2 eq 1701

! Traffic sourced from local LAN with destination of demand-dial VPN clients.
access-list DEMAND_DIAL_VPN_CLIENTS extended permit ip 10.0.0.0 255.255.255.0 10.0.1.0 255.255.255.0

! Traffic sourced from local LAN with destination of Los Angeles branch office local LAN
access-list LA_BRANCH_OFFICE extended permit ip 10.0.0.0 255.255.255.0 10.0.2.0 255.255.255.0

! Traffic sourced from local LAN with destination of Washington DC branch office local LAN
access-list DC_BRANCH_OFFICE extended permit ip 10.0.0.0 255.255.255.0 10.0.3.0 255.255.255.0

! All the traffic which will be encapsulated by IPsec VPNs (persistent, or demand-dial)
access-list NO_NAT extended permit ip 10.0.0.0 255.255.255.0 10.0.1.0 255.255.255.0
access-list NO_NAT extended permit ip 10.0.0.0 255.255.255.0 10.0.2.0 255.255.255.0
access-list NO_NAT extended permit ip 10.0.0.0 255.255.255.0 10.0.3.0 255.255.255.0

! Allow the inside interface to respond to all icmp requests
icmp permit any inside

! The IP addresses assigned to demand-dial VPN clients
ip local pool DEMAND_DIAL_VPN_CLIENT_POOL 10.0.1.200-10.0.1.210 mask 255.255.255.0

! Do port-address-translation (PAT) for all traffic with source IP of 10.0.0.0/24 with destination off-link
global (outside) 1 interface
nat (inside) 1 10.0.0.0 255.255.255.0

! Don’t NAT IPsec traffic
nat (inside) 0 access-list NO_NAT

! Allow L2TP establishment to the outside interface of the PIX
access-group INBOUND in interface outside

route outside 0.0.0.0 0.0.0.0 192.168.10.1

! The Windows Internet Information Server information for authenticating demand-dial VPN clients
aaa-server IAS_SERVER protocol radius
aaa-server IAS_SERVER 10.0.0.131 key MY!RADIUS!SECRET

! Don’t make VPN traffic subject to ACL filtering
sysopt connection permit-vpn

! Policy details for establishing a session from L2TP/IPsec clients. User-specified policies are not supported for L2TP, only DefaultRAPolicy
group-policy DefaultRAPolicy internal
group-policy DefaultRAPolicy attributes
  dns-server value 10.0.0.2
  vpn-tunnel-protocol IPSec l2tp-ipsec
  default-domain value MYHOST.MYDOMAIN.NET
  vpn-idle-timeout 30
  split-tunnel-policy tunnelspecified
  split-tunnel-network-list value DEMAND_DIAL_VPN_CLIENTS

! Policy details for establishing an on-demand session from Cisco-specific VPN software or hardware
group-policy CISCO_CLIENT_VPN_POLICY internal
group-policy CISCO_CLIENT_VPN_POLICY attributes
  dns-server value 10.0.0.2
  default-domain value MYHOST.MYDOMAIN.NET
  vpn-idle-timeout 30
  split-tunnel-policy tunnelspecified
  split-tunnel-network-list value DEMAND_DIAL_VPN_CLIENTS
  nem-enable

! Transforms for supporting both demand-dial and persistent (transport-mode & tunnel-mode) IPsec VPNs
! 3DES is the common cypher supported by both XP and Vista.
crypto ipsec transform-set TRANS_ESP_AES_SHA esp-aes-256 esp-sha-hmac
crypto ipsec transform-set TRANS_ESP_AES_SHA mode transport
crypto ipsec transform-set TRANS_ESP_3DES_SHA esp-3des esp-sha-hmac
crypto ipsec transform-set TRANS_ESP_3DES_SHA mode transport
crypto ipsec transform-set TUNN_ESP_AES_SHA esp-aes-256 esp-sha-hmac
crypto ipsec transform-set TUNN_ESP_3DES_SHA esp-3des esp-sha-hmac

! L2TP demand-dial using IPsec transport-mode, while Cisco VPN software (and hardware clients) uses IPsec tunnel-mode, hence the dynamic map (which is used for all demand-dial VPN clients) must include both. 
crypto dynamic-map DYN_MAP 10 set transform-set TRANS_ESP_AES_SHA TRANS_ESP_3DES_SHA TUNN_ESP_AES_SHA TUNN_ESP_3DES_SHA
crypto dynamic-map DYN_MAP 10 set security-association lifetime seconds 86400

! Only a single crypto map can be applied to an interface.
! This shows how a single crypto map can handle multiple persistent and demand-dial VPNs concurrently.
! 10 and 20 are for persistent site-to-site tunnels, and 30 is for demand-dial connections.
! Any number of persistent connection maps can be added here (e.g. site-to-site); however, only a single dynamic
! map can be applied to support demand-dial clients.
crypto map OUTSIDE_MAP 10 match address LA_BRANCH_OFFICE
crypto map OUTSIDE_MAP 10 set peer 192.168.20.2
crypto map OUTSIDE_MAP 10 set transform-set TUNN_ESP_AES_SHA
crypto map OUTSIDE_MAP 20 match address DC_BRANCH_OFFICE
crypto map OUTSIDE_MAP 20 set peer 192.168.30.2
crypto map OUTSIDE_MAP 20 set transform-set TUNN_ESP_AES_SHA
crypto map OUTSIDE_MAP 30 ipsec-isakmp dynamic DYN_MAP
crypto map OUTSIDE_MAP interface outside

crypto isakmp identity address
crypto isakmp enable outside
crypto isakmp nat-traversal

! The cypher/hash pair the initiating client requests has to match one of these pairs. Each will be tried
! in order until a match is found

crypto isakmp policy 10
  authentication pre-share
  encryption aes-256
  hash sha
  group 2
  lifetime 86400

crypto isakmp policy 20
  authentication pre-share
  encryption 3des
  hash sha
  group 2
  lifetime 86400

! For persistent connections, the tunnel-group name has to be the same as the peer IP address
tunnel-group 192.168.20.2 type ipsec-l2l
tunnel-group 192.168.20.2 ipsec-attributes
  pre-shared-key LA!PRESHARED!KEY

tunnel-group 192.168.30.2 type ipsec-l2l
tunnel-group 192.168.30.2 ipsec-attributes
  pre-shared-key DC!PRESHARED!KEY

! Tunnel-group for servicing demand-dial L2TP clients
! User-specified groups are not supported for L2TP, only DefaultRAGroup
tunnel-group DefaultRAGroup general-attributes
  address-pool DEMAND_DIAL_VPN_CLIENT_POOL
  authentication-server-group IAS_SERVER
  default-group-policy DefaultRAPolicy

tunnel-group DefaultRAGroup ipsec-attributes
  pre-shared-key MY!PRESHARED!KEY

tunnel-group DefaultRAGroup ppp-attributes
  authentication ms-chap-v2

! Tunnel-group for supporting Cisco client software and hardware VPN clients
tunnel-group CISCO_CLIENT_VPN_GROUP type ipsec-ra
tunnel-group CISCO_CLIENT_VPN_GROUP general-attributes
  address-pool DEMAND_DIAL_VPN_CLIENT_POOL
  authentication-server-group IAS_SERVER
  default-group-policy CISCO_CLIENT_VPN_POLICY
  nem enable

tunnel-group CISCO_CLIENT_VPN_GROUP ipsec-attributes
  pre-shared-key MY!PRESHARED!KEY

tunnel-group CISCO_CLIENT_VPN_GROUP ppp-attributes
  authentication ms-chap-v2

: end

Someone sent me an email recently letting me know I was quoted a bunch of times in a new book titled Tricks of the Microsoft Windows Vista Masters. Specifically the quotes came from some of my posts on the Windows core networking blog. For the record, I do recall the author asking my permission many months ago. Cool.

This is a very interesting idea. My buddy Mark and I were experimenting with his new Windows Mobile phone which enabled Internet sharing with his laptop via USB. Many phones support this through Bluetooth so you don’t have to take the phone out of your pocket. In both Windows Vista and Mac OSX, the experience of tethering your phone and getting Internet access through it is very simple.

A new feature found on newer smartphones (including mine) is WiFi connectivity. The idea is simple, if the high-speed 3G wireless WAN (WWAN) data connectivity from a cell phone can be accessed through a laptop via wired (USB) or wireless (Bluetooth), also make it available via WiFi, except to multiple concurrent PCs (or devices). This can be achieved by enabling access point (AP) functionality in the phone, or allowing the phone to establish multiple ad-hoc WiFi connections. Putting aside the battery life challenge, processing power in smartphones today can surely handle this functionality, and good software can make the setup experience effortless (like plugging in the USB cable).

This is not a technology problem, but rather a business issue. Like any sustainable business, cellular providers obviously want to maximize their revenue for each asset they own (such as their high-speed data network). As such, they currently limit the software on phones to allow only a single PC to access that network via the phone. Otherwise said, every PC that uses the carrier’s high-speed network has to have an associated contract and data plan.

There is also a capacity planning challenge, but this can be overcome and ultimately comes back to a business decision of whether there’s value diluting an asset’s potential return. Having been a Network Engineer in the past, if you can’t reasonably predict how many hosts will concurrently access a resource, it’s hard to ensure sufficient capacity for a pleasant experience (especially for those customers who have signed the contract and are paying for the service). Simplifying the issue, if there are only 10 contracts for high-speed data access, and 10 devices associated with those contracts, but each of the 10 devices can share access with a bunch more devices, the capacity requirements are much greater and far less predictable. The simple solution to this is to enable the capability in phones, but limit the number of devices that can associate with the phone for shared connectivity. This way, capacity planning is still a static figure, and the same over-provisioning rules apply as before.

Anybody know a provider who is doing this? What do you think? I know I’d like this feature, which will be increasingly probable for automotive scenarios in the coming years.

Last week I posted on the core Windows networking blog about a new TechNet article describing network quality-of-service (QoS) support in Windows, and how to enable it. Take a gander if you’re interested.

Let me know if you want me to keep cross-posting like this. I’m not sure if I like it or if you’ll like it.

The folks over at LifeHacker talked about the top 15 reasons to adopt Vista, and the high-level quote represents the Network Map feature. In general, the network map feature is designed to be a diagnostic tool for your network. For those who are tech-savvy, it is a visual replacement for ping, traceroute, and arp. For the non-tech savvy, the network map shows you what your network looks like in addition to providing rich information about the PCs and devices connected to the network. Billy and I posted about this feature a couple of times on the core Windows networking blog should you want some more depth:

• How to Enable the Windows Vista Network Map
• Xbox 360 Fall Update Includes LLTD
• LLTD is Available for Non-Windows Platforms

I’ve done a bit of work in the WiFi Alliance, especially in the areas of quality-of-service (QoS - WiFi calls it Wireless Multi Media, or WMM), and video capable requirements. The most recent work by myself and colleagues was to convince the WiFi Alliance that 802.11n 2.4GHz operation should not be allowed to use the wide, 40MHz, channels, but rather be limited to the more narrow 20MHz channels. Only 5GHz operation allows for 40MHz channel usage, and therefore the super-high throughput that 802.11n is supposed to tout. Why did I push for this you ask? Well, 2.4GHz is a *really* noisy spectrum, and allowing a wider bandwidth in that spectrum would *really* degrade the experience of all other devices in that spectrum. 

Also, for the WiFi consumer electronics (CE) profile (which has a bunch of power saving features and more that you would want from CE devices), 5GHz operation is mandatory! So at minimum, CE devices that have 802.11n connectivity will provide 5GHz. They can also provide 2.4GHz if they want, but the less noisy 5GHz connectivity (with wide 40MHz channels and higher throughput) will ensure a better experience for video. This in-turn should result in better user satisfaction and less product returns.

I post fairly often on the core Windows networking blog, but often want to share other topics both professionally and personally. I’ll use this blog as my primary means to not only talk about the things I do in my life, but also to professionally answer all the questions I hear from customers and partners I interact with. I will also frequently comment on other online writings which I feel need clarification, or I agree/disagree with. I’ll share my thoughts on products, strategies, and even gaps in various markets.

If you have questions or want to comment on anything I write here, please feel free.