From time to time I like to review my network to see where I can tighten up. Review logs, check out the landscape, and make sure there are no gaps. Today, I have some downtime, so I figured it’d be a good for it. Since I am not a certified IT professional, this is what I have cobbled together reading, and seeing what others have done. I’d like to bounce this off you guys who are more experienced than I and get your impressions. If you have any recommendations, I’m always down to be schooled.
So if you’d like to participate in my audit, I have a home network as follows:
- Modem receiving IP from ISP. Modem to router. Router to stand alone pfsense firewall. Router has a 54 character complex password for WiFi. There are no guest provisions for WiFi.
- Pfsense firewall with pfblockerng & suricata running on both lan and wan, both with a full array of rules/feeds updated daily. pfsense has tailscale as an overlay vpn. Server traffic and PC traffic have their own VLAN provided by pfsense. My approach is to deny all until something complains and address that on a case by case basis. Additionally ntopng is utilized for traffic analysis. IPv6 is disabled.
- Server running Tailscale as an overlay VPN, UFW deny all posture, and fail2ban with an aggressive posture. Server has been hardened against Lynis spec where applicable. Not all recommendations apply to my server. Server is utilizing host deny/host allow and SSH keys.
- Server is utilizing containers for services.
- Server is using Cloudflare tunnel/zero trust.
- Server and pfsense communicate via Tailscale encrypted tunnel. PC/Phone/mobile device can communicate with pfsense via Tailscale.
- Server services are accessed via https.
- PC connected to pfsense firewall with same rules as server. PC is using a VPN with Cloudflare 1.1.1.1/1.0.0.1 for DNS queries. Firefox is using 1.1.1.1/1.0.0.1. Settings for Firefox are the strictest for Enhanced Tracking Protection, and DOH. HTTPS-Only mode enabled. PC is also running a soft firewall.
- All other devices such as phones, laptops, and tablets run a VPN with Cloudflare 1.1.1.1/1.0.0.1 for DNS queries.
- IoT devices are isolated. Phones are isolated. Smart TVs are isolated.
How secure would you say this network is and give any recommendations to further harden the network besides keeping up with current updates, monitoring and auditing logs.
Thanks
No scanning? External, internal, and host scans. I’d also set up a network traffic analyzer if you want to go really advanced.
I have chkrootkit, IPTraf-ng, and rkhunter doing daily scans. I use ntopng for traffic analysis. What would you recommend.
Do you place any restrictions on the containers or the container daemon as a whole?
Moreso asking so I can copy your settings. But I have had my server brought down just from the services themselves consuming too much memory or disk space, so something to look into if you haven’t already.
I have had my server brought down just from the services themselves consuming too much memory or disk space
Server is utilizing a 8 TB SSD and 40 GB RAM. I can go into Portainer and regulate how much resources I allot to each container, however, I’ve never had any issues in that regard. Server generally hums along at 15-25% for around 75 different containers.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters DNS Domain Name Service/System IP Internet Protocol NAT Network Address Translation SSD Solid State Drive mass storage VPN Virtual Private Network
5 acronyms in this thread; the most compressed thread commented on today has 12 acronyms.
[Thread #116 for this comm, first seen 24th Feb 2026, 20:31] [FAQ] [Full list] [Contact] [Source code]
Why disable IPv6?
My commercial VPN does not do IPv6. I didn’t want there to be any situation where any IPV6 traffic was leaked out because the VPN is not IPv6 compatible. That may be errant thinking on my part tho. If you see it a different way, I’d entertain your thoughts.
The approach isn’t invalid, but seeing as you already have the framework set up to deny all and log for IPv4, the same could be done with IPv6.
That is to say, your router advertises an IPv6 gateway to the global internet, but you then reject it because your VPN doesn’t support v6 (sadly). I specifically say reject, rather than drop, because you want that ICMP Unreachable (administratively prohibited) message to get returned to any app trying to use v6. That way, Happy Eyeballs will gracefully and quickly fall back to v6. Unless your containers have some exceptionally weird routing rules, v6 connections will only be attempted once, and will always use the route advertised. So if your router denies this attempt, your containers won’t try again in a way that could leak. v6 leaks are more likely when there isn’t even a route advertised.
This makes your apps able to use v6, for that day when your VPN supports it, and so it’s just a question of when the network itself can be upgraded. IMO, apps should always try for v6 first and the network (if it can’t support it) will affirmatively reply that it can’t, and then apps will gracefully fall back.
This also benefits you by logging all attempted v6 traffic, to know how much of your stuff is actually v6-capable. And more data is always nice to have.
because your VPN doesn’t support v6 (sadly)
I have no problem with IPv6, in fact it would probably be a bit more faster/streamlined since IPv6 has simpler headers, eliminates the need for NAT…so direct addressing, and IPV6 has smaller routing tables. So, all in all, yes IPV6 would be more desirable. For the time being until, as you say, my sad VPN provider upgrades to IPv6, I figured it would be best to just disable it and wait. From what I can tell, there are only a small handful of reputable VPNs that support IPv6 like Proton and Mullvad.
Fair, though I personally don’t let my ISP indirectly dictate what I do with my LAN. If I didn’t already have a v6-enabled WAN, I would still manage my LAN using IPv6 private range addresses. There are too many benefits to me, like having VMs and containers be first-class citizens on my LAN, rather than sitting behind yet another layer of NAT. That lets me avoid port forwarding at the border of my home Kubernetes cluster (or formerly, my Docker Swarm), and it means my DNS names correctly resolve to a valid IP address that’s usable anywhere on my network (because no NAT when inside the LAN).
I will admit that NAT64 is kinda a drag to access v4-only resources like GitHub, but that’s only necessary because they’ve not lit up support for v6 (despite other parts of their site supporting v6).
This is my idea of being future-ready: when the future comes, I’m already there.
I would still manage my LAN using IPv6 private range addresses
That is something to consider. Thanks.
No, that makes sense.
I see a lot of people disable it because they assume it’s inherently insecure. Just wanted to check if that was the reason.
