Root-Based IPsec: Cases Where Decryption Does Not Occur

[CHISHIUNG]

Although the IPsec connection itself has been established using route-based IPsec, when I check `show crypto ipsec sa`, I see that only encrypted packets are being counted, as shown below, and the number of decrypted packets is 0. In contrast, the VPN device on the other end is counting only the decrypted packets.It appears that the remote router is not encrypting the return packets.

I would appreciate it if you could tell me the cause.

[My Router]
#pkts encaps: 4437, #pkts encrypt: 4437, #pkts digest: 4437
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0

[Remote Router]
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 4437, #pkts decrypt: 4437, #pkts verify: 4437

Here are the tunnel interface settings. Are these settings incorrect?
・Gi0/1 is the WAN interface
・10.10.10.254 is the LAN-side HSRP VIP

interface Tunnel1
ip unnumbered GigabitEthernet0/1
tunnel source 10.10.10.254
tunnel mode ipsec ipv4
tunnel destination 1.1.1.2
tunnel protection ipsec profile VTI_PROF

[Rob Ingram · Accepted solution]

@CHISHIUNG if your router is encrypting traffic, the peer is decrypted the traffic but the peer is not encrypting any traffic, one reason could be the peer may not have a route via the VPN tunnel to your internal networks, so that router may not have a return path. Or a rogue NAT rule translating traffic can cause issues.

The tunnel configuration looks ok, I assume the peer is also using the same tunnel mode - ipsec ipv4 not gre (which is default if cisco router)?

Do you control the peer device? Can traffic be initiated from the remote side to confirm if routed via the tunnel?

[CHISHIUNG]

@Rob Ingram 

Thank you for your prompt response.
When I ran a ping from the remote router, the number of encrypted and decrypted packets matched on the other end, so there was no issue there.
However, it seems that pings sent from my router are still only encrypted.

[Rob Ingram]

@CHISHIUNG in the first test, where were you pinging from and to - the local network to the remote network (behind the router)? In the second test you when you ping from the router the source IP address would be the tunnel IP, what did you ping the other router tunnel IP or the remote network?

Provide more clarity, provide configurations etc

[CHISHIUNG]

@Rob Ingram 

The first test is from the local network to the remote network (behind the router).
The second test is from the local network on the opposite side to the remote network (behind the router).

Each router has a static route pointing to the tunnel interface for traffic destined for the local network.
I don't think there are any issues with the route-based configuration itself.

[Rob Ingram]

@CHISHIUNG so the second test is the opposite of the first test? from local network to remote network

So repeating the first test, does "My Router" NAT traffic on egress, that is received by the remote router, which then does not have a path to the NAT ip via the tunnel IP?

I assume this is a lab, can you not provide the full configuration for review?

"show ip route" from both routers would be useful too.

[CHISHIUNG]

@Rob Ingram 

The router on the other end is as follows:
#pkts encaps: 3456, #pkts encrypt: 3456, #pkts digest: 3456
#pkts decaps: 3456, #pkts decrypt: 3456, #pkts verify: 3456

GigabitEthernet0/0 is the WAN interface
1.1.1.2 is the WAN interface

interface Tunnel1
ip unnumbered GigabitEthernet0/0
tunnel source 1.1.1.2
tunnel mode ipsec ipv4
tunnel destination 10.10.10.254

[Rob Ingram]

@CHISHIUNG

Please confirm what is the tunnel IP address of both routers? And confirm you can ping them between them with a response or not?

In your initial post, what are you pinging from and to? The local network (behind the router) to the remote network (behind the remote router) or ?

Provide the routing table from both routers, so we can determine the routing.

[CHISHIUNG]

@Rob Ingram 

Pings sent from the remote router to the tunnel address on my router go through, but pings sent from my router to the tunnel address on the remote router do not go through.

[CHISHIUNG]

@Rob Ingram 

For some reason, the other party's encryption device is returning ICMP to the IP address of the terminal that sent the ping, rather than to the address at the other end of the tunnel. I understand that normally, ICMP is sent to the other end of the tunnel via an ESP packet. I wonder why.

[CHISHIUNG]

@Rob Ingram 

I'm sorry.
The routing on the remote router wasn't directed to the tunnel interface, so traffic was being forwarded to the next hop via a different route.
That really helped.

[Rob Ingram]

@CHISHIUNG Ok. Routing is typically the issue in these scenarios, hence the initial reply to confirm.