OPNsense Forum

English Forums => General Discussion => Topic started by: 4fred on December 12, 2023, 11:21:11 pm

Title: double nat design considerations?
Post by: 4fred on December 12, 2023, 11:21:11 pm
So today at home I have one network running on the router supplied by my ISP. The only thing I have done is add a pi hole dns and that's it. The family runs lots of stuff on the network and I kind of do not trust it. Vacuum cleaner, phones and tablets, streaming boxes TV's and all kinds of trinkets. And if you EVER do something to make that network go down, well I guess you know what happens...
So my thought is to make another network inside this one where I run my stuff and can play how ever much I like. Maybe gradually move devices (that I trust) to my network and leave ISP's network just for streaming devices and things I do not trust. If I'm sucessful maybe also replace the pi-hole with opnsense's unbound DNS. So I would have access from the new network to the internet trough my ISP's supplied network and also maybe grant some access to some things on "my" network.

So I would run a opnsense and behind that connect my devices to the newly built network. I've read up some on double nat and from what I understand it would work as long as you do not "Block private networks". Are there any more considerations I should be aware of?

The network supplied by my isp's router is 192.168.1.0/24 and I'd prefer not to change that.
So I was thinking of attaching WAN to this network and a new LAN inside of it, maybe 192.168.3.0/24?
Is this a good or a bad idea... ?
Not a network engineer but I'm trying to learn.
Title: Re: double nat design considerations?
Post by: passeri on December 13, 2023, 12:28:11 am
Are you providing services you can access from the internet? If not, double-nat is not a consideration. You may need single NAT depending on what internal services you offer or access, but most access tends to be outward.

Double NAT adds latency and possible extra maintenance work. In a fairly stable home network with current hardware this is no big deal.
Title: Re: double nat design considerations?
Post by: netnut on December 13, 2023, 01:25:59 am
Have you checked (and double checked) if you can configure a static route in your CPE. A FritzBox for instance allows you to add such route, pointing a static route from your CPE towards your OPNsense box will eliminate any NAT requirements on OPNsense and so "Double NAT".

If your ISP locked down the complete CPE there isn't much choice unfortunately...
Title: Re: double nat design considerations?
Post by: 4fred on December 13, 2023, 12:59:41 pm
I do not publish anything to the internet from my home. If the need comes up I can go with a cloudflare application tunnel or something creative like that.

I can somewhat change network stuff but not a lot :( DHCP range and DNS server and just some very basic things.

So setting up an opnsense with wan/lan leaving wan on dhcp and setting lan to 192.168.3.0/24 would work just fine?
Title: Re: double nat design considerations?
Post by: netnut on December 13, 2023, 02:07:51 pm
So setting up an opnsense with wan/lan leaving wan on dhcp and setting lan to 192.168.3.0/24 would work just fine?

Yes, just to be sure to UNCHECK the Block Private Networks on the WAN interface (which you normally leave checked).
Title: Re: double nat design considerations?
Post by: 4fred on December 14, 2023, 12:28:45 pm
Thanks!
I'll give it a go and let's see if/how it works.
Title: Re: double nat design considerations?
Post by: 4fred on December 17, 2023, 04:35:28 pm
There is something funny.
I set up opnsense with wan/lan, did just some basic stuff and like dns/dhcp range and set lan ip to 192.168.3.1 and the dhcp network just followed automatically.
In settings changed the webport to 5858 and disabled redirection.
Behind the FW I set up two clients and everything worked as expected. Access stuff on the internetz and access to resources on the other LAN (192.168.1.0/24) worked as expected.

Now to the problem.
My plan is to move some stuff from the old lan (192.168.1.0/24) to the new lan (192.168.3.0/24), like my NAS and some other things. These things are used by devices that will still be on the old lan, TV's tablets and things. So to test that this would work I setup a webserver on one of the clients on the new lan and tried to open the port between the two and that does not work. If I test the webserver from the client that are on the same network it works but if I try from the old lan that must go trough opnsense that does not work.
Firewall/NAT/Port forward.
Interface: WAN
TCP Version: IPv4
Protocol: TCP
Source: (didn't change anything so any/any)
Destination: WAN Address
Destination port range from to: HTTP/HTTP
Redirect target IP: Single host or network, IP of the webserver: 192.168.3.101
Redirect target port: HTTP
Enabled logging and let it allow the filter rule by itself, also tested to manually create FW rule but no diffarance).
Basically just save and test, no dice.

I figured that this may be a problem with HTTP so I tried to allow RDP access trought the FW but that dont work.
I went in to logging live view and entered: dst contain: 192.168.3.101 up comes the green and nice things saying opnsense allowing the traffic and nothing is blocked, still it does not work.
So... routing?

Something is "funny" and I dont really know where to beging to look for what's wrong.
Anyone?
Title: Re: double nat design considerations?
Post by: passeri on December 17, 2023, 09:49:25 pm
You speak of opening a port between local networks then create a port forwarding rule from the WAN?

For local access you need PASS a rule IN to the interface of the source network with destination target interface network.

As it is you are setting up external access. That is a separate thing.
Title: Re: double nat design considerations?
Post by: 4fred on December 17, 2023, 11:43:05 pm
I did the setup with wan/lan, so two nics.
One is considered WAN the other is LAN.
So how is this not considered allowing an external network when it's coming from the wan interface?

Please explain cuz I do not understand.
And could you please explain how to do it?
Title: Re: double nat design considerations?
Post by: passeri on December 18, 2023, 02:00:01 am
If you have a basic Opnsense setup, then you should now be able to access the actual WAN (through the ISP router) from devices on its LAN side. Have you tested this yet?

If you have a basic Opnsense setup, then you should not be able to access the devices on its LAN side from anything on the WAN side of Opnsense. Have you tested this yet?

If either test fails, then there is likely to be a problem, that you do not have a default Opnsense setup or else you have a block elsewhere.

It is not necessary, in fact undesirable, to switch off blocking of local networks on the WAN side of Opnsense if the whole idea is to block untrusted devices elsewhere under your ISP router.

Since I have no diagram, I am working on my understanding of your verbal description of your layout and intended results.
Title: Re: double nat design considerations?
Post by: 4fred on December 18, 2023, 03:35:18 pm
192.168.1.10 --> 192.168.3.101 on port 80 does not work.
192.168.3.101 --> 192.168.1.10 on port 80 do work.


From my ISP I got a router. This router is mostly locked for me and I cannot do much with it. It gets a DHCP address on its WAN and it shares out DHCP addresses on its LAN. Family uses this and connects EVERYTHING to it. If I touch this network and breaks it my life is over and done, the rest of the house would turn me into pancakes dough.
Let's call this ISP-LAN and it uses 192.168.1.0/24 and all addresses is handed-out by ISP router and it sits on 192.168.1.1.

Onto opnsense.
I take a box and attach a switch to it's LAN port. I attach two PCs to it. On the box I install opnsense using yes-next-finish type installation. WAN is NOT! connected during install. I then change opnsense LAN IP to 192.168.3.1 and reboot it. Now the two connected PCs gets DHCP addresses from opnsense and they are on the 192.168.3.0/24 network. I UNCHECK the Block Private Networks on the WAN interface, all good everything works but not connection anywhere. I can from the two PCs talk to opnsense and they can talk to it, nice.
Now I connect the opnsensebox WAN port to the ISPs router on the LAN port, and opnsense now get's a WAN-IP on the 192.168.0.1/24 network and have internet access, the two connected PCs also get internet access, all good.

Now the problem:
192.168.3.101 --> 192.168.1.10 on port 80 do work.
192.168.1.10 --> 192.168.3.101 on port 80 does not work.
FROM the ISP-LAN I cannot access anything on the opnsense LAN, 192.168.3.0/24.
FROM the opnsense LAN, 192.168.3.0/24 I can access everything on the ISP-LAN, 192.168.1.0/24.

Let's say I wanna move a webserver from ISP-LAN 192.168.1.0/24 to the opnsense LAN 192.168.3.0/24 - what do I have to do?
Title: Re: double nat design considerations?
Post by: passeri on December 18, 2023, 11:53:56 pm
192.168.3.101 --> 192.168.1.10 on port 80 do work.
192.168.1.10 --> 192.168.3.101 on port 80 does not work.
FROM the ISP-LAN I cannot access anything on the opnsense LAN, 192.168.3.0/24.
FROM the opnsense LAN, 192.168.3.0/24 I can access everything on the ISP-LAN, 192.168.1.0/24.
You called it a problem? The above is exactly expected behaviour. WAN side of Opnsense (192.168.1.x) blocks incoming traffic but anything can get out from behind it (192.168.3.x). Your work to this point is complete, or else your aim was not as has been understood.

Now, the question:
Quote
Let's say I wanna move a webserver from ISP-LAN 192.168.1.0/24 to the opnsense LAN 192.168.3.0/24 - what do I have to do?
Assuming a standard web server, these steps:
1. Install the web server and ensure it has a stable IP address in the 192.168.3.x range.
2. Add to Opnsense a Firewall NAT rule for port 80 IN to the WAN address, redirect to port 80 at the web server's IP address.
3. Test.

As a comment, if your aim is to protect family devices from experimental devices, then the proper place for your internal firewall is in front of the family devices, not the lab/server. What you are currently doing is testing to avoid later pancake risk, not protecting important things yet. That would also simplify things in that your configuration could stop where it is, no NAT needed (nor allowing local networks).
Title: Re: double nat design considerations?
Post by: 4fred on December 19, 2023, 09:40:47 pm
"Yes I called it a problem" ...
In #6 in this thread I described what I had done to try to open the port just like you describe for me how to do and it does not work. I know that opnsense by default blocks everything from WAN, that is why I'm setting it up.

Step one is to protecte/remove the things -I- care about protecting from the family's stuff. Not just buy anything and walk over to the router and connect to network. Cheap trinkets made in wherever probably crap leaking god knows what... THESE are the "experimental devices".
Title: Re: double nat design considerations?
Post by: passeri on December 19, 2023, 10:11:46 pm
Would you mind showing a screenshot of your NAT rule, rather than a description?
Title: Re: double nat design considerations?
Post by: 4fred on December 19, 2023, 10:20:25 pm
Here ya go
Title: Re: double nat design considerations?
Post by: passeri on December 20, 2023, 12:14:31 am
Thank you. I take it that "Add associated rule" is on at the bottom, out of shot.

However, before continuing with any tracing, I am sorry that I am still puzzled by this statement which, however well understood by you, remains a little ambiguous for me.
Step one is to protecte/remove the things -I- care about protecting from the family's stuff. Not just buy anything and walk over to the router and connect to network. Cheap trinkets made in wherever probably crap leaking god knows what... THESE are the "experimental devices".

Is it your primary aim that experimental devices have no access to family devices, in case of buggy, dangerous or malicious code on experimental devices in the lab?

Our present route is the opposite, that family devices are unprotected internally, while family devices are to be given limited access to a web server among the experimental. Is this the correct route?
Title: Re: double nat design considerations?
Post by: 4fred on December 20, 2023, 02:20:34 pm
"Add associated rule" - I tried with and witout it (creating rule manually), no matter - still no dice.
Is the NAT rule correctly created?
To be very clear. What I'm doing now is just a TEST. I picked port 80 and a website cuz it's simple to test.

The much much longer plan is something like this and probably is subject to change.
What I have now is a problem. Walking trough the place looking at all kinds of shit I do not trust. A chinese made vacuumcleaner. Internet connected lights I have no idea where they are made. Some tablets made god knows where runnig god knows what. And these are just a few of the things - and yes, all this shit really need to work. They cast they share links and they do what they do.. not just "them" also wife and extended family.
So to keep the "shit" running and connected while I do something like this.
Let's call shit ISP-LAN, the only LAN I have now.
Move one step back from ISP-LAN and firewall a new LAN. Place what I want to protect from ISP-LAN here and make it accessable (if needed). How I publish things between the networks I'm not certain of yet, maybe NGINX or something like that - no matter HOW, I will need to open ports, and that is the only question I have right now - and I cannot get that to work.

In the the longer term probably give opnsense more legs and capabilities. WiFi, Guest Network, multiple LANs, device isolation? VPN, Proxy, filtering? And so on. And move device after device to make sure they work as expected to keep ppl from pancaing me while I'm doing it. What then is left of ISP-LAN is just IOT shit that everyone can access but it cannot access anything but other IOT shit - if I do not isolate these in another way... if...

So. What I have is a bad situation, most ppl probably have this and dont care, sadly I do and I really have no idea how I ended up here...


Title: Re: double nat design considerations?
Post by: passeri on December 20, 2023, 11:47:01 pm
Thanks, I did not see an error in the NAT rule so we need to test it. In 'Firewall->NAT->Port Forward' it should look like this:
Code: [Select]
<-->   WAN   TCP   *   *   WAN adress   80 (HTTP)   192.168.1.10   80 (HTTP)
Regarding your aim, we are on the correct route. I see what you are setting out to do. My own network is configured into multiple zones including one for an internet-facing server and one for a completely locked down NVR (I call that zone Prison) accessible only from a management zone directly or by VPN. The NVR runs off an internal router with NAT for access from the Management zone, a separate function from NAT on the perimeter to the server. So, while I have edge NAT and internal NAT, I do not have double NAT; nor do you at present.

Your need is not complex (despite our hitting two pages). This is something I have done without difficulty despite not being a network expert, so let us continue and I will call out to actual experts if I hit a wall. I read that the Opnsense WAN address, by DHCP from your ISP router, is 192.168.1.10 (if it is not, we are doing the wrong tests).

Depending on what tools you have to hand, please run from an ISP-zone PC either one of the following commands?
Code: [Select]
nc -vz 192.168.1.10 80 or
Code: [Select]
nmap -Pn -p80 192.168.1.10We are simply testing whether the port is open at the Opnsense address. Ping does not cut it here.

For surety, please also verify that all sub-nets are set to /24, or 255.55.255.0. This is to exclude one potential routing error.