Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Configuring Interface ACLs for VPNs

Every Router connected to the Internet should be protected with an Access-Control-List (ACL) that filters the traffic that is sent to the router. This document shows which Access-List-Entries (ACEs) are needed to allow IPSec-Traffic into the router.

Note1: This applies to IOS-Routers with IOS 12.4+. With older IOS-releases there is more configuration needed. Leave a comment if you are interested in that.

Note2: This does not apply to the ASA where these ACEs are not needed. On the ASA, the interface-ACL by default only filters traffic that is sent through the ASA, but not traffic that is sent to the ASA.

The shown configuration is based on the following topology:



The Router should run a basic staefull firewall that allows return-traffic to enter the router-interface without the need for ACEs. That is part of the baseline-security and simplifies the config. Here we use the legacy CBAC because it's much easier to understand and to implement then the more powerful Zone-Based-Firewall:

ip inspect name FW ftp

ip inspect name FW tcp router-traffic

ip inspect name FW udp router-traffic

ip inspect name FW icmp router-traffic


interface GigabitEthernet0/0

  ip access-group SITE-A-INTERNET-IN in

  ip inspect FW out


ip access-list extended SITE-A-INTERNET-IN

  deny ip any any

Based on that config we extend the ACL with the needed ACEs.

Scenario 1: Only Site-to-Site VPNs with static Peers

Here we assume that all IPSec-Peers have static IPs that are not NATted anywhere. We need to allow the IPSec Data-traffic which is IP-Protocol 50 (ESP) and UDP/500 which is used for ISAKMP. Many examples on the internet show ACEs for IP/51 (AH). But that is normally not used for VPNs.

We start with the creation of an object-group with all VPN-Peers (for object-groups we need at least IOS 12.4(20)T+):

object-group network IPSEC-PEERS



Then we change the ACL to allow ESP- and ISAKMP-traffic from the peers to reach the router-interface:

ip access-list extended SITE-A-INTERNET-IN

  permit esp  object-group IPSEC-PEERS host

  permit udp  object-group IPSEC-PEERS host eq isakmp

  permit icmp object-group IPSEC-PEERS host echo

The last line in the ACL is not needed for the VPN-functionality. But beeing able to ping between the IPsec-peers makes troubleshooting much easier.

Scenario 2: Peers are behind a NAT-device with fixed IPs

If some IPsec-peers are hidden behind a NAT-device, then IPsec uses a technology named NAT-Traversal which starts to communicate with UDP/500 but changes later to UDP/4500.

In this case the ACL needs the following entries:

ip access-list extended SITE-A-INTERNET-IN

  permit esp  object-group IPSEC-PEERS host

  permit udp  object-group IPSEC-PEERS host eq isakmp non500-isakmp

  permit icmp object-group IPSEC-PEERS host echo

The entries in the object-group are still the global public IPs of the peer-router, not the internal (possibly private) IPs of the peer VPN-device.

If you know that all peers are behind a NAT-device, then you don't even need the ACE allowing IP/50, ESP. All user-traffic is sent on port udp/4500 in that case.

Scenario 3: IPsec-peers with dynamic IP-addresses

This is the scenario with Remote-Access-VPNs or Site-to-Site VPNs where some spokes don't have fixed IP-addresses. For Remote-Access-VPNs you should always assume that the client can be behind a NAT-device. The resulting ACL is the following:

ip access-list extended SITE-A-INTERNET-IN

  permit esp any host

  permit udp any host eq isakmp non500-isakmp

  ! generally allow ping from the internet if your security-policy allows that:

  permit icmp any host echo

Here we don't need the object-group with the IPsec-peers any more as we don't know their IP-addresses anyway.

Have fun protecting your VPNs!

Version history
Revision #:
1 of 1
Last update:
‎12-06-2013 12:33 AM
Updated by:
Labels (1)