It is either NAT-T or DVTI or zone based firewall or just me

[yuri_slobodyanyuk]

Hi everyone,

I stumbled upon the following issue with Easy VPN client and would be glad to hear your advice what it could be.

Cisco 1941 , trying to configure Easy VPN using DVTI,, also enabled on the router is zone-based firewall, site-to-site tunnels work fine. My guess it is somehow nat traversal does not kick in , and client keeps on talking to port 500 instead of switching to 4500.

debug cry isakmp is in attached file. What  intersting I guess is this part:

*Jan 18 09:21:27.075: ISAKMP:(1024):Input = IKE_MESG_FROM_AAA, PRESHARED_KEY_REPLY
*Jan 18 09:21:27.075: ISAKMP:(1024):Old State = IKE_R_AM_AAA_AWAIT  New State = IKE_R_AM2

*Jan 18 09:21:27.707: ISAKMP:(0):purging SA., sa=278D7640, delme=278D7640
*Jan 18 09:21:32.159: ISAKMP (1024): received packet from 194.190.3.44 dport 500 sport 4861 Global (R) AG_INIT_EXCH
*Jan 18 09:21:32.159: ISAKMP:(1024): phase 1 packet is a duplicate of a previous packet.
*Jan 18 09:21:32.159: ISAKMP:(1024): retransmitting due to retransmit phase 1
*Jan 18 09:21:32.659: ISAKMP:(1024): retransmitting phase 1 AG_INIT_EXCH...

When I configure DVTI on the routers where it works all goes the same way until this step , then I see:

Jan 18 07:52:15.025: ISAKMP:(1008): sending packet to 194.190.3.44 my_port 500 peer_port    4563 (R) AG_INIT_EXCH
Jan 18 07:52:15.025: ISAKMP:(1008):Input = IKE_MESG_FROM_AAA, PRESHARED_KEY_REPLY
Jan 18 07:52:15.025: ISAKMP:(1008):Old State = IKE_R_AM_AAA_AWAIT  New State = IKE_R_AM2             

Jan 18 07:52:15.033: IKE Dispatcher: Unexpected destination port 4500. Dropping packet!
Jan 18 07:52:15.033: ISAKMP (0:1008): received packet from 194.190.3.44 dport 4500 sport   4564 Global (R) AG_INIT_EXCH
Jan 18 07:52:15.033: ISAKMP:(1008): processing HASH payload. message ID = 0
Jan 18 07:52:15.033: ISAKMP:(1008): processing NOTIFY INITIAL_CONTACT protocol 1
        spi 0, message ID = 0, sa = 66664EAC

Thanks

Yuri

[Marcin Latosiewicz]

Yuri,

In case of debugs you attached looks like a typical packet drop issue (for whatever reasons).

The server is receiving same intialization packet twice and is of course not starting the negotiation for second time.

What would be useful is to check the debus on other side... and look into what can be dropping the packets.

Remember that you flow to NAT-T in Aggressive mode message 3 (you first need to exchange NAT-T capabilities).

Marcin

[yuri_slobodyanyuk]

Thanks Marcin ,

tomorrow I will eliminate NAT-T as a possible cause by trying to connect from device not behind the NAT. VPN client just says in logs "peer stopped responding" . ON ACL I used to allow IPSEC in ZBF class-maps I see hits on port 500 but nothing on 4500 .

If my test tomorrow brings the same result I will post here the show run, as this is my 1st Easy VPn with ZBF , it is possible I missed something in configs.

Yuri

[Marcin Latosiewicz]

Yuri,

As I said I doubt it's NAT-T ... it MAY be the NAT device.

If the situation is EXACTLY the same:

Debugs + captures on/in front of clinet and router would be the way I would check,

if you can run wireshark on physical interface of client you will be able to see incoming IKE messages (if any).

Marcin