IPSec tunnel. Remote can bring up the VPN tunnel, but they cannot see pings until I initiate pings from my side.

[jimmycher]

The far end can bring up the tunnel; I confirm it with the show IPSec SA command. 

They launch a ping, the tunnel comes up, but they do NOT see the echo-reply.

If I tear down the tunnel, and initiate it from my side, the tunnel comes up, AND the remote site can now see their pings successfully.

I'm pretty sure it's on my end; they have dozens of VPNs up, and only mine displays this behavior.

Any ideas?

[balaji.bandi]

This issue required more information and investigation.

1. what is the device both ends.

2. post sample configuration of both ends ( for the VPN).

3. if the interesting traffic not decrypting means, there may be config issue around(this only can config once we see the config)

[RicardoSN]

Hello jimmycher,

Please try to give us a little more context. A simple diagram of your topology would be nice too.

• Is this VPN Tunnel transport or tunnel mode?
• Those pings you're performing, are you sure you are sourcing them from the right interesting IPs and also, on both tests you mentioned, are you pinging the interesting destination IPs or pinging the IPs which you use as peer for the tunnel?
• When you replicate the failure where you cannot see the ICMP Replies, could you check with the "show crypto ipsec sa" command if packets are being encrypted and decrypted / encapsulated and decapsulated / digested and verified?

Here is a simple example of a working VPN Tunnel in Tunnel Mode i just made if you wanna compare:

ROUTER1

Loopback only to simulate a LAN interface for interesting traffic:

Loopback100 172.25.25.1 YES manual up up

Tunnel Interface for a VPN working on Tunnel Mode:

Tunnel50 192.168.50.1 YES manual up up

Phase1 Configuration:

crypto isakmp policy 10
encr aes 256
authentication pre-share
group 2
lifetime 3600
crypto isakmp key MYCRYPTOKEY address 20.20.20.1

Phase2 Configuration:

crypto ipsec transform-set MYTS esp-aes 256 esp-sha-hmac
mode tunnel

!
crypto ipsec profile MyProfile
set transform-set MYTS

Tunnel Interface Configuration:

interface Tunnel50
ip address 192.168.50.1 255.255.255.252
tunnel source 10.10.10.1
tunnel mode ipsec ipv4
tunnel destination 20.20.20.1
tunnel protection ipsec profile MyProfile

Static route to route the interesting traffic thru the tunnel:

ip route 172.45.45.0 255.255.255.0 192.168.50.2

ROUTER2

Loopback only to simulate a LAN interface for interesting traffic:

Loopback100 172.45.45.1 YES manual up up

Tunnel Interface for a VPN working on Tunnel Mode:

Tunnel50 192.168.50.2 YES manual up up

Phase1 Configuration:

crypto isakmp policy 10
encr aes 256
authentication pre-share
group 2
lifetime 3600
crypto isakmp key MYCRYPTOKEY address 10.10.10.1

Phase2 Configuration:

crypto ipsec transform-set MYTS esp-aes 256 esp-sha-hmac
mode tunnel
!
crypto ipsec profile MyProfile
set transform-set MYTS

Tunnel Interface Configuration:

interface Tunnel50
ip address 192.168.50.2 255.255.255.252
tunnel source 20.20.20.1
tunnel mode ipsec ipv4
tunnel destination 10.10.10.1
tunnel protection ipsec profile MyProfile

Static route to route the interesting traffic thru the tunnel:

ip route 172.25.25.0 255.255.255.0 192.168.50.1

I hope this is helpful.

[jimmycher]

I am using a Firepower 2120, running in ASA mode.  The remote site is using a Checkpoint.  There is some discussions about those two devices having issues.  I am using tunnel mode, running IKEv1 and IPSec, with preshared keys.

When I ping the far end, everything works perfectly.  I can see the replies, and she can see her icmp replies.

When she initiates traffic, it builds a tunnel.  So the interesting traffic configuration must be acceptable, right?

Her pings go out, but she does not receive echo-replies.   What's the best way to check that I'm getting her pings?

Thanks.

[jimmycher]

I also see this error:

May 11 20:59:29 [IKEv1]: IP = x.x.31.148, Keep-alives configured on but peer does not support keep-alives (type = None)

(not actually from my device, but I'm sure it is the same error)

Would the NO-NAT statements have anything to do with this?

I've added the sysopt-conn-permit-VPN, which didn't help.