Ste-2-Site VPN is up but no traffic passing

[ittechk4u1]

Hello Experts,

PlantA#sh cry isa sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
80.152.21.187 192.168.178.99 QM_IDLE 1005 ACTIVE

VPN is up but there is no traffic passing via it!! what could be the reason.

Thanks

[Giuseppe Larosa]

Hello ittechk4u1,

I am glad to know your LAN to LAN IPSec VPN is working.

However, a crypto map is not a routing object.

You can add a static route for the Spoke LAN subnet out of gi0/0/2

then you can use a prefix-list and a route-map and redistribute it on EIGRP.

Or you can generate an EIGRP default route.

ip route 10.99.0.0 255.255.0.0 gi0/0/2

ip prefix-list RemoteLAN 10.99.0.0/16

route-map STATIC-into-EIGRP permit 10

match ip address prefix RemoteLAN

router eigrp 100

redistribute static route-map STATIC-into-EIGRP

! define default metric to have a seed metric BW delay reliability load mtu

default-metric 10000 100 255 1 1500

This allows to propagate as EIGRP D EX external route the spoke remote LAN in your central site.

Hope to help

Giuseppe

[ittechk4u1]

Thanks again.

Spoke subnet (10.99.0.0/16), HUB Subnet: 10.18.0.0/16

1. I already have few route-map configured on Spoke router, please check:

2. I also have static route out from gig0/0/2 interface

[ittechk4u1]

Hello Experts,

I’ve completed our configuration   To initiate the VPN Tunnel, I need to force one packet to traverse the VPN and this can be achieved by pinging from one router to another. 

Now my question:

1. Is there any method available to bring the VPN tunnel as it should automatically comes up whenever needed.

2. My VPN is up but still there is no traffic flowing. what could be the reason.

Thanks in advance

[ittechk4u1]

Anyone can help on this issue ? 

[Giuseppe Larosa]

Hello ittechk4u1,

first of all you should understand that all of us have a job and we participate in the Cisco forums as volonteers we are not a paid support service.

It is useless to keep opening new threads on the same issue: I have counted 4 different threds it creates only confusion.

I have examined the whole configuration files that you have attached on the first thread that is the one with 20 or more replies.

I think you have the following basic problem:

you would like to setup a VPN over an interface gi0/0/2 that belongs to vrf ISP3 but you would like to carry traffic that belongs to global routing table because I see that all internal interfaces like SVI interfaces Vlan3, Vlan4, Vlan6.

all of them belong to the Global routing table :

Example:

interface Vlan4
description *** Management Transfer VLAN ***
ip address 10.99.4.252 255.255.255.0
standby 4 ip 10.99.4.254
standby 4 priority 110
standby 4 preempt
standby 4 authentication G@t4it

As we can see there is no vrf forwarding ISP3 statement here.

I think this is the root cause why you are not able to put traffic over the LAN to LAN IPsec VPN.

see VRF aware restrictions on the following document

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_ikevpn/configuration/xe-16-11/sec-ike-for-ipsec-vpns-xe-16-11-book/sec-vrf-aware-ipsec.html?dtid=osscdc000283

In particular we need to focus on the following point :

• When the VRF-Aware IPsec feature is used with a crypto map, this crypto map cannot use the global VRF as the IVRF and a non-global VRF as the FVRF. However, configurations based on virtual tunnel interfaces do not have that limitation. When VTIs or Dynamic VTIs (DVTIs) are used, the global VRF can be used as the IVRF together with a non-global VRF used as the FVRF.

• You must include the VRF in the local-address command when using the local address with VRF in the ISAKMP profile and keyring.

We need to look at the definitions of FVRF and IVRF:

Front Door VRF (FVRF) and Inside VRF (IVRF) are central to understanding the feature.

Each IPsec tunnel is associated with two VRF domains. The outer encapsulated packet belongs to one VRF domain, which we shall call the FVRF, while the inner, protected IP packet belongs to another domain called the IVRF. Another way of stating the same thing is that the local endpoint of the IPsec tunnel belongs to the FVRF while the source and destination addresses of the inside packet belong to the IVRF.

so in your case FVRF = vrf ISP3 and IVRF = global Routing table aka vrf default

So you are in the limitation stated above:

• When the VRF-Aware IPsec feature is used with a crypto map, this crypto map cannot use the global VRF as the IVRF and a non-global VRF as the FVRF. However, configurations based on virtual tunnel interfaces do not have that limitation. When VTIs or Dynamic VTIs (DVTIs) are used, the global VRF can be used as the IVRF together with a non-global VRF used as the FVRF.

You need to review the network design in order to be able to make the site to site VPN to work:

either you put gi0/0/2 in global routing table and remove any vrf reference in crypto related configuration.

Or you put all internal client facing interfaces in a VRF (that can be different from vrf ISP3).

The same limitation applies to the HUB router too.

Hope to help

Giuseppe