I did not start with a perfect privacy setup. I started with a basic VPS, a public IP address, and the same question many people have after buying a VPN subscription: who is seeing my traffic now?
I wanted a setup I could understand. I needed a private route for my phone and laptop when I was away from home, DNS filtering that I controlled, and a server with a small, clear purpose.
Before: online, but not ready
At first, the VPS had a public IP and reachable SSH. My devices used whatever DNS resolver the local network or mobile provider supplied. On hotel Wi-Fi, public Wi-Fi, or mobile data, I had to trust the network and the DNS provider handling my requests.
I had written about why a VPS can be useful for privacy and control, but this project made the lesson practical. The VPS itself was not the security improvement. The improvement came from deciding what it could do, what it could not do, and what needed to remain private.
The goal was privacy, not a magic anonymity claim
I was not trying to become invisible online. A self-hosted VPN cannot promise that honestly.
My VPS provider still knows I rent the server. Websites can still recognize me when I sign into normal accounts. Cookies, browser fingerprinting, and my own habits can link sessions together. A VPN changes the network path. It does not erase identity.
That difference matters because privacy and anonymity are not the same thing. My goal was better control: encrypt traffic between my devices and the VPS, stop DNS requests from going to random providers, and reduce the number of companies in the middle.
What I changed on the VPS
I treated the VPS like a small security project, not a quick app install.
SSH uses keys instead of passwords, root login is disabled, and the firewall allows only the services that need to exist. The VPN needs one UDP port for WireGuard. SSH stays available through a controlled management path. Pi-hole, Unbound, and their web interfaces do not need to be public, so they are not.
Adding WireGuard for a private tunnel
Each phone and laptop gets its own WireGuard peer and its own key. There is no shared VPN profile passed around between devices.
When I connect, my device creates an encrypted tunnel to the VPS. With a full-tunnel configuration, normal internet traffic exits through that server instead of directly through the local network. Someone on public Wi-Fi sees an encrypted connection to the VPS, not a plain list of every service I am using.
My post on self-hosted VPNs and what they really protect explains the tradeoff. A self-hosted VPN gives me control, but it also makes me responsible for updates, backups, and revoking access when a device is lost.
Putting Pi-hole and Unbound behind the VPN
A VPN without private DNS leaves part of the problem unsolved. A device can tunnel web traffic while DNS requests still go elsewhere if the configuration is careless.
I placed Pi-hole and Unbound behind the VPN. Pi-hole blocks known ad, tracking, malware, and unwanted domains before a device connects to them. Unbound resolves allowed requests without sending my full query history to a large public resolver by default.
The flow is simple: a connected device sends a DNS request through the VPN. Pi-hole checks whether the domain should be blocked. Unbound resolves allowed requests. DNS port 53 is not public, and the Pi-hole admin page is not a public website.
Some apps use their own encrypted DNS, and browser secure DNS can bypass a local resolver if I allow it. That is why I test the setup instead of assuming it works. My guide to Pi-hole and Unbound for private DNS covers the details.
After: a setup with clearer boundaries
After the changes, the traffic path is easier to reason about:
Phone or laptop
-> encrypted WireGuard tunnel
-> my VPS
-> Pi-hole and Unbound for DNS
-> the internet
On an untrusted network, my device connects to the VPN first. DNS filtering follows the same route. Public-facing services are limited to what the VPN needs. Management tools stay private. Each device has its own VPN identity, so I can revoke one device without disrupting the others.
What this setup does not solve
A VPN does not make a logged-in account anonymous or protect a compromised phone. For situations where anonymity is genuinely required, Tor Browser and careful identity separation are better tools. I also check the public IP, DNS leak results, and IPv6 behavior. A kill switch on supported devices blocks traffic if the VPN drops.
Why this matters for clients
Most people do not need a complicated privacy lab. They need a setup that works away from home, does not expose an admin dashboard to the internet, blocks obvious tracking, and has a clear recovery plan when a phone is lost or replaced.
That is what I would build for a client: separate VPN access per device, private DNS, no public admin panels, documented recovery steps, and a setup that remains understandable six months later.
Need help setting this up?
If you want a private VPN and DNS setup but do not want to spend your weekend troubleshooting firewall rules, DNS leaks, and device profiles, I can help. I build practical privacy setups for individuals, families, and small businesses, with the security boundaries explained clearly. Reach out through the contact page and let us talk about your setup.
Frequently asked questions
Is a self-hosted VPN better than a commercial VPN?
It depends on the goal. A self-hosted VPN gives you control over the server, configuration, and logging choices. A commercial VPN may be easier to use and can offer exit locations not tied directly to your VPS. Neither option provides automatic anonymity.
Does Pi-hole make me anonymous online?
No. Pi-hole blocks many ad and tracking domains at the DNS level. It improves privacy and reduces unwanted connections, but it does not hide your identity from websites where you log in.
Should I expose Pi-hole to the internet?
No. DNS and the Pi-hole administration interface should remain private. Allow VPN clients to use DNS through the tunnel, but do not create a public resolver or public admin page.