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

    Openvpn server on Virtual IP address not working

    OpenVPN
    2
    14
    4.3k
    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.
    • C
      CheeMG
      last edited by CheeMG

      Hi All
      We are able to get Openvpn server working in our PFSense 2.4.4_1. But when we used a Virtual IP (IP Alias on WAN interface) for the Openvpn server interface, it stopped working.

      Client can still reach the Openvpn server (the Openvpn status shows that the client is connected but with no virtual IP and UNDEF common name), but we keep getting "TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity.) TLS Error: TLS handshake failed" errors.

      We created a rule to let IPv4 UDP to the Virtual IP for Port 1194 and enabled logging for the rule and the logs showed that our client was able to pass through the firewall. And we also created a rule to let in all traffic under Openvpn rule. Similar to the two rules created by the Openvpn wizard.

      What else do we have to do to make Openvpn server on Virtual IP work?
      We have no problem getting Openvpn server on the WAN address to work, so it shouldn't be a network or key or certificate issue.

      Thank you very much in anticipation.

      More info on our setup:
      Virtual IP
      Type: IP Alias
      Interface: WAN
      Address: 74.120.2.5 (example)

      OpenVPN Server
      Server mode: Remote Access (SSL/TLS + User Auth)
      Backend for authentication: Local Database
      Protocol: UDP IPv4 and IPv6 on all interfaces (multihome)
      Device mode: tun - Layer 3 Tunnel Mode.
      Interface: 74.120.2.5
      Local port: 1194

      Client Export
      Host Name Resolution: Other
      Host Name: 74.120.2.5

      Firewall Rule
      Action: Pass
      Interface: WAN
      Address Family: IPv4
      Protocol: UDP
      Source: any
      Destination: Single host or alias 74.120.2.5
      Destination Port Range: From Openvpn (1194) To Openvn (1194)

      Firewall Rule
      Action: Pass
      Interface: OpenVPN
      Address Family: IPv4
      Protocol: Any
      Source: any
      Destination: any

      Again, we have no problem when we don't use Virtual IP. No problem when we use WAN interface for Openvpn server. But we cannot use the WAN interface address for Openvpn server. We need to use another IP and that's why we use Virtual IP.

      Update: We found this https://www.derman.com/blogs/OpenVPN-Firewall-Setup
      And changed the two Firewall -> NAT -> Outbound rules auto-added by the Openvpn wizard:
      Advanced Outbound NAT Entry
      Interface: WAN
      Address Family: IPv4+IPv6
      Protocol: any
      Source Network: 10.105.0.0/24 (the VPN tunnel network)
      Destination: Any
      Translation: Address: 74.120.2.5 ( we changed from Interface address i.e. WAN address to the Virtual IP address 74.120.2.5)
      Advanced Outbound NAT Entry
      Interface: WAN
      Address Family: IPv4+IPv6
      Protocol: any
      Source Network: 10.105.0.0/24 (the VPN tunnel network)
      Destination: Any Port 500
      Translation: Address: 74.120.2.5 ( we changed from Interface address i.e. WAN address to the Virtual IP address 74.120.2.5)

      1 Reply Last reply Reply Quote 0
      • nodauN
        nodau
        last edited by

        Hi,

        I would change the interface in the Openvpn config to localhost. The server then is listening to all ip addresses it knows. Change the nat translation ip to 127.0.0.1. I use this config in a HA environment without issues.

        Norman

        virtualized pfSense 2.7.2 HA-Cluster on vsphere 8

        1 Reply Last reply Reply Quote 0
        • C
          CheeMG
          last edited by CheeMG

          Thank you Norman for the suggestion, but we need to use another external static IP address, e.g., 74.120.2.5, for the OpenVPN server. We cannot let the Openvpn server listen to all IP addresses. We created a Virtual IP -> IP Alias on the WAN Interface, and tested it working. Was able to ping to this external IP address after creating a ICMP rule in the firewall. Also, the Openvpn client was able to connect to the server - according to the Openvpn Status in PFSense and the System log. But it stopped at "rror: TLS key negotiation failed to occur within 60 seconds ".

          When we used the WAN interface address for the Openvpn server, we have no problem at all. But we have our reason for not using the WAN interface address. Isn't Virtual IP supposed to work? We did everything necessary: creating a firewall rule under WAN to allow IPv4 UDP to the OpenVPN server IP 74.120.2.5, and another rule under OpenVPN to allow all traffic. But it is still not working. There are a few posts in this forum on this but no solution. So PFSense OpenVPN server with Virtual IP (IP Alias on WAN) has a bug?

          Thank you once again.

          No resolution:
          https://forum.netgate.com/topic/130201/using-openvpn-with-virtual-ip-address/9

          https://forum.netgate.com/topic/32727/openvpn-on-virtual-ip/4

          1 Reply Last reply Reply Quote 0
          • nodauN
            nodau
            last edited by nodau

            I also use ip aliases and it is working with localhost as interface. You need a nat rule for OpenVPN to work. Destination address your alias and 127.0.0.1 your redirect.

            Norman

            virtualized pfSense 2.7.2 HA-Cluster on vsphere 8

            C 1 Reply Last reply Reply Quote 0
            • C
              CheeMG @nodau
              last edited by

              @bahsig
              Thank you Norman. Tried to use IP Alias on Localhost and created a NAT rule for UDP for destination 74.120.2.5 and redirect 127.0.0.1 for Openvpn port but still not working. Also created a NAT for ICMP.
              But not it is even worst, 74.120.2.5 (example) is not reachable from the Internet at all. Cannot ping 74.120.2.5. Openvpn client cannot connect to 74.120.2.5 at all. Previously, when using Virtual IP alias on WAN, at least the Openvpn client was able to connect to the server and we could ping 74.120.2.5. Do you know what we are missing here? Thank you once again.

              1 Reply Last reply Reply Quote 0
              • nodauN
                nodau
                last edited by

                Maybe you have a misconfigured ip alias. Look there or post your configuration.

                Norman

                virtualized pfSense 2.7.2 HA-Cluster on vsphere 8

                1 Reply Last reply Reply Quote 0
                • C
                  CheeMG
                  last edited by

                  Thank you Norman.
                  As per your suggestion, we created the Virtual IP with Type IP Alias and Interface Locahost (instead of WAN).

                  Firewall -> Virtual IPs
                  Type: IP Alias
                  Interface: Localhost
                  Address: 74.120.2.5 /28

                  Fireall -> NAT -> Port Forwarding
                  Interface: WAN
                  Protocol: ICMP
                  Destination: 74.120.2.5 (Virtual IP creaded above bind to Localhost)
                  Redirect target IP: 127.0.0.1

                  Fireall -> NAT -> Port Forwarding
                  Interface: WAN
                  Protocol: UDP
                  Destination: 74.120.2.5 (Virtual IP creaded above bind to Localhost)
                  Destination port range from OpenVPN to OpenVPN
                  Redirect target IP: 127.0.0.1
                  Redirect target port: OpenVPN

                  In SystemAdvancedFirewall & NAT,
                  we selected Pure NAT for NAT Reflection mode for port forwards
                  we checked "Enable automatic outbound NAT for Reflection"

                  1 Reply Last reply Reply Quote 0
                  • nodauN
                    nodau
                    last edited by

                    Hi,

                    you misunderstood my last post. Virtual IP needs to be configured as an IP alias for wan interface. Asuming this public IP is reachable through your public wan ip. Your Nat rules look good. Nat reflection only needs to be selected, if you want to connect from your Lan or other internal network like wlan or dmz.
                    I like to use splitdns rather than nat, so clients don‘t need to go out the internet and come back to reach an internal service.

                    Openvpn server interface needs to be set to localhost. The IP alias is pointing to the wan interface.

                    Hope it‘s more understandable now.

                    Norman

                    virtualized pfSense 2.7.2 HA-Cluster on vsphere 8

                    1 Reply Last reply Reply Quote 0
                    • C
                      CheeMG
                      last edited by CheeMG

                      Could this be the problem?
                      This is from Diagnostics -> State

                      WAN udp 98.223.42.169:65316 -> 74.120.2.5:1194 NO_TRAFFIC:SINGLE 3 / 0 210 B / 0 B

                      WAN udp 74.120.2.3:1194 -> 98.223.42.169:65316 SINGLE:NO_TRAFFIC 3 / 0 246 B / 0 B

                      74.120.2.3 is the WAN Interface IP of the firewall.
                      74.120.2.5 is a WAN IP Alias - a Virtual IP used by the Openvpn server.
                      98.223.42.169 is the Openvpn Client.
                      The Client is connected to 74.120.2.5 (the Virtual IP used by the Openvpn server).
                      But the Openvpn server is responding to the client as 74.120.2.3 (the Firewall WAN IP).

                      When using Localhost for Openvpn server and then creating a NAT to redirect the Virtual IP to 127.0.0.1, got something similar:

                      WAN udp 98.223.42.169:58014 -> 127.0.0.1:1194 (74.120.2.5:1194) NO_TRAFFIC:SINGLE 4 / 0 280 B / 0 B

                      WAN udp 74.120.2.3:1194 -> 98.223.42.169:58014 SINGLE:NO_TRAFFIC 4 / 0 328 B / 0 B

                      1 Reply Last reply Reply Quote 0
                      • nodauN
                        nodau
                        last edited by

                        mine shows this:

                        WAN1 udp 91.x.x.x:59797 -> 127.0.0.1:1194 (195.x.x.x:1194) MULTIPLE:MULTIPLE 128 / 140 15 KiB / 79

                        What does the client log say?

                        Norman

                        virtualized pfSense 2.7.2 HA-Cluster on vsphere 8

                        1 Reply Last reply Reply Quote 0
                        • C
                          CheeMG
                          last edited by

                          Thank you Norma.
                          So you don't have another state from your WAN (or WAN IP Alias) to your client IP?
                          If so, something is wrong with my setup.
                          Here's my client log (IP changed):
                          Tue Jan 01 12:12:39 2019 Note: option tun-ipv6 is ignored because modern operating systems do not need special IPv6 tun handling anymore.
                          Tue Jan 01 12:12:39 2019 OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 26 2018
                          Tue Jan 01 12:12:39 2019 Windows version 6.2 (Windows 8 or greater) 64bit
                          Tue Jan 01 12:12:39 2019 library versions: OpenSSL 1.1.0h 27 Mar 2018, LZO 2.10
                          Enter Management Password:
                          Tue Jan 01 12:12:45 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]74.120.2.5:1194
                          Tue Jan 01 12:12:45 2019 UDP link local (bound): [AF_INET][undef]:0
                          Tue Jan 01 12:12:45 2019 UDP link remote: [AF_INET]74.120.2.5:1194
                          Tue Jan 01 12:13:45 2019 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
                          Tue Jan 01 12:13:45 2019 TLS Error: TLS handshake failed
                          Tue Jan 01 12:13:45 2019 SIGUSR1[soft,tls-error] received, process restarting
                          Tue Jan 01 12:13:50 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]74.120.2.5:1194
                          Tue Jan 01 12:13:50 2019 UDP link local (bound): [AF_INET][undef]:0
                          Tue Jan 01 12:13:50 2019 UDP link remote: [AF_INET]74.120.2.5:1194
                          Tue Jan 01 12:14:51 2019 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
                          Tue Jan 01 12:14:51 2019 TLS Error: TLS handshake failed
                          Tue Jan 01 12:14:51 2019 SIGUSR1[soft,tls-error] received, process restarting
                          Tue Jan 01 12:14:56 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]74.120.2.5:1194
                          Tue Jan 01 12:14:56 2019 UDP link local (bound): [AF_INET][undef]:0
                          Tue Jan 01 12:14:56 2019 UDP link remote: [AF_INET]74.120.2.5:1194
                          Tue Jan 01 12:15:57 2019 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
                          Tue Jan 01 12:15:57 2019 TLS Error: TLS handshake failed
                          Tue Jan 01 12:15:57 2019 SIGUSR1[soft,tls-error] received, process restarting

                          1 Reply Last reply Reply Quote 0
                          • nodauN
                            nodau
                            last edited by

                            Does it work, if you use localhost for the OpenVPN interface and point the rules to your wan ip (not the alias).

                            If it is working I would delete the ip alias and recreate it. And don‘t test from your internal network, to exclude nat reflection issues.

                            Norman

                            virtualized pfSense 2.7.2 HA-Cluster on vsphere 8

                            C 1 Reply Last reply Reply Quote 0
                            • C
                              CheeMG @nodau
                              last edited by CheeMG

                              @bahsig
                              Hi Norman
                              I finally got it working without using localhost for Openvpn server.

                              The problem is I had selected "UDP IPv4 and IPv6 on all interfaces (multihome)" in the Openvpn server protocol setting.
                              This caused the Openvpn server to actually listen on all interfaces (instead of on the WAN IP Alias).
                              I did a netstat -an in Diagnostis -> Command Prompt and it showed:
                              udp46 0 0 *.1194 .

                              Then I ssh-ed to the PFSense server as admin and tried to add
                              local 74.120.2.5 to the /var/etc/openvpn/server1.conf file (to force it to listen on 74.120.2.5 which is my WAN IP Alias).
                              But this doesn't work because the /var/etc/openvpn/server1.conf file is refreshed every time you restart the Openvpn server or the firewall. PFsense probably gets the settings from the settings file somewhere and then recreates the /var/etc/openvpn/server1.conf file.

                              So later I realized it could be because the Virtual IP (the WAN IP Alias) only has IPv4 address and no IPv6 address (not possible assign both IPv4 and IPv6 addresses to a IP Alias virtual IP?). So I changed the protocol setting in the Openvpn server to "UDP on IPv4 only" and restarted the Openvpn server in Status->Openvpn, and viola everything started working.

                              So the problem is since we cannot bind both IPv4 and IPv6 addresses to a IP Alias Virtual IP, we cannot select "UDP IPv4 and IPv6 on all interfaces (multihome)" protocol in the Openvpn server configuration if we want to use Virtual IP for Interface.

                              I think this should be considered a design flaw. I decided to use both IPv4 and IPv5 for the Openvpn server protocol because the PFSense book says "OpenVPN can connect a site-to-site tunnel to either an IPv4 address or an IPv6 address and both IPv4 and IPv6 traffic
                              may be passed inside of an OpenVPN tunnel at the same time. IPv6 is supported both in site-to-site and mobile clients,
                              and it can be used to deliver IPv6 to a site that only has IPv4 connectivity.".
                              But apparently, this does not work if you use a Virtual IP as the server interface. Maybe if they allow both IPv4 and IPv6 addresses to be bound to a IP Alias Virtual IP, it will work? For now, I am dropping IPv6.

                              Thank you again Norman

                              1 Reply Last reply Reply Quote 0
                              • C
                                CheeMG
                                last edited by

                                I think this is more of a OpenVPN problem rather than PFSense problem.
                                Apparently, it isn't possible for OpenVPN server to listen on both IPv4 and IPv6 addresses. It can listen to ALL (meaning all IPv4 and IPv6 interfaces on server) OR a single IP address (IPv4 or IPv6).

                                https://sourceforge.net/p/openvpn/mailman/message/34193818/
                                "AFAIK this is currently not possible - openvpn can either bind to ALL
                                addresses (IPv4 and IPv6) or it can bind to a single address - either
                                IPv4 or IPv6. "

                                https://community.openvpn.net/openvpn/ticket/937?cversion=0&cnum_hist=5

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