10mb/s (fullduplex) link, limited to 3Mb/s upload.(traffic shapping not anabled)



  • Hello,

    I have a lan-to-lan 10mb/s (fullduplex) link connecting two offices of my company. (both using Pfsense as border firewall)
    About a week ago, my site-2 stopped to upload at 10mb/s and is now limited to 3 mb/s, and I didn't configure any kind of Traffic Shape at all!
    I called my link operator and ran some tests removing my site-2 Pfsense and the link (physical layer) is just fine, uploading at 10mb/s again.
    Can someone, please, help me to find out what is going on?

    Any help is appreciated.



  • Is this a physical cable between the two offices, or OpenVPN, or IPSec or?

    What versions of pfSense are you running?

    Any packages, Snort, Squid?

    How long was up and running ok before the slow down?



  • Hi divsys,

    Thanks for your reply.
        It's a physical link, but I use OpenVPN on top of it.
        The Pfsense version os 2.1 and there is no packages installed.
        According to our RDD graphics, we could use the whole link about 6 or 7 days ago. A Vlan and a Virtual IP were created at this time, but not on the same Physical card.
        The strangest thing, is that only the upload (from our site-2) is compromised, I still can send at full speed (10mb/s) from site-1 to site-2.

    Thanks again.

    Best Regards.



  • Anything else? I'm really desesperated here!  :-\


  • Netgate Administrator

    What hardware are you running? What does the CPU usage look like?
    The fact you created a VLAN  is probably related or at least that you made some config change.
    What NICs do you have? Are they still negotiating the link correctly?

    Steve



  • Status >> Interfaces shows any errors?
    And you might want to check the speed/duplex on the uplink port to the ISP. They have to match. For instance if it's set to auto on pfSense then the ISP modem has to be set to auto too.
    Anything coming up on pfSense system logs?
    Cheers



  • I just see Your post i have something similar issue like You
    https://forum.pfsense.org/index.php?topic=77193.0

    Perhaps try things what i already tried :

    1)IP Fastforwarding 1
    2)Enable TCP Inflight mode 0
    3)added mssfix 1400
    4)tried diferent ports (1194-1200, 443, 1500)
    5)tried on TCP
    6)tested both connections with speedtest.net and both seams to be ok
    7)enough CPU power (4 cores 2GB ram and not more than 5 % usage when uploading)

    Also check MTU on ovpn with mtu-test (add it to adv setting of ovpn server and after 3-4 min check ovp loogs)



  • Hello everybody.

    First, I must thanks all of you for the great help.

    stephenw10
          I'm running Pfsense virtualized on a Esxi 5.0 over a Dell PowerEdge R420.
          The CPU is fine, no more than 10% used.
          And the Nics are at 100mb/s Full-duplex, no errors or negotiation problems.

    rds_correia
          No logs or nic errors.

    mumin50
          Thanks, the post is very similar in deed, and I'm trying to run all your tests.

    I'll come back to you with the results ASAP.

    thanks again;



  • Since you're running OpenVPN, check for this in the OpenVPN log:

    event_wait : Interrupted system call (code=4)
    

    -nb



  • Got this, 3 times on the client site.

    May 10 17:42:54 HOSTNAME openvpn[16967]: event_wait : Interrupted system call (code=4)
    May 19 12:37:07 HOSTNAME openvpn[20318]: event_wait : Interrupted system call (code=4)
    May 19 12:38:43 HOSTNAME openvpn[28678]: event_wait : Interrupted system call (code=4)



  • Yeah, sounds like you have the same problem that a lot of people are having.

    OpenVPN chokes when the bandwidth of its WAN is saturated.
    You see that error, and then OpenVPN restarts itself in 10-30 seconds (or so).

    These other threads all have the same problem from the looks of it, but no bug has been filed yet.
    https://forum.pfsense.org/index.php?topic=75989.0
    https://forum.pfsense.org/index.php?topic=76735.0
    https://forum.pfsense.org/index.php?topic=77169.0

    I'm hoping this gets filed soon.  The problem has been present in 2.1.1, 2.1.2, and 2.1.3 (64bit) (versions I've tried)
    -nb


Log in to reply