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

    Packet loss over openvpn bridge

    Scheduled Pinned Locked Moved OpenVPN
    4 Posts 2 Posters 3.3k 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.
    • P
      paul_dundee
      last edited by

      Hi all.

      We have a WAN bridge configured between our HQ and datacentre, using pfSense 2.0.2/OpenVPN.  The datacentre end is the server, the HQ the client.  At the HQ side, we have the virtual appliance running without issue on a standalone ESXi 4.1 server.  We want this on our cluster, however when we move the VM or load the appliance in vcenter - while the connection is successful - there is consistent packet loss.  There is no packet loss when pinging the local side of the bridge, but there is packet loss pinging the "local" ip address at the datacentre.

      I'm not sure if this should be in virtualisation forum or OpenVPN, apologies if this is the wrong place!

      thanks in advance for any help.

      1 Reply Last reply Reply Quote 0
      • Cry HavokC
        Cry Havok
        last edited by

        Do you get packet loss outside of the VPN?

        What protocol are you using for the VPN - TCP or UDP? What do the logs from the OpenVPN client and server show?

        1 Reply Last reply Reply Quote 0
        • P
          paul_dundee
          last edited by

          I think i've narrowed it down to teaming.  Creating a second virtual switch on our cluster with a single NIC resolved, adding the second NIC (even in standby mode) caused the fault to occur.  When teaming is configured (even as failover only), the local IP of the pfSense VM responds fine, it's only the remote IP (OpenVPN) where we're seeing packets dropped.  That's why I've kept this in OpenVPN and not VMWare.  If this needs to go to vmware, please let me know.

          We're using TCP for the VPN.  I can't access the machine with the issues again til later.  When that's online, I will get the logs. Thanks

          1 Reply Last reply Reply Quote 0
          • P
            paul_dundee
            last edited by

            OpenVPN on client:

            Feb 18 16:34:31 openvpn[13124]: TCPv4_CLIENT link local (bound): [AF_INET]xx.xx.xx.xx
            Feb 18 16:34:31 openvpn[13124]: TCPv4_CLIENT link remote: [AF_INET]xx.xx.xx.xx:1197
            Feb 18 16:34:31 openvpn[13124]: Peer Connection Initiated with [AF_INET]xx.xx.xx.xx:1197
            Feb 18 16:34:32 openvpn[13124]: Initialization Sequence Completed

            Ping results:
            Packets: Sent = 101, Received = 69, Lost = 32 (31% loss),
            Approximate round trip times in milli-seconds:
            Minimum = 22ms, Maximum = 126ms, Average = 37ms

            OpenVPN on server:
            Feb 18 16:34:28 openvpn[11737]: Inactivity timeout (–ping-restart), restarting
            Feb 18 16:34:28 openvpn[11737]: SIGUSR1[soft,ping-restart] received, process restarting
            Feb 18 16:34:29 openvpn[11737]: NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
            Feb 18 16:34:29 openvpn[11737]: Re-using pre-shared static key
            Feb 18 16:34:29 openvpn[11737]: Preserving previous TUN/TAP instance: ovpns1
            Feb 18 16:34:29 openvpn[11737]: Listening for incoming TCP connection on [AF_INET]xx.xx.xx.xx:1197
            Feb 18 16:34:31 openvpn[11737]: TCP connection established with [AF_INET]xx.xx.xx.xx:1765
            Feb 18 16:34:31 openvpn[11737]: TCPv4_SERVER link local (bound): [AF_INET]xx.xx.xx.xx:1197
            Feb 18 16:34:31 openvpn[11737]: TCPv4_SERVER link remote: [AF_INET]xx.xx.xx.xx:1765
            Feb 18 16:34:31 openvpn[11737]: Peer Connection Initiated with [AF_INET]xx.xx.xx.xx:1765
            Feb 18 16:34:32 openvpn[11737]: Initialization Sequence Completed

            As you can see, these logs show the initial connection but there is nothing after that.

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