cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2421
Views
0
Helpful
2
Replies

VPN route-based pkts encaps but doesn't decaps

Hello guys,

 

I'm trying to establish a route-based VPN with a partner but I'm not able to reach the routes on the partner side. I configured my side and could see the VPN is working, I can ping the interface tunnel but not the local routes on the other side.

 

AGCANFW02P/sec/act# ping 169.255.1.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 169.255.1.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 10/16/20 ms
AGCANFW02P/sec/act# ping 10.33.129.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.33.129.1, timeout is 2 seconds:
?????
Success rate is 0 percent (0/5)

 

If I run a "show crypto ipsec sa peer IP-Partner" I see that the packets are encapsulating but not decapsulating.

peer address: XXXXXXXX
Crypto map tag: __vti-crypto-map-6-0-1, seq num: 65280, local addr: XXXXXXXXXXX

local ident (addr/mask/prot/port): (10.0.0.0/255.0.0.0/0/0)
remote ident (addr/mask/prot/port): (10.33.129.0/255.255.255.192/0/0)
current_peer: XXXXXXXXXXXXX


#pkts encaps: 50, #pkts encrypt: 50, #pkts digest: 50
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0

 

 

But works between the two tunnel interfaces.

Crypto map tag: __vti-crypto-map-6-0-1, seq num: 65280, local addr: XXXXXXXXXXx

local ident (addr/mask/prot/port): (169.255.1.6/255.255.255.255/0/0)
remote ident (addr/mask/prot/port): (169.255.1.5/255.255.255.255/0/0)
current_peer: XXXXXXXXX


#pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5
#pkts decaps: 5, #pkts decrypt: 5, #pkts verify: 5
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 5, #pkts comp failed: 0, #pkts decomp failed: 0

 

Below is my config.

crypto ipsec ikev2 ipsec-proposal STEFANINNI-SLE-PROPOSAL
protocol esp encryption aes-256
protocol esp integrity sha-384 sha-256 sha-1
!
crypto ipsec profile STEFANINNI-SLE-PROFILE
set ikev2 ipsec-proposal STEFANINNI-SLE-PROPOSAL
set pfs group5
!
Interface Tunnel1
no shutdown
nameif STEFANINNI-SLE-VTI01
ip address 169.255.1.6 255.255.255.252
tunnel destination XXXXXXXXXX
tunnel source interface outside
tunnel protection ipsec profile STEFANINNI-SLE-PROFILE
tunnel mode ipsec ipv4
!
group-policy STEFANINNI-SLE-GROUP-POLICY internal
group-policy STEFANINNI-SLE-GROUP-POLICY attributes
vpn-tunnel-protocol ikev2
!
tunnel-group XXXXXXXXXX type ipsec-l2l
tunnel-group XXXXXXXXXX general-attributes
default-group-policy STEFANINNI-SLE-GROUP-POLICY
tunnel-group XXXXXXXXXX ipsec-attributes
peer-id-validate nocheck
ikev2 local-authentication pre-shared-key XXXXXXXXXX
ikev2 remote-authentication pre-shared-key XXXXXXXXXXX
isakmp keepalive threshold 10 retry 2
!
crypto ikev2 policy 50
encryption aes-256
integrity sha256
group 5
prf sha256
lifetime seconds 86400
crypto ikev2 policy 60
encryption aes-256
integrity sha
group 5
prf sha
lifetime seconds 86400

 

route STEFANINNI-SLE-VTI01 10.33.129.0 255.255.255.192 169.255.1.5 1

 

 

 

Someone can give me a help?

1 Accepted Solution

Accepted Solutions

Josue Brenes
Cisco Employee
Cisco Employee

Hi Mateus,

It’s odd that your SA is showing the real traffic selectors 10.0.0.0 and 10.330.129.0.

On a VTI we should see the SA as 0.0.0.0(any), since it’s route based.

Can you check with the following command “show run map” if there is a crypto map pointing to the same peer IP address?

Also, based on the behavior you’re describing we are just not getting replies from the remote end.

You can confirm that with a packet capture on the firewall: capture capout interface outside match ip host x.x.x.x host x.x.x.x, where the x stands for the tunnel source and tunnel destination ip addresses.

Make sure the remote end has a proper route configured on their side pointing to 169.255.1.6.

 

Rate if it helps.

 

Regards,

Josue Brenes

TAC - VPN Engineer.

View solution in original post

2 Replies 2

Josue Brenes
Cisco Employee
Cisco Employee

Hi Mateus,

It’s odd that your SA is showing the real traffic selectors 10.0.0.0 and 10.330.129.0.

On a VTI we should see the SA as 0.0.0.0(any), since it’s route based.

Can you check with the following command “show run map” if there is a crypto map pointing to the same peer IP address?

Also, based on the behavior you’re describing we are just not getting replies from the remote end.

You can confirm that with a packet capture on the firewall: capture capout interface outside match ip host x.x.x.x host x.x.x.x, where the x stands for the tunnel source and tunnel destination ip addresses.

Make sure the remote end has a proper route configured on their side pointing to 169.255.1.6.

 

Rate if it helps.

 

Regards,

Josue Brenes

TAC - VPN Engineer.

Hi Josue, sorry for the delay, Is happening many things here in my job, hehe. The problem was with the other side, the admin needed to create a static routing pointing to my network.

Thank you for helping me.
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: