Navigation

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

    PfSense 2.3.4 OpenVPN

    HA/CARP/VIPs
    3
    4
    635
    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.
    • D
      darkfader last edited by

      Hi,

      I've (like always) bound my OpenVPN instance to my WAN-side CARP VIP.
      Now in this new test cluster I got this funny situation that OpenVPN on the secondary cluster node tries to bind to the IP forcefully and dies, very unhappily (because the IP is still on the primary)

      This is what it looks like:

      Time Process PID Message
      Aug 21 20:59:42 openvpn 614 TCP/UDP: Socket bind failed on local address [AF_INET]192.168.65.2:1194: Can't assign requested address
      Aug 21 20:59:42 openvpn 614 Exiting due to fatal error
      Aug 21 20:59:43 openvpn 5919 OpenVPN 2.3.17 amd64-portbld-freebsd10.3 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Jun 26 2017
      Aug 21 20:59:43 openvpn 5919 library versions: OpenSSL 1.0.1s-freebsd 1 Mar 2016, LZO 2.10
      Aug 21 20:59:43 openvpn 6215 NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
      Aug 21 20:59:43 openvpn 6215 Control Channel Authentication: using '/var/etc/openvpn/server1.tls-auth' as a OpenVPN static key file
      Aug 21 20:59:43 openvpn 6215 TCP/UDP: Socket bind failed on local address [AF_INET]192.168.65.2:1194: Can't assign requested address
      Aug 21 20:59:43 openvpn 6215 Exiting due to fatal error

      I found a report of the same thing back from 2016 where the guy went to all sorts of crazy hoops with NAT and binding to OPT interfaces instead. I don't think that's the way to go.
      This must be a config mistake anyway, unless noone ever tested CARP + OpenVPN in 2.3+ but I surely doubt that.

      Anyone got an idea where I should look?

      1 Reply Last reply Reply Quote 0
      • V
        viragomann last edited by

        @darkfader:

        I found a report of the same thing back from 2016 where the guy went to all sorts of crazy hoops with NAT and binding to OPT interfaces instead. I don't think that's the way to go.

        Why not. Just give it a try.

        You may also forwart OpenVPN to localhost and set your OpenVPN server to listen to localhost. Why else do you think it's possible to select localhost for listening interface in the server settings?

        1 Reply Last reply Reply Quote 0
        • D
          darkfader last edited by

          Well, because it's a regression and none of the docs have been updated?

          So noone actually bothered and you're the one guy who went down the hard way to make it work.
          Binding to localhost is kind of of clean just I'd have loved to hear "no, this is a known issue and someone is planning to do something about it".

          Is that really surprising?

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

            Is this a client or a server?

            OpenVPN servers bound to CARP VIPs are kept shut down on whichever unit has the VIP in a BACKUP state. So it's normal for them not to be running on the secondary.

            When the VIP state transitions to MASTER they are started automatically.

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

            Products

            • Platform Overview
            • TNSR
            • pfSense Plus
            • 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