Forwarded ports on my WAN IP from my LAN/OPTx networks
-
Thanks Derelict!
LAN1 = 182.16.1.X/24
ServerA = 182.16.1.10:80
ServerB = 182.16.1.20:81
LAN2 = 182.16.2.X/24
WAN = 83.14.35.11/30WAN has a NAT rule to allow 83.14.35.11:80 to forward to 182.16.1.10:80, and another rule to allow 83.14.35.11:81 to forward to 182.16.1.20:81 - this works fine. My external domain name www.example.com routes to WAN address.
Prior to pfsense deployment, I could do www.example.com:80 and hit server A, and www.example.com:81 and hit server B - both internally (LAN1/2) and externally.
What I'm trying to avoid is having to define everything as ServerA.example.com, ServerB.example.com, etc.; there is sufficient information in the port number alone to make this work.
The bit I'm struggling with is getting LAN1/2 to route as if coming from the external side of the firewall.
-
182.16.1.0/24 is an allocated prefix for someone residing in Hong Kong, I don't think that's you?
-
@kpa:
182.16.1.0/24 is an allocated prefix for someone residing in Hong Kong, I don't think that's you?
You're right, it's not… it's an example range, which approximately mirrors my actual ranges.
A little added security through obscurity.If you can point me in the right direction for that range, I can easily remap that onto my network.
-
Disclosing the private RFC1918 addresses used on your LAN networks is totally harmless, an outside attacker gains no advantage from knowing them. There are officially allocated "example" ranges. First one is 192.0.2.0/24 and the other two are 198.51.100.0/24 and 203.0.113.0/24.
-
@kpa:
Disclosing the private RFC1918 addresses used on your LAN networks is totally harmless, an outside attacker gains no advantage from knowing them. There are officially allocated "example" ranges. First one is 192.0.2.0/24 and the other two are 198.51.100.0/24 and 203.0.113.0/24.
With all due respect, I would absolutely disagree. Say someone managed to get access to one of my machines remotely; knowing the IP ranges I use immediately narrows down the list of places they need to look for other servers. Granted it's not a massive risk, as the addresses are internal, but giving out internal addresses is unnecessary in this instance.
Please substitute 192.0.1 for 182.16.1, and 192.0.2 for 18.16.2, if that helps.
-
Anyone? I sort of need to make this work…
-
… managed to get access to one of my machines remotely; knowing the IP ranges I use ...
If I already conquered your network I have no problems looking around your broadcast domain to find further targets.
-
If you are already telling your users they need to go to :81 on the outside, split DNS will work the same from the inside.
Generally people run into problems with split DNS when they want a bunch of different addresses all listening on :80 to go to different ports on the inside like :80 to :8080, :80 to :8081, :80 to :8082, etc.
-
Dude if you don't want to post your rfc1918 space because your tin foil hat is squeezing the blood out your ears… then for gosh sake map it to some other rfc1918 space that your not using... Because to be honest posting up some public space that is not yours and showing that as being on your lan networks makes you look like an idiot.. No offense..
Im with Derelict, how exactly is split dns not your solution since you have stated that you don't like nat reflection.. You show your servers listening on different ports... While the one that is using the standard port can be gotten too with your typical url http://some.name.tld your other one on 81 can not, no matter what you do inside or outside you would have to attach that :81 to your url so http://someother.name.tld:81 so how exactly is split dns not work for you?
Oh
I could do www.example.com:80 and hit server A, and www.example.com:81 and hit server B - both internally (LAN1/2) and externally.
Why would you do that… Why don't you just use different names?? host1.example.com, host2.example.com run a reverse proxy and send them to the correct place on your rfc1918 space on same default port 80. Then internally resolve host1 and host2 to the respective rfc1918 IP.
Or if you don't want to use reverse proxy then use host1.example.com and host2.example.com:81
-
NAT reflection doesn't have a significant performance impact unless you're reflecting a huge number of connections. And if you had a consumer grade router that could handle it before, you definitely aren't.
-
But its still an abomination if you ask me ;) And be it a huge performance hit doesn't change the fact that its not optimal, why send traffic through or even to my firewall/router that is just going to a box sitting next to me on my own lan..
I can not think of a reason where someone would say, yeah nat reflection is the best way to do this.. I see it as a work around for bad design choices sure.
