Terminating VPN on ASA behind PAT router

Hey guys,

Having issues with terminating a VPN on an ASA 5505 when it's behind a standard home DSL router running PAT.

Looks like this:

Juniper SSG520 -> ASA 5520 -> Internet -> Netopia 2247 -> ASA 5505

Interesting traffic is: 172.26.1.0/24 (Juniper) , 172.16.2.0/24 (ASA 5505)
Juniper IP(Peer): 2.2.2.2
ASA 5505 IP(Peer): 1.1.1.1

Site to site VPN terminating on the Juniper and ASA 5505.
The VPN can be established when the Netopia is in bridge mode. So usual VPN requirements configured on the Juniper and ASA 5505 and an ACL rule on the ASA 5520 allowing isakmp, esp and non-isakmp through. Using main mode for phase 1. NAT-T not required because it's a static map being used on the 5520 for the outside IP of the Juniper and not PAT. I tested NAT-T anyway and it negotiates fine.

It all breaks down when I leave the Netopia in it's standard mode. (The usual home DSL router. PPPoE, PAT etc.)

Created the subnet 172.16.1.0/24 between the ASA and Netopia.
Added a default route on the ASA to point towards 172.16.1.254. (Inside IP of Netopia)
Added a static route on the Netopia for the network 172.16.2.0/24 (Inside network of ASA) to point towards 172.16.1.253. (Outside IP of ASA)
Port forwarded ports 500 and 4500 on the Netopia to 172.16.1.253 (Outside IP of ASA)

Here's the result of the debug on the ASA 5505 after trying to initiate VPN from Juniper side. (172.26.1.0/24)

