support@technetguy.site Remote IT Services · Worldwide · Get a Quote →
Network & Security

Network Engineering & Hardening

Rolling out remote access at scale, picking a filtering strategy that survives scrutiny, and fixing exposure the right way — by understanding it first.

VPN rollout to a distributed workforce

A site running a legacy VPN concentrator needed remote access rebuilt for a distributed team without a central office network. The rollout moved user by user to a WireGuard-based road-warrior setup, verified individually rather than pushed as one big-bang cutover: each new peer's public key was diffed against its private configuration file before being marked done, not after a user reported it broken. That check alone caught a silent key-mismatch bug in half of one rollout batch — the kind of bug that looks fine until someone actually tries to connect.

A recurring root cause worth calling out: reachability issues that looked like routing bugs turned out to be a live firewall alias whose in-kernel table had silently desynced from its own configuration. Re-applying the same config fixed it — the lesson was to always verify the running state, not just the saved config.

Choosing a DNS filtering strategy

The obvious answer for network-wide DNS filtering is a dedicated appliance like Pi-hole or AdGuard Home. For a site that needed high availability and role-based access control for multiple admins, that answer didn't hold up — neither tool has a real HA story. The decision instead was to use the existing firewall's built-in DNS resolver with its extended blocklist feature: one less service to keep alive, and access control that was already solved. Sometimes the right architecture call is the boring one that doesn't add a new single point of failure.

Hardening: investigate before you fix

The pattern that holds up across every hardening pass, including the one that secured this site: don't patch an exposure until you know exactly who's been using it and how. A finding is not "close the port" — it's "read the logs, find out who actually depends on this working the current way, and design the fix so nothing breaks."

Publicly exposed files — before locking anything down, the logs get checked for who's actually pulled the files, and the file contents get read to know whether real secrets are involved or not, since that changes whether anything needs rotating.
Services bypassing the intended access path — before closing a port, confirm how the legitimate workflow happens today. Default to the safer design (bind to localhost, front it with the same authentication already in place) only after confirming nothing breaks.
SSH exposure — tens of thousands of failed login attempts is normal internet background noise, not necessarily a breach. The useful question is whether any *successful* logins don't match known-good patterns, and whether fail2ban is actually enabled, not just installed.