Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Heavy traffic on OpenVPN client kills primary connection

    Scheduled Pinned Locked Moved General pfSense Questions
    5 Posts 2 Posters 711 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • J
      jkiel
      last edited by jkiel

      Having an issue with OpenVPN client configured on pfsense 2.4.4-RELEASE-p3, with rules to direct public bound traffic from a VLAN through this VPN connection's gateway.

      Problem is, it seems like heavy activity on the VPN, like torrenting with a bunch of clients connected (maybe ~1000 connections?), will eventually stop pfsense from routing traffic on the main, non-vlan network through the default, non-vpn gateway.

      Restarting the VPN client clears the issue up immediately.

      Interestingly, the OpenVPN client seems to stay up and running, with clients using its VLAN able to use the network as normal. Also, any existing connections through the default gateway (like an SSH session) seem to work just fine. Just new connections are blocked through the default gateway are apparently blocked, until the VPN client is restarted.

      Pfsense has 8GB ram. State table, memory use, etc., all seem very low when this happen.
      Settings:
      Firewall Maximum States: 2000000
      Firewall Maximum Table Entries: 1000000
      Firewall Maximum Fragment Entries: 10000

      Any ideas on where I should look for what's happening?

      1 Reply Last reply Reply Quote 0
      • stephenw10S
        stephenw10 Netgate Administrator
        last edited by

        How much traffic are you talking about when this happens? What CPU are you running?

        Steve

        1 Reply Last reply Reply Quote 0
        • J
          jkiel
          last edited by jkiel

          Celeron 3955U. Cpu use isn't above 50%. Have a gigabit fiber WAN. Traffic isn't really anything insane, maybe 10MB up/down with somewhere around 1000 open connections on the VPN when the issue seems to trigger, though that's just a guess based on the maximums set in the torrent client.

          After the issue has triggered, killing the torrent client doesn't resolve the issue with the default gateway. Restarting the VPN client the torrent client is using is the only way to get new connections working on the default gateway.

          1 Reply Last reply Reply Quote 0
          • stephenw10S
            stephenw10 Netgate Administrator
            last edited by

            Hmm, interesting.
            OpenVPN is single threaded so with one client like that it will be using once core only. 50% total CPU load could be 100% on one core of that CPU, though it seems unlikely at 80Mbps. Try running top -aSH at the command line to see what is using the CPU and how the load breaks down across the cores.

            Do you see anything logged in the system or gateway logs when this happens?
            I could imagine maybe the main WAN gateway could get marked down due to latency and the VPN gateway gets set as default. If that is happening make sure the main WAN is set specifically as the default v4 gateway rather than 'automatic' in System > Routing > Gateways

            Steve

            1 Reply Last reply Reply Quote 0
            • J
              jkiel
              last edited by

              @stephenw10 said in Heavy traffic on OpenVPN client kills primary connection:

              I could imagine maybe the main WAN gateway could get marked down due to latency and the VPN gateway gets set as default. If that is happening make sure the main WAN is set specifically as the default v4 gateway rather than 'automatic' in System > Routing > Gateways

              Thanks Steve. I think that was exactly the issue. After making that change a few weeks ago, WAN hasn't gone down!

              1 Reply Last reply Reply Quote 0
              • First post
                Last post
              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.