Self-Hosting - Access Concerns

Interesting.

So that I understand this correctly:

WAN → ISP Router
AX89X → ISP Router
WebServer → ISP Router → PortFowarding 80/443

NAS → AX89X
Services → AX89X
Home Network → AX89X

Creating two different IP groupings, in your example .8 and .9

And this would have the effect of separating them out, so that the Webhosting server on .8 would not have access to the NAS on .9?

If that is correct, that would actually be really good solution for me - as it is half set up like that already…

In regards to WiFI the AX89X is the one serving the home currently as it is WiFi 6 and i have a couple of devices that are WiFi 6 - not turned off the ISP routers, but can do as I am not using it.

2 Likes

My diagram would be,

WAN - R.ISP -+- R.AX89X ---+- S.TrueNAS
             |             +- Device.A
             +- S.Ubuntu   +- Device.B
                           +- Device.…

Where the left side is outwards towards the internet (WAN), and the left side of each router (R._) entry is where it LAN ports or WiFi connects.

I think @MazeFrame and I are describing a similar idea, but I am assuming no new hardware, whereas I think the 🜨 symbols indicate dedicated switching boxes? or those may be routers, and the ↔ indicate new switches?

MazeFrame’s mention of management does bring up the fact the the outer LAN router (R.ISP) should have a good admin login password set, since the Ubuntu server (S.Ubuntu), being on its LAN ports, could access its admin login page.

Edit: my point about turning WiFi off on the ISP router (R.ISP) is to keep end user devices (Device._; ex: phone, laptop) from accidentally connecting to it via WiFi, where they would be exposed to the Ubuntu server (and also would be unable to reach your TrueNAS server, S.TrueNAS).

1 Like

Now that wasn’t how I was thinking about it…

WAN - R.ISP -+- R.AX89X ---+- S.TrueNAS
        |                  +- Device.A
        +----+- S.Ubuntu   +- Device.B
                           +- Device.…

This then creates two distinct networks, which would have distinct IP ranges. The R.AX89X would share 1 IP with the S.Ubuntu range - but I can simply block traffic from that IP on the R.AX89X - and the S.Ubuntu machine simply couldn’t access everything behind the R.AX89X.

Was that not what you meant?

In your diagram, what does it mean that the line comes off the bottom of the ISP router? Does it have three different types of ports?

My diagram was trying to distinguish ports where the router/device will accept an IP address on the left side, and ports where the router will assign its own IP addresses via DHCP on the right.

WAN - R.ISP -+- R.AX89X ---+- S.TrueNAS
             |             +- Device.A
             +- S.Ubuntu   +- Device.B
                           +- Device.…
             ↑             ↑
            …8._          …9._

As a reminder, for what I am describing, I am using addresses from my previous example:

In terms of hierarchy:

  • R.ISP
    • S.Ubuntu
    • R.AX89X
      • S.TrueNAS
      • everything else

Please be aware that my diagram is not some kind of standard,
I’m not a network engineer, or the network engineer’s son, but I’ll do the networking ‘til the network engineer comes.

I think our diagrams are the same . I think I saw the line from the AX going to the ISP - as including the Ubuntu on your diagram, so moved it back to make it clear that these two were not connected.

I thought I would post here, because I had an odd video come up on my timeline on youtube, going through a demonstration of using Cloudflare tunnels.

Which looks to be a way of doing this without a lot of the separation discussed above.

Just wondered if anyone had any thoughts on this?

So I got around to doing this today, and wanted to give my feedback.

Using these Cloudflare tunnels is pretty easy to set up - 80% of that video is other stuff, you might find it useful, but the actual set up of the tunnels is pretty straight forward if you are using docker, which you probably are if you are on this website - there is a nice trick he tells you about using -d to keep it running that is useful (I didn’t test to see if it would stop if I left the terminal)

In the video, he is asked for payment details - I am not sure why, I was asked no such question, but I can’t remember if I provided any when I signed up for cloudflare originally - I don’t think I did, but it has been awhile so can’t be sure - but in any case, I wasn’t asked to provide payment details - this may be a difference between Europe and the US, again not sure.

After doing this, I was able to close the ports that were open on my router for Nginx Proxy Manager (80, 443) - and my websites still work. Which I think is quite a benefit for a free service.

Oddly, another video from Networkchuck if you are more familiar with him: