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

    MultiWAN and 1 to 1 NAT Reflection

    Scheduled Pinned Locked Moved Routing and Multi WAN
    3 Posts 3 Posters 1.8k 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.
    • Y
      YoppConsult
      last edited by

      I've been searching the forums, but have not seen anything on this topic.

      I had everything working with 1 to 1 NAT reflection for a while.  Internal hosts were able to hit a 1 to 1 IP and reflect back properly to the correct internal host through pfSense.

      This broke when I set up Gateway Groups for load balancing/failover in a MultiWAN setup.  The 1 to 1 NAT ceased to reflect.  If I turned off the Gateway Group selection in my LAN firewall rules, it started working again.

      I was finally able to narrow this down and resolve the connection block.  I added a LAN firewall rule that passed traffic from a source of "LAN net" to a destination alias that contains the internal IP addresses of my hosts that use 1 to 1 NAT with no defined gateway.  It also worked with the more permissive "LAN net" to "LAN net" version of the same rule (e.g. just overriding the Gateway Group for LAN->LAN traffic).

      My first reason for writing this is that it may help someone else in similar situation who's 1 to 1 NAT configuration broke suddenly with the addition of a Gateway group to the "Default Allow LAN to any rule".

      I also have some follow-up questions:

      1)  Is the above LAN firewall rule the best way to go about handling this traffic?
      2)  Isn't the configuration of the reflection rules supposed to be automatic when "System->Advanced->Firewall/NAT->Enable NAT Reflection for 1:1 NAT" is checked?  If so, why does the addition of a Gateway group stop the traffic?

      I hope this helps someone, and I would appreciate any insight into the follow-ups.

      Sincerely,
      Michael

      1 Reply Last reply Reply Quote 0
      • P
        phil.davis
        last edited by

        1)  Is the above LAN firewall rule the best way to go about handling this traffic?
        2)  Isn't the configuration of the reflection rules supposed to be automatic when "System->Advanced->Firewall/NAT->Enable NAT Reflection for 1:1 NAT" is checked?  If so, why does the addition of a Gateway group stop the traffic?

        1. IMHO yes, there is not going to be any harm in allowing LANnet to LANnet, because anyway all the devices in LANnet can talk to each other directly on the LAN switch/es if they wish - in your case the traffic is only going through pfSense because of the tricky NAT reflection thing. The only security thing would be if you happened to have LANaddress webGUI… access lockdown requirements - then you would want some prior rules blocking destination LANaddress.
        2. The gateway group "policy routing" really forces the matching traffic to be shoved out the highest-tier active member/s of the gateway group. So the matching traffic misses the chance for any other fancy stuff or ordinary routing. But actually, I thought it might have pushed the traffic out to your ISP gateway, which would promptly send it straight back to, because the destination IP of the packets is your public IP - so it sounds like the changing of the destination IP (to implement NAT reflection) might happen i=still in this case, but the policy-route pushes the traffic out a WAN, which is not good/useful.

        As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
        If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

        1 Reply Last reply Reply Quote 0
        • I
          igpit
          last edited by

          i just wasted an hour after setting up gateway groups wondering why NAT reflection broke…

          i strongly suggest this side effect should be mentioned in the pfsense book - which i didnt find or overlooked.

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