01-16-2014 06:58 AM
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:
Is this even a problem with PAT?
Best regards
Tobias
Solved! Go to Solution.
01-20-2014 08:14 AM
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
01-16-2014 07:14 AM
Hi,
Have your forwarded port UDP/4500 also?
- Jouni
01-16-2014 07:21 AM
Hi Jouni,
sorry missed that, Yes UDP 500 and 4500 are forwarded.
BR
Tobias
01-20-2014 07:18 AM
No one has any idea?
01-20-2014 08:14 AM
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
01-21-2014 09:02 AM
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
01-21-2014 10:12 AM
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
01-22-2014 06:37 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide