Are you familiar with using Wireshark for traffic analysis? I think the next step is to figure out what is getting through and what isn’t, to the Windows machine to start with.
Focusing on IPv4 for now, I would hope the network trace shows the DHCP request being sent out, the DHCP response with an IP for the Windows machine, and then some outbound web TCP traffic (eg google.com), followed by some sort of TCP response. But since it’s not working, I imagine the latter would be replaced by – ideally – ICMP error messages that will describe the problem.
Your switch and AP configuration seem to be fine, so I would guess that the issue is on the routing/firewall side in OPNsense. Do I understand correctly that you assigned 192.168.10.0 as the IP address for OPNsense on the VLAN10 interface?
That might pose an issue, since in a /24 sized subnet in IPv4, the .0 address is the network identifier. Some software historically would wrongly disallow using this as an IP address, either as a source or as a destination. You might try changing your address to 192.168.10.1/24 to see if that works for your devices.
Do you have no sense of adventure!! I installed openWRT for the fun of it!
OK, I concede haha. You’re absolutely right that doing things Just Because ™ is as valid as reason as anything else, and as an engineer I shouldn’t be dissuading other folks from exploring. One thing I will say is that because my work develops network switches, it’s an occupational hazard that I’ve become less interested in going home and doing more recreational networking. I still do, but not on my “production” home network. I have a separate equipment stack for playing around with.
maybe I should learn more networking and learn to use this first router well
I would doubly recommend this: networking is a great big world that underpins so many things, but is often unsung and misunderstood, or even just not understood at all. Looking under the hood is seldom unenlightening.
my Unifi switch needs a separate controller software running on a Pi or similar to configure it
You’ve pretty much arrived at exactly the reason why I don’t use Ubiquiti’s switch products, inexpensive and capable as they are. I’m a proponent of “fewer moving parts”, so it’s either self-contained network appliances (ie router, switch, modem) or tightly-integrated equipment with configurability and performance that overcomes the complexity burden. These controller-managed or cloud-managed devices are just adding points-of-failure, IMO.
Regarding the feature you mention, I think the industry uses the term “mirroring”, as in Port Mirroring or VLAN Mirroring. That said, the volume of traffic is basically a firehose and could potentially overwhelm whatever port or entity is to receive the mirrored traffic. High-end switches will instead forward traffic on a more granular basis, based on filters issued from the IDS for what constitutes suspicious traffic. You might consider reading about OpenFlow and Software Defined Networking (SDN) for how some of these scenarios are implemented, but this is getting rather deep into networking.
The refresher I was given a while ago to read for networking was The All-New Switch Book, second edition. It’s a bit old at this point, but it’s a solid foundation on Ethernet and standard network features.
The ONT can still have an IP address independent of pass-through mode; this is often done so the ONT can be remotely trouble shooted by the ISP, although if they’re burning a public IPv4 address to do this… that’s just wasteful.
As for CGNAT, I think what matters is whether other hosts on the Internet can see the address your router has configured. I like to check wtfismyip.com
Traceroute has some known deficiencies, or rather it is often used for things it wasn’t meant for, so I wouldn’t necessarily put too much concern behind what it reports for the intermediate routers. If you’ve got a pubic IP address and it behaves like one to your applications, then you should be good to go.
If the ISP router has a VLAN ID configured, there’s a possibility that they strip it before passing through to your equipment, so you wouldn’t need to configure it on your end. So while there’s no guarantee copying the VLAN ID will work, it could still be worth a try.
IMO, custom firmware is a means to an end, rather than an activity undertaken just for the sake of it. That is, I run custom firmware when it gives me features I otherwise wouldn’t have had, or because the original firmware has issues.
For a great majority of home routers, OpenWRT and the like open up enormous possibilities, so I have no objection there. For a managed switch, however, the returns are diminishing: most of the time, the complexity of a network falls upon its gateway or firewall, rather than the switch. Yes, there could exist complex VLANs with priority flow control and GRE tunnels, but if a switch doesn’t support that, it’s usually because it can’t, due to lack of ASIC support or necessary performance, rather than firmware not implementing it.
Of course, things get wild in the enterprise switch space, where switches rise to the forefront of network design, with things like per-user VLANs and “lite L3” routing. But I’m ignoring those, since they’re hideously expensive and beyond the entirety of Ubiquity’s product line.
So I posit to you: what sort of feature would you want to see in your switch that’s not there today? Would that feature have to be on the switch, or could it still operate if it was on your router?
This may be a sizable leap in debugging, but for strange networking issues, I’ll usually start Wireshark and monitor whatever traffic is coming from the ISP’s equipment, looking for clues. A really nice clue would be something like VLAN tagged traffic, which would indicate the ISP requires a certain VLAN ID. Or perhaps you could see if your DHCP requests are being answered or not.
I do recognize that this sort of network sleuthing is as much art as it is science, so your mileage will vary.
I bought a Naples (Gen 1) Epyc CPU and mobo from eBay back in 2021. My understanding is that it was from Chinese data centers clearing out to make room for Rome (Gen 2), since they would have been running Naples for a while and it probably made sense to upgrade.
Overall, the experience was fine, although I will note the CPU was rather lightly packaged and the description didn’t make it clear if it came with the plastic alignment piece to install the CPU – it did.
The product manual for the OR700 indicates that it comes with a set of rack mount brackets. A bit of searching with Google Images shows that these brackets are only supported by the front rails.
Generally speaking, a product’s official rack-mount hardware is sufficient to support the product on its own, without anything pressing on it from above, and assuming all four screws (probably not included) are secured into cage nuts of the matching size and thread.
From my experience, 8 kg (18 lbs) for a device which is only 23 cm deep (9.2 in) is no cause from alarm, when installed with all 4 screws. Heavier appliances exist which also don’t require a 4 post rack.
Whichever rack you do get, try to get one with square holes. That said, pre-threaded holes aren’t common for server racks, so they should be easy to identify and avoid. I say to prefer square holes because it is preferable to replace a removable cage nut (eg M6-1.0 size) than to repair and retap a stripped hole in the rack.
The other comments have already touched upon specific security recommendations and useful learning material. But since you did request an ELI5, I figured I’d throw in some simple advice.
I don’t know much about Tailscale, but it looks to be an encrypted VPN into your server. This pipe to your server is secure from actors spying on your public WiFi connection, but would not help if – for example – your laptop is compromised and uses the VPN to further attack your server. To that end, the principle of “defense in depth” says that the server itself should have its own firewall, as a secondary or tertiary layer to keep the bad things away.
Your server firewall should default to reject*/block all inbound connections, with explicit exceptions only for services you intend to expose, such as a web server, SSH server, JellyFin, etc. Once an inbound connection is approved through the firewall, the outgoing reply to the client would also be allowed through, as would any follow-up traffic that is part of that same connection. This is connection-tracking, which all stateful firewalls can perform. Debian/Ubuntu use ufw as the default firewall, and it is IMO very easy to configure for common services or port numbers.
The next thing you can do to secure the server itself is to limit your attack space. Don’t use password authentication if you can avoid it, and use good, complex passwords where you must. Your SSH server can be configured to silently reject passwords and only accept public-key authentication, and your JellyFin authentication can be generated and stored by a good password manager.
At this point, we could go on about per-application recommendations, but just having a firewall on your server staves off a lot of script-kiddie level of attacks, from outside or even within your LAN.
The difference between reject and block in the firewall context is that reject causes a reply to be sent back to the client, positively informing them that access is denied and to not try again. The drawback is that this reveals that a firewall is in place, but is also valuable information when debugging a network connection. Whereas block silently discards network traffic, the same result as if the network lost the packet. IMO, block should only ever be used for WAN firewalls – to not reveal too much info to a potential attacker – but internally, firewalls within a LAN should use reject, as the benefits outweigh the risk of a network intruder who is already on the LAN.
As for the bonus question, with that much hardware, you could do interesting things such as experimenting with a Kubernetes cluster, or a ZFS filesystem. Or maybe you can do Chia mining with all that disk space, or Folding@Home (and CureCoin). If you’re more into just VMs and how they network together, it would be a good test bench to learn about Layer 2 forwarding and Layer 3 routing, if you wanted to understand how IPv6* traffic traverses multiple (virtual) Ethernet links.
Note: I am an IPv6 fanboy and promote it wherever I can over legacy IP (aka IPv4)
Finally, from the hardware specs you’ve given, might this be some sort of Dell or HPE server? If so, I would strongly urge you to enable the Lights-out Management (LOM) functionality (Dell calls this iDRAC; HPE calls it iLO), if you haven’t already. It may be the single most important tool for any system administrator, which is your role now, since you are in charge of this server. In short, LOM is like having a KVM, plus power control, and the ability to push physical buttons on the server and attach USB drives, all via a slick HTML5 interface.
As other posters have remarked, it’s difficult to offer a generalized statement on PoE efficiency. One thing I will point out that hasn’t been mentioned yet is that PoE switches tend to have poor “wall to device” efficiency when lightly loaded. Certifications like 80 Plus only assess efficiency at specific loading levels.
Hypothetically, a 400W PoE switch serving only a 5W load may cause an additional 10W to be drawn from the wall, which is pretty horrific. But if serving loads totalling 350 W, could draw 390 W from the wall, which might be acceptable efficiency.
Your best bet is to test your specific configuration and see how the wall efficiency looks, with something like a Kill-o-Watt. Note that even a change from 120V input voltage to 240V input voltage can affect your efficiency results.