[SOLVED] Solution to SonicWall VPN Client Behind pfsense [Now Up To $200]
-
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).
-
Done! Thank you to everyone for their patient help. I just paid my $200 (Confirmation No. 3HS208994B4607915), and it was well worth it.
What I did was to ensure that scrub was disabled (it was). I also chose Manual Outbound NAT rule generation (Advanced Outbound NAT (AON)), setting up rules for ports 50, 500, and 4500, which I understand from other sources are used by the SonicWall client. Of course, I still have the inbound and outbound firewall rules allowing traffic to and from the VPN server's ip address. Even at that point, the client would not connect. The final step, which allowed the connection, was to enter 1500 in the MTU field on the WAN interface. (It is a bit fuzzy, but I first set the MTU to 1300. The software firewall on the XP client then asked me to approve the outbound connection of the SonicWall Client. That had never happened before. I clicked OK to allow the connection, but still had no connection. It was not until I entered 1500 into the MTU that the connection succeeded.)
I made no changes on the XP client, although NAT Traversal is Forced On.
Thanks again.
-
I didn't get any part of the money :P
-
@ermal:
I didn't get any part of the money :P
He must have just made a project donation, and not a payment to any one person.
