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

    [SOLVED] NAT reflection not working for LAN clients

    Scheduled Pinned Locked Moved NAT
    13 Posts 4 Posters 4.7k 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.
    • M
      muswellhillbilly
      last edited by

      @captdragon: You're best off entering a local address for your local server in your internal DNS. It's simple, elegant and doesn't create the sorts of issues you can encounter using NAT reflection.

      1 Reply Last reply Reply Quote 0
      • C
        captdragon
        last edited by

        @muswellhillbilly:

        @captdragon: You're best off entering a local address for your local server in your internal DNS. It's simple, elegant and doesn't create the sorts of issues you can encounter using NAT reflection.

        @muswellhillbilly:

        You don't need your clients to NAT through to your internal server because your clients and your server all sit on your LAN. I don't see the point of this at all, unless there's some other part of your issue which you're not mentioning.

        Thanks for your comment. I suppose I could explain it further.

        I need to be able to configure my mobile applications to reach the same endpoint regardless if a user goes off Wireless LAN and starts using 4G External network. This way they don't have to reconfigure their application settings depending on where they are. Anytime, Anywhere, Anydevice is what I'm striving for.

        Here is an example of what I'm trying to achieve regardless of whether they are inside or outside the network:

        https://app1.mydomain.com(:443) –-> | pfSense |  ---> | Reverse Proxy | ---> http://VMServer1:8081
        https://app2.mydomain.com(:443) ---> | pfSense |  ---> | Reverse Proxy | ---> http://VMServer2:8082
        https://app3.mydomain.com(:443) ---> | pfSense |  ---> | Reverse Proxy | ---> http://VMServer3:8083

        etc.

        app1.mydomain.com and all the rest of my domains are registered with an external domain registry. I've also added them to my internal DNS resolver to point to VMServer1 so I can reach https://app1.mydomain.com from inside the network, but it does not go through pfSense and reverse proxy. it goes directly to my VMServer on 443 which is not hosting any web applications on that port.

        :o I'm pretty sure I just answered my own question. I think what I need to do is have my internal resolver point app1.mydomain.com to pfsense instead of my VMs so pfSense can do the NAT. I will test this out and report back.

        1 Reply Last reply Reply Quote 0
        • V
          viragomann
          last edited by

          Try "NAT reflection + proxy". But I've never tested it with port translation.

          1 Reply Last reply Reply Quote 0
          • M
            muswellhillbilly
            last edited by

            @captdragon:

            https://app1.mydomain.com(:443) –-> | pfSense |  ---> | Reverse Proxy | ---> http://VMServer1:8081
            https://app2.mydomain.com(:443) ---> | pfSense |  ---> | Reverse Proxy | ---> http://VMServer2:8082
            https://app3.mydomain.com(:443) ---> | pfSense |  ---> | Reverse Proxy | ---> http://VMServer3:8083

            Is this exactly what you're trying to do? Forward SSL traffic to non-SSL hosts?!!

            I'd change the port on the forwards to port 80 for starters. Then I'd put a redirect on each of the VMServers, having each listen also on port 80,  so that when you hit them they direct traffic to the relevant 808x port. That would mean your internal hosts would be able to access each server when inside the LAN. Your port forwards from the outside in would then only have to look like this:

            http://app1.mydomain.com(:80) –-> | pfSense |  ---> | Reverse Proxy | ---> http://VMServer1:8081
            http://app2.mydomain.com(:80) ---> | pfSense |  ---> | Reverse Proxy | ---> http://VMServer2:8082
            http://app3.mydomain.com(:80) ---> | pfSense |  ---> | Reverse Proxy | ---> http://VMServer3:8083

            This would mean your internal DNS would resolve app1.mydomain.com locally, for instance, the redirect would then take your internal clients to the correct connection (port 8081 in this case). Your external hosts would resolve app1.mydomain.com to the outside address which would just port forward to VMServer1:8081 directly.

            1 Reply Last reply Reply Quote 0
            • C
              captdragon
              last edited by

              @muswellhillbilly:

              Is this exactly what you're trying to do? Forward SSL traffic to non-SSL hosts?!!

              Yes it's called SSL offloading. But don't worry about that because my reverse proxy (pound) does that great. port 80 is not an option, it's also so last decade.

              I tried activating another interface (OPT1) on pfSense and resolving all my internal DNS aliases to OPT1 and setting up the NAT on OPT1 to forward 443 to POUND. WOW still nothing. When I ping my DNS aliases they ping as expected to opt1. For some reason when I go via my browser, on 443 it takes me directly to the VMServer and not through the NAT rule.

              1 Reply Last reply Reply Quote 0
              • C
                captdragon
                last edited by

                @viragomann:

                Try "NAT reflection + proxy". But I've never tested it with port translation.

                Tried that and it didn't work.  :-\

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

                  Think it's time to stop shotgunning and start troubleshooting.  Systematically look at each interface (packet capture) within the path to see what is or is not happening.

                  1 Reply Last reply Reply Quote 0
                  • M
                    muswellhillbilly
                    last edited by

                    @captdragon:

                    Yes it's called SSL offloading. But don't worry about that because my reverse proxy (pound) does that great. port 80 is not an option, it's also so last decade.

                    If the pages need to be secure and your proxy is handling the SSL traffic then that's fine. You can still do a redirect internally and a straight port-forward from outside. This really doesn't have to be as difficult as you seem to be making it. NAT reflection is a poor workaround, and I'm not the only one who thinks this. Among others the co-author of the official pfSense manual says so as well.

                    1 Reply Last reply Reply Quote 0
                    • C
                      captdragon
                      last edited by

                      @muswellhillbilly:

                      If the pages need to be secure and your proxy is handling the SSL traffic then that's fine. You can still do a redirect internally and a straight port-forward from outside. This really doesn't have to be as difficult as you seem to be making it. NAT reflection is a poor workaround, and I'm not the only one who thinks this. Among others the co-author of the official pfSense manual says so as well.

                      That's great, but I still need a solution. I'm not married to NAT reflection. My internal clients need to access the applications in the same way my external clients do.

                      Redirects only work for web applications on a browser.

                      1 Reply Last reply Reply Quote 0
                      • C
                        captdragon
                        last edited by

                        Okay, I believe i've resolved my problem but would like to hear feedback to see if this is an "acceptable" solution.

                        I created a Virtual IP on the  LAN interface and have all my internal app aliases (app1.mydomain.com, app2.mydomain.com, etc) resolve to this VIP. Then I'm setting the same NAT rule on that VIP as I have on the WAN which forwards 443 onto POUND (Reverse Proxy).

                        ;D

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