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

    Multi-WAN Port Forward Blocked (Showing Incorrect Interface in logs)

    NAT
    2
    11
    722
    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.
    • B
      boulwarek
      last edited by boulwarek

      We have two ISP connections. WAN1 (Static /29 CIDR Block) and WAN2 (DHCP). We have port forwarding setup for an Exchange server using a Virtual IP address within the /29 CIDR block of WAN1. We also have Outbound NAT for this same Exchange server to always use that Virtual IP address.
      As soon as the WAN2 interface is turned on, port forwarding intermittently works. Some traffic gets through and some is blocked. Reviewing the Firewall Logs, the blocked traffic is showing as originating from the WAN2 interface, though it obviously came in on the WAN1 interface due to the destination IP address.
      We do also have NAT Reflection turned on if that is of any interest.
      What would make incoming traffic from WAN1 show as originating from WAN2 in the firewall logs?

      0_1543604342619_Interface LAN.png 0_1543604347550_Interface WAN1.png 0_1543604351457_Interface WAN2.png 0_1543604358564_Virtual IP Exchange Public.png 0_1543604365853_Port Forwards.png 0_1543604369060_Outbound NAT.png 0_1543604377527_Firewall Rules WAN1.png 0_1543604381032_Firewall Rules WAN2.png 0_1543604384018_Firewall Log.png

      1 Reply Last reply Reply Quote 0
      • DerelictD
        Derelict LAYER 8 Netgate
        last edited by Derelict

        Looks like your ISP is sending you traffic for 174.X.X.214 on WAN2 when it's up.

        Why is that?

        All of the blocks shown for WAN1 look like ports that have not been forwarded/passed and should be blocked.

        Should probably also show your switch configuration just to be sure that's all correct.

        Chattanooga, Tennessee, USA
        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
        Do Not Chat For Help! NO_WAN_EGRESS(TM)

        B 1 Reply Last reply Reply Quote 0
        • B
          boulwarek @Derelict
          last edited by boulwarek

          WAN2 was historically connected to a different router and served guest wireless on a completely separate physical network. In that configuration, we didn't see these issues.
          Also, when WAN2 is enabled, it doesn't block all traffic incoming to the 214 IP. Seems random. For instance, one of my cell phones connected fine, but the other one was blocked and stated WAN2 for the interface. Maybe this is something to do with active states before enabling WAN2, but I also cleared all states after enabling the interface and still had working devices.
          WAN2 is also on a completely different IP range. It seems like the rerouting of traffic is happening within the Netgate router, just not sure what is causing it. Attached are the switch configuration pages.
          0_1543689999336_SwitchVLANs.PNG 0_1543690003125_Switch Ports.PNG

          1 Reply Last reply Reply Quote 0
          • DerelictD
            Derelict LAYER 8 Netgate
            last edited by

            Traffic to that address should never be arriving on WAN2. That's the point.

            Is it the same ISP? Same subnet or something?

            Chattanooga, Tennessee, USA
            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
            Do Not Chat For Help! NO_WAN_EGRESS(TM)

            1 Reply Last reply Reply Quote 0
            • B
              boulwarek
              last edited by

              That's why I'm confused. Same ISP. Both enter through the same ONT, but are on completely different ip ranges. See screenshot below of WAN2 IP.0_1543690998938_WAN2 IP.PNG

              1 Reply Last reply Reply Quote 0
              • DerelictD
                Derelict LAYER 8 Netgate
                last edited by Derelict

                Like I said, you need to get with them to see why they are sending that traffic to the wrong WAN. Are you sure it's supposed to be two connections and not one with a routed subnet? Two WANs from one provider over one fiber doesn't make any sense to me from a redundancy point-of-view.

                Chattanooga, Tennessee, USA
                A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                Do Not Chat For Help! NO_WAN_EGRESS(TM)

                1 Reply Last reply Reply Quote 0
                • B
                  boulwarek
                  last edited by

                  Thank you for the reponses. I will get with the ISP and see if they can find any errors on their end.
                  While these do eventually terminate to the same ONT, they are two different services. Because we are in the middle of nowhere, we somehow ended up with their junction box, that would typically go outside, inside our server room. They serve our phones and internet from there. I am told these two services actually originate from different directions to our building. They are also billed as two completely different services as well.

                  1 Reply Last reply Reply Quote 0
                  • DerelictD
                    Derelict LAYER 8 Netgate
                    last edited by

                    OK

                    From what you have posted it looks like the traffic for that destination address is really arriving on ETH3. Not a lot the firewall can do about that.

                    Chattanooga, Tennessee, USA
                    A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                    DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                    Do Not Chat For Help! NO_WAN_EGRESS(TM)

                    1 Reply Last reply Reply Quote 0
                    • B
                      boulwarek
                      last edited by

                      I agree, just wanted to be sure there wasn't some goofy setting that would somehow re-route the traffic before it hit the firewall service and make it look like it originated from ETH3.

                      1 Reply Last reply Reply Quote 0
                      • B
                        boulwarek
                        last edited by

                        Looks like you may be onto something here. Performed a tracert using WAN1 to 8.8.8.8 and the first hop is using an IP in the same range as the WAN2 address. Both WAN1 and WAN2 use the same first hop. Very interesting. Will definitely be speaking with the ISP about this.0_1543695008174_Traceroute.png

                        1 Reply Last reply Reply Quote 0
                        • DerelictD
                          Derelict LAYER 8 Netgate
                          last edited by

                          You never know what IP address will respond to a traceroute. It could be sourced from any IP address on the router.

                          What matters is what interface traffic destined for your IP address arrives on.

                          Chattanooga, Tennessee, USA
                          A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                          DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                          Do Not Chat For Help! NO_WAN_EGRESS(TM)

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