IPSec VRF Aware (Crypto Map)

[alexey.bogatikov]

Hello!

I have some problem with configuring vrf aware Ipsec (Crypto Map).

Any traffic (from subnet 10.6.6.248/29) do not pass trouth router, but if i run command "ping vrf inside 10.5.5.1 source gi 0/1.737" it working well.  

Configuration below:

ip vrf outside
 rd 1:1
!         
ip vrf inside
 rd 2:2
!

track 10 ip sla 10 reachability

ip sla schedule 10 life forever start-time now

!

crypto keyring outside vrf outside 
  pre-shared-key address 10.10.10.100 key XXXXXX

!

crypto isakmp policy 20
 encr aes 256
 authentication pre-share
 group 2
!

crypto isakmp invalid-spi-recovery
crypto isakmp keepalive 10 periodic

!

crypto isakmp profile AS_outside
   vrf inside
   keyring outside
   match identity address 10.10.10.100 255.255.255.255 outside
   isakmp authorization list default

!

crypto ipsec transform-set ESP-AESesp-aes 256 esp-sha-hmac 
 mode tunnel
crypto ipsec df-bit clear

!

crypto map outside 10 ipsec-isakmp 
 set peer 10.10.10.100
 set security-association idle-time 3600
 set transform-set ESP-AES 
 set pfs group2
 set isakmp-profile AS_outside
 match address inside_access

!

ip route vrf inside 10.5.5.0 255.255.255.0 GigabitEthernet0/0.806 10.10.10.100 track 10

!

ip access-list extended inside_access
 permit ip 10.6.6.248 0.0.0.7 10.5.5.0 0.0.0.255

!

icmp-echo 10.10.10.100 source-interface GigabitEthernet0/0.806
 vrf outside

interface GigabitEthernet0/0.806

ip vrf forwarding outside

ip address 10.10.10.101 255.255.255.0

crypto-map outside

interface GigabitEthernet0/1.737

ip vrf forwarding inside

ip address 10.6.6.252 255.255.255.248

[Frank DeNofa]

Alexey,

I have a few suggestions to help you troubleshoot:

1. You may want to consider removing the "track 10" from your static route to eliminate any issues that this could be causing
2. If you teardown the tunnel, can the traffic from your end client (not the ping generated locally) cause the tunnel to build? If not, you may want to use netflow or ACL counters to verify that your packets are hitting the inside interface.

You may also want to run "debug crypto isakmp" and "debug crypto ipsec" if the tunnel is not establishing. "show ip cef vrf inside exact-route 10.6.6.250 10.5.5.1" and "show ip cef vrf inside 10.5.5.1/24 internal" should give you some additional information regarding the routing of the packets.

HTH,

Frank

[Frank DeNofa]

Additionally, here's a guide which goes through some of the configuration and troubleshooting for VRF aware IPsec: https://supportforums.cisco.com/document/51931/vrf-aware-ipsec-cheat-sheet

Frank

[alexey.bogatikov]

>> Additionally, here's a guide which goes through some of the configuration and troubleshooting for VRF aware IPsec: https://supportforums.cisco.com/document/51931/vrf-aware-ipsec-cheat-sheet

I built my config on the basis of this post. 
Pre-tested on GNS3. There it works perfectly. On real hardware is not.

[ipetrashkevich]

Hello, Alexey.

Is there any additional info about resolving this issue? I have the same problem - fvrf and ivrf are different and nothing is working:)

In gns3 I resolved this problem by turning off and turning on cef on interface pointing to the inside vrf and removing reverse route option from crypto map, but i didn't tested it in real production environment yet. 

[alexey.bogatikov]

hello !

I resolved this problem.

It is no Bug.

In this 

ip route vrf inside 10.5.5.0 255.255.255.0 GigabitEthernet0/0.806 10.10.10.100 track 10

10.10.10.100 must be changed to next hop gateway for f-vrf.

After that 

show ip cef vrf inside 10.24.1.0/24 internal    

do not show INCOMPETE status.

​ISR-vpn-1#show ip cef vrf inside 10.24.1.0/24 internal                
10.5.5.0/24, epoch 0, RIB[S], refcount 5, per-destination sharing
  sources: RIB 
  feature space:
   NetFlow: Origin AS 0, Peer AS 0, Mask Bits 24
  ifnums:
   GigabitEthernet0/0.806(24): 10.10.10.100
  path 22D160E8, path list 22AC27E8, share 1/1, type attached nexthop, for IPv4
  nexthop 10.10.10.100 GigabitEthernet0/0.806, adjacency IP adj out of GigabitEthernet0/0.806, addr 10.10.10.100 (incomplete)
  output chain: IP adj out of GigabitEthernet0/0.806, addr 10.10.10.100

And IPSec working fine.

if you need help please lay out your config.

[ipetrashkevich]

hmm, on my asr 1002-x i had the same route and it showed me incomplete status, only reverse-route static helped in this situation. Now everything is working well.

so, lots of platforms, lots of howto's:)

[alexey.bogatikov]

Hello Frank!

>>  1. You may want to consider removing the "track 10" from your static route to eliminate any issues that this could be causing.

I tried it before. Nothing changes.

>> 2. If you teardown the tunnel, can the traffic from your end client (not the ping generated locally) cause the tunnel to build? If not, you may want to use netflow or ACL counters to verify that your packets are hitting the inside interface.

It is also checked. netflow present counters and ACL counters not present. Source ip is 10.6.6.254/29.

show command below:

ISR-vpn-1#show ip cef vrf inside exact-route  10.6.6.254 10.5.5.1
 10.6.6.254  -> 10.5.5.1 => IP adj out of GigabitEthernet0/0.806, addr 10.10.10.100 (incomplete)

ISR-vpn-1#show ip cef vrf inside 10.24.1.0/24 internal                
10.5.5.0/24, epoch 0, RIB[S], refcount 5, per-destination sharing
  sources: RIB 
  feature space:
   NetFlow: Origin AS 0, Peer AS 0, Mask Bits 24
  ifnums:
   GigabitEthernet0/0.806(24): 10.10.10.100
  path 22D160E8, path list 22AC27E8, share 1/1, type attached nexthop, for IPv4
  nexthop 10.10.10.100 GigabitEthernet0/0.806, adjacency IP adj out of GigabitEthernet0/0.806, addr 10.10.10.100 (incomplete)
  output chain: IP adj out of GigabitEthernet0/0.806, addr 10.10.10.100 (incomplete)

[ipetrashkevich]

Alexey, the problem is in ios-xe, e.g.: https://tools.cisco.com/bugsearch/bug/CSCue78552

I fixed this problem with removing static route from i-vrf, adding reverse-route remote-peer xxx.xxx.xxx.xxx static to crypto map and adding static route under f-vrf pointing to i-vrf network over some interface.

Hope the same will help you.

[alexey.bogatikov]

in my case it does not work. I've tried this before. 
See my comment on your previous post. My solution should work on all platforms.

[ipetrashkevich]

On what platform do you use ipsec-tunnel?