{"id":222,"date":"2004-09-02T09:09:20","date_gmt":"2004-09-02T08:09:20","guid":{"rendered":"http:\/\/wp.devco.net\/?p=222"},"modified":"2009-10-09T17:17:58","modified_gmt":"2009-10-09T16:17:58","slug":"major_pix_annoyance","status":"publish","type":"post","link":"https:\/\/www.devco.net\/archives\/2004\/09\/02\/major_pix_annoyance.php","title":{"rendered":"Major PIX annoyance"},"content":{"rendered":"

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.
\nWhen 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<\/i> with various sub groups of information associated with individual VPNs.<\/p>\n

\n
\naccess-list 101 permit ip host y.y.y.y host z.z.z.z\ncrypto ipsec transform IPSECXFORM esp-des esp-sha-hmac\ncrypto map IPSECMAP 20 ipsec-isakmp\ncrypto map IPSECMAP 20 match address 101\ncrypto map IPSECMAP 20 set peer x.x.x.x\ncrypto map IPSECMAP 20 set transfrom-set IPSECXFORM\ncrypto map IPSECMAP 20 set security-association lifetime seconds 28800\ncrypto map IPSECMAP interface outside\n<\/pre>\n<\/blockquote>\n
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.
\nWhen you type any of the above crypto map<\/i> commands a new submap gets initialized with defaults:<\/p>\n
\n# crypto map MAP 1 set peer 1.1.1.1
\n# sh crypto map
\nCrypto Map: “MAP” interfaces: { outside }
\nCrypto Map “MAP” 1 ipsec-isakmp
\nWARNING: This crypto map is in an incomplete state!
\n(missing peer or access-list definitions)
\nPeer = 1.1.1.1
\nNo matching address list set.
\nCurrent peer: 1.1.1.1
\nSecurity association lifetime: 4608000 kilobytes\/28800 seconds
\nPFS (Y\/N): N
\nTransform sets={ }\n<\/p><\/blockquote>\n
The problem here is that if the IPSECMAP crypto map is active on the outside<\/i> interface at the time, this incomplete crypto map will prevent all traffic from flowing.  Only when you have both the peer<\/i> and the match address<\/i> specified will it have enough information to not try and crypt all the traffic on the interface.
\nThe 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:<\/p>\n
\nWhile 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.\n<\/p><\/blockquote>\n
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<\/i> 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!
\nUPDATE:<\/B> 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<\/i> 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 \ud83d\ude42<\/p>\n","protected":false},"excerpt":{"rendered":"
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 […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"","_et_pb_old_content":"","footnotes":""},"categories":[1],"tags":[38,39,25],"_links":{"self":[{"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/posts\/222"}],"collection":[{"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/comments?post=222"}],"version-history":[{"count":1,"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/posts\/222\/revisions"}],"predecessor-version":[{"id":773,"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/posts\/222\/revisions\/773"}],"wp:attachment":[{"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/media?parent=222"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/categories?post=222"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/tags?post=222"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}