Can only establish a VPN one way

mj11 · ‎12-02-2011

Hi All

I am having an issue with a VPN tunnel in that we can only establish this from the VPN 3k side to the 2800 and not from the 2800 to the VPN 3k , the setup is as follows:

VPN3k----PIX------WWW------ASA-------ASA----2800

I am awaiting the logs from the VPN 3k but here is the debugs from the 2800

debug ISAKMP

1d23h: ISAKMP:(0):Checking ISAKMP transform 1 against priority 10 policy

1d23h: ISAKMP: encryption 3DES-CBC

1d23h: ISAKMP: hash SHA

1d23h: ISAKMP: default group 2

1d23h: ISAKMP: auth pre-share

1d23h: ISAKMP: life type in seconds

1d23h: ISAKMP: life duration (basic) of 3600

1d23h: ISAKMP:(0):atts are acceptable. Next payload is 3

1d23h: ISAKMP:(0):Acceptable atts:actual life: 0

1d23h: ISAKMP:(0):Acceptable atts:life: 0

1d23h: ISAKMP:(0):Basic life_in_seconds:3600

1d23h: ISAKMP:(0):Returning Actual lifetime: 3600

1d23h: ISAKMP:(0)::Started lifetime timer: 3600.

Regards MJ

1d23h: ISAKMP:(0): processing vendor id payload

1d23h: ISAKMP:(0): vendor ID seems Unity/DPD but major 69 mismatch

1d23h: ISAKMP (0:0): vendor ID is NAT-T RFC 3947

1d23h: ISAKMP:(0): processing vendor id payload

1d23h: ISAKMP:(0): vendor ID seems Unity/DPD but major 245 mismatch

1d23h: ISAKMP (0:0): vendor ID is NAT-T v7

1d23h: ISAKMP:(0): processing vendor id payload

1d23h: ISAKMP:(0): vendor ID seems Unity/DPD but major 157 mismatch

1d23h: ISAKMP:(0): vendor ID is NAT-T v3

1d23h: ISAKMP:(0): processing vendor id payload

1d23h: ISAKMP:(0): vendor ID seems Unity/DPD but major 123 mismatch

1d23h: ISAKMP:(0): vendor ID is NAT-T v2

1d23h: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE

1d23h: ISAKMP:(0):Old State = IKE_R_MM1 New State = IKE_R_MM1

1d23h: ISAKMP:(0): constructed NAT-T vendor-rfc3947 ID

1d23h: ISAKMP:(0): sending packet to x.x.x.x my_port 500 peer_port 500 (R) MM_SA_SETUP

1d23h: ISAKMP:(0):Sending an IKE IPv4 Packet.

1d23h: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE

1d23h: ISAKMP:(0):Old State = IKE_R_MM1 New State = IKE_R_MM2

1d23h: ISAKMP:(1017): retransmitting phase 1 MM_KEY_EXCH...

1d23h: ISAKMP (0:1017): incrementing error counter on sa, attempt 3 of 5: retransmit phase 1

1d23h: ISAKMP:(1017): retransmitting phase 1 MM_KEY_EXCH

1d23h: ISAKMP:(1017): sending packet to x.x.x.x my_port 500 peer_port 500 (R) MM_KEY_EXCH

1d23h: ISAKMP:(1017):Sending an IKE IPv4 Packet.

1d23h: ISAKMP (0:0): received packet from x.x.x.x dport 500 sport 500 Global (R) MM_SA_SETUP

1d23h: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH

1d23h: ISAKMP:(0):Old State = IKE_R_MM2 New State = IKE_R_MM3

1d23h: ISAKMP:(0): processing KE payload. message ID = 0

1d23h: ISAKMP:(0): processing NONCE payload. message ID = 0

1d23h: ISAKMP:(0):found peer pre-shared key matching x.x.x.x

1d23h: ISAKMP:(1018): processing vendor id payload

1d23h: ISAKMP:(1018): vendor ID is Unity

1d23h: ISAKMP:(1018): processing vendor id payload

1d23h: ISAKMP:(1018): vendor ID is DPD

1d23h: ISAKMP:(1018): processing vendor id payload

1d23h: ISAKMP:(1018): speaking to another IOS box!

1d23h: ISAKMP:received payload type 20

1d23h: ISAKMP (0:1018): NAT found, the node inside NAT

1d23h: ISAKMP:received payload type 20

1d23h: ISAKMP:(1018):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE

1d23h: ISAKMP:(1018):Old State = IKE_R_MM3 New State = IKE_R_MM3

1d23h: ISAKMP:(1018): sending packet to x.x.x.x my_port 500 peer_port 500 (R) MM_KEY_EXCH

1d23h: ISAKMP:(1018):Sending an IKE IPv4 Packet.

1d23h: ISAKMP:(1018):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE

1d23h: ISAKMP:(1018):Old State = IKE_R_MM3 New State = IKE_R_MM4

1d23h: ISAKMP:(1017): retransmitting phase 1 MM_KEY_EXCH...

