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

    TLS handshake failed / OpenVPN with NetworkManager

    Scheduled Pinned Locked Moved OpenVPN
    2 Posts 1 Posters 3.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.
    • S
      scar
      last edited by

      hello,

      i am trying to get a VPN setup between my pfsense-1.2.3 boxes and a debian lenny client using NetworkManager.

      i followed this guide to create the CA, server, and client certificates and keys:

      http://thegoldenear.org/toolbox/unices/pfsense-1.2-openvpn-certificates-keys.html#client-certs

      my VPN settings in pfsense:

      
      protocol: UDP
      local port: something random
      address pool: new /24 subnet
      local network: my LAN subnet
      cryptography: AES-128-CBC
      authentication method: PKI
      custom options: engine cryptodev
      

      i pasted in the CA Cert, Server cert, Server key, and DH params. i am using a netgate firewall with dual alix.2d3 boards (with CARP) so that is why i added 'engine cryptodev'

      i added a UDP firewall rule, allow any to single host (CARP shared WAN address), dest port range matches VPN port.

      when i try to initiate the connection from my debian client using NetworkManager, i can see in the pfsense firewall log that the connection was allowed.  but, in the openvpn logs i see "TLS handshake failed".  in NetworkManager / VPN properties, i made sure to match the cipher (AES-128-CBC).

      i think that's about it… what else can i check?  thanks

      1 Reply Last reply Reply Quote 0
      • S
        scar
        last edited by

        ah cool… i figured it out!

        i think i just had to add the option 'local <wan carp="" ip="">' to the VPN's custom options in addition to the 'engine cryptodev'

        i also added an AON rule before trying this, which didn't help, but maybe it was needed too?  i made the rule for source <new 24="" subnet="">:* to : with NAT address<wan carp="" ip=""></wan></new></wan>

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