IP transit ACL best practise?

[switched switch]

All,
Need to get some validation on the below.
In summary, our border routers dont have any filtering on, but this needs to
start happening in a slow progression (eg blocking our address space inbound etc)
I am proposing an ACL that is applied to our IP Transit interfaces and IX peering interfaces blocking internal access.

As we are a service provider, I have many GRE tunnels etc coming into our network, and l2tp's (even via out IP transit) etc as we are a service provider. I am concerned that by applying an ACL we will cause some impact to customer networks.

The first lot is to protect our devices withi public IPs placed on our network devices. Below is protecting tunnel equipment to allow host 1.1.1.1 in, and block the rest to teh tunnel equipment and permit every other traffic.

ip access-list extended ACL-INBOUND
1 permit ip host 1.1.1.1 host 2.2.2.2
2 permit esp host 1.1.1.1 host 2.2.2.2
3 permit gre host 1.1.1.1 host 2.2.2.2
4 deny ip any host 2.2.2.2
5 deny esp any host 2.2.2.2
6 deny gre any host 2.2.2.2
100000 permit ip any any

Will the above if placed on our border (specifically the permit ip any any) ensure that customers will not be impacted? Eg if they have ESP/GRE will it be permitted?
Is there anything else here that I need to consider?

[Barry Yost · Accepted solution]

I'm pretty sure that GRE and ESP are considered subsets of IP (just like TCP, UDP, and ICMP are). In other words, permit ip host 1.1.1.1 host 2.2.2.2 should allow GRE and ESP since they're coming in as IP payloads. Thus your rules 2 and 3 will probably never match any traffic and just waste time evaluating packets needlessly.

Your final "permit ip any any" should prevent your filter from blocking any packet that rides an IPv4 packet because the rule explicitly permits the protocol as a whole, regardless of payload type.

[Richard Burts]

Barry makes a good point that statement 1 in the ACL makes statements 2 and 3 superflous. The same thing is true of statement 4 which makes statements 5 and 6 superflous.

The result of this ACL is that the only traffic that is allowed to get to host 2.2.2.2 is traffic sourced from 1.1.1.1. And any traffic sourced from 1.1.1.1 is allowed (it could be RDP, or SSH, or TFTP, or anything). If that is what you intend then the ACL works and does not impact any other traffic (other than anything with a destination of 2.2.2.2)

HTH

Rick

[switched switch]

Hi thanks for both of your replies. The aim is to start to clamp down on the environment and in this case I want to allow traffic from known sources to terminate vpn  tunnels behind our border routers, everything else to be blocked at the border. By allowing this ACL (I'll remove the ESP/gre) I think we are covered. Any other suggestions?