Why is NAT Reflection not a good thing?
-
A nice flatly laid out example, thank you. Then I can just use the correct subdomain in the host override. I can do that, just means I will have to buy more EV certs. Didn't want to go through that expense.
-
A nice flatly laid out example, thank you. Then I can just use the correct subdomain in the host override. I can do that, just means I will have to buy more EV certs. Didn't want to go through that expense.
And why would you when there is a viable solution already? If it works and serves your purpose and needs then it is not broke. As with most things there is more than one way to accomplish something. Some are better than others in one way or another but also may have other undesirable liabilities. Like cost. Sometimes the "better" way is overkill for the situation/environment etc. There are considerations that make NAT reflection the "better" solution for situations. "Hair pinning" is not a significant concern, and performance is not a significant requirement, in some cases. And NAT reflection works just fine. Labeling it a "hack" is just emotional response that doesn't really matter.
Design your infrastructure to meet your needs/requirements. That includes cost and practicality for what it needs to support, etc. Split DNS and NAT reflection are both viable designs. Use them as needed to meet your needs.
https://forum.pfsense.org/index.php?topic=122088.msg674603#msg674603
-
Thanks, I think I will go back to NAT Reflection instead of spending money on multiple EV Certificates. A shame I can't get a wildcard EV cert.
-
A nice flatly laid out example, thank you. Then I can just use the correct subdomain in the host override. I can do that, just means I will have to buy more EV certs. Didn't want to go through that expense.
Thanks, I think I will go back to NAT Reflection instead of spending money on multiple EV Certificates. A shame I can't get a wildcard EV cert.
If SAN (Subject Alterative Names) will work for you instead of a wildcard, that may be an option for your EV cert.
-
I think I will go back to NAT Reflection
Pardon my ignorance, we already learned that your servers are on a different subnet than your LAN.
It isn't NAT reflections then but simple port forwards, is it?
AFAIK a reflection only goes back to the same subnet. -
Yeah, looked into the SAN EV but the cost is even higher. That is the best solution but I previously disregarded it because of the expense. Wanted to see if there was something I could do within PFsense. That answer seems to be stay with NAT Reflection until December when the EV cert expires then get the multi-domain SAN cert
-
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..
