Major PIX annoyance

by R.I. Pienaar | Sep 2, 2004 | Uncategorized

Most products have some quirks that you don’t like, some requires you to slightly amend the way you work and I am usually quite happy with that. The Cisco PIX has one major annoyance that I just can’t come to grips with.
When adding a VPN to the PIX you put one policy set on the interface that the traffic will leave. For each interface you define a crypto map with various sub groups of information associated with individual VPNs.

access-list 101 permit ip host y.y.y.y host z.z.z.z
crypto ipsec transform IPSECXFORM esp-des esp-sha-hmac
crypto map IPSECMAP 20 ipsec-isakmp
crypto map IPSECMAP 20 match address 101
crypto map IPSECMAP 20 set peer x.x.x.x
crypto map IPSECMAP 20 set transfrom-set IPSECXFORM
crypto map IPSECMAP 20 set security-association lifetime seconds 28800
crypto map IPSECMAP interface outside

These few commands will essentially set up the phase 2 of the IPSEC connection. Later on when you want to add a second VPN you just add a new numbered submap to the IPSECMAP since each interface can only ever have one MAP assigned to it.
When you type any of the above crypto map commands a new submap gets initialized with defaults:

# crypto map MAP 1 set peer 1.1.1.1
# sh crypto map
Crypto Map: “MAP” interfaces: { outside }
Crypto Map “MAP” 1 ipsec-isakmp
WARNING: This crypto map is in an incomplete state!
(missing peer or access-list definitions)
Peer = 1.1.1.1
No matching address list set.
Current peer: 1.1.1.1
Security association lifetime: 4608000 kilobytes/28800 seconds
PFS (Y/N): N
Transform sets={ }

The problem here is that if the IPSECMAP crypto map is active on the outside interface at the time, this incomplete crypto map will prevent all traffic from flowing. Only when you have both the peer and the match address specified will it have enough information to not try and crypt all the traffic on the interface.
The PIX CLI has no way to send a batch of commands to it, and there is no way to enable/disable just a sub crypto map. Cisco’s documentation has the following suggestion:

While a new crypto map instance is being added to the PIX Firewall, all clear and SSH traffic to the firewall interface stops because the crypto peer/ACL pair has not yet been defined. To workaround this, use PIX Device Manager (PDM) to add the new crypto map instance or, through the PIX Firewall CLI, remove the crypto map interface command from your configuration, add the new crypto map instance and fully configure the crypto peer/ACL pair, and then reapply the crypto map interface command back to the interface. In some conditions the CLI workaround is not acceptable as it temporarily stops VPN traffic also.

So you either use the GUI or you turn off ALL OTHER VPN’s while adding a new one!? That is insane, there are so many ways to elegantly fix this problem, they can have a simple addition to the crypto map command set, something like crypto map IPSECMAP 20 disable and make that the default state, only when you have configured the whole sub map would you enable it, however now I am stuck using the GUI!
UPDATE: This seems to only affect PIX Firewall Version 6.2, from 6.3 onwards the problem goes away, the bit of output from sh crypto map is from a 6.3 PIX and it knows the MAP is incomplete, 6.2 initialised it to 0.0.0.0 matching all traffic. Time to upgrade my lab PIX machines 🙂