There are quite a few posts here that deal with this, but nothing I have been able to glean from the forums has helped.
I am trying to put the sonicwall VPN client on a machine behind my ISA firewall and connect to a VPN hosted by my ISP. I can put this client on a machine outside ISA and get connected just fine, but not from inside the ISA server.
When I start the VPN client it goes throught the following steps:
Makes a UDP connection attempt from a dynamic port to port 62516 on the VPN server. That is all that I ever see behind ISA. It's almost like my initial requests never get out of the firewall. Nothing is logged on ISA that I can find.
I hooked this PC up outside the firewall and traced it as well. Here are the steps it goes through.
?First attempts to see if the connection is up? My PC(220.127.116.11) broadcasts (255.255.255.255) on UDP port 62514 to 62516.
Figures out the connection isn't up.
Makes a UDP connection attempt from a dynamic port to port 62516 on the VPN server.
Server responds from port 62516 to port 62514 on my PC and the connection is established.
Hope this helps. My internal PC's are all secureNAT clients and firewall client is not used anywhere internally.
After much tugging of hair this finally is working and I do have the sonic client doing IPSEC via ISA without problem. Another big part of getting this all working is to have cooperation of the folks on the other side of the VPN. What we discovered is that the client needed to be setup in aggressive mode and that caused it to use port 500. I don't know the ins/outs of sonic vpns, but we eventually solved this by using the ethereal sniffer and just watching what the client did when it started up. (We did this both behind and in front of ISA). We discovered that it never tried to negotiate the ISAKMP session, just wanted to start working on the UDP port. Once we reconfigured everything it worked great.
In short this is what a good session looks like. We are trying to ping the server on other end of the vpn (10.0.0.2) my station is 192.168.0.1 vpn gateway is 18.104.22.168
1) ICMP PING request from 192.168.0.1 to 10.0.0.2 2) UDP from 127.0.0.1#62514 to 192.168.0.1#62516 3) UDP from 192.168.0.1#dynam1 to 22.214.171.124#62516 4) ISAKMP from 192.168.0.1#500 to 126.96.36.199#500 (Agressive) 5) ISAKMP from 188.8.131.52#500 to 192.168.0.1#500 (Agressive) 6) ISAKMP from 192.168.0.1#500 to 184.108.40.206#500 (Agressive) 7) ISAKMP from 192.168.0.1#500 to 220.127.116.11#500 (Quick Mode) 8) ISAKMP from 18.104.22.168#500 to 192.168.0.1#500 (Quick Mode) 9) ISAKMP from 192.168.0.1#500 to 22.214.171.124#500 (Quick Mode) 10) UDP from 192.168.0.1#dynam2 to 126.96.36.199#62516
After this point, 192.168.0.1 and 10.0.0.2 are talking and there is no problem.
One thing that we did find out is if packet's 5-9 are replaced by some kind of (Informational) message you have a problem in negotiating keys, session, etc. This is a configuration issue between the gateway and client rather than an ISA problem.
good to hear you have it working and thanks for the follow up!
Did you see any communication on UDP port 4500? It is my understanding that if the IPSec implementation supports NAT Traversal, then after about 2 request/response pairs, the traffic should move to UDP port 4500. For more info, check out http://www.isaserver.org/articles/IPSec_Passthrough.html .
From: the Netherlands
I created the protcol definitions and rule as described in your article, but instead of UDP port 4500 for the IPSec NAT-T rule I used UDP port 50 and it's working perfect.
At my site I'm using ISA on W2K with all the patches. The client has a Sonicwall soho3, on my laptop I'm using the softremote 8.0.0 build 10 client with the security policy phase 1 negotiation in aggressive mode
my advice is to test it first with the Firewall client disabled. Therefore, the internal host must be setted up as a SecureNAT client too. Once that is working, you can then start to play with the Firewall clients *local* LAT.