Why is NAT Reflection not a good thing?
-
jahonix,
I thought so too, but no one mentioned port forwards would work with the the LAN interface when WAN port forwards already exist. Some people on this forum seem hard fast in their own design principals than coming up with answers to special situations. Sometimes we need to look outside the box.Let me re-ask this way.
Can I also port forward LAN requests to specific IP's based on the port number by specifying the LAN as the interface and destination? These ports are all uncommon port numbers not used by anything else.
Thanks for your response. This question I think got way deeper than it should have. My fault, but it got me here to ask the right question.
-
Ok I am confused on what the actual goal is here.
So you have some server that sits on a network segment behind pfsense. Lets call it 192.168.2.100..
Now you access this via some fqdn on the public internet.. lets call it www.yourdomain.com which points to your public IP that sits on pfsense wan interface.
And you have some services running on the non standard http/https ports? So Im on the public internet I hit https://www.yourdomain.com:8888 for example.. You forward this to your server 192.168.2.100
You have a ssl cert on this box that is trusted by the public since it is signed by a public CA..
So now your question is how does a box on one of your other networks, lets say clientA at 192.168.1.45 wants to go to this box and name needs to match so you cert is trusted right??
Why do port forwards come into play?? Just create a host override in your dns that points www.yourdomain.com to 192.168.2.100, and allow your devices on lan to go to 192.168.2.100 on whatever ports they might be using. So your clientA just uses the same https://www.yourdomain.com:8888 url..
I am not seeing how this is a problem?? Or has anything to do with port forwarding, nat or or nat reflection, etc.
This box at 192.168.2.100 can serve up all kinds of different site on different ports 3000, 8080, 8443, etc.. that has nothing to do with its name. Its name would always be www.yourdomain.com or whatever other names you have certs for. Your url would just reflect the port ie https://www.yourdomain.com:8443 or :9999 etc..
-
johnpoz: Really simple what's the problem. He's trying to use one hostname for multiple services on multiple machines. It's like trying to use example.com for SMTP, WWW, FTP and god knows what. Just one level up (www.example.com). That obviously does not work well neither from WAN, nor from LAN.
-
Johnpoz,
On the public internet,
if someone requests https://www.yourdomain.com:9999 it goes to 192.168.20.2
if someone requests https://www.yourdomain.com:8888 it goes to 192.168.20.3
if someone requests https://www.yourdomain.com:7777 it goes to 192.168.20.4
Port forwards handle this via the public internet. Locally on the LAN all requests goto 192.168.20.2 regardless of the port number because port forwards only redirect the public internet and DNS controls the local resolution.This is why my question was, can I setup 2 LAN port forwards as well to direct these ports 8888 and 7777 to go to the correct IP?
All I need to know is will this work? If not then I will go back to NAT Reflection until my cert expires in December. I have no choice because I have one EV cert with one FQDN. I cannot use sub-domains at this time, SSL will fail on those.
-
No you cannot, because the traffic will never hit the firewall if it resolves to LAN IPs. Already explained. Multiple times.
-
Ok then NAT Reflection it is. Thanks.
-
well for starters using ports to get to different boxes is pretty much a borked work around. Sure you can do that if you only have 1 IP. But the better solution would be to use a reverse proxy if you are limited to 1 public IP. Better solution would be to get more public IPs ;)
And with dok if your hosting these services on other boxes, they should have different names. You could still point them to your single IP and use reverse proxy.
As to not wanting to spend money to get another cert with the different name.. Again your hack is not how you would do it in any real setup. Its a hack/work around to save what amounts to a few bucks in the big picture..
If I am not mistaken you can get EV certs for free from startssl
https://www.startssl.com/NewsDetails?date=20160330While seems like there is still the 200$ validation cost, you don't have to pay a fee for your other certs is the way I read it.
Others I show ev certs are $99 a year.. If what your running is a business then that is part of doing business.. If your not running a business then you sure and the hell do not need EV certs and could just go completely free route for all your different boxes, etc.
-
It is actually one server running different apps that bind to different ports. These are not web servers apps. They are encrypted storage apps each one serves a different purpose and binds to its own unique port but must connect using SSL via a URL.
I currently use Starfield for my certs, just renewed in December. I would have to pay $349 for a multiple domain cert. The budget does not allow for the additional expense. But I can build it in for next year. This is a non-profit business that has tight funding. The beginning of the year is the worse time to get funds. Reason for the EV cert is for HIPAA regulations.
That's why I wanted to know more about NAT Reflection. I care more about security than I do performance.
-
I have a local LAN interface on 192.168.1.0/24 and one server on OPT2 with a subnet of 192.168.20.0/24.
…
The server I want to locally forward to is NOT on the same subnet or switch as the local LAN interface.No you cannot, because the traffic will never hit the firewall if it resolves to LAN IPs.
…
You can use the same principle on LAN -> OPT as you already use on WAN -> OPT.
Just copy the port forwards and change the interface from WAN to LAN, maybe add rules as well.Don't know why we run circles around this challenge over and over again.
-
Same principle as in what exactly? Create another screwed hostname override for internal LAN, pointing to OPT? Yeah, makes a lot of "sense". Really better to stick with the NAT reflection clusterfuck.
-
Sorry, I want to understand the problem which I'm currently failing.
There's one DNS entry resolving www.example.com to 192.168.20.x and it's probably already there.
The rest is just NAT.
Except for that it's not elegant, what am I missing? -
AFAIK a reflection only goes back to the same subnet.
We segregate our server subnet off from our working LAN subnet here and reach it via NAT reflection just fine. If it is not supposed to work then it must be broke.
-
AFAIK a reflection only goes back to the same subnet.
We segregate our server subnet off from our working LAN subnet here and reach it via NAT reflection just fine. If it is not supposed to work then it must be broke.
I take that tongue in cheek. But it's working as designed. It goes to the same place as the external redirect goes.
-
"It is actually one server running different apps that bind to different ports."
"They are encrypted storage apps each one serves a different purpose and binds to its own unique port but must connect using SSL via a URL."But your forwarding them to different IPs on different segments.. So how is 1 server?
if its 1 box then it would have 1 name.. If this server only has 1 IP then all you need is a host override for the name your using.. If your using ports for the different applications - then 1 host override solves your problem with your cert.
Where is the requirement from HIPAA that it needs to be EV.. TLS sure - but EV is nothing more than marketing nonsense it has nothing to do with the actual security of the connection.
https://www.atlantic.net/blog/hipaa-compliant-hosting-requirements-checklist/
"Also, be aware that an EV certificate, creating a green address bar, and/or respected brand name such as Norton or GeoTrust, can help increase trust and credibility for your system."That is not a requirement.. Just a suggestion is all.. If your a non-profit and you spent $349 for a EV that was money wasted that is for sure.. Pretty sure the requirements for HIPAA and TLS sites is that you follow nist 800-52 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf
That for sure says nothing about having to use EV cert.. Did you follow that pub?? Did you modify what ciphers are presented, there is a specific list of what can be used to follow 800-52 Is ssl v3 even off?
If the page is not actually coming up in someone's browser, and some application that hits the url for storage - then the user doesn't even see the green EV cert nonsense..
-
HIPAA is not the only reason. The lawyers and hospitals that use this server demanded an EV certificate. Not up to me or you to challenge.
There are 3 IP's in the one server bound to one NIC. Each software program is bound to an IP running on the same server. And yes the box has one FQDN. The IP's must be different with each program because they communicate internally with each other via IP addresses within the same server. All three software programs must use the same FQDN, thus run on the same server. Each software program communicates internally via an IP and externally via an HTTPS URL. Internally they use IP's. Externally they use HTTPS URL's via a browser. Yes, sub domains with a multi-domain cert would have been the way to go initially, but that is not an option right now.
The cert works fine for external internet because of port forwards, just not locally because regardless of the port number, DNS host overrides always deliver to the same IP when it should be the IP that corresponds to the correct port. So the wrong software gets the request. I cannot use IP's in the URL because the cert would be invalid.
Shortly I am trying the LAN to OPT2 port forward and see if it works.
Remember, this system always runs flawlessly from an external internet connection. And did so locally with NAT Reflection. -
Tried the new port forward LAN rules and it did not work. Went back to NAT Reflection and all works fine now.
Thanks for all your help.
-
"The lawyers and hospitals that use this server demanded an EV certificate"
Sorry but I find that hard to believe they even know the difference between an DV and EV cert.. But sure ok those seem like the most technical kind of people that should demand IT standards ;) But sure they demanded something, and now your hacking it up to get it to work. Vs using different certs for different names??
" I cannot use IP's in the URL because the cert would be invalid."
Says who?? This is a simple SAN.. There is nothing saying that your cert can not be valid and GREEN via a IP.. Now your going to have a issue trying to do that with an EV cert and using any sort of rfc1918 address..
"All three software programs must use the same FQDN, thus run on the same server"
"The IP's must be different with each program because they communicate internally with each other via IP addresses within the same server."Yeah what software is this??? I am starting to guess that is not even setup correctly or optimal at all… Your saying its a requirement of the software that it use different IPs and they have to be the same box and use the same FQDN to access?? If you need to direct some software to a port via a name it would use a SRV record so you could do that. And it uses these IPs to talk to itself?? Huh?? Is this some home grown software??? Or an actual commercial product? So the user is actually calling up these 3 different urls in their browser so they can see this demanded by them EV cert??
-
NOYB said it best in another thread. I will stick with NAT Reflection since it works perfectly and so does the software.
-
dcol, your configuration is a bit unusual, which is probably why it confused all these kids telling you it was the wrong way to do it. But your reasoning is sound. I find it amazing that you presented them with some simple limitations like budget considerations and certification requirements that are out of your control and they just couldn't get why that should be important. Amazed but not surprised. I've been doing this for decades, in technologies they've never heard of, and it never ceases to amaze me when people with such a limited scope just can't understand there are things they don't know about. People that criticize your design without having the slightest idea about your problems are neophytes and should simply be ignored.
As to your configuration, I use NAT reflection right now and am looking for a way not to. In pfSense, I've had somewhat inexplicable problems with it at times and that the only reason. Given it's simple firewall/routing, it should not add any real overhead but pfSense does not appear to do it well.
That being said, why add work to the firewall that isn't necessary. I have a much larger network than yours and use the same port forwarding internally as externally. Copying your forwarding rules from WAN -> OPT to LAN -> OPT will work. As I said, that is what I do and it works great. Very little overhead, no need for a reverse proxy (what was that about?), and you simply need to have the same config on both interfaces. It really should work.
Let me know if you still need help.
-
"budget considerations and certification requirements"
Those too statements are contradictions. There is zero reason for a EV cert in the scenario as presented.. And they are not cheap.. So if you have budget constraints an unwarranted EV cert would should never have been even considered.
