cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
680
Views
0
Helpful
7
Replies

Site-to-Site VPN with one side PAT

Tobi
Level 1
Level 1

Hi all,

i created a site-to-site VPN between two ASA 5505s with one side having a static public IP and one side behind a device with PAT. UDP 500 is forwarded to the ASA.

The tunnel works fine if initiated from the side behind the PAT but it can not be initiated from the other side.

Here is what i see in the syslog when initiating from the "wrong" side:

vpn.JPG

Is this even a problem with PAT?

Best regards

Tobias

1 Accepted Solution

Accepted Solutions

Hi,

To be honest these are sometime a bit hard to troubleshoot especially when you dont have access to the actual devices.

To me the logs you shared seem to indicate a problem with the Phase 1 negotiation where this local end is sending Phase 1 proposals to the remote device until it has resent them enough for the negotiation to be terminated.

So I would try to confirm at the remote site device that this traffic is indeed allowed. You could for example check the remote VPN device through management connection when the VPN is NOT up and see if there is any sign of the VPN negotiation taking place when you initiate the traffic from the other site. This would tell if it even sees the initial messages in the direction that is having problems with initiating the tunnel.

When you initiate the VPN negotiation from this site, what can you see with the output of

show crypto isakmp sa

or with the newer softwares

show crypto ikev1 sa

Try to take the  output multiple of times while you are generating traffic for the VPN

If the remote device is not answering at all you would probably see something like MM_WAIT_MSG2 which essentially means that the local VPN device is waiting for the first reply (second message in the negotiation) from the remote VPN device.

Maybe this will help narrow down the problem a bit.

- Jouni

View solution in original post

7 Replies 7

Jouni Forss
VIP Alumni
VIP Alumni

Hi,

Have your forwarded port UDP/4500 also?

- Jouni

Hi Jouni,

sorry missed that, Yes UDP 500 and 4500 are forwarded.

BR

Tobias

Tobi
Level 1
Level 1

No one has any idea?

Hi,

To be honest these are sometime a bit hard to troubleshoot especially when you dont have access to the actual devices.

To me the logs you shared seem to indicate a problem with the Phase 1 negotiation where this local end is sending Phase 1 proposals to the remote device until it has resent them enough for the negotiation to be terminated.

So I would try to confirm at the remote site device that this traffic is indeed allowed. You could for example check the remote VPN device through management connection when the VPN is NOT up and see if there is any sign of the VPN negotiation taking place when you initiate the traffic from the other site. This would tell if it even sees the initial messages in the direction that is having problems with initiating the tunnel.

When you initiate the VPN negotiation from this site, what can you see with the output of

show crypto isakmp sa

or with the newer softwares

show crypto ikev1 sa

Try to take the  output multiple of times while you are generating traffic for the VPN

If the remote device is not answering at all you would probably see something like MM_WAIT_MSG2 which essentially means that the local VPN device is waiting for the first reply (second message in the negotiation) from the remote VPN device.

Maybe this will help narrow down the problem a bit.

- Jouni

Hey Jouni,

when the VPN is not up and i send traffic from the device where initiation is not working i can see

Result of the command: "show crypto ikev1 sa"

IKEv1 SAs:

   Active SA: 1

    Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)

Total IKE SA: 1

1   IKE Peer: xxx.xxx.xxx.xxx

    Type    : user            Role    : initiator

    Rekey   : no              State   : MM_WAIT_MSG2

Result of the command: "show crypto ikev1 sa"

There are no IKEv1 SAs

So this would suggest that the remote ASA is not answering at all, while communication is working fine if the tunnel is initiated from the other side. Is there anything else which would need to be forwarded for the initation? The device used to forward is just a simple box from the isp, i also used it to forward an Anyconnect VPN which is working totally fine.

Thanks so far!

Tobias

Hi,

Well the operation of a very typical firewall would allow all traffic from the LAN side (where it works) and deny anything that is formed from the WAN side.

You do say that you have already allowed Anyconnect from the WAN side so I would assume that you have also allowed the L2L VPN required ports on the same device since they dont seem to go through?

Does the device have anykind of log to determine if the traffic stops there (which I assume happens)? Have you confirmed on the actual target VPN device if it even sees the first message of the Phase 1 negotiation? The originating host shows that it has not received a reply but does the receiver see anything?

Does the NAT device in front of the VPN device have any VPN capabilities? Something that would perhaps prevent forwarding those ports through the device?

- Jouni

Hey Jouni,

unfortunately the NAT device does not even provide any logfiles at all and seems to be setup correctly from what i can tell. As everything else is working fine and support for the device will be hard to find i will work around the problem.

Thanks very much for your help in narrowing the problem down, much appreciated!

Tobias

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: