This did not seem to work. Looking at the doc's it appears this is used for auth source address. The tunnel establishes fine it's only when I try to recive traffic that comes off a taged port.

It works fine with no encryption. It also seems to break the tunnel after getting this error message because I can not ping the other side of the tunnel after the error message.

Wish I had a fix for you, but only some more questions based upon some painful experience with GRE/CEF/IPSec

Q1. Are intending to use multiple GRE interfaces based off the one physical interface for PE/CE links with IPSec encryption?

Q2. Is the other tagged interface another GRE interface based on the same local address? (with or without crypto)

I've been burnt a few times with issues like this, and the more features you have to combine (like CEF, for MPLS) with crypto & GRE the more likely it will all unravel on you. One problem I've seen a few times is that when basing multiple GRE tunnels off one physical interface, and then placing encryption over the lot with a single crypto-map, a separate tunnel is instantiated to reference each logical interface + the physical interface for each GRE tunnel. So where you think you may end up with 10 associations for 5 GRE tunnels, you end up with 30 instead. In such cases I've also seen strange packet forwarding behaviour, where you could ping each end of the encrypted GRE tunnel but no traffic actually traverses beyond the boundaries of the tunnel.

Most of the fixes I would suggest are things that you won't want to hear, like using separate interfaces etc, but if you can throw any more light on your config and what resources (hardware etc) you have available, I'd be interested in trying to help.

OK it looks like this. I am setting up two head end routers (for redundancy) to terminate connections from customers. These customers could have overlapping addresses. My design was to use MPLS/VPN to connect these customers as CE’s to avoid overlapping address space.

2 3660’s on our end connected via FastE to a switch (dot1q trucking). There is a VLAN for communication between the 3660’s. This is a tagged port. Each 3660 goes to a different service provider via T1. Each 3660 has a GRE/IPSec tunnel to a single customer router (2600/1700). Those Tunnel interfaces are in there own VRF. Then there is a VLAN interface for each server on our backend. A customer is assigned a server and the VRF’s are merged. There are many customers per server.

The problem I am having is when I shutdown the VLAN interface on one 3660 and the tunnel interface on the other 3660 (causing traffic to traverse the tagged port for interconnection) the return traffic spits out the error above. This also seems to “break” the tunnel because no traffic passes after the error message.

Now I can really sympathise with your plight. I have 2x 3662 working in a H/A arrangement for crypto at the top of a network I'm responsible for, and, like yourself I was hoping to use .1q trunking to give me sufficient interface density for all the things I had to do. Problem was that the Cisco spaghetti code is somewhat different in how it instantiates logical interfaces from physical ones. I found that I had to use a separate physical interface for one of the interfaces where I needed to have CEF applied, turn off CEF on the underlying physical interface of the .1q trunks (to get NAT to work) and apply crypto on the .1q subinterfaces. Nett result is that we've found quite a few times now that beyond a certain point the only reliable way to get these things to work is by using separate physical interfaces. Given that turning off CEF is not one of the options you seem to have, are you in a position to separate out your router to router segment to separate physical interfaces and see if it makes any difference?