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

    [SOLVED] NAT to another subnet

    Scheduled Pinned Locked Moved NAT
    7 Posts 2 Posters 4.0k 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.
    • G
      georgeman
      last edited by

      Hello!! I have setup the following config not too long ago:

      WAN1<–>pfSense1<------------------>pfSense2<-->WAN2
                       |                                          |
                     LAN1                                     LAN2

      LAN1 is 192.168.0.0/24
      LAN2 is 192.168.1.0/24

      Both pfSense boxes are linked via a dedicated interface (configured on 10.254.254.0/30, 1 IP for each)

      I have static routes added, so I can access LAN1 from LAN2 and viceversa (this works fine)

      What I need to do is to be able to port forward from WAN1 to LAN2 and from WAN2 to LAN1. I can't get it to work!! I thought that the static routes would be enough, but I am obviously missing something. Is there any specific setup needed? Both pfSenses are 2.0.

      Thanks a lot!!

      Cheers!

      If it ain't broke, you haven't tampered enough with it

      1 Reply Last reply Reply Quote 0
      • Cry HavokC
        Cry Havok
        last edited by

        Can you connect from LAN1 to LAN2, using the LAN2 IP address? Can you connect from LAN2 to LAN1, using the LAN1 IP address?

        1 Reply Last reply Reply Quote 0
        • G
          georgeman
          last edited by

          Yes to both. Both subnets are accesible from each other.

          Let me tell you I have just figured out part of the problem, but now I have another one.

          I hadn't selected a gateway on the interface properties for the "link" interface on each pfSense (I call "link" to the dedicated interface between pfSenses). After selecting the other pfSense as the gateway for each "link" interface, port forwading works… BUT!…

          I am also trying to configure a failover config with the two WANs. When both WANs are up, each LAN should route internet traffic through their "own" WAN. If any of the WANs goes down, all internet traffic from both LANs should be directed through the remaining active WAN.
          As monitor IPs I chose each WAN's default gateway, which responds to ping (both WANs are static IPs). I have also configured the appropriate gateway group, firewall rules for directing traffic into the group, and policy route negation (so LAN-to-LAN traffic gets always routed as per the system routing table).

          Now, if I select a "gateway" for the LINK interface (which I did and fixed the NAT issue), monitoring of the other gateway does not work, i.e. cannot monitor WAN1 DG from pfSense2 and cannot monitor WAN2 DG from pfSense1. It always shows offline. Also, pinging WAN2 DG from pfSense1 fails when the gateway in selected on the interface (and the same with the other one). So, failover is broken

          Selecting "None" as a gateway for the LINK interface on both pfSenses allows me to monitor the other WAN DG without problems, I am able to ping it, and failover works.

          At this point I really don't understand what the option to select a gateway for an interface really does. Would you give me some tips?

          Thanks again!!!

          If it ain't broke, you haven't tampered enough with it

          1 Reply Last reply Reply Quote 0
          • G
            georgeman
            last edited by

            Let me clarify something else. I assume both pfSense boxes will be always on. So monitoring the pfSense directly does not much sense for what I want. I want to be able to monitor the default gateway from WAN2 from pfSense1, and obviosly that monitoring traffic needs to be routed through pfSense2 and WAN2.

            If it ain't broke, you haven't tampered enough with it

            1 Reply Last reply Reply Quote 0
            • Cry HavokC
              Cry Havok
              last edited by

              Ah, so what you want is a combination of CARP (failover) and multi-WAN?

              1 Reply Last reply Reply Quote 0
              • G
                georgeman
                last edited by

                Not really. If I understand correctly, CARP involves hardware redundancy. In my scenario, if one of the pfSense boxes goes down itself, its whole subnet would left without access, and it is fine. What is critical is the internet access. I am trying to configure a Dual-WAN with failover (just two gateways with different tiers).

                Let me tell everybody I finally figured it out. My configuration involved NAT'ing from the LINK interface towards the other WAN. This rule was not added automatically. By adding an Outbound NAT rule from LINK to WAN on both pfSenses, failover works fine, and I can forward ports correctly as well! ;D

                Thanks a lot! I hope this becomes useful to somebody else some day ;)

                If it ain't broke, you haven't tampered enough with it

                1 Reply Last reply Reply Quote 0
                • G
                  georgeman
                  last edited by

                  For the record, let me explain why this happened (now that I think I understood it!)

                  In this case, by selecting a gateway on the LINK interface, it became a "WAN type" connection. As the hint says on the Outbound NAT page, "rules are not added automatically for WAN type connections". In this particular case, the LINK interface is actually both a WAN (when failover gets activated) and LAN (always). So a manual Outbound NAT rule is needed in order to allow translation between the WAN and the LINK subnet (for monitoring to work). I also had to delete the LAN to LINK outbound NAT rules as my config involves just routing over there.

                  Cheers!

                  If it ain't broke, you haven't tampered enough with it

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