Navigation

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

    Site-to-Site OpenVPN compression slower than Viscosity client

    OpenVPN
    2
    3
    1350
    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.
    • R
      rkelleyrtp last edited by

      Greetings all,

      I am running a test between my house and the data center using pfSense 2.1.5 and pfSense OpenVPN client vs Viscosity client (Mac version 1.5.3).

      I have two server instances of OpenVPN setup at the DC; one for my Viscosity client listening on port 1194 and the other for the pfSense site-to-site configuration listening on port 1195.  I have enabled LZO compression on both server configs (the server configs are almost 100% identical).  I have enabled LZO compression in my Viscosity config file as well as enabled LZO compression on my client OpenVPN config in pfSense.

      To test the compression speeds, I created a 100MB null test file on a remote server (dd if=/dev/zero of=file bs=1M count=100) and moved this to the web server's directory.  When I establish the OpenVPN connection with my Viscosity client, I get 12MB/sec download using the command, "curl -O http://1.2.3.4/file1".  When I establish the OpenVPN connection using pfSense as the client, I get 7MB/sec download using the same command.  During this time, the CPU on the client side hovers around 55% while the server side stays around 3%.

      I have tried various LZO options on both the OpenVPN client and server configs, but nothing has worked as well as the Viscosity client connection.  I looked over the Viscosity configuration file and made sure the same options were set in the pfSense configs.

      Any pointers?  I would expect both client connection types (Viscosity and pfSense) to give the same compression speeds…

      Thanks.

      1 Reply Last reply Reply Quote 0
      • jimp
        jimp Rebel Alliance Developer Netgate last edited by

        How many cores on the client firewall? Sitting at 55% sounds like two cores and one core is fully maxed out.

        Your PC probably has a faster CPU (and perhaps crypto acceleration), so it's not too surprising it handles more VPN traffic than the firewall alone in that case.

        1 Reply Last reply Reply Quote 0
        • R
          rkelleyrtp last edited by

          Thanks jump.

          Yep, that seems to be it.  I am running an ATOM Dual-Core 1.66GHz D510 CPU, and it can only muster about 7-8MB/sec with compression on the OpenVPN tunnel.  I can easily hit 10-11MB/sec using my Mac laptop (Quad-core i7).

          Appreciate the reply.

          1 Reply Last reply Reply Quote 0
          • First post
            Last post

          Products

          • Platform Overview
          • TNSR
          • pfSense
          • Appliances

          Services

          • Training
          • Professional Services

          Support

          • Subscription Plans
          • Contact Support
          • Product Lifecycle
          • Documentation

          News

          • Media Coverage
          • Press
          • Events

          Resources

          • Blog
          • FAQ
          • Find a Partner
          • Resource Library
          • Security Information

          Company

          • About Us
          • Careers
          • Partners
          • Contact Us
          • Legal
          Our Mission

          We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

          Subscribe to our Newsletter

          Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

          © 2021 Rubicon Communications, LLC | Privacy Policy