IPSec DVTI /SVTI issue

[Soma-II]

Hello,

We're in the process of setting up a HUB-and-SPOKE topology using IPsec VTIs.

The HUB router is configured with DVTI, and the SPOKE router uses SVTI.

While there is IP connectivity between the routers, Phase 1 of the IPsec negotiation is failing. The HUB router (ROUTER_HUB) is not receiving any IP packets from the SPOKE router (ROUTER_SPOKE).
We’ve reviewed multiple documents and guides, and based on that, the configuration appears to be correct.

Configuration and test outputs are attached below for reference.

I'd really appreciate any assistance you can offer.

EDIT: I've added the solution file for future reference

Thank you for everything

[MHM Cisco World]

1- Tunnel vrf must config under virtual tunnel of hub

2- check this link how you config ikev1 vrf aware 

https://ccietbd.com/2023/03/15/study-notes-vrf-aware-policy-based-ikev1-vpn/

These three points you need since tunnel source is vrf aware 

MHM

[Rob Ingram]

---

@MHM Cisco World wrote:

1- Tunnel vrf must config under virtual tunnel of hub

2- crypto ikev2 policy

match fvrf <>

3- crypto ikev2 profile xxx

Match fvrf <>

These three points you need since tunnel source is vrf aware 

MHM

---

@Soma-II is using IKEv1, so those IKEv2 commands are not applicable. The IKEv1 (isakmp) equivalent commands have already been provided.

[Soma-II]

Hello again,

I sincerely apologize for not being able to reply yesterday. Today, I modified the configuration and also upgraded the router’s software version, just in case.

First of all, thank you very much. I was able to bring Phase 1 up thanks to both of your guidance.

I'm thrilled that both Phase 1 and Phase 2 are now established. However, no traffic is passing through the tunnel..... I've configured an SLA with continuous pings, but there's still no response. I’ll update the initial file with the latest test results shortly.

I also tried applying the following command on the tunnel interface:

tunnel protection ipsec policy ipv4 Traffic-to-encrypt

ip access-list extended Traffic-to-encrypt
permit ip 55.55.55.4 0.0.0.0 55.55.55.3 0.0.0.0
but it wasn’t accepted.

Thank you both for your help!!!

[Rob Ingram]

@Soma-II it's a VTI, configure a routing protocol and advertise the networks over the tunnel. The remote peers would then learn the routes and route over the tunnel.

[Soma-II]

Hello Rob!

Of course, that's already done. You can see the ping tests, and I've set up an SLA, which is working... but for some reason, the traffic isn't going through the tunnel.

I'm not sure if a static route through Virtual-Access1 should be created dynamically on the HUB router due to the set reverse-route distance 5 command, because that part isn't working. I even removed the current static route, but no dynamic route appeared through Virtual-Access1.

I have the impression that there's a simple mistake somewhere, but I can't figure out where.

Thank you!! 

[Soma-II]

Finally, it's working! Thank you all for your help.
I'm going to add a file in short with the configuration for future reference

[MHM Cisco World]

""I even removed the current static route, but no dynamic route appeared through Virtual-Access1.""

Can you more elaborate about this point.

MHM

[Soma-II]

Hello!

Ofc! This static route must be removed

ip route vrf VRF_555 55.55.55.4 255.255.255.255 172.21.55.69 

Because, ROUTER_HUB must create a route dynamically through Virtual-tunnel1

Virtual-Access1 55.55.55.3 YES unset up up  -->
Virtual-Template555 55.55.55.3 YES unset up down

AMSTERDAM#show ip route vrf VRF_555 55.55.55.4
Load for five secs: 1%/0%; one minute: 1%; five minutes: 1%
Time source is NTP, 09:32:23.567 UTC Mon May 12 2025
Routing Table: VRF_555
Routing entry for 55.55.55.4/32
Known via "static", distance 5, metric 0 (connected)
Routing Descriptor Blocks:
* directly connected, via Virtual-Access1
Route metric is 0, traffic share count is 1