Worldwide Locations
The subject of this week’s post was actually prompted by a question from a former colleague. Soon after the PIX Firewall added support for IPSec Virtual Private Networks, a command was added to the command-line, sysopt connection permit-ipsec. This command was subsequently changed to sysopt connection permit-vpn in ASA/PIX OS 7.0 after support for PPTP tunnel services was discontinued. This post will explore the implications of leaving this default command intact or disabling it.
Below is a screenshot of the above CLI command as seen in the ASDM GUI. Note that this configured under the Advanced menu option under System Options.
As noted above, the default setting allows inbound decrypted IPSec packets to bypass any configured access-lists on the outside interface. This is also a default setting that appears in the IPSec VPN Wizards. When a network administrator encounters this functionality in the ASA they are understandably concerned, as there is no corresponding configuration statement in the Cisco IOS. On routers which terminate VPN connections, a rather complex access-list often exists which must permit not only the ISAKMP and ESP protocols (used by IPSec) entry into the “applied to” interface, but also the decrypted packets that flow beyond it.
Closer examination of the above screenshot should calm some nerves here. A very viable (and powerful!) option would be to configure a VPN filter as part of the group policy applied to the tunnel-group. For remote access implementations, this can be further enhanced through the use of downloadable ACLs using RADIUS, referred to above by the phrase “per-user authorization lists”.
The ASA and PIX have the advantage of not requiring explicit access-list statements to permit ISAKMP and ESP protocols into an interface used to terminate a VPN connection. This behavior is an artifact of the inherent characteristics of access-lists on security appliance interfaces; namely, they only affect throughput traffic, not traffic to the ASA. While this might apparently convince the administrator to disable (or uncheck) the implicit allowance of IPSec packets and implement access-lists instead, there can be some potential problems with this approach.
First, if the admin is careless and DOES NOT include an appropriate permit statement for the decrypted packet to initiate a connection to a server on a higher security-level interface, an undesirable result occurs. A VPN session will be successfully initiated (and seen via CLI or ASDM monitoring) but no traffic will flow. A second potential problem can be that the access-list with all of its permit statements becomes unwieldy, and, since VPN connections most often have group-specific access privileges, a set of filter rules associated with a user or site-to-site tunnel group is by far the more manageable option.
Author: Doug McKillip
References