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.
    • 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.