Network standalone / firewall / router mode

[danmons]

I'm beginning to put some code together to build a "standalone" or "firewall" mode RetroNAS setup. The design goal is the following:

The RetroNAS device itself can be configured in one of two ways:

1. With two interfaces, one that we deem "the modern interface", the other we deem "the retro interface". The name indicates which side of the network that interface lives on (modern for your new computers and systems, retro for all your old computers/consoles). I'm calling this "router mode" for now.

2. With one interface where the RetroNAS will plug directly in to an old system with no upstream service. I'm calling this "standalone mode" for now.

From here, I'll load up a couple of services. For now I'm going with:

• ISC-DHCP for DHCP serving. I'm choosing this over dnsmasq as the latter has severe limitations for future ideas we want to implement (PXE and/or network booting of a large variety of old computers, consoles, arcade systems, etc).

• dnsmasq for DNS forwarding only. We won't be using the TFTP portion (we have that already in RetroNAS), nor the DHCP portion (as it's too limited, so we'll go with ISC-DHCP). It will purely for be forwarding the DNS provided to RetroNAS's "modern interface" and providing DNS services back down to the "retro interface" network. I am 100% against just pushing 8.8.8.8 to systems like so many other projects do, as that's terrible practice to force Google DNS on users without them knowing about it. Whatever DNS a user chooses for their household network, RetroNAS will obey and use via DHCP on the "modern interface" (alternatively, the user can configure upstream DNS manually if they wish).

• firewalld - this will configure the basic portions we need depending on (1 - router) or (2 - standalone) modes, such as

  • IP Masquerading for Internet access for retro systems
  • Firewalling 1: preventing retro systems seeing modern systems and vice versa, but allowing retro systems to see the internet (user can optionally configure WebOne for retro proxying. I may add in Squid separately for a more modern proxy option)
  • Firewalling 2: Allowing modern and retro systems to see RetroNAS itself, but not across RetroNAS into the other network, providing some layer of security for people worried about old and new systems communicating without their knowledge.

The configuration page should be fairly simple:

• Simple chooser menu to set which is the "modern interface", which is the "retro interface"
• A "retro interface" is mandatory, a "modern interface" is optional (without it, we default to "standalone mode")
• Interfaces themselves can be configured via Cockpit, raspi-config, etc. I won't be creating yet another tool to set an interface IP address or dhcp client details when several exist already.

In 99% of cases I envisage one the following use cases for people wanting this specific feature:

1. User has a home WiFi network, but requires RetroNAS to be wired in for latency/bandwidth reasons (OPL2/ps3netsrv/MiSTer/EtherDFS/etc all are better off wired than wireless). RetroNAS can then talk to the modern network over WiFi using that as the administrative interface, and connect in to the retro network via wired interface. This also helps if users don't have Ethernet cables into their gaming areas (a common feedback item I hear from users).

2. Users have a completely standalone retro network. Maybe they're travelling with a MiSTer device, maybe they just want a small RPi device tucked in behind their PS2 and direct-connects via a single Ethernet cable with no switch but is able to serve DHCP to the PS2, etc.

On top of all of this, I need to include a way to disable this. Should the user make a mistake in the configuration, there needs to be a way to undo the firewalling and set the device back to normal mode. This will likely just be an "undo" menu item for RetroNAS that turns off dhcpd and sets firewalld to an allow-all mode.

I'm not sure what to call this in the menus. "Router mode" might make the most sense to people intuitively? Or as per the subject of this discussion with "Network router/firewall/standalone mode" or something?

Discussion is open for further ideas, design criticisms, or any other commentary.

[danmons]

Optionally, I could put in an optional "paranoid" mode too. This would only allow the "modern network" to access the RetroNAS device on SSH/SFTP (TCP/22), Cockpit TLS (TCP9090) and SMB2 (TCP/445 only, no TCP/UDP 135-139 for SMB1/NetBIOS/NMB/WINS/RPC), with all other services denied (makes it difficult to test things from the modern network, but keeps people happy who are insisting that Linux-served SMB1 on their home network will cause planet-ending events, while they all continue to happily use plain-text FTP anyway).

This could be a simple third option in the configuration page (where the retro/modern interfaces are specced. Just a yes/no item for "paranoid mode").

[sairuk]

We should consider approaching this with some kind of yaml config that has the retronas defaults/suggested and a local.d config for users to override to their requirements, then gen the actual service configs from that

