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

    Unable to properly initiate an OpenVPN connection.

    Scheduled Pinned Locked Moved OpenVPN
    6 Posts 3 Posters 16.8k 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
      Papa Midnight
      last edited by

      Ok, I've been trying to get this VPN to work properly for the better part of an hour.

      Following the Road Warrior's Guide, I got to the point that it connected, but failed to handshake over TLS. By changing from UDP to TCP (I assume the network I'm on blocks UDP packets), I was able to resolve this issue and I believed my self to be successfully connected… till I saw this:

      Mon Nov 23 11:22:46 2009 Initialization Sequence Completed
      Mon Nov 23 11:22:55 2009 Authenticate/Decrypt packet error: cipher final failed
      Mon Nov 23 11:22:55 2009 Fatal decryption error (process_incoming_link), restarting
      Mon Nov 23 11:22:55 2009 TCP/UDP: Closing socket
      Mon Nov 23 11:22:55 2009 SIGUSR1[soft,decryption-error] received, process restarting
      Mon Nov 23 11:22:55 2009 Restart pause, 5 second(s)

      And I see that roughly every 5 seconds after a successful connection.

      I'm not sure what I'm doing wrong and would appreciate any help given.

      Here's the full log of what I see. Just copy and paste it because it repeats every 20 seconds or so.

      Client Side:

      Mon Nov 23 11:19:58 2009 Authenticate/Decrypt packet error: cipher final failed
      Mon Nov 23 11:19:58 2009 Fatal decryption error (process_incoming_link), restarting
      Mon Nov 23 11:19:58 2009 TCP/UDP: Closing socket
      Mon Nov 23 11:19:58 2009 SIGUSR1[soft,decryption-error] received, process restarting
      Mon Nov 23 11:19:58 2009 Restart pause, 5 second(s)
      Mon Nov 23 11:20:03 2009 NOTE: OpenVPN 2.1 requires '–script-security 2' or higher to call user-defined scripts or executables
      Mon Nov 23 11:20:03 2009 Re-using SSL/TLS context
      Mon Nov 23 11:20:03 2009 LZO compression initialized
      Mon Nov 23 11:20:03 2009 Control Channel MTU parms [ L:1544 D:140 EF:40 EB:0 ET:0 EL:0 ]
      Mon Nov 23 11:20:03 2009 Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:135 ET:0 EL:0 AF:3/1 ]
      Mon Nov 23 11:20:03 2009 Local Options hash (VER=V4): '69109d17'
      Mon Nov 23 11:20:03 2009 Expected Remote Options hash (VER=V4): 'c0103fa8'
      Mon Nov 23 11:20:03 2009 Attempting to establish TCP connection with ...:21
      Mon Nov 23 11:20:03 2009 TCP connection established with ...:21
      Mon Nov 23 11:20:03 2009 Socket Buffers: R=[8192->8192] S=[8192->8192]
      Mon Nov 23 11:20:03 2009 TCPv4_CLIENT link local: [undef]
      Mon Nov 23 11:20:03 2009 TCPv4_CLIENT link remote: ...:21
      Mon Nov 23 11:20:03 2009 TLS: Initial packet from ...:21, sid=795148d9 e0e8dd55
      Mon Nov 23 11:20:04 2009 VERIFY OK: depth=1, [Redacted]
      Mon Nov 23 11:20:04 2009 VERIFY OK: nsCertType=SERVER
      Mon Nov 23 11:20:04 2009 VERIFY OK: depth=0, [Redacted]
      Mon Nov 23 11:20:05 2009 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1544', remote='link-mtu 1559'
      Mon Nov 23 11:20:05 2009 WARNING: 'comp-lzo' is present in local config but missing in remote config, local='comp-lzo'
      Mon Nov 23 11:20:05 2009 WARNING: 'cipher' is used inconsistently, local='cipher BF-CBC', remote='cipher CAMELLIA-256-CBC'
      Mon Nov 23 11:20:05 2009 WARNING: 'keysize' is used inconsistently, local='keysize 128', remote='keysize 256'
      Mon Nov 23 11:20:05 2009 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
      Mon Nov 23 11:20:05 2009 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
      Mon Nov 23 11:20:05 2009 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
      Mon Nov 23 11:20:05 2009 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
      Mon Nov 23 11:20:05 2009 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
      Mon Nov 23 11:20:05 2009 [pfSense] Peer Connection Initiated with ...:21
      Mon Nov 23 11:20:07 2009 SENT CONTROL [pfSense]: 'PUSH_REQUEST' (status=1)
      Mon Nov 23 11:20:07 2009 PUSH: Received control message: 'PUSH_REPLY,route [Redacted] [Redacted],route [Redacted] [Redacted],ping 10,ping-restart 60,ifconfig [Redacted] [Redacted]'
      Mon Nov 23 11:20:07 2009 OPTIONS IMPORT: timers and/or timeouts modified
      Mon Nov 23 11:20:07 2009 OPTIONS IMPORT: –ifconfig/up options modified
      Mon Nov 23 11:20:07 2009 OPTIONS IMPORT: route options modified
      Mon Nov 23 11:20:07 2009 Preserving previous TUN/TAP instance: Local Area Connection 2
      Mon Nov 23 11:20:07 2009 Initialization Sequence Completed

      Server Side

      Nov 23 11:32:53 openvpn[57852]: [Redacted]:31701 [Papa_Midnight] Peer Connection Initiated with [Redacted]:31701
      Nov 23 11:32:52 openvpn[57852]: [Redacted]:31701 WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo'
      Nov 23 11:32:52 openvpn[57852]: [Redacted]:31701 WARNING: 'keysize' is used inconsistently, local='keysize 256', remote='keysize 128'
      Nov 23 11:32:52 openvpn[57852]: [Redacted]:31701 WARNING: 'cipher' is used inconsistently, local='cipher CAMELLIA-256-CBC', remote='cipher BF-CBC'
      Nov 23 11:32:52 openvpn[57852]: [Redacted]:31701 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1559', remote='link-mtu 1544'
      Nov 23 11:32:51 openvpn[57852]: TCPv4_SERVER link remote: [Redacted]:31701
      Nov 23 11:32:51 openvpn[57852]: TCPv4_SERVER link local: [undef]
      Nov 23 11:32:51 openvpn[57852]: TCP connection established with [Redacted]:31701
      Nov 23 11:32:51 openvpn[57852]: Re-using SSL/TLS context
      Nov 23 11:32:46 openvpn[57852]: Papa_Midnight/[Redacted]:31056 Fatal decryption error (process_incoming_link), restarting
      Nov 23 11:32:46 openvpn[57852]: Papa_Midnight/[Redacted]:31056 Authenticate/Decrypt packet error: cipher final failed
      Nov 23 11:32:33 openvpn[57852]: [Redacted]:31056 [Papa_Midnight] Peer Connection Initiated with [Redacted]:31056
      Nov 23 11:32:33 openvpn[57852]: [Redacted]:31056 WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo'
      Nov 23 11:32:33 openvpn[57852]: [Redacted]:31056 WARNING: 'keysize' is used inconsistently, local='keysize 256', remote='keysize 128'
      Nov 23 11:32:33 openvpn[57852]: [Redacted]:31056 WARNING: 'cipher' is used inconsistently, local='cipher CAMELLIA-256-CBC', remote='cipher BF-CBC'
      Nov 23 11:32:33 openvpn[57852]: [Redacted]:31056 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1559', remote='link-mtu 1544'
      Nov 23 11:32:31 openvpn[57852]: TCPv4_SERVER link remote: [Redacted]:31056
      Nov 23 11:32:31 openvpn[57852]: TCPv4_SERVER link local: [undef]
      Nov 23 11:32:31 openvpn[57852]: TCP connection established with [Redacted]:31056
      Nov 23 11:32:31 openvpn[57852]: Re-using SSL/TLS context

      Any help would be greatly appreciated.

      Edit: I should mention that I do, albeit briefly, successfully connect. I even get an IP. Then of course, the connection fails and we launch into this endless loop.

      Edit 2: Enabled comp-lzo remotely. Even got into my network and was able to get to the pfSense webgui. Changed to the default of BF-CBC (128 bit) as well. Then I got this:

      Mon Nov 23 11:47:55 2009 OPTIONS IMPORT: route options modified
      Mon Nov 23 11:47:55 2009 Preserving previous TUN/TAP instance: Local Area Connection 2
      Mon Nov 23 11:47:55 2009 Initialization Sequence Completed
      Mon Nov 23 11:47:56 2009 read TCPv4_CLIENT: Permission denied (WSAEACCES) (code=10013)
      Mon Nov 23 11:47:56 2009 Connection reset, restarting [-1]
      Mon Nov 23 11:47:56 2009 TCP/UDP: Closing socket
      Mon Nov 23 11:47:56 2009 SIGUSR1[soft,connection-reset] received, process restarting
      Mon Nov 23 11:47:56 2009 Restart pause, 5 second(s)

      However, once data stops passing, the connection becomes stable suddenly.

      So basically, the connection is fine, then once data actually starts moving, the connection starts disconnecting and reconnecting, sending data in spurts each time, till the data finally finishes and the connection becomes stable.

      This is becoming heavily frustrating.

      1 Reply Last reply Reply Quote 0
      • P
        Papa Midnight
        last edited by

        bumpity bump.
        Anyone?

        1 Reply Last reply Reply Quote 0
        • AhnHELA
          AhnHEL
          last edited by

          ISP might be blocking Port 21, dont use it as a OpenVPN port.  Stick with 1194 or if you want to use a non-standard OpenVPN port, use something higher than port 1024 so it doesnt interfere with any other service ports.  UDP is also recommended.

          AhnHEL (Angel)

          1 Reply Last reply Reply Quote 0
          • P
            Papa Midnight
            last edited by

            I've previously used port 21 to serve an FTP Server from my own personal LAN so I know the ISP is not blocking it. I also know it's one of only 3 ports allowed where I am (21, 80, and 443. Even 8080 and 110 don't get passed).

            443 is in use (I need to redirect RDP somewhere so I can get to my network) as is 80, and I no longer run an FTP server; therefore, 21 is my only option.

            UDP packets are blocked where I am, as well, otherwise I'd use it (I personally understand why it is recommended).

            Now at this point, I can connect, ping, etc. I can do everything but hold a stable connection as the connection (as previously described) disconnects and reconnects constantly while relatively larger amounts of data is being passed; I say relative because the amount of data which seems to be small and that which seems to be large makes the difference between what fails and what doesn't. In example: A ping will not cause a disconnection. I can serve pings all day (went an hour non-stop without issue) and not disconnect. Yet, the moment I go for something a little bit bigger (say, loading the webGUI or a 30kB picture), everything screeches to a grinding halt, disconnects, reconnects, gets a little more, disconnects, reconnects, gets a little more, repeat till the picture finally loads and the connection is once again stable. Accompanied with this is an error which presents itself ambiguously as (as previously described):

            Mon Nov 23 11:47:56 2009 read TCPv4_CLIENT: Permission denied (WSAEACCES) (code=10013)

            This is what I need resolved and I am unable to resolve as of present.

            1 Reply Last reply Reply Quote 0
            • P
              Papa Midnight
              last edited by

              Can I assume from the lack of response that no one has any clue as to what may be causing this issue or what may be done to rectify it?

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

                Nov 23 11:32:33    openvpn[57852]: [Redacted]:31056 WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo'
                Nov 23 11:32:33    openvpn[57852]: [Redacted]:31056 WARNING: 'keysize' is used inconsistently, local='keysize 256', remote='keysize 128'
                Nov 23 11:32:33    openvpn[57852]: [Redacted]:31056 WARNING: 'cipher' is used inconsistently, local='cipher CAMELLIA-256-CBC', remote='cipher BF-CBC'
                Nov 23 11:32:33    openvpn[57852]: [Redacted]:31056 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1559', remote='link-mtu 1544'

                You have mismatched settings between client and server. Cipher (keysize is determined by choice of cipher) and lzo compression settings have to match exactly.

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