Help - OpenVPN Tunnel has bandwitdh limit per user?

  • Hello all,

    I've been searching all over the OpenVPN site and here for some mention of the problem I am experiencing, and have come up empty.  So, I hope someone here can answer this question.

    I have two offices both using pfSense 2.0.1 routers.  At my main office I have an OpenVPN server configured, and at the remote office an OpenVPN client for my site-to-site VPN.  It all works and there are no problems with the operation per se.  However, my internet connections at both offices are 10Mbps up/down connections and yet, the maximum bandwidth I get through the OpenVPN tunnel when copying files from one office to the other is approximately 2Mbps PER USER.  I had a user copy 31GB from one office to the other and as a result of the restricted bandwidth, it took several days.  If multiple users copy files across the VPN, then the bandwidth total jumps up in 2Mbs increments.  So, I know that the ISP is not limiting bandwidth.  I've tested with 1, 2, and 3 simultaneous file copy operations.  The bandwidth across the VPN goes from 2Mbps, to 4Mbps, to 6 Mbps respectively.

    On the client side, I have verified that the Max outgoing bandwidth setting is blank.  (I have also tried setting this to 1000 KBps with no change.  I can find no other OpenVPN settings that relate to bandwidth limits per user.  I am not using Captive Portal and it is not enabled.  Both routers are dual WAN, but I have verified that the OpenVPN traffic is appearing on the correct interface (OPT1 in this case).

    Traffic shaping is not turned on either.  But for all practical purposes, it seems that there is a built-in limit of 2Mbps per user across the OpenVPN tunnel.  Any user at any machine on either network and go to and when they test they get near the full 10Mbps bandwidth both up and down.  So, this limit seems specific to the OpenVPN tunnel.

    What am I missing?  Please help

    Thank you,

  • Thank you Biggsy for the tip.  I was very hopeful upon reading that thread, but it did not make any significant difference.  I modified the value of net.inet.ip.fastforwarding to "1" under System/Advanced/Tunables on both routers.

    I then retested a large file-copy from a windows workstation on one network to a workstation on the remote network, and vice-versa.  In both cases, the file copy speed was about 260 to 300 KBps on a 10.5 Mbps connection with no other traffic on the network (doing this at night).  Further testing shows:
    1.  If I open multiple file copy processes on one workstation, they are all throttled such that the sum of the bandwidth of all the simultaneous copies is about 250-300 KBps.
    2.  If I open a copy process on separate workstations, each one gets a bandwidth of approximately 250-300 KBps, so the total in the tunnel increase from 250 to 500 to 750 and so on up to the 10.5Mbps capacity.

    So, there is definitely some form of traffic shaping per session is occurring when transversing the tunnel.

    As an experiment, I implemented an IPSec site-to-site tunnel and retested using it instead of the OpenVPN tunnel.  The results were identical.  The bandwidth per session is being limited to about 1/5 of total bandwidth available.

    How can I change this?  I really, really need my site-to-site VPN to have access to most of my bandwidth for a single machine.  This appears to me to be a built-in limitation by design in pfSense.  Is that true?

    So called network "experts" keep harping on me to go buy Cisco ASA 5505 appliances to replace my pfSense routers.  Will that fix this problem?  Will I then have control over the bandwidth per session in my VPN?

    Please help.

    Thank you!

  • Through further testing, I discovered that this issue only occurred when doing SMB file copies from a Win7 machine to a Samba server (or vice versa).  The issue was caused by the settings of SO_SNDBUF and SO_RCVBUF socket options in Samba.  The recommended settings of 8192 cause a significant performance hit when transferring files over a VPN.  Changing the settings to 65536 cured the problem completely.


Log in to reply