Problem solve Get help with specific problems with your technologies, process and projects.

The inherent capabilities of IPsec selectors and their use in remote-access VPNs

Network security expert Lisa Phifer explains the inherent capabilities of IPsec selectors versus how they're commonly used for remote-access VPNs.

In a recent SearchSecurity webcast, speaker Lisa Phifer, vice president and owner of consulting firm Core Competence, addressed technological developments in virtual private networks. Here Lisa answers a user-submitted question that she didn't have time to answer during the broadcast. If you missed our webcast New directions in VPNs or would like to review it, you may listen to the recorded webcast on-demand.

You mentioned during the webcast that IPsec can access the entire network behind the firewall whereas SSL can access only the assigned server. But I noticed that you set that in IPsec by setting the subnet address range rather than the entire network. Am I missing something here?

Good catch. I didn't elaborate on this in the webcast, but there's a difference between the capabilities inherent in IPsec selectors (traffic filters) and the way in which most companies use them. IPsec selectors can be based on entire IP subnets, partial subnets, individual destinations, protocol types and source/destination ports. That means that it's possible to create an IPsec selector that permits encrypted access to just one server and just one application (port) on that server (depending upon product support).

But in practice, most remote-access VPNs are configured with fairly coarse IPsec selectors, allowing access either to an entire subnetwork or (more often) to all destinations ( The latter is very common; to avoid split tunneling, all outbound traffic is sent via the IPsec tunnel. Once the traffic reaches the VPN gateway, it is decrypted and forwarded along to the final destination, whether that's inside the private Intranet or somewhere on the public Internet. This configuration lets the company monitor, log and filter all user traffic, no matter what the destination -- for example, stripping a malicious attachment at the VPN gateway that the user might otherwise pick up while downloading shareware from a public Web site.

SSL VPNs that act as circuit-layer proxies can be configured in a similar fashion to forward all outbound application traffic across the SSL VPN tunnel. However, many SSL VPN products are configured in a more granular fashion to ignore or drop traffic that lies outside the VPN policy and relay only that application traffic covered by the VPN's policy. SSL VPN products do tend to allow more granularity in filter configuration than even the most granular IPsec selectors -- for example, filtering on individual URLs, Web objects or even application commands. Using this kind of fine granularity can require more complex policy maintenance and so is usually done with group-level policies that apply the same complex filters to a set of users, rather than to individual users.

In short, product capabilities vary, but it's more important to decide the level of policy granularity your business requires, and then make sure the product you pick can support than level of granularity without a lot of administrative overhead.


This was last published in March 2004

Dig Deeper on VPN security

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.