GRE Traffic over VRFs

Hey /r/networking friends;

Edit: I don't know why I titled it as GRE over VRFs when they're IPSec tunnels. Just, ignore that brain fart. I have both running on the router, this configuration relates to the IPSec. Durr.

I'm running into an odd one that I'm just not sure about, and I'm sure that it's going to be something simple and dumb, and I'd rather just go ahead and rather than chase my tail.

In AWS (ultimately irrelevant) I have a CSR1000v that I'm trying to terminate some IPSec tunnels on, with the interfaces and the tunnel path being in separate VRFs.

The egress interface (Gig1) forwards on vrf vpn0 with the default route pointing out (which then translates to an ENI that is publicly accessible). If I create the IPSec with an isolated vrf and set the tunnel vrf to use vpn0, the interfaces don't come up:

Router#show ip int brief Interface IP-Address OK? Method Status Protocol GigabitEthernet1 10.163.255.6 YES DHCP up up [...unrelated interfaces...] Tunnel2 169.254.44.186 YES manual up down Tunnel4 169.254.46.42 YES manual up down interface Tunnel2 ip vrf forwarding vpn-73c2de12 ip address 169.254.44.186 255.255.255.252 ip tcp adjust-mss 1387 tunnel source GigabitEthernet1 tunnel mode ipsec ipv4 tunnel destination <far end 1> tunnel vrf vpn0 tunnel protection ipsec profile ipsec-vpn-aws ip virtual-reassembly end interface Tunnel4 ip vrf forwarding vpn-73c2de12 ip address 169.254.46.42 255.255.255.252 ip tcp adjust-mss 1387 tunnel source GigabitEthernet1 tunnel mode ipsec ipv4 tunnel destination <far end 2> tunnel vrf vpn0 tunnel protection ipsec profile ipsec-vpn-aws ip virtual-reassembly end 

However, if you strip out the vrf in-use by Gig1 and dump it to the global table, and remove the tunnel vrf vpn0 command from the tunnels, it comes up.

Router>#show ip int brief Interface IP-Address OK? Method Status Protocol GigabitEthernet1 10.163.255.6 YES DHCP up up [...unrelated interfaces...] Tunnel2 169.254.44.186 YES manual up up Tunnel4 169.254.46.42 YES manual up up interface GigabitEthernet1 ip address dhcp negotiation auto end interface Tunnel2 ip vrf forwarding vpn-73c2de12 ip address 169.254.44.186 255.255.255.252 ip tcp adjust-mss 1387 tunnel source GigabitEthernet1 tunnel mode ipsec ipv4 tunnel destination <far end 1> tunnel protection ipsec profile ipsec-vpn-aws ip virtual-reassembly end interface Tunnel4 ip vrf forwarding vpn-73c2de12 ip address 169.254.46.42 255.255.255.252 ip tcp adjust-mss 1387 tunnel source GigabitEthernet1 tunnel mode ipsec ipv4 tunnel destination <far end 2> tunnel protection ipsec profile ipsec-vpn-aws ip virtual-reassembly end ip vrf vpn0 rd 65000:0 ip vrf vpn-73c2de12 rd 65000:3 route-target export 65000:0 route-target import 65000:0 

So what am I missing?

Potential add-on details:

Recommended to use the isolated vrf for the tunnel interfaces as the addresses can ultimately be re-used by AWS, so the actual endpoint termination needs to be separate from the rest of the traffic as to not cause an ip conflict.

I have Gig1 on a separate vrf as I have multiple interfaces on various subnets (Gig2 and Gig3), so that I have traffic isolation for what's public versus what's private. Gig1 handles public facing traffic, Gig2 and Gig3 handle the egress back to the private facing sides.