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

    OpenVPN relying on WAN1 when it should rely only on WAN2

    Scheduled Pinned Locked Moved OpenVPN
    31 Posts 3 Posters 2.6k Views 4 Watching
    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.
    • A Offline
      abuttino @Rico
      last edited by abuttino

      @Rico I am using 10.0.0.0/8 for LAN. I am guessing that may be an issue; the way you said it. This has never been a problem until my network started growing.

      Forgot to mention "NanoStation" is actually WAN2/eth1

      Only one thing is effected by it now because it runs straight into a Unifi Security Gateway that has it's NAT and Firewall disabled (basically using it for DHCP, HE.net tunnel, DPI)

      If you were to tell me to change the address to a /16 address, I don't think that would be a big issue.

      Bob.DigB 1 Reply Last reply Reply Quote 0
      • Bob.DigB Offline
        Bob.Dig LAYER 8 @abuttino
        last edited by

        @abuttino Nord is using 10.8. for their Servers.

        1 Reply Last reply Reply Quote 0
        • RicoR Offline
          Rico LAYER 8 Rebel Alliance
          last edited by

          Yeah your LAN overlaps with almost any VPN providers tunnel network.

          -Rico

          A 1 Reply Last reply Reply Quote 0
          • A Offline
            abuttino
            last edited by

            Fixed, testing tonight..

            I presume that is why it was bringing down the entire thing, correct?

            1 Reply Last reply Reply Quote 0
            • A Offline
              abuttino @Rico
              last edited by abuttino

              @Rico Don't know what to try next, unplugging the cable on WAN1 still brought the VPN down..

              97732585-9599-44a2-a778-c5d23861ab26-image.png

              This table continues but these are the first few entries.

              WAN2 is NANOSTATION

              1 Reply Last reply Reply Quote 0
              • RicoR Offline
                Rico LAYER 8 Rebel Alliance
                last edited by

                Please post the logs here when the VPN is going down.

                -Rico

                A 1 Reply Last reply Reply Quote 0
                • A Offline
                  abuttino @Rico
                  last edited by abuttino

                  @Rico
                  This is from a complete cycle when I pull the plug on WAN1 to when I put it back in.

                  https://pastebin.com/SWHnmD3j

                  I fixed the issue with UPSMon, Changed IP and neglected to change the IP on the NUT server

                  1 Reply Last reply Reply Quote 0
                  • RicoR Offline
                    Rico LAYER 8 Rebel Alliance
                    last edited by

                    Is your pfSense default gateway WAN2?
                    Try to bind the OpenVPN client Interface to localhost then.

                    -Rico

                    A 3 Replies Last reply Reply Quote 0
                    • A Offline
                      abuttino @Rico
                      last edited by

                      @Rico No, the default gateway is WAN1. I'll give it a shot.

                      1 Reply Last reply Reply Quote 0
                      • A Offline
                        abuttino @Rico
                        last edited by abuttino

                        @Rico

                        I saw that there was a LOT of errors for WAN_DHCP6 and it was trying like hell to route traffic there. I disabled it and the VPN did NOT lose connection at all. Localhost was not the trick

                        However, I still can't reach the internet when I am failed over for some reason. I know WAN2's connection is good because it's responsible for the VPN's connection to the server.

                        UPDATE:
                        Internet is reachable but won't use the VPN.

                        1 Reply Last reply Reply Quote 0
                        • A Offline
                          abuttino
                          last edited by

                          I am witnessing some very odd behavior and I can't explain it.

                          The LAN is supposed to use the failover group but when I disconnect the cable, it goes dead.
                          7724a131-449f-4e08-9405-d8a0fb234c27-image.png

                          WAN2's gateway is set to only use the right gateway for any traffic:
                          f9aae79d-f077-4a07-9be1-78761a5f5407-image.png

                          and, the Outbound NAT rules tell EVERYTHING how to find LAN /16:
                          e4514be8-6e6c-47ab-bed6-5dfc4ca35d88-image.png

                          As soon as I disconnect WAN1 everything goes down.

                          When I have traffic using the VPN, it's an all or nothing, it won't just use WAN2.

                          VPN Setup that WON'T Use the vpn on WAN1
                          9f5760db-3291-4fc9-9031-f41e1ce05e20-image.png

                          and:
                          If I uncheck Don't pull routes, it will use it on WAN1, until WAN1 goes down. Then everything goes down

                          I am lost.

                          1 Reply Last reply Reply Quote 0
                          • A Offline
                            abuttino
                            last edited by

                            I found that if you make a gateway group and and have plans to change it, you must remake the entire thing AND Reboot. It doesn't like changes like that. Spent an hour figuring out why it wouldn't let me fail to the bare modem.

                            Still can't use the VPN on WAN2 only. That seems to be the last problem which was also the original problem.

                            1 Reply Last reply Reply Quote 0
                            • A Offline
                              abuttino @Rico
                              last edited by abuttino

                              @Rico @netgate

                              I believe I have uncovered 2 bugs with this.

                              Bug 1: OpenVPN relies on WAN Interface DHCPv6 even though it says IPv4 in the configuration for this VPN. Ignores the Interface it is supposed to look at for connection

                              Steps for Replication. Use an OpenVPN interface as in a Gateway group, pull plug on WAN1 where it has DHCP. Watch the VPN connection go down after the plug has been pulled.

                              Bug 2: The OpenVPN cannot be reached in a gateway group, uses the WAN connection instead of OpenVPN for communication but, Can be reached with a firewall rule LAN to OpenVPNGateway but NOT LAN to FailOverGateway.

                              Steps for Replication:
                              Use OpenVPN Client connection as interface, and use in a gateway Load Balance and Fail-over group. then on the firewall LAN config pick that gateway group as LAN net's gateway. It will use the connection WAN2 on to the VPN (perform a 'what's my ip' test).

                              I will report both of these as bugs to the bug tracking board if they are indeed bugs or if it is by design.

                              Thanks, in advance, for your time to look into this issue and your time to reply.

                              1 Reply Last reply Reply Quote 0
                              • A Offline
                                abuttino
                                last edited by

                                @Netgate-Steve can you take a look at this and tell me if it warrants a bug report, please.

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