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

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.

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.

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.

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:

6 acronyms in this thread; the most compressed thread commented on today has 7 acronyms.

[Thread #116 for this comm, first seen 24th Feb 2026, 20:31]
[FAQ] [Full list] [Contact] [Source code]

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.

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.

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.

I would still manage my LAN using IPv6 private range addresses

That is something to consider. Thanks.

Op is running suricata

Running suricata on your wan interface is just generating a ton of noise and will be really confusing for you if you haven't reviewed packet inspection alerts before. Not a lot of value in it unless you have many users "phoning home".

Just run it on the lan interface.

Your approach of deny all until something complains is pretty much the most solid way to get a grip on security.

I assess and recommend security practices for a living, and I would say the most important first step is understanding where your data lives and where it goes. Once you know that, the rest is relatively easy with the tools available to us.

I've been told this before. I also acknowledge and appreciate your advice coming from a professional pov. However, here's the thing...my OCD would never allow me not to know. It would drive me up the wall not knowing. I get what you are saying, and you are right. It is my kryptonite not to know. It is a curse I can tell you.

OK, well it's not harming anything, so if you're game to learn, by all means.

When you look at traffic on a public interface, besides learning what to filter out that is just normal (probes, crawls, etc from legit sources), but you also will run into badly-formed TCP traffic:

Martian packets: https://en.wikipedia.org/wiki/Martian_packet
IP spoofing: https://en.wikipedia.org/wiki/IP_address_spoofing (I used to have a better resource for this,I'll try to find it)

How RPC works: https://pentest.co.uk/labs/research/researching-remote-procedure-call-rpc-vulnerabilities/

That should help clarify a lot of what you'll see in traffic on your segment.

You may also want to briefly read about how CDNs work, you'll see a lot of akamai and cloudflare traffic too.

As a certified IT professional I can tell you I’d much rather have a coworker who got down in the weeds and did things. Anyone can pick up a cert, that’s resume padding. Operational experience is the real prize

That should help clarify a lot of what you’ll see in traffic on your segment.

Thank you for the links and guidance. I will definitely read those. Yeah I do see a lot of things like:

• SURICATA STREAM FIN2 FIN with wrong seq (this is from local chatter)
• ET INFO DNS Query for Suspicious .ml Domain (must check out this suspicious domain /s)
• ET INFO Observed DNS Query to .world TLD (same as above)
• SURICATA STREAM Packet with invalid timestamp (local chatter - common triggered event from what I understand)
• SURICATA STREAM FIN invalid ack (known domain speedtest)

So, since I am working within the framework of my own personal shortcomings and have to know, I research them to find out why they get triggered. That way I don't freak out over them A lot of them are benign and due to normal occurrences between server and user.

Operational experience is the real prize

Perhaps, but I've found that HR likes paper tigers. LOL Not discounting anyone's hard work at all. I do learn from others more knowledgeable than I. I've had a computer of some sort in front of me since the mid 70s with the Altair. Don't mistake longevity with knowledge tho. What little I do know came from reading, doing, screwing it up, rinse, repeat ad nauseam until success, and then write that shit down because it will come up again more than likely.

Awesome! You’re making me want to give Portainer another go.

I’m running a potato pi with 0.5 TB and 8 GB RAM so…slightly different situation here :P

It doesn't really matter if you're running a pi or a full stack rack in the closet, it's all good. I use Portainer because I learned how to drive that bus and it just seemed to click with me so I kept it. There are other similar and even better options out there.

You’re ahead of an alarming number of my colleagues by just trying until you can get it working then documenting things

I have to document. At 71, with a TBI, my brain is not what it used to be. Sometimes I don't even remember what I had for breakfast. LOL