1d23h: ISAKMP (0:1017): incrementing error counter on sa, attempt 4 of 5: retransmit phase 1

1d23h: ISAKMP:(1017): retransmitting phase 1 MM_KEY_EXCH

1d23h: ISAKMP:(1017): sending packet to x.x.x.x my_port 500 peer_port 500 (R) MM_KEY_EXCH

1d23h: ISAKMP:(1017):Sending an IKE IPv4 Packet.

1d23h: ISAKMP:(1018): retransmitting phase 1 MM_KEY_EXCH...

1d23h: ISAKMP (0:1018): incrementing error counter on sa, attempt 1 of 5: retransmit phase 1

1d23h: ISAKMP:(1018): retransmitting phase 1 MM_KEY_EXCH

1d23h: ISAKMP:(1018): sending packet to x.x.x.x my_port 500 peer_port 500 (R) MM_KEY_EXCH

1d23h: ISAKMP:(1018):Sending an IKE IPv4 Packet.

Marcin Latosiewicz · ‎12-02-2011

MJ,

Long story short, there is something stateful on the way dropping UDP/4500 when initiated the other way.

IKE will switch to UDP/4500 from UDP/500 when NAT is detected. And guess what:

1d23h: ISAKMP (0:1018): NAT found, the node inside NAT

You need to make sure that al devices allow UDP/4500 bi-directionally.

Marcin

Patrick0711 · ‎12-02-2011

Admittedly, I am not as familiar with IOS router debugs compared to ASA debugs, but it does not appear that the IKE P1 negotiation switches to UDP 4500 when NAT is detected:

1d23h: ISAKMP (0:1018): NAT found, the node inside NAT

1d23h: ISAKMP:received payload type 20

1d23h: ISAKMP:(1018):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE

1d23h: ISAKMP:(1018):Old State = IKE_R_MM3 New State = IKE_R_MM3

1d23h: ISAKMP:(1018): sending packet to x.x.x.x my_port 500 peer_port 500 (R) MM_KEY_EXCH

1d23h: ISAKMP:(1018):Sending an IKE IPv4 Packet.

1d23h: ISAKMP:(1018):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE

1d23h: ISAKMP:(1018):Old State = IKE_R_MM3 New State = IKE_R_MM4

1d23h: ISAKMP:(1017): retransmitting phase 1 MM_KEY_EXCH...

1d23h: ISAKMP (0:1017): incrementing error counter on sa, attempt 4 of 5: retransmit phase 1

1d23h: ISAKMP:(1017): retransmitting phase 1 MM_KEY_EXCH

1d23h: ISAKMP:(1017): sending packet to x.x.x.x my_port 500 peer_port 500 (R) MM_KEY_EXCH

1d23h: ISAKMP:(1017):Sending an IKE IPv4 Packet.

1d23h: ISAKMP:(1018): retransmitting phase 1 MM_KEY_EXCH...

1d23h: ISAKMP (0:1018): incrementing error counter on sa, attempt 1 of 5: retransmit phase 1

1d23h: ISAKMP:(1018): retransmitting phase 1 MM_KEY_EXCH

1d23h: ISAKMP:(1018): sending packet to x.x.x.x my_port 500 peer_port 500 (R) MM_KEY_EXCH

1d23h: ISAKMP:(1018):Sending an IKE IPv4 Packet.

Perhaps the issue is not that UDP 4500 is blocked, but rather that the device is not switching to UDP 4500 and an upstream PAT device may be preventing to connection establishment. Just a thought...

Marcin Latosiewicz · ‎12-03-2011

Patrick,

I do not know RFC by heart (as you already pointed out :-)), but what I see is that 2800 is the responder, and we never recieive MM5 which shoule be the first packet with UDP/4500 (this is common on all Cisco devices, I have never seen any debugs indiacting otherwise). That being said we don't see vpn3k info at all, so hard to say for cerrtain what's going on.

I doubt it's a PAT device on the way - it would also cause UDP/500 to get dropped. (depends of course on how the PAT is done).

With limited info we have I'm sticking to my analysis.

M

mj11 · ‎12-03-2011

Hi Guys

I have been looking at this and this is a strange setup, I will try and explain as best I can.

What we have is a VPN between the 2800 and the VPN3k, if the VPN3k initiated the VPN this works fine. The problem seems to be when this is initiated from the 2800, there are othe VPN's peers (2) on the 2800 that work fine.

so here is the setup: 2800-------ASA-1-------ASA-2------PIX-----VPN3k

| _______________VPN_____________________|

When traffic gets to ASA-1 there is no NAT control but a VPN tunnel to ASA-2, then this ASA-2 has a static translation to the outside interface.

I was thinking maybe the problem is on ASA-2, we are allowing ISAKMP, ESP, UDP4500 to the static address of the 2800.

static (inside,outside) <2800 ip addr> netmask 255.255.255.255

access-list outside_in ext permit esp object-group host

access-list outside_in ext permit udp object-group host eq isakmp

access-list outside_in ext permit udp object-group host eq 4500

Regards MJ