I remember there was a tool so you can download your lemmy subscriptions then upload it to your new Lemmy instance so in that way it will federate with those you are interested in. I don’t exactly remember the name but if I find it will comment back here.
It wasn’t but now it does I guess. I just searched a community didn’t existed locally on my instance and I got same result as you. No votes, no comments. I think this is enough to open an issue in the Lemmy repo.
Internet -> router/firewall -> your network with all devices
No DMZ needed or wanted.
You will want a dhcp server which will likely be the router/firewall. It will tell all your internal systems to use it as a “gateway” for Internet traffic. The router then allows outbound for everybody and does NAT - basically it makes requests on that systems behalf and sends the results back. If your want external access to a system you configure port-forwarding on the router (again it acts as the middleman between external and internal systems).
Edited to add: I love that you provided a diagram though! Makes it much easier to discuss.
It seems, based on your comments and others in the post, that my next step is to flash OpenWRT and do a deep dive on its firewall functions. Thanks for taking the time to educate me!
Yeah - basic home-networking is typically pretty straight-forward. You’ll want to figure out your basic services (DHCP, DNS, and routing) but after that it’s pretty simple. OpenWRT should handle the DHCP and routing. I’m not sure about DNS though.
DHCP will tell systems "here is your IP, here is the CIDR of the network you are on, here is the router that handles traffic for things NOT on that network (e.g. the internet), and here are the DNS servers you should use for name resolution.
With DHCP you can also hand out “static leases” to give systems reliable IP addresses based on their MAC addresses. Then you can setup a DNS server that does internal name resolution if you want to be able to reference systems by name. This DNS server doesn’t need to be publicly available (and indeed should not be).
The Firewall is typically only for things coming into your network from the internet. You can restrict outbound traffic as well if you want but that’s less common. By default things on the internet will NOT be able to get to your internal systems because of NAT. So to allow things “out there” to access a service running on an internal system you’ll need to do port forwarding on your firewall. This will a) open a port on the internet side and b) send all traffic to that port to a port on an internal system. The router will handle all of the network-to-network and traffic handling stuff.
I’ll make a note here that a firewall is useful for internal traffic, too. Those IoT devices can get pretty annoying, so you’d want to e.g. drop your cheap webcams into a VLAN and disallow them from talking to enjoying but their cloud, and especially the other VLANs, or isolate Alexa capable device so it won’t try to figure what else you got there in your house over mDNS (it will).
A managed switch would do nicely. Having isolated ports on the switch (and the wifi AP) is also great if you want to make sure the specific device will only talk to the gateway and not its peers.
The issue could still be a fail-to-band issue if fail-to-band is looking at the user agent string (I’m not sure fail to ban looks at the user agent string, but it might be worth checking out.). The user agent string would likely be different on a mobile app versus a browser login.
If you’ve an OpenWRT compatible router why are you thinking about pfsense? There isn’t much to gain there, your OpenWRT will do NAT and also has a firewall.
I like this device since 3ports would allow me to create a physically separate DMZ
OpenWRT can do this as well. What are your plans with the DMZ tho?
Be careful with the use of the acronym DMZ as in the context of typical routers and ISPs it has a different meaning of what you’re implying here. DMZ usually is used in the context for a single host that is “outside” the ISP router’s firewall and all requests coming into the ISP router will be forward to that device.
With my current diagram, it seems like it is not possible for the NAS to receive updates from the internet.
You NAS will never “receive updates” it will ask for updates. Maybe add a firewall rule that allows traffic from the NAS to the internet but not the other way around (this is usually the default state of any router, it will allow local devices to go to the internet but not incoming connections to those devices).
My TrueNas has 2x2.5Gb ports. Can i connect each NIC to a different network? Would this have any benefit?
You can, but is it really worth it? If someone hacks the device they’ll access the rest of the network. Same applies to your computers and cames consoles, they can be used to jump to the other side and vice versa.
Frankly I don’t see the usefulness of your setup as you’ll end up with weak points somewhere. Just get a single OpenWRT router and throw everything into the same network. Apply firewall restrictions as needed.
Would this let me do something like SSH to a bastion host, elevate privs with sudo, and SSH forward from there, then elevate privs again on the final target I’m trying to get to? Maybe do that on 100 servers at the same time?
Back a half decade, I and my team of DBAs would have killed for something like that.
Sorry if I’m the “can it do this weird and unnecessary thing” guy, but it really looks like a dream come true if it’s what I think it is
You always have to fiddle around a bit with SSH jumps and fowards as there are two different ways in xpipe to handle that. You also have to take care of your authentication maybe with agent forwarding etc. if you use keys. But I’m confident that you can make this work with the new custom SSH connections in xpipe as that allows you to do basically anything with SSH.
I hear Anna’s Archives is great for ebooks. I don’t do audiobooks, and can’t stand podcasts, but it sounds like a lot of good suggestions were made for those already.
It is basically a graphical wrapper around your CLI tools like ssh, docker, kubectl, and more that gives you the features you know from tools like graphical SFTP clients but supports much more types of connections and allows you to use your favourite terminal and editor for your remote connections.
selfhosted
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.