[HylianPeasant]

For those who are using Retronas in a VM : say we assign two network adapters to the VM to match the idea of a retro interface and a modern interface.
Would your scripting be compatible with this kind of usage ? Would we be able to say "this interface is the modern one" and "this interface is the retro one" even in the case of two vNIC ?

Reading the use case, it seems the main idea is focused on the use of a RPI where the WLAN is the modern interface and the LAN is the retro interface.
I reckon the support for VMs is less relevant for this kind of retro/modern interface stuff (since there is already a lot of ways to achieve isolation of Retronas with virtualization and networking) but it would be nice if this was flexible enough to support that kind of scenario.

Another thing : I like the idea of a dedicated DHCP server for the retro devices.
For my personal scenario, this would allow me to disable on my router the DHCP scope for my retro devices connected inside my retro dedicated LAN and thus cutting another tie that those legacy stuff could have into my today stuff.

[danmons]

For those who are using Retronas in a VM : say we assign two network adapters to the VM to match the idea of a retro interface and a modern interface. Would your scripting be compatible with this kind of usage ? Would we be able to say "this interface is the modern one" and "this interface is the retro one" even in the case of two vNIC ?

Reading the use case, it seems the main idea is focused on the use of a RPI where the WLAN is the modern interface and the LAN is the retro interface. I reckon the support for VMs is less relevant for this kind of retro/modern interface stuff (since there is already a lot of ways to achieve isolation of Retronas with virtualization and networking) but it would be nice if this was flexible enough to support that kind of scenario.

Any two-interface setup could work, physical or virtual. RPi is used as an example (mostly because I hear this a lot - people often don't have wired Ethernet in their houses, and want the Pi to bridged WiFi to Wired safely). But a VM with two interfaces works just as well, assuming you've configured things correctly for your networking (e.g.: you're either using multiple physical wired connections out of your VM host, or you've set up VLANs or some other software defined network split with virtual interfaces inside the RetroNAS VM to match).

Another thing : I like the idea of a dedicated DHCP server for the retro devices. For my personal scenario, this would allow me to disable on my router the DHCP scope for my retro devices connected inside my retro dedicated LAN and thus cutting another tie that those legacy stuff could have into my today stuff.

That's definitely part of the goal - proper isolation between "modern" and "retro" portions of a home network. Much of the feedback from RetroNAS in the early days was that people setting it up have security concerns about network-enabling legacy devices and old protocols. This should assist with that by offering a line of demarcation between the two types of devices.

[sairuk]

We are currently looking into this into the firewalld branch, i have a working setup on an rpi that I am slowly replicating into this branch with a mind to make it flexible. Primary target will be rpi initially

my current setup includes

• a retro (eth0/wlan1 2.4GHz ap) firewalld zone
• a modern (wlan0 5GHz infrastructure) firewalld zone
• forwarding/masquerading is enabled for retro -> modern with firewalld policy
• modern only has a minimal set of services exposed for modern i.e. ssh, "modern" samba (445/tcp) and cockpit.
• wlan1 is provided by an edimax wireless usb adapter (i wanted a 2.4Ghz ap and you cant run 2 radios on the same interface)
• i have a vap0 virtual interface on wlan1 which allows me to add another access point with WEP support for nds (untested)

i think sane defaults from this experiment for the rpi is something like this

                             |
                             |
                             |
              +--------------+--------------+
              |              |              |
              |              |              |
    ethernet  | retro     ---+-->   modern  |  wifi (wlan0)
wifi (wlan1)  | 10.99.x      |              |
              |              |              |
              +------+-------+---+---+---+--+
                     |       |   |   |   |
                     |       |   |   |   |   ssh (22/tcp)
                     |       |   |   |   +---------------
         p/service   |       |   |   |    samba (445/tcp)
      ---------------+       |   |   +-------------------
                             |   |     cockpit (9090/tcp)
                                 +-----------------------

this diagram is what i'll be working towards, with some options to override the interface assignments/nets i expect

[sairuk]

i am doing other stuff as well with port forwarding to access the webui of the dedicated NAS I have for my retro net setup from the modern net and also accessing an NFS (vers=4.2) share directly off said NAS from a machine on my modern net

this is going to be considered advanced stuff that will require manual config on the cli if people want it. we may add some basic general interface to manage port forwards but this retroNAS is not (yet) a router, although it is starting to go that way with this.