I am having some problems getting this to work. I am trying to use SonicWall Global VPN Client 3.1.0.556 to connect to a SonicWall Firewall at another site.
I am doing this from a client computer which sits behind an ISA 2000 Server and a SonicWall Pro2040. I know its not the SonicWall Pro2040 because when I try this from inside the DMZ it works. I am certain its the ISA 2000 server thats not letting this through.
I followed a guide on this site and set up a Protocol rule with NAT-T and IKE. It still falls at the same place when its trying to go through ISAKMP phase 1 negotiation.
Hopefully one of you guys has set this up before and will know where to point me or even tell me where im going wrong.
as mentioned in http://www.isaserver.org/articles/IPSec_Passthrough.html, make sure the clients are configured as SecureNAT clients only for the duration of the VPN connection and that IP fragment filtering is disabled on the ISA server.
when you tried it from the DMZ, was NAT-T negotiated or ESP? Did you check out that the remote box is configured to accept NAT-T as well as ESP? How far does the negotiation goes? Any traces or NetMon captures? ...
I think the remote box accepts NAT-T as well as ESP but it doesnt seem to get past the ISA anyway. I didnt realise that until I used Ethereal to capture the network activity.
If you would be kind enough to look over it I will send you this if you email me (sjohnston(at)eg-consulting.com).
From looking at the capture it seems to use udp ports 2600 and 2601 along with ISAKMP Aggressive port 500. Then on second attempt it uses 2602 and 2603 along with 500. It discards these though.
if you carefully look at the Ethereal trace, you'll see that the client sents two IP fragments each time. When you let Ethereal reassemble them you'll see that the client announces his NAT-T capability. However, nobody is responding.
The very likely cause of that problem are my words 'IP fragments'. By default ISA 2000 filters out all IP fragments. So, change that setting (IP Packet Filters properties) and I think it will work.
OK, what do you see if you take a trace on the ISA external interface? You should see the same sequence but now with as source IP the primary IP address assigned to the ISA external interface and a source port different from UDP 500.
Also, what is the ISA logging telling you? Make sure the fields Rule#1 (protocol rule) and Rule#2 (Site&Content rule) are included.
if you look in the external trace and compare it with the internal one (filtered on ip.addr == 217.40.216.138), you can see that the IKE packets are indeed sent by the ISA server with as source IP the primary IP address assigned to the ISA external interface and a source port different from UDP 500.
However, I can make the folllowing two comments on it:
The two IP fragments we saw on the internal network are now combined by ISA server into one non-fragmented IP packet. The content of the packet (the IKE packet) is however the same, including the NAT-T capability proposal.
I see each time two identical packets with an interval of only a 0.050 msec (frame 213/214, 887/888, 1531/1532, etc...). Unless it is an Ethereal/Wireshark capture issue, that doesn't sound good! Note: if possible, disable IP routing on ISA (IP Packet Filters properties) and see if it solves that problem of 'duplicating' packets. If not, I suggest you call Microsoft PSS to resolve that problem.
Nevertheless, the IKE packets are sent by the ISA server. So, why doesn't the remote VPN gateway respond? Does the remote box accept IKE packets with a source port different from UDP port 500? That's the only reason I could think of!
I've succesfully run IPSec NAT-T through ISA 2000, 2004 and 2006. So, except for the duplicate packets I saw in your trace, I don't think that upgrading to ISA 2004 or even better 2006 would change the situation. Nevertheless, if you decide to upgrade, do it immediately to ISA 2006.
Did you already call Microsoft PSS for that duplicate packet issue? You definitely should!
quote:
Does the remote box accept IKE packets with a source port different from UDP port 500? That's the only reason I could think of!
I have resolved this issue and thought since it took me a long time and was simple enough I would share it with you guys.
I upgraded the firmware on the Sonicwall Firewall that sits on the permiter. I was running Standard OS 2 and now im running the latest, 3 point something.
Hey presto it works with protocol rules IKE and NAT-T in place.
|
My Subscription |
My Forums |
Address Book |
Member List |
Search |
FAQ |
Ticket List |
Log Out
Printable Version
All Forums >> [ISA Server 2004 Firewall] >> Access Policies >> SonicWall Global VPN Client through ISA 2000 
SonicWall Global VPN Client through ISA 2000 - 
RE: SonicWall Global VPN Client through ISA 2000 - 
RE: SonicWall Global VPN Client through ISA 2000 - 
New Messages
No New Messages
Hot Topic w/ New Messages
Hot Topic w/o New Messages
Locked w/ New Messages
Locked w/o New Messages
Post New Thread