TCP Windowing Question
-
Afternoon Everyone.
I currently have 2 PFsense firewalls; 1 each at two different locations. Both firewalls are connected to a 50mbps WAN link with a Site-to-site VPN connection connecting the two locations. I am only getting about 4mbps through the VPN tunnel with occasional spikes up to 8mbps. Protocol doesn't matter (It can be CIFS/SAMBA, FTP, TFTP, HTTP, Mail traffic)…its consistant across the board. I have been told by my vendors that Wan acceleration is what is needed to fix the problem, and I am open to the possibility of doing that...I just think its a little extreme and premature to look at that.
So, I was running some tests between the two sites (Mainly doing tracert's and pings, Latency between the two sites is consistent at 27ms) The Tracerts always error out on Hop 2, because its going across the encrypted tunnel and it doesn't make it to the other end before it times out. This got me thinking that this delay or lack of acknowledgement is causing the TCP window settings to not open up to their fullest potential.
So, my question is: Do the PFsense firewalls have anything to do with the TCP windows sizes setout and if so, is there a way to force open the window size to allow more packets to go through without having the ACK.
It should also be noted that I can have 13 Concurrent FTP sessions running at the same time, each one will run at 4mbps max and stay consistent.
Any advice or suggestions how I can better utilize the power of these firewalls would be appreciated.
-
Window sizes are a function of the endpoints. WAN optimization devices are largely an overpriced way to accommodate things you can do on the endpoints if you know what you're doing. There are some benefits, but most of them can be accommodated by configuring the endpoints accordingly.
So, I was running some tests between the two sites (Mainly doing tracert's and pings, Latency between the two sites is consistent at 27ms) The Tracerts always error out on Hop 2, because its going across the encrypted tunnel and it doesn't make it to the other end before it times out. This got me thinking that this delay or lack of acknowledgement is causing the TCP window settings to not open up to their fullest potential.
Again, strictly a function of the endpoints. traceroute not answering on a hop has nothing to do with TCP ACKs. Delay isn't what causes a lack of response, there is a hop where you won't see anything when going over IPsec, that's just how it works.