[SOLVED] Solution to SonicWall VPN Client Behind pfsense [Now Up To $200]
-
what are the versions of sonicwall client and sonicwall firewall?
-
Does this help? It is from the log file:
Application Name: SonicWALL Global VPN Client
Application Version: 4.0.0.830
IPsec Driver Name: RCFOX IPSec Driver
IPsec Driver Version: 10.0.7.31
Virtual Adapter Driver Name: SonicWALL VPN Adapter
Virtual Adapter Driver Version: 9.0.3.2
DNE Adapter Driver Name: Deterministic Network Enhancer
DNE Adapter Driver Version: 3.21.2.16899
Reported Generated At: 21:54:13 Thu Jul 09 2009 GMTSystem Summary
OS Name: Microsoft Windows XP
System Name: 5.1.2600 Service Pack 2 Build 2600
OS Manufacturer: Microsoft Corporation
System Name: PC-ONT-006
System Manufacturer: PC-ONT-006
System Model: PC-ONT-006
System Type: X86-based PC
Processor: x86 Family 6 Model 23 Stepping 6 GenuineIntel ~2393 Mhz
BIOS Version: 06/16/08
Windows Directory: C:\WINDOWS
Locale: United States
Time Zone: Pacific Daylight Time
Total Physical Memory: 2014 MB
Available Physical Memory: 1363 MB
Total Virtual Memory: 2047 MB
Available Virtual Memory: 1972 MB
Page File Space: 1861 MB -
Hello,
I don't have any trouble using VPN client on WIFI, behind a Pfsense box with captive portal up ; I got trouble as soon as i enable the traffic shapper, all is running VERY slow, or even not connecting.
Pfsense 1.2.2
WinVista sp1 / Xp SP3
Vpn client 4.0.0.xxx -
Meulator–
Naturally, it is great to hear that you are not having my problem because it means that a solution is possible. However, that fact alone does not help me with my configuration issues. Would you mind explaining how you are set up?
Or, perhaps someone can earn the bounty by addressing the issues raised in my original post.
Thanks.
-
Are you using manual outbound NAT?
If so, have you tried turning on static port on the outbound NAT rule?
-
At one time, I selected "Manual Outbound NAT . . . ." and then set up a mapping on the WAN interface, for source port 500 with static port enabled. However, it did not work and no other host could get out either. On reflection, I must have been tired because it would not make sense.
What is the best way to configure Advance Outbound NAT with Static Port enabled? It would seem that there should be a mapping to allow normal outbound traffic by the other hosts. I am not sure how that would be established. Does there also need to be another mapping to allow the VPN client? Is Static Mapping enabled in both cases? I will try different configurations of this later tonight, when I am behind the pfsense firewall. In the interim, if you have any tips that will speed it up, I would appreciate it.
-
With automatic outbound NAT, it should be doing static port for IPsec automatically.
Otherwise you just make a new outbound NAT rule that looks like the default, and set it for destination port 500 and check the box for static port and that should do it.
-
If I am using Automatic outbound NAT rule generation (IPsec passthrough) already, which if I understand you correctly should be doing static port for IPsec automatically, what can I gain by switching to manual outbound NAT rule generation? As I said, I tried that once, customizing the default outbound NAT rule to allow all traffic from any host originating on port 500 to go to any destination, but it did not allow the VPN client and also stopped normal traffic on all hosts.
I will try it again if you think it should work. Again, do I need two manual rules: One for default traffic and one for destination port 500?
-
Yes, you'd need two manual rules, one for all traffic, and one up above that for port udp/500, or whatever other ports that the sonicwall client might use.
You won't gain much against automatic outbound NAT if it's just for port 500/5060, which are static port already with that setup.
You might try using tcpdump to watch the traffic flow and see if you spot any oddities that way, especially if it's using an alternate port or some other technique. I don't remember much of anything about the sonicwall client, I don't know if it uses the usual ports or what.
I've seen VPN clients use port 10000, 4500, 500, etc. So looking at their traffic is the only way to find out what it is trying to do.
If it's IPsec, tcpdump can always show you how far it's making it in the negotiation.
-
Indeed we have a problem here. Sonicwall client sends ISAKMP packets (UDP port 500) but in weird way.
Every packet is fragmented into two - 1314 and 162 bytes on wire. These packets do not go through pfSense. -
Disable scrub?
-
Indeed we have a problem here. Sonicwall client sends ISAKMP packets (UDP port 500) but in weird way.
Every packet is fragmented into two - 1314 and 162 bytes on wire. These packets do not go through pfSense.Try lowering your LAN MTU or the MTU on the client system.
-
Probably it would help but all flags in IP packets seem to be correct (do not fragment flag is not set).
I can't do it on production firewall. What is interesting on pfSense-1.0.1 SonicWall works (just tested)!! Completely confused…
Edited: I was talking about scrub. -
Have you also tried to enable NAT-T on the Sonicwall and in the client?
-
Yes I did.
The issue is 'packet from LAN does not go out of WAN'. I can't believe -\\ -
I was looking back over the thread, and I didn't see where you said what version of pfSense you were running now.
A lot has changed since the 1.0 days, unfortunately, and a lot has even changed between pfSense 1.2.2 and 1.2.3-RC2.
-
I tried this antient 1.0.1 only because it still alive in my server room and I clearly remember that at those days SonicWall worked through this box. And indeed it works.
-
I have tried both the automatic and forced NAT-T setting on the client. While I do not have access to the VPN server, I believe that NAT-T is set on that side as well, because my colleague in Germany (where the server is located) is the one who originally advised me to adjust the NAT-T setting. As to the version of pfsense, I am running 1.2.3-RC1.
-
I disabled 'scrub' on 1.2-RELEASE and… fragmented packet started to go from LAN to WAN but not natted!
19:59:42.253327 IP 192.168.7.189.500 > x.x.x.144.500: isakmp: phase 1 I agg
19:59:42.253745 IP 192.168.7.189 > x.x.x.144: udp
Normal icmp is natted normally
20:00:52.032185 IP x.x.x.144 > x.x.x.251: ICMP echo reply, id 26258, seq 30208, length 40
20:00:52.988798 IP x.x.x.251 > x.x.x.144: ICMP echo request, id 26258, seq 30464, length 40 -
I managed to fix my SonicWall client by doing the following.
On my XP PC (where SonicWall client is installed) I went to Registry [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
Interfaces[Adapter ID]] found the virtual adapter installed by SW installation, changed MTU from 1300 to 1500. Then you have to run SW install again, it "repairs" its own installation and only after this "repaie" segmentation disappears as disappears the problem. On pfSense you have to allow only UDP:500, leave 'scrub' off.Resume: although the problem at pfSense exists you can avoid it by adjusting MTU on client (as jimp fairly mentioned).
