GRE over IPSec and ACL's

[dennylester]

We are trying to setup a GRE tunnel over IPSec to use as a backup should the frame relay circuit go down.

Looking at the crude network diagram, I have an IPSec tunnel setup between the Pix515E and the Cisco 1841. Between the Cisco 2811 and the 1841 I have a GRE tunnel setup. The crypto map is configured to allow GRE traffic between the 2811 address to the 1841's public address.

From the 2811 when I ping the tunnel interface on the 1841 I can see the encaps and decaps counters incrementing when I issue "show crypto ipsec sa" on both the Pix and the 1841, but I get no replies to the pings. I also see the encaps and decaps increasing when I ping from the 1841 to the 2811, but again no replies.

I suspect an ACL my be the problem but I am not certain.

On the 1841 the tunnel source is the F0/1 interface. This interface has an ACL applied to it. Will this ACL be used to filter traffic coming into the tunnel interface?

This is driving me nuts.

Denny

[dennylester]

I forgot the map.

[Richard Burts]

Denny

At this point I am not sure quite what the problem is. It could certainly be an access list. If you post the configuration of the access list we might see a problem.

I also wonder if the problem might be assymetric traffic. Especially if the IPSec/GRE is intended as a backup for the Frame Relay, are you doing anything to simulate a failure of the Frame Relay when you test? Or is this testing done with the Frame Relay up?

One step I would suggest for testing this is to run debug ip icmp on the 1841 and try to ping from the 2811. The debug will tell you if the ping arrived, and if so what it saw as the source and destination addresses. Then run debug on the 2811 and ping from the 1841. This should give us some helpful information about what is (or is not) getting through.

HTH

Rick

[dennylester]

Hi Rick,

Yes, I was testing this while the frame relay was up. Since the tunnel interfaces fall with in their own subnet I was trying to ping from one tunnel interface to the other.

I will try the debug icmp when I return from vacation.

One question I have is, does the ACL on a physical interface get applied to traffic coming in through the tunnel interface?

Is there a way to see if the GRE tunnel came up?

I've never setup a GRE tunnel before but from the reading I have done they suggest setting up the GRE tunnel first and verify it works before applying IPSec. In my case, I do not want to expose the internal router to the Internet so I can't perform that step first.

Thank you,

Denny

[Richard Burts]

Denny

If an access list is applied to a physical interface then I believe that every packet coming through the interface gets evaluated against the access list. It is my understanding that in traditional IOS implementation a packet that comes in on a GRE/IPSec tunnel actually gets evaluated twice (once when it comes in encapsulated and encrypted and again after it has be de-encrypted and de-encapsulated). I believe that recent versions of IOS have a way to eliminate the double processing in the access list.

Telling if the GRE tunnel has come up has been quite tricky. In traditional IOS implementation the GRE tunnel would show as up/up as long as the router had a route to the tunnel destination and the outbound interface for that route was available. In recent versions of IOS Cisco has added a feature of GRE tunnel keepalives. If you configure this feature the router will send keepalives on the tunnel interface. If it fails to receive the keepalive the router will mark the tunnel interface as protocol down. So with this new feature it is much easier to know if the tunnel has actually come up.

HTH

Rick

[dennylester]

Running Debug IP ICMP helped me nail down the problem. Turns out I wasn't allowing GRE in one direction on the Pix.

Thank you for pointing me in the right direction.