• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
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.
  • C
    captdragon
    last edited by Apr 20, 2016, 6:05 PM Apr 17, 2016, 10:01 PM

    I'm hoping someone can help me with what I'm trying to achieve. This is my basic setup:

    |
            WAN | ISP Network
                |
          .–--+------x.x.x.x--------.
          |  pfSense                  |
          '-----+---'192.168.1.1'--'
                |
            LAN | 192.168.1.0/24
                |
          .----+-----------.
          | LAN-Switch |
          '----+-----------'
                |
        ...-----+------... (Clients/Servers)

    I have a NAT rule that works perfectly from outside my network:
    WAN TCP * * WAN address 443 (HTTPS) pound 443 (HTTPS) pass through to pound

    Basically it forwards all my HTTPS port to another server on my network.

    Naturally this is ignored for my internal clients. However, reading the pfSense documentation, i'm lead to believe that enableing NAT reflection, the NAT rule would also apply to my internal clients. But this isn't working. Not sure if it's because NAT reflection isn't configured correctly or my clients are never reaching pfSense because they are able to find each other by way of my common switch.

    What is likely going on? And how would be a good way to force my clients on my switch to go through pfSense so that the NAT rule applies to them?

    I tried adding the same rule to the LAN interface on pfSense, but I get the same results. I think my switch is passing  traffic without going through pfSense.
    LAN TCP * * LAN address 443 (HTTPS) pound 443 (HTTPS)

    1 Reply Last reply Reply Quote 0
    • M
      muswellhillbilly
      last edited by Apr 18, 2016, 8:35 AM

      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.

      1 Reply Last reply Reply Quote 0
      • N
        NOYB
        last edited by Apr 18, 2016, 9:16 AM

        @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.

        https://en.wikipedia.org/wiki/Network_address_translation#NAT_loopback

        1 Reply Last reply Reply Quote 0
        • M
          muswellhillbilly
          last edited by Apr 18, 2016, 11:36 AM

          @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 Apr 18, 2016, 4:51 PM

            @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 Apr 18, 2016, 8:47 PM

              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 Apr 19, 2016, 10:41 AM Apr 19, 2016, 7:44 AM

                @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 Apr 20, 2016, 12:42 AM

                  @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 Apr 20, 2016, 1:10 AM

                    @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 Apr 20, 2016, 1:40 AM

                      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 Apr 20, 2016, 7:56 AM

                        @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 Apr 20, 2016, 6:29 PM Apr 20, 2016, 3:41 PM

                          @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 Apr 20, 2016, 6:09 PM Apr 20, 2016, 6:05 PM

                            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
                            1 out of 13
                            • First post
                              1/13
                              Last post
                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                              This community forum collects and processes your personal information.
                              consent.not_received