Large data transfers stalling over VPN
-
MSS clamping is what you want, but ICMP can't test MSS clamping – MSS clamping only affects TCP traffic.
Set it to ~1300 and see if it works better. If it does you can start to increase it a bit until it breaks, then dial it back down.
-
Thanks for your suggestion, but dialing it down as low as 1280 doesn't help.
I set MSS to 1280 on the IPsec advanced settings, and tried restarting the service.
I also tried setting MSS on the LAN and WAN interfaces, with no luck.
I also tried changing the "Force maximum segment size for TCP connections" option on the Cisco ASA 5505. This defaults to 1380. I tried turning it off as well as dialing it down, but no luck.
What else could it be, and why would pfSense introduce the problem, when it's not evident if I connect directly to the network socket in the wall (which also goes on to some sort of NAT device)?
-
So,
I have just managed to try another experiment:
I booted from a clean embedded USB image of pfSense, set the WAN and LAN interfaces, and connected my Mac's IPsec client to the remote VPN endpoint.
As I understand it, pfSense is only doing NAT in this scenario.
I still get the same problem. I went on to try setting a low MSS on both interfaces, with no luck.
I then went on to try setting a 1:1 NAT from the WAN IP to the client IP. Still same problem.
-
Is there somewhere I can download an older version? Which version would be recommended, eg, when were there last any kind of significant changes which might affect this.
-
There were no changes that would have affected this as far back as I remember. We have a lot of people using the current version in both of those scenarios with success, so perhaps the problem lies elsewhere.
If you want to try older versions, you can find them here: https://atxfiles.pfsense.org/mirror/downloads/old/
-
Okay, thanks.
I have just tried with another machine and another extra network card: Previously I was using AMD64 pfSense on an older Core 2 Duo Dell machine with an onboard intel NIC + a double intel PCIe NIC (interfaces showing up as em0, em1, em2); and just now I tried a Dell Core i7 with onboard intel NIC + a realtek NIC and i386 pfsense.
Exact same problem. So I guess it's not the hardware.
I have managed to at least affect the symptoms of the problem: If I lower the Max Segment Size on the Cisco box I can lower the amount of data that is transferred before the stall. The Cisco box has it's MSS set to 1380 and this will transfer about 5.14MB before the stall. If I lower the MSS to 1000 then it stalls after about 3.7MB.
I can see in the packet capture that playing with the MSS on both the Cisco end and the pfSense end affects the size of the packets traversing it.
I do have an older version of ASA on the Cisco box: version 8.4.1. Perhaps this bug is relevant https://bst.cloudapps.cisco.com/bugsearch/bug/CSCtj50580
I can upgrade the Cisco box if needed, but I am reluctant to go over the the data centre and have site downtime on the off chance this is the problem, considering that I never have a problem when pfSense isn't in the mix.
-
I just tried running ipfire instead of pfSense and I get the same problem.
-
Now I just tried at home, over a cheap ADSL wireless router, and it's 100% fine.
-
I have just installed pfSense onto a virtualbox instance on my machine and am using it to NAT traffic to the internet. I can connect my VPN client to the remote end everything is fine, I don't get any stalling.
The traffic is going through pfSense at about 30Mbps, I can see it on the graphs.
Tomorrow I will try to connect my laptop to the office internet, and see if I can still route VPN traffic through the virtual box pfSense without the stalling.
-
I think you can forget about me, it looks like it's a problem with our network and not pfSense.
Sorry for wasting your time, I feel embarrassed for not working this out before manically posting here.
