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

    1:1 NAT Can't pass traffic

    Scheduled Pinned Locked Moved NAT
    5 Posts 3 Posters 658 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.
    • D
      dg
      last edited by dg

      I am new with pfSense and have a Checkpoint background so that mindset may be throwing me off.

      In a test environment (DMZ'd, main firewall handling security, no security wanted on the pfSense at this point) I am trying to set up 1:1 NATs. This is to simulate remote devices at customer sites that are behind extra NATs which have funky configs when being NAT'ed. The pfSense and Test-PC are VMware VMs. Once the current setup is done I might add another pfSense behind the current one to add another level of NATing.

      If I have a host on the pfSense LAN side without NAT config it can access hosts beyond the WAN subnet via the WAN IP. If I set up a 1:1 NAT the traffic stops.

      Network Diagram
      Network Diagram

      WAN Setup
      WAN Setup

      LAN Setup
      LAN Setup

      Floating Firewall Rules (Protocol is Any, not TCP) Pass all traffic both ways.
      Floating Firewall Rules

      WAN Firewall Rules (Protocol is Any, not TCP) Pass all traffic both ways.
      WAN Firewall Rules

      LAN Firewall Rules (Protocol is Any, not TCP) Pass all traffic both ways.
      LAN Firewall Rules

      1:1 NAT Rules
      1:1 NAT Rules

      Captive Portal
      Captive Portal

      DHCP is set for 192.168.169.111-119.

      My testing is:

      1. Pinging from the Test-PC to a desktop on the inside (172.20.32.101)
      2. Pinging from the Test-PC to 8.8.8.8
      3. Http to a web server inside the main network (172.20.10.10). that reports the IP the client is coming from.

      Testing Results:

      1. When Test-PC is set to DHCP it gets 192.168.169.111 and tests successfully. Web server reports 172.20.4.10 (WAN IP).
      2. When Test-PC is set to a LAN IP that is not part of DHCP nor 1:1 NAT (such as 192.168.169.201) it tests successfully. Web server reports 172.20.4.10 (WAN IP).
      3. When Test-PC is set to an IP that is listed under the 1:1 NATs all above tests fail. It can still ping the WAN IP (172.20.40.10)

      Since tests #1 and #2 pass all my setups in VMware and physical switching/firewalls appear to be correct. Does something else have to be configured so that the pfSense will handle the additional IPs on the WAN interface (ex: 172.20.40.200)?

      1 Reply Last reply Reply Quote 0
      • D
        dg
        last edited by

        As another test, I set Test-PC to 192.168.169.200 (a nat'ed address, so the tests weren't working). I then deleted the NAT for .200, hitting save/apply. Test-PC was still failing. Rebooted the pfSense and once that came back up my pings started working again without doing anything else.

        I've also disabled the Floating Rule, no change in test results, even with a reboot.

        1 Reply Last reply Reply Quote 0
        • KOMK
          KOM
          last edited by

          Yeah, your rules need some work. Floating rules are typically used for controlling QoS. Otherwise, you apply rules to the interface that the data enters. Rules for traffic coming from your LAN into the LAN interface should be put on the LAN tab. Also, you shouldn't have a WAN rule that allows all traffic. WAN should be locked down except for NATs.

          1 Reply Last reply Reply Quote 0
          • chpalmerC
            chpalmer
            last edited by

            You need to research Virtual Addresses. For each one of your port forwards you need a virtual address to match on your WAN.

            https://www.netgate.com/docs/pfsense/firewall/virtual-ip-address-feature-comparison.html?highlight=virtual

            Triggering snowflakes one by one..
            Intel(R) Core(TM) i5-4590T CPU @ 2.00GHz on an M400 WG box.

            1 Reply Last reply Reply Quote 0
            • D
              dg
              last edited by

              Thanks for the responses, problem solved!

              @KOM
              Thanks for the info on the Floating Rules. I hoped it could have been used to handle rules for both directions. As I mentioned in the second post it's been disabled.

              "Also, you shouldn't have a WAN rule that allows all traffic. WAN should be locked down except for NATs."
              Normally I fully agree and that's how our main firewall is set. For this case as I mentioned in the OP security isn't a concern on the pf initially because it is all behind our main firewall. The clock vendor's docs are short on reliable details. Priority is to get full functionality to the NAT'ed clocks then start locking it down.

              @chpalmer
              Virtual IP was the missing link. In the OP I mentioned a Checkpoint mindset might be throwing me off. In CP the Virt IP is made for you when the NAT is assigned. I added the virtual IPs and all tests work now. Thanks!

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