Network Access Control VPN

Network Access Control

In addition to NIDS, access control, generally through the use of a firewall, should be performed before and after the VPN

device. When done on the interior of a VPN device as traffic heads toward the campus, the access control can ensure only

that the proper address ranges and protocols are allowed. As was mentioned earlier, most policies for VPN access tend to

allow the remote users to use almost any protocol they could on the local LAN. As such, it may be easier to define the

protocols you don't want your remote-user communities to be able to access, rather than define the ones that you do want

to allow.

In larger deployments, it is helpful to segment the various types of VPNs off of discrete access control points of the network.

This can be done through providing a dedicated firewall interface for each VPN type, as was done in the large VPN design.

This setup allows different levels of trust for different VPN applications. For example, an organization might decide it trusts

site-to-site VPNs a little more than remote-access VPNs. This better trust is a result of the fact that with site-to-site you know

the IP address of the remote peer and are potentially using digital certificates, whereas with remote-access VPNs you generally

do not know the address of your remote peer and are relying on group preshared keys combined with secondary

authentication to allow your users into the network. When deployed in this manner, VPN traffic can be filtered differently

based on what interface it arrives on at the access-control device.

Filtering outbound from the VPN device (toward the public network) is also important. This filtering can help ensure that

the VPN devices see only IPSec traffic coming into and out of their public interfaces. This filtering can generally be done on

a router with a standard ACL instead of a firewall, freeing the firewall to sit behind the VPN device as was specified earlier.

This setup is in contrast to many deployments today that place the firewall in front of the VPN device. When placed in front,

no visibility into the specific types of user traffic is possible because the traffic is still encrypted. Most of the benefits thatCisco Systems

 

stateful firewalls could provide in front of a VPN device are lost regardless, because IPSec traffic cannot be intelligently

filtered by most firewalls. The administrator would need to open a hole through the firewall to allow the traffic (that is, UDP

500 for IKE and IP 50 for ESP) and at that point, it is behaving in much the same way as a standard packet filter on a router.

Filtering inbound on the VPN device itself is recommended to allow only IKE and ESP. If the NAT transparency mechanism

is enabled, you should allow only the specific UDP or TCP port to the VPN device.

Often this access-control function can exist on the same hardware platform as the IPSec function. It can if your VPN device

also has a stateful firewall, or when a remote user connects using a laptop that has both VPN client software and a personal

firewall.