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

    Trouble with in-coming connection with multi-WAN (fail-over)

    General pfSense Questions
    2
    13
    927
    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
      MacUsers
      last edited by MacUsers

      Hi there,

      I'm working on a test system, to setup a multi-wan in fail-over mode, which is mostly working just fine, after upgrading to v2.5.2RC. But I think I see an issue with accessing pfSense web admin GUI, when it fails over to the WAN2. So, this is my two WANs:

      WAN1 - Public Static IP from ISP
      WAN2 - LTE Dynamic IP (10.xx.xx.xx)

      I also have a dynamic-DNS setup on the fail-over gateway-groups, which updates the public IP of my pfSense box based on the active WAN.
      When it fails over to the WAN2, i.e. dynamic public IP from the LTE provider (which is different than the WAN2 interface IP) it returns the correct/current IP address running e.g. host mypfs.mydomain.com command and curl ipconfig.io also returns the correct/current public IP (which is basically the same from above two commands) but the in-coming connections fails, e.g.

      1. I cannot access the pfSense admin-gui; gets time out
      2. Cannot VPN in, as the client is configured with the DNS-name, like: remote mypfs.mydomain.com 1194 udp4.

      When it falls back to the WAN1 again, the GUI comes back. I think the issue is with incoming connection. Outgoing or surfing Internet is just fine with the fail-over.

      Am I missing something here? I thought I'd be able to assess the admin-GUI regardless of the active WAN as the dynamic-DNS is correctly setting up the the IP address for the host. Can any one explain to me why I'm seeing this or what mistake I'm making pls?

      -San

      V 1 Reply Last reply Reply Quote 0
      • M
        MacUsers
        last edited by

        any one??
        Really cannot get the VPN work, without being able to resolve the hostname when fail-over to WAN2.

        -S

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

          @macusers
          So you have an LTE router in front of pfSense and have to forward incoming packets to pfSense. Did you do that?

          I thought I'd be able to assess the admin-GUI regardless of the active WAN as the dynamic-DNS is correctly setting up the the IP address for the host.

          Basically it's not recommended to open access to the web configurator from the WAN!

          M 2 Replies Last reply Reply Quote 0
          • M
            MacUsers @viragomann
            last edited by

            @viragomann said in Trouble with in-coming connection with multi-WAN (fail-over):

            Basically it's not recommended to open access to the web configurator from the WAN!

            I don't completely agree with that but that's hardly the point. The entire AWS admin-console is opened in the WEB - does it mean your entire infrastructure is exposed? You just need proper access control.

            Anyway, that besides the point - the point is incoming traffic is not coming through when failing over to the secondary WAN, hence I cannot VPN in, to access the admin-console. The direct access admin-console was just another example.

            -San

            1 Reply Last reply Reply Quote 0
            • M
              MacUsers @viragomann
              last edited by MacUsers

              @viragomann said in Trouble with in-coming connection with multi-WAN (fail-over):

              So you have an LTE router in front of pfSense and have to forward incoming packets to pfSense. Did you do that?

              Trying to understand what actually mean. The Cable and the LTE modem both connected to the pfSense as WAN1 and WAN2, in a fail-over Gateway group. In coming works fine when WAN1 (cable modem) is active with the current configuration but when it fails over to WAN2 (LTE modem) it stops working. Outgoing is always okay. What do I do from here?

              -S

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

                @macusers
                Again, you will have to forward the incoming traffic on the LTE router to pfSense WAN2. You still didn't mention, if you did something like that already.

                On pfSense you can check if incoming packets are arriving on the WAN2 interface using Diagnostic > Packet Capture. But I'm in doubt.

                If you have forwarded the traffic and still no joy, check if you have a real public IP on the LTE. Provides like to provide CGNs. If it's this, you're lost.
                Also it's possible that the ISP is blocking incoming traffic.

                M 1 Reply Last reply Reply Quote 0
                • M
                  MacUsers @viragomann
                  last edited by MacUsers

                  @viragomann said in Trouble with in-coming connection with multi-WAN (fail-over):

                  Again, you will have to forward the incoming traffic on the LTE router to pfSense WAN2. You still didn't mention, if you did something like that already.

                  I don't think I did anything special for WAN2. My question I'm trying answer to myself: How it's working on WAN1, as I didn't do do anything for WAN1 either? Could you give me some pointers how do I do that?

                  my LTE does provide a real public IP address, which I can see is getting updated in my DNS record (during the failover) and also can so see the public-ip running host command on the DNS name.

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

                    @macusers
                    As you stated above

                    When it fails over to the WAN2, i.e. dynamic public IP from the LTE provider (which is different than the WAN2 interface IP)

                    the LTE public IP is not the WAN2 IP on pfSense. So the LTE router in front does NAT.
                    You might get the packets on the LTE WAN address, but if they are not forwarded from the router to pfSense, you cannot reach anything for sure.

                    M 1 Reply Last reply Reply Quote 0
                    • M
                      MacUsers @viragomann
                      last edited by MacUsers

                      @viragomann said in Trouble with in-coming connection with multi-WAN (fail-over):

                      You might get the packets on the LTE WAN address, but if they are not forwarded from the router to pfSense, you cannot reach anything for sure.

                      I think I understood what you mean but LTE modem is running in bridge/IP-pass-through mode, so routing functionality is turned off. Which one is the router here?

                      Having said that though, now makes me thinking, how the WAN2 is getting an IP from 10.xx.xxx.xxx network, which changes with every reboot. I have to agree I don't understand mobile data-network very well.

                      -S

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

                        @macusers said in Trouble with in-coming connection with multi-WAN (fail-over):

                        WAN2 is getting an IP from 10.xx.xxx.xxx network,

                        This is not a public IP, it's a private one. Look Private network.

                        No matter if the LTE is in bridge mode or not, your pfSense has not the public IP on its interface. Therefor incoming traffic have to be forwarded to it.
                        Maybe your ISP only provides a private network to you. So there is no possibility to get incoming connections from the internet, unless he forward it.

                        M 2 Replies Last reply Reply Quote 0
                        • M
                          MacUsers @viragomann
                          last edited by

                          @viragomann said in Trouble with in-coming connection with multi-WAN (fail-over):

                          This is not a public IP, it's a private one. Look Private network.

                          I know that private IP 😁 and, hence my comment 😉
                          Anyway, let me see if I can make it working with a forward rule.

                          -S

                          1 Reply Last reply Reply Quote 0
                          • M
                            MacUsers @viragomann
                            last edited by

                            @viragomann said in Trouble with in-coming connection with multi-WAN (fail-over):

                            Therefor incoming traffic have to be forwarded to it.

                            I couldn't figure out how to forward the traffic from public facing dynamic IP to WAN2 interface IP. Could you possibly give me an example or some sample screen-shots pls?

                            -San

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

                              @macusers
                              First of all, again check your internet-facing IP on the LTE router. If this is not a real public IP, your ISP provides only a private subnet to you and there is nothing you can do. You will not get any traffic from the internet to your router, cause this is controlled by the ISP.
                              In this case you can only use it for upstream connections.

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