TEST-ASA5505# Jul 21 09:26:34 [IKEv1]: IP = 2.2.2.2, IKE_DECODE RECEIVED Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 196
Jul 21 09:26:34 [IKEv1 DEBUG]: IP = 2.2.2.2, processing SA payload
Jul 21 09:26:34 [IKEv1 DEBUG]: IP = 2.2.2.2, Oakley proposal is acceptable
Jul 21 09:26:34 [IKEv1 DEBUG]: IP = 2.2.2.2, processing VID payload
Jul 21 09:26:34 [IKEv1 DEBUG]: IP = 2.2.2.2, processing VID payload
Jul 21 09:26:34 [IKEv1 DEBUG]: IP = 2.2.2.2, Received NAT-Traversal ver 02 VID
Jul 21 09:26:34 [IKEv1 DEBUG]: IP = 2.2.2.2, processing VID payload
Jul 21 09:26:34 [IKEv1 DEBUG]: IP = 2.2.2.2, processing VID payload
Jul 21 09:26:34 [IKEv1 DEBUG]: IP = 2.2.2.2, Received DPD VID
Jul 21 09:26:34 [IKEv1 DEBUG]: IP = 2.2.2.2, processing VID payload
Jul 21 09:26:34 [IKEv1 DEBUG]: IP = 2.2.2.2, processing IKE SA payload
Jul 21 09:26:34 [IKEv1 DEBUG]: IP = 2.2.2.2, IKE SA Proposal # 1, Transform # 1 acceptable Matches global IKE entry # 3
Jul 21 09:26:34 [IKEv1 DEBUG]: IP = 2.2.2.2, constructing ISAKMP SA payload
Jul 21 09:26:34 [IKEv1 DEBUG]: IP = 2.2.2.2, constructing NAT-Traversal VID ver 02 payload
Jul 21 09:26:34 [IKEv1 DEBUG]: IP = 2.2.2.2, constructing Fragmentation VID + extended capabilities payload
Jul 21 09:26:34 [IKEv1]: IP = 2.2.2.2, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 124
Jul 21 09:26:38 [IKEv1]: IP = 2.2.2.2, Duplicate Phase 1 packet detected. Retransmitting last packet.
Jul 21 09:26:38 [IKEv1]: IP = 2.2.2.2, P1 Retransmit msg dispatched to MM FSM
Jul 21 09:26:38 [IKEv1]: IP = 2.2.2.2, IKE_DECODE RESENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 124
Jul 21 09:26:42 [IKEv1]: IP = 2.2.2.2, Duplicate Phase 1 packet detected. Retransmitting last packet.
Jul 21 09:26:42 [IKEv1]: IP = 2.2.2.2, P1 Retransmit msg dispatched to MM FSM
Jul 21 09:26:42 [IKEv1]: IP = 2.2.2.2, IKE_DECODE RESENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 124
Jul 21 09:26:46 [IKEv1]: IP = 2.2.2.2, Duplicate Phase 1 packet detected. Retransmitting last packet.
Jul 21 09:26:46 [IKEv1]: IP = 2.2.2.2, P1 Retransmit msg dispatched to MM FSM
Jul 21 09:26:46 [IKEv1]: IP = 2.2.2.2, IKE_DECODE RESENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 124
Jul 21 09:26:50 [IKEv1]: IP = 2.2.2.2, Duplicate Phase 1 packet detected. Retransmitting last packet.
Jul 21 09:26:50 [IKEv1]: IP = 2.2.2.2, P1 Retransmit msg dispatched to MM FSM
Jul 21 09:26:50 [IKEv1 DEBUG]: IP = 2.2.2.2, IKE MM Responder FSM error history (struct &0xd7e41be

<state>, <event>: MM_DONE, EV_ERROR-->MM_WAIT_MSG3, EV_RESEND_MSG-->MM_WAIT_MSG3, NullEvent-->MM_SND_MSG2, EV_SND_MSG-->MM_SND_MSG2, EV_START_TMR-->MM_SND_MSG2, EV_RESEND_MSG-->MM_WAIT_MSG3, EV_RESEND_MSG-->MM_WAIT_MSG3, NullEvent
Jul 21 09:26:50 [IKEv1 DEBUG]: IP = 2.2.2.2, IKE SA MM:57474668 terminating: flags 0x01000002, refcnt 0, tuncnt 0
Jul 21 09:26:50 [IKEv1 DEBUG]: IP = 2.2.2.2, sending delete/delete with reason message
Jul 21 09:26:50 [IKEv1]: IP = 2.2.2.2, Removing peer from peer table failed, no match!
Jul 21 09:26:50 [IKEv1]: IP = 2.2.2.2, Error: Unable to remove PeerTblEntry

Any thoughts?

My thoughts right now are that traffic from the ASA 5505 is being dropped somewhere. It can receive traffic as it received the proposal. It then tries to send something back. Just after this we see the "Duplicate Phase 1 packet detected. Retransmitting last packet". I think this means that the Juniper resent something back because it did not receive the acknowledge ment of the original proposal...

I should have a look at the logs on the Juniper side when initiating the VPN from the ASA side to see if it receives anything.

Find more posts tagged with

Comments

mikearama

I am not good with VPN's on the ASA's, but here's what jumped out at me...

ConstantlyLearning wrote: »

The VPN can be established when the Netopia is in bridge mode.

NAT-T not required because it's a static map being used on the 5520 for the outside IP of the Juniper and not PAT.

Could you be mistaken. You've proved that as soon as PAT is in place, your otherwise working config breaks. Case in point, when the Netopia is in bridge mode (no PAT'ting happening), you get a connection.

Whether you have a static map pointing to the Juniper or not, the source IP is getting PAT'ted, so your ESP config has to get busted.

And you said you tested NAT-T and it negotiated fine... does that mean your config worked when you added NAT-T?

ConstantlyLearning

mikearama wrote: »

Could you be mistaken. You've proved that as soon as PAT is in place, your otherwise working config breaks. Case in point, when the Netopia is in bridge mode (no PAT'ting happening), you get a connection.

Yes. Bridge mode good, PAT bad.

mikearama wrote: »

Whether you have a static map pointing to the Juniper or not, the source IP is getting PAT'ted, so your ESP config has to get busted.

Yes again. When Netopia is not in bridge mode, PAT will be done by the Netopia so there is a requirement for NAT-T.

mikearama wrote: »

And you said you tested NAT-T and it negotiated fine... does that mean your config worked when you added NAT-T?

Think I made this part a bit confusing.

