DPD error help VPN Tunnel

[m.s.rees1]

We are getting issues with a VPN tunnel. One side can bring up the tunnel but will receive no traffic from the peer, and the peer cannot even bring up the tunnel. With some further debugging I finally came across this, and wondering if it is pointing to something:

Our debug shows: (the last line is interesting):

IKEv2-PROTO-4: (55): Received Packet [From 100.100.100.100:500/To 200.200.200.200:500/VRF i0:f0]
(55): Initiator SPI : B19FD963254B6CA3 - Responder SPI : 15854B7F5E0DD417 Message id: 27
(55): IKEv2 INFORMATIONAL Exchange RESPONSEIKEv2-PROTO-5: (55): Next payload: ENCR, version: 2.0 (55): Exchange type: INFORMATIONAL, flags: RESPONDER MSG-RESPONSE (55): Message id: 27, length: 80(55):
Payload contents:
(55):
(55): Decrypted packet:(55): Data: 80 bytes
IKEv2-PLAT-4: (55): Decrypt success status returned via ipc 1
(55): REAL Decrypted packet:(55): Data: 0 bytes
IKEv2-PROTO-7: (55): SM Trace-> SA: I_SPI=B19FD963254B6CA3 R_SPI=15854B7F5E0DD417 (I) MsgID = 0000001B CurState: INFO_I_WAIT Event: EV_RECV_INFO_ACK
IKEv2-PROTO-4: (55): Processing ACK to informational exchange
IKEv2-PROTO-7: (55): SM Trace-> SA: I_SPI=B19FD963254B6CA3 R_SPI=15854B7F5E0DD417 (I) MsgID = 0000001B CurState: INFO_I_WAIT Event: EV_CHK_INFO_TYPE
IKEv2-PROTO-7: (55): SM Trace-> SA: I_SPI=B19FD963254B6CA3 R_SPI=15854B7F5E0DD417 (I) MsgID = 0000001B CurState: EXIT Event: EV_CHK_PENDING
IKEv2-PROTO-7: (55): Processed response with message id 27, Requests can be sent from range 28 to 28
IKEv2-PROTO-7: (55): SM Trace-> SA: I_SPI=B19FD963254B6CA3 R_SPI=15854B7F5E0DD417 (I) MsgID = 0000001B CurState: EXIT Event: EV_NO_EVENT
IKEv2-PROTO-7: (55): SM Trace-> SA: I_SPI=B19FD963254B6CA3 R_SPI=15854B7F5E0DD417 (I) MsgID = 0000001B CurState: EXIT Event: EV_FREE_NEG
IKEv2-PROTO-7: (55): Deleting negotiation context for my message ID: 0x1b
IKEv2-PROTO-7: (55): Timer expired, Sending DPD

When showing the logging with this attempt we see this:

Aug 17 2023 14:46:45: %ASA-7-713906: IKE Receiver: Packet received on 200.200.200.200:500 from 100.100.100.100:500
Aug 17 2023 14:46:55: %ASA-7-750016: Local:200.200.200.200:500 Remote:mosaic:500 Username:100.100.100.100 IKEv2 Need to send a DPD message to peer

This repeats but nothing happens. As requested by the peer we have this on the tunnel config:

tunnel-group 100.100.100.100 ipsec-attributes
isakmp keepalive disable
ikev2 remote-authentication pre-shared-key *****
ikev2 local-authentication pre-shared-key *****

I'm just wondering if the 'need to send a DPD message to peer' is highlighting the problem. If anyone could shed any light or see anything in the debug that would be great.

Thanks.

[balaji.bandi]

Not sure what ASA  code running,

Try clear the tunnel -clear crypto isakmp sa and add below config and check if that fix the issue

isakmp keepalive threshold infinite

[m.s.rees1]

Attempted this already previously but still no joy. Thanks for the reply though.

[Rob Ingram]

@m.s.rees1 DPD keepalives are used to clear stale IPSec SAs, I don't see why they would not stop one side from establishing a tunnel.

Though I believe this relates to another post you created earlier, I think the peer is misconfigured, either routing or NAT. They need to provide some troubleshooting debugs and configuration.

[m.s.rees1]

Thanks @Rob Ingram appeciate your responses. Ye I am back and fore with them at the moment. Bit of a stalemate going on. Their config seems fine from what I am seeing and it seems to replicate mine. They can't establish the tunnel at all and I see nothing coming through when they try. When I bring it up and have them try again, the debug above is what we see. So it does show them attempting something. I still think it is pointing to their side but it can be hard to determine.

[Rob Ingram · Accepted solution]

@m.s.rees1 if the peer can never initiate the tunnel, it could be numerous issues. They could be configured to answer/respond only and not initiate the tunnel (or bidirectional) or you could be configured initiate only and not bidirectional....but I don't think either is the issue if you can establish the tunnel, encrypt traffic but not receive return traffic from the peer.

It could be routing on their side, if their firewall is a dedicated VPN concentrator (and not the default gateway from the LAN) it could be your IP address is not routed to the VPN concentrator so the traffic from their network is not sent to the correct firewall.

It could be a misconfigured NAT on the remote side that is unintentially translating the traffic, so not matching the crypto ACL not encrypting the traffic.

[m.s.rees1]

Thankyou @Rob Ingram. The more information I am gathering, the more it is pointing to something their side as you say. I will try and get some more time with them and see if we can figure it out. Should be quite simple!