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

    LAN Hosts can't access NAT Network

    Scheduled Pinned Locked Moved NAT
    8 Posts 2 Posters 3.4k 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.
    • X
      x-spirit
      last edited by

      I have a pfsense gw running 1.2.3-Release on FreeBSD 7.2-RELEASE-p5 i386.
      Got WAN: 212.x.y.174/30, LAN: 10.131.0.0/24 and LAN2: 192.168.0.0/24
      I have a public network - 212.x.y.8/29 with NAT to 212.x.y.174
      I have also placed 1:1 NAT from 212.x.y.12 -> 10.131.0.3 (internal IP of a server)
      When I try to access that server from LAN or LAN2 requests time out.

      What happens is: When I send a ping request from host 10.131.0.22 to 212.x.y.12 and dump the gateway wan interface i get

      
14:04:36.333806 IP 212.x.y.174 > 212.x.y.12: ICMP echo request, id 5284, seq 5, length 64
14:04:36.334149 IP 212.x.y.174 > 212.x.y.12: ICMP echo request, id 5284, seq 5, length 64
14:04:37.341762 IP 212.x.y.174 > 212.x.y.12: ICMP echo request, id 5284, seq 6, length 64
14:04:37.342084 IP 212.x.y.174 > 212.x.y.12: ICMP echo request, id 5284, seq 6, length 64

      at the same time I dump the lan interface of the server (10.131.0.3)

      
14:19:31.694047 IP 212.x.y.174 > 10.131.0.3: ICMP echo request, id 5284, seq 3, length 64
14:19:31.694114 IP 10.131.0.3 > 212.x.y.174: ICMP echo reply, id 5284, seq 3, length 64
14:19:32.702506 IP 212.x.y.174 > 10.131.0.3: ICMP echo request, id 5284, seq 4, length 64
14:19:32.702567 IP 10.131.0.3 > 212.x.y.174: ICMP echo reply, id 5284, seq 4, length 64
14:19:33.710687 IP 212.x.y.174 > 10.131.0.3: ICMP echo request, id 5284, seq 5, length 64
14:19:33.710750 IP 10.131.0.3 > 212.x.y.174: ICMP echo reply, id 5284, seq 5, length 64
14:19:34.718868 IP 212.x.y.174 > 10.131.0.3: ICMP echo request, id 5284, seq 6, length 64
14:19:34.718934 IP 10.131.0.3 > 212.x.y.174: ICMP echo reply, id 5284, seq 6, length 64

      and the dump on the LAN interface  gets the reply back from the server

      
14:16:02.322991 IP 212.x.y.174 > 10.131.0.3: ICMP echo request, id 23468, seq 253, length 64
14:16:02.324145 IP 10.131.0.3 > 212.x.y.174: ICMP echo reply, id 23468, seq 253, length 64
14:16:03.322953 IP 212.x.y.174 > 10.131.0.3: ICMP echo request, id 23468, seq 254, length 64
14:16:03.324874 IP 10.131.0.3 > 212.x.175.y: ICMP echo reply, id 23468, seq 254, length 64

      But then nothing gets send back to 10.131.0.22 and I can't find anything in the Firewall, that might cause that.

      X ISN'T EQUAL TO Y

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

        http://doc.pfsense.org/index.php/Why_can%27t_I_access_forwarded_ports_on_my_WAN_IP_from_my_LAN/OPTx_networks%3F

        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
        • X
          x-spirit
          last edited by

          @GruensFroeschli:

          http://doc.pfsense.org/index.php/Why_can%27t_I_access_forwarded_ports_on_my_WAN_IP_from_my_LAN/OPTx_networks%3F

          Method 1

          If you're using 1:1 NAT, you can't use NAT Reflection.

          Mathod 2 is non-usable, because I need direct IP access, not different resolve.

          Method 3

          If you have only a portion of your CIDR block behind pfSense, and you're using 1:1 NAT, you may have a difficult situation. Here's a possible approach you can consider. This may not work, or may work in only some situations.

          And I already tried it with aliases. The forwarding doesn't work with them anyhow.

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

            You "could" add normal portforwards for the ports you need on top of the 1:1 NAT to invoke reflection.
            However this only works of you just need a few ports and not whole ranges.

            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
            • X
              x-spirit
              last edited by

              @GruensFroeschli:

              You "could" add normal portforwards for the ports you need on top of the 1:1 NAT to invoke reflection.
              However this only works of you just need a few ports and not whole ranges.

              Port forward worked. It is however a temporary fix.

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

                Do you really need 1:1 NAT?
                I've made the experience that i never use 1:1 except in cases where i don't control the server.
                And even then… with normal portforwards you can "emulate" the same functionality than 1:1. (normal forward 1-65535, plus outbound rule for the NAT IP)

                Alternatively: since you have a few public IPs.
                You could put the server on it's own interface and bridge it to the WAN
                --> Have the public IP directly on the server itself.

                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
                • X
                  x-spirit
                  last edited by

                  @GruensFroeschli:

                  Do you really need 1:1 NAT?
                  I've made the experience that i never use 1:1 except in cases where i don't control the server.
                  And even then… with normal portforwards you can "emulate" the same functionality than 1:1. (normal forward 1-65535, plus outbound rule for the NAT IP)

                  Alternatively: since you have a few public IPs.
                  You could put the server on it's own interface and bridge it to the WAN
                  --> Have the public IP directly on the server itself.

                  I thought of that, but then I can't use my firewall and I must set a custom firewall on every server. The port forward seems the only solution, and, honestly, i think it will do :). It's just that we've got some lotus domino servers and they require a lot of ports open and i am too lazy to do it, so i chose the easy way :) 10x for the response.

                  P.S.(For anyone wondering what the problem was) NAT is only single-directional and when a internal host tries to access the public IP the packets get forwarded by the gateway to another internal host. The way back is not possible.

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

                    What do you mean that you then cannot use your firewall in such a case?
                    If you bridge two interfaces with pfSense still all firewall rules apply.
                    –> if you delete all rules allowing traffic to the server, no traffic will cross the bridge.

                    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.