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

    Problem with NAT port forward

    Scheduled Pinned Locked Moved NAT
    7 Posts 2 Posters 3.3k 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.
    • N
      nian
      last edited by

      I want to port forward from WAN to LAN. Seems simple … but I've tried various configurations and I don't know if it's something screwy with my network or what! Here's the setup:

      A. pfsense (WAN: 75.x.x.x, LAN: 10.16.0.2)
      ... of particular note: static route defined as 10.0.0.0/8 to gateway 10.16.0.1
      B. test server on same subnet (LAN: 10.16.0.3)
      C. destination server (LAN: 10.5.0.1)

      Basic setup:

      1. Open the firewall on WAN and LAN. Do this to log all traffic and remove firewall as a source of problem.
      2. Create a NAT rule on WAN (any interface)

      Tests:

      1. Edit the NAT rule on WAN (any interface) to forward port 22 to pfsense LAN
      ... it works!

      2. Edit the NAT rule on WAN (any interface) to forward port 22 to test server (B) on same subnet
      ... it fails! tcpdump on (B) shows no traffic at all

      3. Edit the NAT rule on WAN (any interface) to forward port 22 to destination server (C)
      ... it fails! tcpdump on (C) shows no traffic at all

      I've looked in the forums here and read that NAT is resolved before we hit the firewall. In all three test cases above, I see the firewall log an attempt from my IP to the NAT destination. As in test case (2) and (3) above, however, I don't see the traffic to hit it.

      So I think this is a routing problem, but at the same time, from pfsense I can ping both my test server (B) and my desired destination server (C). Is there something I'm missing? Thanks!

      1 Reply Last reply Reply Quote 0
      • GruensFroeschliG
        GruensFroeschli
        last edited by

        What exactly do you mean with static route defined as 10.0.0.0/8 to gateway 10.16.0.1?

        An how did you test that?
        The test server 10.16.0.3 is where?
        And where is the destination server 10.5.0.1 ?

        Directly connected on the same subnet?
        Then traffic would never go over the pfSense.

        We do what we must, because we can.

        Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

        1 Reply Last reply Reply Quote 0
        • N
          nian
          last edited by

          @GruensFroeschli:

          What exactly do you mean with static route defined as 10.0.0.0/8 to gateway 10.16.0.1?

          An how did you test that?
          The test server 10.16.0.3 is where?
          And where is the destination server 10.5.0.1 ?

          Directly connected on the same subnet?
          Then traffic would never go over the pfSense.

          This is the setup as defined by my hosting provider. As they provision servers for us, we may be on what looks like multiple subnets but really, we are our own VLAN. All of these servers have access to each other. Example: I can ping (or SSH, web, etc.) all of these internal IPs from each other (10.16.0.2 to 10.16.0.3, 10.16.0.2 to 10.5.0.1, 10.16.0.3 to 10.5.0.1, etc.). The static route that's defined on pfsense is the same static route that's defined on server (B) and server (C). That's just how the hosting provider does it.

          To answer specifically your follow-up: it's not something we test. test server (B) 10.16.0.3 might be in one server room, where destination server (C) 10.5.0.1 might be physically in another server room. But they're all connected together in the same VLAN.

          The traffic I'm trying to port forward comes in on the pfsense WAN and I want it to come out the pfsense LAN to my destination server (C). Since I can ping and connect (SSH) from my pfsense LAN to my destination server (C), I'm baffled as to why NAT port forward can't do it.

          1 Reply Last reply Reply Quote 0
          • GruensFroeschliG
            GruensFroeschli
            last edited by

            Ah now i see.

            Could it be something small, as that you've set the wrong subnet on the config-page on pfSense? (a /24 instead of a /8 ?)

            Can you verify that you have access from the pfSense to the server with a ping?
            (there is a ping in the diagnostics menu)
            Can you ping 10.16.0.1, as this seems to be the route to the rest of the (physical?) network?

            Can you verify (maybe with a tcpdump) that pings to your servers really go to 10.16.0.1?

            We do what we must, because we can.

            Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

            1 Reply Last reply Reply Quote 0
            • N
              nian
              last edited by

              @GruensFroeschli:

              Ah now i see.

              Could it be something small, as that you've set the wrong subnet on the config-page on pfSense? (a /24 instead of a /8 ?)

              Can you verify that you have access from the pfSense to the server with a ping?
              (there is a ping in the diagnostics menu)
              Can you ping 10.16.0.1, as this seems to be the route to the rest of the (physical?) network?

              Can you verify (maybe with a tcpdump) that pings to your servers really go to 10.16.0.1?

              Thanks for the suggestion! Checking all the small things … from the interface page, I've verified I have the correct network settings for this to work. My particular LAN interface is configured as 10.16.0.2/26, with a static route defined for 10.0.0.0/8. This is configured correctly, according to my hosting provider.

              I can also ping and better yet, connect via SSH from pfsense both to test server (B) and to destination server (C). I can also ping 10.16.0.1, the gateway, as the route to the rest of the network. I don't think I need to tcpdump during these tests.

              When I do attempt to access via the NAT the same thing (SSH to pfsense WAN) and have tcpdump running on destination server (C), I do not see ANY packets arrive. The NAT port forward is configured as above, in this case, and the firewall log shows the incoming packet. Since NAT resolves before firewall, I assume NAT is working, but that doesn't explain what happens after it leaves the firewall!

              Is there other data I can capture that would help, or another point I should be checking for this traffic?

              1 Reply Last reply Reply Quote 0
              • N
                nian
                last edited by

                New information!

                I'm getting in via a different network interface, and am able to run tcpdump both on pfsense (A) and on the destination server (C). I see packets leave the LAN IP of pfsense (10.16.0.2) but I don't see anything arrive on the LAN of my destination server (C, 10.5.0.1)

                So does it seem the routing rules of how NAT works is the culprit? Is there something in the OSI model that conflicts with my hosting provider's particular setup?

                1 Reply Last reply Reply Quote 0
                • GruensFroeschliG
                  GruensFroeschli
                  last edited by

                  Well to be honest i find it a bit strange that you have a subnet of 10.0.0.0/8 on your LAN, and at the same time traffic destined for 10.0.0.0/8 should be sent to a gateway.

                  To me this seems a bit conflicting.

                  I mean if something is in the same subnet than the interface itself this means you shouldnt have to send it to a gateway because it's directly reachable.

                  We do what we must, because we can.

                  Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

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