Issue with IOS 15.0M on a router acting as an Easy VPN Server

[benstrauss]

Before I open a TAC case, I tought I'd bounce this one off everyone.

I am experiencing an issue which occurs with IOS 15.0M and which does not occur with IOS 12.4(24)T1.  I have verified this by reverting to 12.4 on a production router where I experienced the issue after upgrading. I can reproduce the issue freely in a test environment. I have experienced this on both 2800 series and 871 routers.

When an ASA (ver 8.2(1)) or PIX (ver. 6.3(5)) operating as an Easy VPN client in network extension mode connects to a router running IOS 15 with a traditional crypto map-based configuration acting as an Easy VPN server, traffic can pass to and from the client site and the site to which the VPN session is connected, but cannot pass beyond the router's site to other sites on the network, even though all routing entries appear to be identical to that under 12.4.

The problem occurs regardless of whether a full or split tunnel is being used.

(In this case EIGRP was being used between the router sites, but the symptoms persist even with static entries.)

If I can duplicate this, surely someone else can as well.

[aaron.storey]

What did Cisco have to say about this issue?  I am having the same issue with one of my routers.  Can't VPN to it and then route to a remote network on the other side of it, but forwarding to the locally-connect inside network works fine.

[benstrauss]

First of all, let me note that I later dicovered that this problem seems to have something to do with CEF on the return side (i.e. heading back toward the tunnel). If you turn off CEF on the router (no ip cef), the problem goes away.  This is not a good idea from a performance standpoint.

That being said...

I opened a TAC case at the end of December and they were a bit slow to get around to really looking into it, but in the past few days they finally went for an accurate recreation and were able to duplicate the problem.  The last I heard (Feb 7) was that the problem has been passed to the development team for analysis. I will keep you posted here.

[benstrauss]

Problem solved (apparently).

TAC finally came through.  Although the previous configuration worked under IOS 12.4(24)T2, it is apparently now necessary to use the very misleadingly named "remote-peer" option on the reverse-route command.

Basically, my crypto map contained (among other things) the following lines:

crypto dynamic-map EasyVPNDynMap 65535
  reverse-route

It turns out that I need to specify the next-hop gateway address pointing toward the tunnel as a parameter as follows:

  reverse-route remote-peer

Note that the address given has absolutely nothing to do with any VPN peer address.  Do not get confused by the "remote-peer" designation.  The address to use is that of the next-hop device that traffic returning to the remote peer address would pass through.  For example, our Easy VPN traffic all comes in via an ASA before reaching the Easy VPN server router and thusly returns through there.  We specify the address of the ASA on this line.  (Often, this address will be the same as the router's default gateway.)