When the Netopia is in bridge mode - VPN works with or without NAT-T. (If you enable NAT-T with this setup it will negotiate to use it even though it's not required.)

When the Netopia is not in brdige mode - VPN does not work even with NAT-T enabled.

burbankmarc

I'm no expert but it looks like the ASA is sending a response, but it's not getting to the remote host.

Jul 21 09:26:46 [IKEv1]: IP = 2.2.2.2, Duplicate Phase 1 packet  detected.  Retransmitting last packet.
Jul 21 09:26:46 [IKEv1]: IP = 2.2.2.2, P1 Retransmit msg dispatched to  MM FSM
Jul 21 09:26:46 [IKEv1]: IP = 2.2.2.2, IKE_DECODE RESENDING Message  (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) +  NONE (0) total length : 124

It looks like your remote side is initializing but is not getting anything back, so they both just time out.

Is there anyway to see the remote side's debugs?

ConstantlyLearning

burbankmarc wrote: »
I'm no expert but it looks like the ASA is sending a response, but it's not getting to the remote host.
Jul 21 09:26:46 [IKEv1]: IP = 2.2.2.2, Duplicate Phase 1 packet  detected.  Retransmitting last packet.
Jul 21 09:26:46 [IKEv1]: IP = 2.2.2.2, P1 Retransmit msg dispatched to  MM FSM
Jul 21 09:26:46 [IKEv1]: IP = 2.2.2.2, IKE_DECODE RESENDING Message  (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) +  NONE (0) total length : 124
It looks like your remote side is initializing but is not getting anything back, so they both just time out.

Is there anyway to see the remote side's debugs?

Yep, I'll be doing that later and posting results. Netopia dropping it maybe? Can't think why.

Traffic coming back from 172.16.2.0/24 (ASA 5505) will be routed to 172.16.1.254 (Default route on ASA), it will then be patted to 1.1.1.1 (public IP of Netopia) and sent on it's way...

ConstantlyLearning

Here's the result of debugs when trying to initiate the VPN from the ASA 5505 side:

Debug on the Juniper:

1.1.1.1 being the public IP of the Netopia
10.6.12.2 being the outside IP of the Juniper which is NAT'd to 2.2.2.2 on the ASA 5520 that's in front of the Juniper.

## 2010-07-21 18:45:54 : responder create sa: 1.1.1.1->10.6.12.2
## 2010-07-21 18:45:54 : init p1sa, pidt = 0x0
## 2010-07-21 18:45:54 : change peer identity for p1 sa, pidt = 0x0
## 2010-07-21 18:45:54 : IKE<0.0.0.0 > peer_identity_create_with_uid: uid<0>
## 2010-07-21 18:45:54 : IKE<0.0.0.0 > create peer identity 0x7a65b10
## 2010-07-21 18:45:54 : IKE<0.0.0.0 > peer_identity_add_to_peer: num entry before add <1>
## 2010-07-21 18:45:54 : IKE<0.0.0.0 > peer_identity_add_to_peer: num entry after add <2>
## 2010-07-21 18:45:54 : peer identity 7a65b10 created.
## 2010-07-21 18:45:54 : IKE<0.0.0.0 > EDIPI disabled
## 2010-07-21 18:45:54 : IKE<0.0.0.0 > dh group 2

Debug on ASA 5505

EST-ASA5505# Jul 21 17:35:31 [IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0
Jul 21 17:35:31 [IKEv1]: IP = 2.2.2.2, IKE Initiator: New Phase 1, Intf inside, IKE Peer 2.2.2.2 local Proxy Address 172.16.2.0, remote Proxy Address 172.26.1.0, Crypto map (L2L)
Jul 21 17:35:31 [IKEv1 DEBUG]: IP = 2.2.2.2, constructing ISAKMP SA payload
Jul 21 17:35:31 [IKEv1 DEBUG]: IP = 2.2.2.2, constructing NAT-Traversal VID ver 02 payload
Jul 21 17:35:31 [IKEv1 DEBUG]: IP = 2.2.2.2, constructing NAT-Traversal VID ver 03 payload
Jul 21 17:35:31 [IKEv1 DEBUG]: IP = 2.2.2.2, constructing NAT-Traversal VID ver RFC payload
Jul 21 17:35:31 [IKEv1 DEBUG]: IP = 2.2.2.2, constructing Fragmentation VID + extended capabilities payload
Jul 21 17:35:31 [IKEv1]: IP = 2.2.2.2, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 204
Jul 21 17:35:31 [IKEv1]: IP = 2.2.2.2, IKE_DECODE RECEIVED Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 176
Jul 21 17:35:31 [IKEv1 DEBUG]: IP = 2.2.2.2, processing SA payload
Jul 21 17:35:31 [IKEv1 DEBUG]: IP = 2.2.2.2, Oakley proposal is acceptable
Jul 21 17:35:31 [IKEv1 DEBUG]: IP = 2.2.2.2, processing VID payload
Jul 21 17:35:31 [IKEv1 DEBUG]: IP = 2.2.2.2, processing VID payload
Jul 21 17:35:31 [IKEv1 DEBUG]: IP = 2.2.2.2, Received NAT-Traversal ver 02 VID
Jul 21 17:35:31 [IKEv1 DEBUG]: IP = 2.2.2.2, processing VID payload
Jul 21 17:35:31 [IKEv1 DEBUG]: IP = 2.2.2.2, Received DPD VID
Jul 21 17:35:31 [IKEv1 DEBUG]: IP = 2.2.2.2, processing VID payload
Jul 21 17:35:31 [IKEv1 DEBUG]: IP = 2.2.2.2, constructing ke payload
Jul 21 17:35:31 [IKEv1 DEBUG]: IP = 2.2.2.2, constructing nonce payload
Jul 21 17:35:31 [IKEv1 DEBUG]: IP = 2.2.2.2, constructing Cisco Unity VID payload
Jul 21 17:35:31 [IKEv1 DEBUG]: IP = 2.2.2.2, constructing xauth V6 VID payload
Jul 21 17:35:31 [IKEv1 DEBUG]: IP = 2.2.2.2, Send IOS VID
Jul 21 17:35:31 [IKEv1 DEBUG]: IP = 2.2.2.2, Constructing ASA spoofing IOS Vendor ID payload (version: 1.0.0, capabilities: 20000001)
Jul 21 17:35:31 [IKEv1 DEBUG]: IP = 2.2.2.2, constructing VID payload
Jul 21 17:35:31 [IKEv1 DEBUG]: IP = 2.2.2.2, Send Altiga/Cisco VPN3000/Cisco ASA GW VID
Jul 21 17:35:31 [IKEv1 DEBUG]: IP = 2.2.2.2, constructing NAT-Discovery payload
Jul 21 17:35:31 [IKEv1 DEBUG]: IP = 2.2.2.2, computing NAT Discovery hash
Jul 21 17:35:31 [IKEv1 DEBUG]: IP = 2.2.2.2, constructing NAT-Discovery payload
Jul 21 17:35:31 [IKEv1 DEBUG]: IP = 2.2.2.2, computing NAT Discovery hash
Jul 21 17:35:31 [IKEv1]: IP = 2.2.2.2, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + KE (4) + NONCE (10) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NAT-D (130) + NAT-D (130) + NONE (0) total length : 296
Jul 21 17:35:34 [IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0
Jul 21 17:35:34 [IKEv1]: IP = 2.2.2.2, Queuing KEY-ACQUIRE messages to be processed when P1 SA is complete.
Jul 21 17:35:34 [IKEv1]: IP = 2.2.2.2, Duplicate Phase 1 packet detected. Retransmitting last packet.
Jul 21 17:35:34 [IKEv1]: IP = 2.2.2.2, P1 Retransmit msg dispatched to MM FSM
Jul 21 17:35:34 [IKEv1]: IP = 2.2.2.2, IKE_DECODE RESENDING Message (msgid=0) with payloads : HDR + KE (4) + NONCE (10) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NAT-D (130) + NAT-D (130) + NONE (0) total length : 296
Jul 21 17:35:38 [IKEv1]: IP = 2.2.2.2, Duplicate Phase 1 packet detected. Retransmitting last packet.
Jul 21 17:35:38 [IKEv1]: IP = 2.2.2.2, P1 Retransmit msg dispatched to MM FSM
Jul 21 17:35:38 [IKEv1]: IP = 2.2.2.2, IKE_DECODE RESENDING Message (msgid=0) with payloads : HDR + KE (4) + NONCE (10) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NAT-D (130) + NAT-D (130) + NONE (0) total length : 296
Jul 21 17:35:40 [IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0
Jul 21 17:35:40 [IKEv1]: IP = 2.2.2.2, Queuing KEY-ACQUIRE messages to be processed when P1 SA is complete.
Jul 21 17:35:42 [IKEv1]: IP = 2.2.2.2, Duplicate Phase 1 packet detected. Retransmitting last packet.
Jul 21 17:35:42 [IKEv1]: IP = 2.2.2.2, P1 Retransmit msg dispatched to MM FSM
Jul 21 17:35:42 [IKEv1]: IP = 2.2.2.2, IKE_DECODE RESENDING Message (msgid=0) with payloads : HDR + KE (4) + NONCE (10) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NAT-D (130) + NAT-D (130) + NONE (0) total length : 296
Jul 21 17:35:46 [IKEv1]: IP = 2.2.2.2, Duplicate Phase 1 packet detected. Retransmitting last packet.
Jul 21 17:35:46 [IKEv1]: IP = 2.2.2.2, P1 Retransmit msg dispatched to MM FSM
Jul 21 17:35:46 [IKEv1 DEBUG]: IP = 2.2.2.2, IKE MM Initiator FSM error history (struct &0xd7e41be

<state>, <event>: MM_DONE, EV_ERROR-->MM_WAIT_MSG4, EV_RESEND_MSG-->MM_WAIT_MSG4, NullEvent-->MM_SND_MSG3, EV_SND_MSG-->MM_SND_MSG3, EV_START_TMR-->MM_SND_MSG3, EV_RESEND_MSG-->MM_WAIT_MSG4, EV_RESEND_MSG-->MM_WAIT_MSG4, NullEvent
Jul 21 17:35:46 [IKEv1 DEBUG]: IP = 2.2.2.2, IKE SA MM:f8948041 terminating: flags 0x01000022, refcnt 0, tuncnt 0
Jul 21 17:35:46 [IKEv1 DEBUG]: IP = 2.2.2.2, sending delete/delete with reason message
Jul 21 17:35:46 [IKEv1]: IP = 2.2.2.2, Removing peer from peer table failed, no match!
Jul 21 17:35:46 [IKEv1]: IP = 2.2.2.2, Error: Unable to remove PeerTblEntry
Jul 21 17:35:50 [IKEv1]: IP = 2.2.2.2, Invalid packet detected!
Jul 21 17:35:54 [IKEv1]: IP = 2.2.2.2, Invalid packet detected!
Jul 21 17:35:58 [IKEv1]: IP = 2.2.2.2, Invalid packet detected!
Jul 21 17:36:02 [IKEv1]: IP = 2.2.2.2, Invalid packet detected!
Jul 21 17:36:06 [IKEv1]: IP = 2.2.2.2, Invalid packet detected!
Jul 21 17:36:10 [IKEv1]: IP = 2.2.2.2, Invalid packet detected!
Jul 21 17:36:14 [IKEv1]: IP = 2.2.2.2, Invalid packet detected!

So traffic is getting through to the Juniper.

ul 21 17:45:55 [IKEv1]: IP = 217.114.172.72, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 204
Jul 21 17:45:55 [IKEv1]: IP = 217.114.172.72, IKE_DECODE RECEIVED Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 176

## 2010-07-21 18:45:54 : responder create sa: 62.77.172.161->10.6.12.2

EDIT:

Also have these info messages in the Juniper GUI:
IKE 1.1.1.1 Phase 1: Responder starts MAIN mode negotiations.
IKE 1.1.1.1 Phase 1: Retransmission limit has been reached.

burbankmarc

Have you removed your NAT rules since changing your netopia device?

ConstantlyLearning

burbankmarc wrote: »

Have you removed your NAT rules since changing your netopia device?

Yeah, removed NAT rules on ASA and added default route to point towards inside IP address of the Netopia.

shednik

Are you stuck using a site to site?

In cases like these we use EZVPN in NEM mode and things work well behind the router doing NAT/PAT.

The only real issue I see with using it this way is that you're using ISAKMP aggressive verses main mode, but if it's in a secured location part of the risk is mitigated to a point.