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

Proto tcp-client vs proto tcp (OpenVPN: Client Export Utility)

Scheduled Pinned Locked Moved 2.0-RC Snapshot Feedback and Problems - RETIRED
4 Posts 2 Posters 28.1k 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.
  • U
    Unlogic
    last edited by Jun 25, 2011, 4:51 PM

    I upgraded an old pfSense 1.2.3 installation a to 2.0 RC3 yesterday. I decided to dump my old configuration file and setup everything from scratch to in order to have a look at all the new features.

    I run a OpenVPN server on port 443 using TCP and after upgrading to 2.0 I noticed that the VPN connection kept going down about twice a minute with a connection reset in the client log but nothing in the server log.

    After lots of fiddling I narrowed it down to the fact that the OpenVPN: Client Export Utility sets the protocol in the client configuration to "proto tcp-client" if the OpenVPN server it set to TCP. If i change the protocol manually in the client configuration to "proto tcp" everything works fine and the connection is rock stable.

    I looked up the proto parameter for the client configuration on the OpenVPN website to find out what difference is between using "proto tcp-client" versus "proto tcp".

    The OpenVPN 2.2 manual doesn't even mention the "proto tcp" option:

    –proto p
       Use protocol p for communicating with remote host. p can be udp, tcp-client, or tcp-server.

    http://openvpn.net/index.php/manuals/427-openvpn-22.html

    The client configuration examples on the other hand only use the "proto udp" and "proto tcp" options:

    Are we connecting to a TCP or

    UDP server?  Use the same setting as

    on the server.

    ;proto tcp
    proto udp

    http://openvpn.net/index.php/open-source/documentation/howto.html#examples

    I'm not sure if I should file a bug regarding the OpenVPN: Client Export Utility for this issue or not due to the lack on information regarding the arguments for the proto option.

    It's however clear in my case that using "proto tcp-client" does not work properly while "proto tcp" does.

    Anyone else out there using OpenVPN over TCP that could test this?

    PS. It should also be mentioned that the client I'm using to test this is a Windows 7 x64 machine using OpenVPN 2.2.

    1 Reply Last reply Reply Quote 0
    • C
      cmb
      last edited by Jun 26, 2011, 1:47 AM

      tcp-client is correct and works fine. 'proto tcp' isn't even a valid argument per the 2.2 man page.
      http://openvpn.net/index.php/open-source/documentation/manuals/427-openvpn-22.html

      maybe you're running an old version of OpenVPN?

      1 Reply Last reply Reply Quote 0
      • U
        Unlogic
        last edited by Jun 26, 2011, 7:25 AM

        I'm using the following OpenVPN version:

        OpenVPN 2.2.0 Win32-MSVC++ [SSL] [LZO2] built on Apr 26 2011
        Originally developed by James Yonan
        Copyright (C) 2002-2010 OpenVPN Technologies, Inc. sales@openvpn.netconfig_all.py

        Compile time defines:  ENABLE_HTTP_PROXY=1, ENABLE_DEBUG=1, ENABLE_MANAGEMENT=1,
        ENABLE_CLIENT_SERVER=1, ENABLE_PASSWORD_SAVE=1, ENABLE_CLIENT_ONLY=0, ENABLE_SO
        CKS=1, ENABLE_FRAGMENT=1,/sales@openvpn.net

        1 Reply Last reply Reply Quote 0
        • U
          Unlogic
          last edited by Jun 26, 2011, 7:38 AM

          Found a discussion about this very subject here:

          http://forums.openvpn.net/topic7168.html

          1 Reply Last reply Reply Quote 0
          1 out of 4
          • First post
            1/4
            Last post
          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
            This community forum collects and processes your personal information.
            consent.not_received