08-30-2010 01:49 PM - edited 03-04-2019 09:36 AM
Hello All,
I have a Cisco 837 running this ISO "c837-k9o3sy6-mz.124-10c.bin" and I'm having a problem with attaching an ACL to a GRE tunnel, once the ACL is attached to the tunnel it'll go down for some reason (I had the same configuration on the same router but with older ISO version and it used to work just fine), if I unattach the ACL (access_101) the tunnel will go back up.
This is my tunnel's configs ROUTER1:
interface Tunnel1
ip address 172.28.0.1 255.255.255.252
keepalive 10 3
ip access-group access_101 in
tunnel source Dialer0
tunnel destination 172.20.20.1
And this is the remote router tunnel's config ROUTER2 (which goes down)
interface Tunnel0
ip address 172.28.0.2 255.255.255.252
keepalive 10 3
tunnel source Dialer0
tunnel destination 172.22.22.2
And this is the access-list on ROUTER1 tunnel1:
Extended IP access list access_101
10 permit tcp 192.168.5.0 0.0.0.255 host 10.0.0.2 established
20 permit tcp 192.168.50.0 0.0.0.255 host 10.0.0.2 established
30 permit tcp 192.168.55.0 0.0.0.255 host 10.0.0.2 established
40 deny tcp 192.168.5.0 0.0.0.255 any
50 deny tcp 192.168.50.0 0.0.0.255 any
60 deny tcp 192.168.55.0 0.0.0.255 any
70 permit icmp 192.168.5.0 0.0.0.255 host 10.0.0.2 echo-reply
80 permit icmp 192.168.50.0 0.0.0.255 host 10.0.0.2 echo-reply
90 permit icmp 192.168.55.0 0.0.0.255 host 10.0.0.2 echo-reply
100 deny icmp 192.168.55.0 0.0.0.255 any
110 deny icmp 192.168.50.0 0.0.0.255 any
120 deny icmp 192.168.5.0 0.0.0.255 any
131 permit ip host 172.20.20.2 any
140 deny ip any any (569 matches) (once the ACL is attached ti tunnel1 on router1 i see the hit count going up)
Your answers are more than welcome
Thanks
Solved! Go to Solution.
08-30-2010 02:06 PM
You are dropping outgoing GRE keepalives from ROUTER1. Those will have source IP 172.20.20.1 and destination 172.22.22.2 - exactly opposite of outer IP Header of GRE. You can verify this with log parameter in deny statement, there might be plenty of output, so better disable console logging use buffered logging.
08-30-2010 02:06 PM
You are dropping outgoing GRE keepalives from ROUTER1. Those will have source IP 172.20.20.1 and destination 172.22.22.2 - exactly opposite of outer IP Header of GRE. You can verify this with log parameter in deny statement, there might be plenty of output, so better disable console logging use buffered logging.
08-31-2010 12:45 AM
Hi Pavol,
I added this ACL "permit ip host
Thank you for you helpful reply.
08-30-2010 02:06 PM
You are dropping outgoing GRE keepalives from ROUTER1. Those will have source IP 172.20.20.1 and destination 172.22.22.2 - exactly opposite of outer IP Header of GRE. You can verify this with log parameter in deny statement, there might be plenty of output, so better disable console logging use buffered logging.
08-30-2010 10:34 PM
The description by the original poster raises some questions about the topology of the network which may bear on the issue here. The tunnel destination of R1 is 172.20.20.1 which is presumably an address on R2. But the access list on R1 has a permit ( 131 permit ip host 172.20.20.2 any). So who is host 172.20.20.2?
If it is a typo error and really meant to permit packets from 172.20.20.1 then I suspect that the keepalives would work and the tunnel would stay up.
I believe that Pavol is on the right track but got a detail incorrect. The problem is that the access list is denying the keepalive packets. But it is not denying the outbound keepalive. For one thing an access list can not deny packets that are generated by the router itself. so the router can not deny its own outbound keepalive packets. And besides the access list is applied in so it is filtering inbound packets not outbound packets. I believe that the access list is denying the inbound keepalive packets and causing the tunnel to go protocol down.
Pavol does have a good suggestion if the original poster wants to verify what is the problem. If the access list included the log parameter on the deny ip any any then the access list would log the packets that it is denying - and I believe that among them would be packets from R2 to R1 designed to perform the keepalive function.
HTH
Rick
06-21-2016 09:21 AM
access_101 on ROUTER1's Tunnel1 interface is not permitting GRE keepalives from ROUTER2. The lack of keepalive response from ROUTER1 causes ROUTER2's tunnel to go down.
Please see Cisco's article on GRE keepalives:
Interestingly enough, the ACL line you'll need to add on ROUTER1 for the Tunnel1 interface is
permit gre host 172.22.22.2 host 172.20.20.1
which is unintuitive because on the inbound ACL for the tunnel, you're permitting a GRE packet sourced from ROUTER1 itself to ROUTER2 despite this packet being generated from ROUTER2 originally.
This is because the keepalive packet from ROUTER2 contains the return GRE keepalive that ROUTER1 needs to send back, and here lies the key to the ACL line. Tunnel1's ACL is evaluated post-decapsulation, which is actually the pre-packaged GRE keepalive packet that ROUTER1 is meant to forward to ROUTER2 (in red), not the original GRE header (in black).
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: