[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