I have an issues with an access-list configured in INBOUND on Tunnel interface at the HUB routers (HUB1 and HUB2).
I attach a simple drawing of my setup:Drawing-Lab-Setup.Jpeg
Let me explain my configuration quickly:
- I have configureddual HUB and DUAL DMVPN layout
- DMVPN phase 3 is configured and I use EIGRP
- All the traffic is going (including Internet) through HUB location
- All spokes are configured with FVRF and receive only a default route from HUB routers
- Spoke to spoke traffic is possible and can be restricted if necessary by configuring a route to Null on spokes router
- HUB1 is the primary router and HUB2 is the backup router
- Spokes access Internet through HUB and are only permitted to access HTTP,HTTPS,FTP and ICMP
- Spokes can access everything at HUB location
In order to meet the security requirements and simplify at the maximum the configuration on the spokes I thought that I could implement an inbound access-list on the tunnel interface at HUB1 and HUB2. So Like that everytime I add a new spoke I don't have to configure more lines in the spoke config. I attach the access-list which I have configured on HUB1 and HUB2 and also the configuration of the tunnel interface (only for HUB1, HUB 2 is the same).
My isssue starts here. When I apply the access-list which is called DMVPN_INSIDE_IN on the tunne interface, spokes can ping the HUB location, no problem. The issue is when a spoke host try to reach the Internet (ping from 192.168.100.2) in this case 184.108.40.206 (see drawing) the access-list deny the packet by saying the following:
%SEC-6-IPACCESSLOGDP: list DMVPN_INSIDE_IN denied icmp 220.127.116.11 -> 18.104.22.168 (8/0), 1 packet
But the firewall sees actually the right source address before to be natted:
%FW-6-SESS_AUDIT_TRAIL_START: Start icmp session: initiator (192.168.100.2:8) -- responder (22.214.171.124:0)
If I remove the access-list everything is working fine! It looks like the access-list is inspecting the packet after the NAT process. Actually sometimes is working sometimes not. If I remove the access-list and put it back on again 192.168.100.2 can ping 126.96.36.199 without problem.
So what I don't understand is how I can apply this access-list on the tunnel interface? Should it be OUTBOUND instead of INBOUND? I don't really understand the Cisco IOS process here. How the Tunnel Interface viewed in this case?
Any ideas what is it happening here?
Looks to be related to CEF then (at least to me not knowing too much about it). Probably now a valid adjacency is installed and it will work until it's removed from FIB for whatever reason.
A good test would be to check if it will keep working after you remove and add cef, or was is just some minor problem with access-lists.