IPSec Performance
-
Hi guys,
I have two pfSense box's with Intel Atom D525 CPU's @ 1.8Ghz. I currently have an IPSec tunnel running between them with Blowfish 128-bit encryption on both Phase 1 and Phase 2. I had read that Blowfish encryption would be the best in this situation since there is no hardware acceleration (that I know of) available with this setup.My question is, how do I increase the throughput on the tunnel, or is it even possible?
Any information is helpful, thanks! :)
-
Increase throughput beyond what? In general, you should only be limited by the connection speeds at the sites. In some rare cases that may be difficult to achieve because the paths between the two locations aren't great. If they're physically far apart (1000+ miles), the latency can make it difficult to impossible to achieve line rate.
-
@cmb:
Increase throughput beyond what? In general, you should only be limited by the connection speeds at the sites. In some rare cases that may be difficult to achieve because the paths between the two locations aren't great. If they're physically far apart (1000+ miles), the latency can make it difficult to impossible to achieve line rate.
Oh sorry, I guess I forgot that bit.
Right now I am having issues getting decent performance from an RDP connection. I got a lot of slow-loading images, particularly when a lot changed on the screen. However, when using the connection direct to the server from outside the IPSec tunnel, it works fine. When I ping the host on the other side, I usually see pings of around 17ms or so.
I'm not sure exactly what my throughput is at the moment in terms of concrete numbers. Is there a way I can test that fairly easily?
-
You might try enabling MSS clamping, System > Advanced, on the Misc tab. Could be an MTU issue holding you back.
-
You might try enabling MSS clamping, System > Advanced, on the Misc tab. Could be an MTU issue holding you back.
my guess as well, that can cause RDP stalls in scenarios like those described.
-
Okay thanks guys, I'll give that a shot.
Will the default MSS setting be fine (can I leave the field blank)?
EDIT:
I changed the MSS setting, and did a little "benchmark."I moved a file from a computer on the far end to this end and timed it (since Server 2003 doesn't show transfer rate), and found that it transferred at just over 24KB/s. Does that seem about par for the course? I think the upload speed at the remote site ~2Mbps, so that strikes me as pretty slow, but I don't have a lot of experience with IPSec (yet!).
I have yet to try another RDP session; when I get the opportunity, I'll let you guys know the results!
Thanks again!
-
Last question: So are these boxes powerful enough to get line rate on an encrypted IPSec tunnel, as described above?
I'm starting to wonder if there might be a hardware issue somewhere if they are.
-
They're way more than fast enough to saturate 2 Mb.
Everything with SMBv1 (pre-Vista/2008) performs poorly over anything with higher than LAN latency so that's not a good test. Use HTTP or FTP or basically anything other than SMB to test any VPN throughput.
-
So I ran a little test using FTP through the tunnel.
I found that Mozilla reported the speed anywhere between 14KB/s to 40KB/s, and that in the FileZilla server console, the speed seemed to be bursting. It would sit at 0KB/s, then shoot up for a moment to something like 30KB/s for a bit, then back down to 0KB/s.
I'm not really sure what the deal is here, I can't think of what would be limiting the tunnel. Any ideas, by chance?
-
I hate to bump this, but I'm really hoping that there is a solution, and that I'm not just SOL.
Could it have anything to do with the Comcast "Business Class" cable modems? I wasn't able to shut off the NAT on it, which is very annoying (if you know how, please let me know), but I wouldn't think that would slow things down.
It's strange to me that all traffic outside of the tunnel is line speed no problem, but inside the tunnel isn't even close.
-
Alright! I've successfully fixed my problem! ;D
For anyone that may have problems like this, I fixed my issue by disabling "Prefer older IPSec SAs" in the System -> Advanced -> Miscellaneous section. On my two systems, it seems that box was checked by default.
-
That's very strange, because "Prefer older IPSec SAs" has no connection with IPsec throughput …
I'd start by investigating the MTU issue, as suggested by previous posters. Also, are you filtering traffic inside the IPsec tunnel (icmp traffic in particular) ?
-
That's very strange, because "Prefer older IPSec SAs" has no connection with IPsec throughput …
I'd start by investigating the MTU issue, as suggested by previous posters. Also, are you filtering traffic inside the IPsec tunnel (icmp traffic in particular) ?
I had already turned MTU clamping on, and that didn't seem to make a difference. No traffic is being filtered on the tunnel, it's a straight-shot both directions.
The interesting thing was about this "throughput" issue, wasn't so much that the system didn't seem able to go over a certain speed, but instead, it was "bursting." In other words, it would shoot up to 66kb/s then back down to 0kb/s over and over, almost like it gained and lost connection repeatedly, or like the tunnel was going up and down rapidly.
My thought was that perhaps the firewalls were fighting between older and newer SAs constantly, but like I said earlier, I'm not all that well versed in terms of IPSec.
Is it possible that my MTU setting didn't take until I modified and saved another setting on the page?
-
The problem has returned…
Man this is frustrating.
-
It appears you fellas were correct about the whole MTU thing!
I had initially left the MSS clamping text box blank, assuming that the default 1400 would do the trick. However, after some fooling around, I changed the MSS clamping setting to 1300, and the speed shot up! I then changed it to 1400, and the speeds once again slowed way down. Once again, I set them to 1300, and the speeds shot up again, so I think it's safe to assume that was the issue.
Now I'm curious as to why this was the case between these two boxes. Can anyone give me a high-level explanation, or perhaps knows of some documentation that would explain this issue?
Thanks!
-
Now I'm curious as to why this was the case between these two boxes. Can anyone give me a high-level explanation, or perhaps knows of some documentation that would explain this issue?
Sometimes there are paths between point A and point B on the Internet that have a lower MTU, and end up being a PMTUD black hole, which is especially common with IPsec. By MSS clamping, you're preventing the outer ESP from being too large for such a path by limiting the inner TCP.