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

  • 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

  • LAYER 8 Netgate

    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.

  • 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

  • LAYER 8 Netgate

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

    Is it the same ISP? Same subnet or something?

  • 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

  • LAYER 8 Netgate

    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.

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

  • LAYER 8 Netgate


    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.

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

  • Looks like you may be onto something here. Performed a tracert using WAN1 to 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

  • LAYER 8 Netgate

    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.

Log in to reply