[SOLVED] NAT reflection not working for LAN clients

captdragon

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)

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.

NOYB

@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

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.

captdragon

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

viragomann

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

muswellhillbilly

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

captdragon

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

captdragon

@viragomann:

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

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

NOYB

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.

muswellhillbilly

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

captdragon

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

captdragon

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