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

    OpenVPN - performance issues under VMware

    Scheduled Pinned Locked Moved OpenVPN
    5 Posts 3 Posters 5.0k 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.
    • A
      alexandru.ast
      last edited by

      Hello,

      I have some weird performance issues with openvpn (BF-CBC) on pfsense.
      On a remote office, my older config was made of a Pentium III 800MHz, 512MB RAM - running windows 7 with vmware workstation, and, on top of that, pfsense 2.0 (don't throw with rocks, I know it sucks) - it was used for backup purposes, and it worked quite well, cpu tops at 8-11Mbps (OpenVPN - 60%, IRQ - 40%), vmxnet virtual adapters.

      Now, I replaced that piece of crap with a more capable - but still old - machine (HP DC7700p), Celeron D 2.8GHz, 4GB RAM, running VMware ESXi 4.1

      The problem is that, somehow, I cannot get pass the 12Mbps mark - CPU still tops at 10-12Mbps (OpenVPN - 85%, IRQ - 15%)

      At home, I have another HP DC7700p, but with Core2Duo 1.8Ghz. When transferring data over vpn to the remote site, this machine uses 8% CPU for OpenVPN (10-12Mbps) - while, in contrast, in the remote office, the CPU tops at 100%, resulting in bottleneck.

      The link between sites is 100Mbps, I am using TCP OpenVPN (the link is behind proxy)

      All pfsense VM's are configured with 1CPU, 512MB RAM
      Virtual ethernet adapters are e1000, they are working fine, no taskq or irq problems this time.

      I was hoping to get at least 20Mbps, but it seems something is wrong…
      How is that a openvpn process running on a 800Mhz P3, at 60% cpu and a 2.8GHz P4 Celeron, at 85% cpu can both push about the same Mbps of data?

      1 Reply Last reply Reply Quote 0
      • A
        alexandru.ast
        last edited by

        What is further intriguing is that I disabled encryption and tls auth, but the performance is the same.
        I am really wondering why the openvpn process uses same cpu with or without encryption.

        1 Reply Last reply Reply Quote 0
        • G
          gridrun
          last edited by

          Check this out: http://forum.pfsense.org/index.php/topic,47567.0.html

          Cheers
          Chris

          Tech stuff on my blog: http://niston.wordpress.com

          1 Reply Last reply Reply Quote 0
          • A
            alexandru.ast
            last edited by

            Hello,

            I've already done that, I see no visible improvement in my setup unfortunately…

            1 Reply Last reply Reply Quote 0
            • K
              knome
              last edited by

              I have been dealing with a similar problem.. and ip fast forwarding did not help much.

              Essentially, I have BGP setup, 6 pfSense boxes connected in a full mesh with some backend MPLS as the primary connectivity, but OpenVPN tunnels from everything to everything as a backup. 6 OpenVPN tunnels all TCP (BGP doesn't seem to want to play nice with UDP tunnels) and one of them, but only one, exhibits this problem. It is in fact a general problem with that pfSense box, as all OpenVPN tunnels out/in are slow, even though it is very new hardware. I have pored over it extensively, and I can't see anything that would alter its network behavior.

              I am on 2.0.1-release, and I am really not sure where to go from where I am now…

              I have done everything except look at frame sizes and packet traces. If anyone can give me a pointer in the right direction it would be sincerely appreciated!

              EDIT- This has included taking all encryption off the tunnel, so it is definitely not to do with encryption load. I am getting 140ms transit times and low bandwidth (4 +/- .5 MBps) when I am getting 94ms WAN to WAN

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