[vpn-help] Connexion stated as established but no !

Matthew Grooms mgrooms at shrew.net
Tue Jul 6 10:54:11 CDT 2010


On 7/6/2010 3:31 AM, Keys2It Laurent Richelle wrote:
> Hi Everyone,
>
> just found the reason why ! But I'm totaly dazed about this.
>
> I found that the 'NAT Traversal' option onto the gateway caused the
> problem !!!
> After disabling each option and restarting from scratch, I finally found
> that this option was the source of my problem.
>
> This configuration has not been changed as it's the proposed one into de
> Support pages four our gateway. (Linksys RV042)
>
> As I'm not a network specialist, could someone explain me the use of NAT
> Traversal and why suddenly this option put our network config totaly down.
>

The NAT-T ( or Nat Traversal ) IKE/IPsec protocol extension is designed 
to detect the use of a NAT between two IPsec peers. If present, IKE and 
IPsec packets will be multiplexed/encapsulated using a single source and 
destination UDP port pair. In practice what this means is that when a 
NAT is detected, the IKE port in use will migrate from 500 to 4500.

This is very likely where the communication breakdown occurs between 
clients and your gateway. When the negotiation begins, the packets are 
being sent on port 500. Once the client receives the second packet from 
your gateway, it sends the third packet to port 4500 since NAT has been 
detected. From your gateway log output, it would appear that the 3rd 
packet isn't being received or processed.

Is there another firewall outside your gateway? The log output from the 
client would suggest this ...

10/07/04 19:24:14 ii : nat discovery - local address is translated
10/07/04 19:24:14 ii : nat discovery - remote address is translated
10/07/04 19:24:14 ii : switching to src nat-t udp port 4500
10/07/04 19:24:14 ii : switching to dst nat-t udp port 4500

Is the firewall outside your VPN gateway allowing UDP port 4500 packets 
inbound?

-Matthew



More information about the vpn-help mailing list