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

    Open VPN-Additional Client Conf options-Add 2nd WAN

    Scheduled Pinned Locked Moved OpenVPN
    11 Posts 3 Posters 4.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.
    • C
      costasppc
      last edited by

      Hello!

      In Client Export > Additional Configuration Options:I have added remote MY_SECOND_WAN_IP 1196 in order to have failover WAN for OpenVPN. However, the specific connection works only with the second wan ip.

      Is this possible at all (to add both WAN ips in one OpenVPN connection)?

      Best regards

      Kostas

      1 Reply Last reply Reply Quote 0
      • M
        Metu69salemi
        last edited by

        Does your confic includes

        
        remote first_wan_ip port
        remote second_wan_ip port
        
        
        1 Reply Last reply Reply Quote 0
        • C
          costasppc
          last edited by

          Thank you.

          No, just remote first WAN IP port.

          Kostas

          1 Reply Last reply Reply Quote 0
          • M
            Metu69salemi
            last edited by

            What happens if you add that kind of configuration?

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

              I will try and post back.

              I have to check with the first WAN connected and then disconnected, in order to see if it falls to the second.

              Thank you!

              Kostas

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

                After several checks I found this: the OpenVPN accepts connections only in one of the WANs. If I set the other WAN as option in client export I get:

                Feb 08 17:54:13: TCP/UDP: Incoming packet rejected from <wan-1-ip></wan-1-ip>:1196[2], expected peer address: <wan-2-ip></wan-2-ip>:1196 (allow this incoming source address/port by removing –remote or adding --float)

                There is a floating rule for OpenVPN, though.

                The **<wan-1-ip></wan-1-ip>**is a PPoE VLAN interface and the **<wan-2-ip></wan-2-ip>**is the main WAN port of PFSense.

                Best regards

                Kostas

                1 Reply Last reply Reply Quote 0
                • N
                  Nachtfalke
                  last edited by

                  @costasppc:

                  After several checks I found this: the OpenVPN accepts connections only in one of the WANs. If I set the other WAN as option in client export I get:

                  Feb 08 17:54:13: TCP/UDP: Incoming packet rejected from <wan-1-ip></wan-1-ip>:1196[2], expected peer address: <wan-2-ip></wan-2-ip>:1196 (allow this incoming source address/port by removing –remote or adding --float)

                  There is a floating rule for OpenVPN, though.

                  The **<wan-1-ip></wan-1-ip>**is a PPoE VLAN interface and the **<wan-2-ip></wan-2-ip>**is the main WAN port of PFSense.

                  Best regards

                  Kostas

                  Am I right, that your OpenVPN server is listening on WAN1 and WAN2 and you are using UDP as protocol ?

                  Then Failover will not work. Failover and OpenVPN do not work with this kind of configuration. To make it work configure it this way:

                  The OpenVPN Server is listening on the LAN address, port 1194, UDP
                  Create a "Port Forward" from WAN1 address, poirt 1194 to LAN address, port 1194
                  Create a "Port Forward" from WAN2 address, port 1194 to LAN address, port 1194
                  Create corresponding firewall rules for these two Port Forwards.

                  Add this to your OpenVPN client.conf

                  
                  remote-random
                  remote WAN1_address 1194
                  remote WAN2_address 1194
                  
                  

                  remote random means: The client tries to use the one or the other IP. There is no order, it is "random".
                  If you delete "remote random" then the client first uses WAN1-IP and if this fails WAN2-IP. It checks the remote IP addresses from top to down.

                  PS: Delete the floating rule for OpenVPN - just use "normal" rules like I wrote above - that's enough.

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

                    Thank you for your answer!

                    It is listening to <any>interface, UDP, port 1196 (I have a OpenVPN appliance in 1194).

                    If I delete remote-random (I need a specific faster (WAN1) to be tried first and if failed, the other (WAN2)) my client conf is like this?

                    remote WAN1_address 1196
                    remote WAN2_address 1196
                    

                    Best regards

                    Kostas</any>

                    1 Reply Last reply Reply Quote 0
                    • N
                      Nachtfalke
                      last edited by

                      @costasppc:

                      Thank you for your answer!

                      It is listening to <any>interface, UDP, port 1196 (I have a OpenVPN appliance in 1194).

                      If I delete remote-random (I need a specific faster (WAN1) to be tried first and if failed, the other (WAN2)) my client conf is like this?

                      remote WAN1_address 1196
                      remote WAN2_address 1196
                      

                      Best regards

                      Kostas</any>

                      If you first WAN1 is faster and you want that the WAN1 should be used first if it is up, than remove "remote-random". Then in your case it will first youse WAN1 and only WAN2 if WAN2 is down/not reachable.

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

                        Thank you!

                        I will check and get back.

                        Best regards

                        Kostas

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

                          Well, it not working on the one of the WANs, only to the second:

                          I have deleted the floating rule for the WAN in question, created a NAT rule and the corresponding FW rule. I have let the other floating rule untouched, though:

                          NAT Rule

                          Firewall rule

                          I have added the info to the Client export for Viscosity:

                          However, Viscosity conf contains the info for the 1st WAN address, nothing for the second:

                          dev tun
                          persist-tun
                          persist-key
                          proto udp
                          cipher AES-128-CBC
                          tls-client
                          client
                          resolv-retry infinite
                          remote 1st_WAN_address 1196
                          tls-remote VPNServer
                          auth-user-pass
                          comp-lzo

                          ca ca.crt
                          tls-auth ta.key 1
                          cert cert.crt
                          key key.key

                          The connection is failing, the log is below, and if by hand change the WAN address in the conf file to the 2nd WAN address the connection succeeds:

                          Mar 03 14:38:46: LZO compression initialized
                          Mar 03 14:38:46: UDPv4 link local (bound): [undef]:1194
                          Mar 03 14:38:46: UDPv4 link remote: 46.198.128.106:1196
                          Mar 03 14:39:46: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
                          Mar 03 14:39:46: TLS Error: TLS handshake failed
                          Mar 03 14:39:46: SIGUSR1[soft,tls-error] received, process restarting

                          Best regards

                          Kostas

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