GRE tunnel will go down when attaching an ACL to it

Answered Question
Aug 30th, 2010
User Badges:

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

Correct Answer by Pavol Golis about 6 years 10 months ago

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Correct Answer
Pavol Golis Mon, 08/30/2010 - 14:06
User Badges:
  • Cisco Employee,

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.

shaijosef Tue, 08/31/2010 - 00:45
User Badges:

Hi Pavol,


I added this ACL "permit ip host any" and the tunnel is up and running now and I do see hits this this ACL statement.



Thank you for you helpful reply.

Pavol Golis Mon, 08/30/2010 - 14:06
User Badges:
  • Cisco Employee,

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.

Richard Burts Mon, 08/30/2010 - 22:34
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

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

lltran1988 Tue, 06/21/2016 - 09:21
User Badges:

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:

http://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/118370-technote-gre-00.html


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).

Actions

This Discussion