[SOLVED] Solution to SonicWall VPN Client Behind pfsense [Now Up To $200]
-
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.
-
I paid the bounty as a project donation, which is what I though I was supposed to do. Indeed, I was told specifically to do that on another bounty. I am very sorry for the misunderstanding and will be sure to clarify that point next time. It is a great project, and I was happy to help financially.
As a practical matter, how else would it get paid when so many people contributed to the eventual solution?
-
I paid the bounty as a project donation, which is what I though I was supposed to do. Indeed, I was told specifically to do that on another bounty. I am very sorry for the misunderstanding and will be sure to clarify that point next time. It is a great project, and I was happy to help financially.
As a practical matter, how else would it get paid when so many people contributed to the eventual solution?
That is, as I understand it, how things have been done lately as an "escrow" sort of deal and then cmb or someone else with access to that can distribute it.
As to who gets what, that is up to you, depending on however you see fit to allocate. :-)
