A Geek with Guns - Self-Hosting

Setup IPv6 in WireGuard

2025-12-30T15:30:00-06:00

Introduction</h1>
Over the holiday break I finished upgrading all of my self-hosted services to make them available via IPv6. The upgrade was straightforward for all of my services except one: my WireGuard VPN</abbr> server. I wanted to provide my VPN clients with IPv6 connectivity without using NAT</abbr>. Unfortunately most of the guides online use NAT for IPv4 and IPv6. NAT is necessary for IPv4, but goes against the very design of IPv6. I wanted to provide each client with a globally routable IPv6 address. This ended up being simple once I figured it out.</p>
I previous wrote a guide for setting up WireGuard to share a public static IPv4 address</a>. The formatting was ruined in the transition from my old WordPress blog to this statically generated one, but it explains how to setup a WireGuard VPN server for IPv4. This post will explain how to setup a WireGuard VPN server for IPv6.</p>

Preamble</h1>
First a major caveat. As of this writing, I've had this iteration of my VPN server running for two days. I've tested it on my home network, on my phone's cellular network, and on an IPv4 only network through my travel router. IPv6 appears to work in all cases. I haven't finished thorough testing though. There may be a number of corner cases that don't work. I will update this guide as I find and fix them. Therefore, if you find something broken, check back and I might have discovered it and posted the solution already.</p>
I also pieced my setup together by taking bits and pieces of several online guides. I pillaged from this guide</a>, this guide</a>, this guide</a>, and this guide</a>. If there are unnecessary configuration steps in this guide, I likely took it from one of these guides and didn't test my final setup without the configuration. Such mistakes are entirely my fault.</p>
In order to follow this guide, you need a source of IPv6 addresses and specifically a separate subnet from your hosting network. My ISP</abbr> provides me with a /48 prefix. This gives me roughly a bajillion addresses and subnets.</p>

Conventions Used in This Guide</h1>
For the purposes of this guide, I'm going to use the following IP addresses (`2001:db8</code> is the` `prefix reserved for examples and documentation</a> for those not aware):</p>`
`2001:db8:1234::/48</code>: The prefix provided by our ISP.</p>`
`2001:db8:1234:9999::/64</code>: The subnet of our hosting network. The subnet 9999</code> was chosen for readability purposes.</p>`
`2001:db8:1234:ffff::/64</code>: The subnet provided to our WireGuard VPN clients. Throughout this guide remember that the subnet with numbers is for our hosting network and the subnet with letters is for our VPN clients.</p>`
`2001:db8:1234:9999::1</code>: The IPv6 address used by clients to connect to our WireGuard VPN server.</p>`
`2001:db8:1234:ffff::1</code>: The IPv6 address of the WireGuard interface. This differs from the above address in that a client only uses it after it has connected to the WireGuard VPN server through the above address. Once connected, clients will use this address as their gateway.</p>`
`2001:db8:1234:ffff::1:1</code>: The IPv6 address provided to the first of our WireGuard VPN clients. This address will be incremented subsequently so our second client will have an IPv6 address of 2001:db8:1234:ffff::1:2</code>, our third 2001:db8:1234:ffff::1:3</code>, etc.</p>`
`I will also use en0</code> as the name of the network interface of our WireGuard VPN server, 51820</code> as the port used to connect to WireGuard on our server, and wg-vpn.conf</code> as the name of our WireGuard configuration file.</p>`

The Actual Guide</h1>
The first thing you will need to do is ensure that the router between your hosting network and ISP is setup to route the subnet for our VPN clients to our VPN server. How you do this will depend on both your ISP and your router. For my Ubiquiti Cloud Gateway Ultra, I created a static route that routes the entire 2001:db8:1234:ffff::/64</code> subnet to 2001:db8:1234:9999::1</code>. You will also need to configure your router's firewall to allow incoming WireGuard traffic to your VPN server.</p>
I'm hosting my VPN server on Fedora Server. By default, IPv6 forwarding isn't enabled on Fedora Server. I enabled it by adding net.ipv6.conf.all.forwarding=1</code> to /etc/sysctl.conf</code> and issued the sysctl -p</code> command to load the changes. I also added several other lines. /etc/sysctl.conf</code> on my VPN server contains the following contents:</p>

net.ipv4.ip_forward=1
</span>net.ipv6.conf.en0.proxy_ndp=1
</span>net.ipv6.conf.all.forwarding=1
</span>net.ipv6.conf.en0.accept_ra=2
</span></code></pre>
The first line enables IPv4 forwarding. It's enabled by default on Fedora Server, but I added the line just to ensure it's always enabled. The second line enables proxying NDP</abbr> packets, which is used by IPv6 to discover neighboring devices. The final line enables router advertisements while IPv6 forwarding is enabled. I added it to the file when I was trying to dole out IPv6 addresses through another method. I'm not sure if it's needed for my final setup. This is one of those potentially unnecessary configuration steps I mentioned in the preamble for this guide.</p>
The only port I opened on my VPN server's firewall is 51820</code> for UDP</abbr> packets. WireGuard only uses UDP so you don't need to open the port for TCP</abbr>. I also enabled masquerading capabilities. Masquerading capabilities are only needed for NAT, which means it's only necessary for IPv4. You don't need to enable it if you're only using IPv6 on your VPN server.</p>
Everything else happens in the WireGuard configuration file located at /etc/wireguard/wg-vpn.conf</code>. The first section of the configuration file sets up the interface:</p>
[Interface]
</span>PrivateKey = <Your Server's Private Key>
</span>Address = 2001:db8:1234:ffff::1/64
</span>SaveConfig = false
</span>ListenPort = 51820
</span></code></pre>
This is all pretty basic. PrivateKey</code> obvious contains your server's private key that was generated with wg genkey</code>. Address</code> is the IPv6 address of the WireGuard interface. Clients will use this address as their gateway once they've connected to our VPN server. SaveConfig</code> determines if the current configuration is saved when the WireGuard interface is shutdown. I generate my configuration files with Ansible so I don't want any state maintained and disable this feature. ListenPort</code> is the port through which clients will connect to the VPN server.</p>
The next section is where the heavy lifting is done. PostUp</code> commands run when the WireGuard server is being started. PostDown</code> commands run when the WireGuard server is being stopped. In this case, the PostDown</code> commands simply undo the PostUp</code> commands. Also note that %i</code> stands for the WireGuard interface name, which is wg-vpn</code> since the configuration file is wg-vpn.conf</code>.</p>
PostUp = ip6tables -A FORWARD -i en0 -o %i -j ACCEPT;
</span>PostUp = ip6tables -A FORWARD -i %i -j ACCEPT;
</span>
</span>PostUp = ip -6 neighbor add proxy 2001:db8:1234:ffff::1:1 dev en0
</span>PostUp = ip -6 neighbor add proxy 2001:db8:1234:ffff::1:2 dev en0
</span>PostUp = ip -6 neighbor add proxy 2001:db8:1234:ffff::1:3 dev en0
</span>
</span>PostDown = ip6tables -D FORWARD -i en0 -o %i -j ACCEPT;
</span>PostDown = ip6tables -D FORWARD -i %i -j ACCEPT;
</span>
</span>PostDown = ip -6 neighbor del proxy 2001:db8:1234:ffff::1:1 dev en0
</span>PostDown = ip -6 neighbor del proxy 2001:db8:1234:ffff::1:2 dev en0
</span>PostDown = ip -6 neighbor del proxy 2001:db8:1234:ffff::1:3 dev en0
</span></code></pre>
PostUp = ip6tables -A FORWARD -i en0 -o %i -j ACCEPT;</code> and PostUp = ip6tables -A FORWARD -i %i -j ACCEPT;</code> enable IPv6 forwarding between the server's network interface (en0</code> in this example) and the WireGuard interface (wg-vpn</code> in this example). This allowed IPv6 traffic originating from our clients to be forwarded out of the VPN server's network interface and return traffic routed from the VPN server's network interface to the appropriate client.</p>
PostUp = ip -6 neighbor add proxy 2001:db8:1234:ffff::1:1 dev en0</code> and the following two lines setup NDP proxies for each client. You could probably replace all of these lines with PostUp = ip -6 neighbor add proxy 2001:db8:1234:ffff::/64 dev en0</code>. Again I generate my configuration file with an Ansible playbook so it's just as easy for me to loop through my list of clients and add a line per client. As mention above, the PostDown</code> lines simply undo the PostUp</code> lines when the WireGuard interface is stopped.</p>
The final part of the file contains configuration information for each peer:</p>
[Peer]
</span>PublicKey = <The Client's Public Key> 
</span>AllowedIPs = 2001:db8:1234:ffff::1:1/128
</span>
</span>[Peer]
</span>PublicKey = <The Client's Public Key> 
</span>AllowedIPs = 2001:db8:1234:ffff::1:2/128
</span>
</span>[Peer]
</span>PublicKey = <The Client's Public Key> 
</span>AllowedIPs = 2001:db8:1234:ffff::1:3/128
</span></code></pre>
This is straightforward. PublicKey</code> contains the client's public key and AllowedIPs</code> contains the IPv6 address we're assigning to the client. Running systemctl start wg-quick@wg-vpn.service</code> will bring the WireGuard interface up so clients can start connecting.</p>
The configuration file for each client is simple:</p>
[Interface]
</span>Address = 2001:db8:1234:ffff::1:1/64
</span>PrivateKey = <The Client's Private Key>
</span>
</span>[Peer]
</span>AllowedIPs = ::/0
</span>Endpoint = [2001:db8:1234:9999::1]:51820
</span>PublicKey = <Your Server's Public Key>
</span></code></pre>
Address</code> is the globally routable IPv6 address our VPN server is assigning to the client. PrivateKey</code> is the client's private key. There's similarly little to say about the [Peer]</code> section, which contains connection information for the VPN server.</p>
AllowedIPs = ::/0</code> tells the client to route all IPv6 traffic through the WireGuard interface. Endpoint</code> contains the IPv6 address clients use to connect to the VPN server. Note the square brackets. Because IPv6 addresses use ':' as a separator and ':' is also used by convention to separate an IP address from a port number, the square brackets are used to disambiguate the ':' in the IPv6 address from the ':' differentiating the port number.</p>
When the client connects to the VPN server, it will have the globally routable IPv6 address of 2001:db8:1234:ffff::1:1</code>. If you connect to a website that tests IPv6 connectivity such as this IPv4 and IPv6 connectivity test</a>, it should show 2001:db8:1234:ffff::1:1</code> as your IPv6 address.</p>
There you have it, a WireGuard VPN server that provides clients with globally routable IPv6 addresses.</p>



Advice for Self Hosters
2025-12-23T19:45:00-06:00
I just finished upgrading my final self hosted service to be available over IPv6. This was a staged upgrade handled over several months. All of the upgrades went smoothly. I attribute this success to years of stupidity. I've made a number of mistakes over the years. Some of them cost me a great deal of time and grief. But they all taught me valuable lessons. This post is a collection of some of those lessons. If You're interested in self-hosting, I hope this advice proves valuable to you.</p>
1. Automate everything.</h2>
This is probably the most important lesson I've learned over the years. The reason my server upgrades went so well is because all of my builds are automated. This allows me to treat all of my servers like cattle. When the time is right, I slaughter them. The time is usually right when there's a major Fedora release. This is because most of my services run on Fedora Server at the moment. When a new major version is released, I don't do a dnf system-upgrade. Instead I nuke the virtual machine that hosts my service, create a new one, and install everything from scratch.</p>
My builds weren't always automated. I manually built all of my servers for many years. Because of how arduous building some of my servers was, I would sometimes let the host operating system get woefully out of date. Eventually they would get to a point where I had to rebuild them. Sometimes this was due to a hardware failure. Sometimes it was due to a security vulnerability in my stack. What I discovered is that I didn't remember all of the ins and outs of building the server. The task would take much longer because I had to rediscover everything I forgot. That isn't a problem now that everything is automated.</p>
This advice doesn't apply only to building servers. Your backups should be automated. If your backups aren't automated, they won't get done. TLS certificate renewals should also be automated, especially now that certificate lifetimes are becoming shorter and shorter. Everything</em> should be automated.</p>
You'll hear a lot of advice about the best automation tools. Each automation tool has ups and downs. I settled on Ansible for automating my system builds. It's a good tool in general but configurations are done in YAML and YAML sucks. NixOS is an option more people seem to be adopting. The upside is the entire system build is declared in a configuration file. The downside is you have to use NixOS (I don't think NixOS is bad, I just want to note that you can't use the NixOS method with other operating systems). Don't let yourself succumb to decision paralysis. Look up a few automation tools, pick one that looks good, and learn it. Even shell scripts are better than nothing.</p>
2. Consider maintenance.</h2>
Every self hosted service will require maintenance. How easy or hard the maintenance is will determine how often it gets done. I'll use TLS certificate management as an example. TLS certificates have a lifetime. That lifetime is becoming shorter and shorter</a>:</p>


From today until March 15, 2026, the maximum lifetime for a TLS certificate is 398 days.</li>
As of March 15, 2026, the maximum lifetime for a TLS certificate will be 200 days.</li>
As of March 15, 2027, the maximum lifetime for a TLS certificate will be 100 days.</li>
As of March 15, 2029, the maximum lifetime for a TLS certificate will be 47 days.</li>
</ul>
</blockquote>
Certificate management used to be much more complicated than today. You had to create an account with a certificate authority. Once you had an account, you had to verify your identity, usually by providing a picture of your government ID. Then you could get a certificate for your domains that was good for one to two years. The maintenance wasn't insignificant, but you only had to go through the process every one or two years. However, it was often easier to create your own certificate authorities if your self hosted services that were only available on your local network or were only used by devices you controlled.</p>
Now the maintenance burden is changing. As certificate lifetimes shrink, it'll become infeasible to manually manage your TLS certificates. If automating your certificate maintenance isn't possible, which it might not be for a service only available on your local network, you can still provide a secure connection to it using something like WireGuard. WireGuard keys have no prescribed lifetime. Depending on your situation, it might be easier to make your self hosted service only available over a WireGuard connection so you can avoid the hassle of dealing with certificates.</p>
3. Simple is usually better.</h2>
The best illustration of this rule is my post about Caddy</a>. I migrated my reverse proxy server (and since then all of my HTTP servers) from Nginx to Caddy. The reason for this migration was that Caddy is much simpler to configure than Nginx. What can easily require two dozen lines of configuration in Nginx can often be done in a single line in Caddy.</p>
My migration from OpenVPN to WireGuard was done for similar reasons. OpenVPN is a very flexible protocol. Unfortunately that flexibility comes with significant complexity and that complexity hides a lot of footguns. WireGuard on the other hand is opinionated. There's very little flexibility. That lack of flexibility means configuring a WireGuard interface is simple and there are no obvious footguns.</p>
Another example is my self hosted Nextcloud instance. My original Nextcloud instance was built (using Ansible, of course) by setting up the database backend, installing all of the required packages, copying the Nextcloud PHP files to the web root, and bringing everything up with systemd services. Then the Nextcloud team released their All-in-One Docker container</a>. Installing the All-in-One Docker container is much</em> easier than building everything from scratch. I use it now because it's simple to install and maintain (it can do automatic updates).</p>
I'll point to this blog as my final example. For many years this was a WordPress blog. Last year I finally migrated it to a static website</a>. I can't overstate how much simpler this blog is to maintain. I no longer need a database or PHP-FPM. I don't have to worry about the seemingly endless security issues that WordPress suffers. Best of all is I don't have to worry about a WordPress update enshitifying writing and editing posts</a> (Gutenberg was such a terrible experience that I had a WordPress plugin to bring back the old editor). Now I can write my posts with any text editor I please.</p>
I won't go so far as to say that the simpler option is always better. But preferring the simpler option is a sane default.</p>
4. Practice your recovery plan.</h2>
I noted that you should have automated backups in my first suggestion. But a backup isn't useful if you can't restore the data. The only thing harder than getting people to backup their data is getting them to test restoring it.</p>
Since I automate (see how important my first suggestion is) building my systems and I rebuild them every time there's a major Fedora release, I have an opportunity to test my recovery plan roughly every six months (Fedora releases a new major version about twice a year). Part of my automated builds involves pulling data from my hot backup system. I know my restores work because I test them frequently. Get in the habit of testing yours. It's much better to know how to restore backups when you don't need them than to find out you can't restore them when you do need them.</p>
5. Have fun.</h2>
I'll level with you. If playing with operating systems, building servers, and learning networking doesn't sound fun to you, self-hosting isn't for you. If you're not having fun when things are working, you definitely won't have fun when things aren't working.</p>
Self-hosting is part research, part engineering, and part detective work. The research is the easy part. You think of a service you need, find what options are ability that fulfill that need, read the documentation (if there is no documentation, don't use it), and end up with an idea of how well the service will fill your need and how easy it will be to setup and maintain. Then comes building the service. This is where the engineering part comes in. If you listen to my advice, you'll automated the building process. But even manually building a service will require engineering effort. Then eventually something will go wrong. This is where the detective part comes in. What went wrong? What are the likely causes? How can those causes be address? Is it DNS? It can't be DNS. It was DNS!</p>
Life is too for voluntary suffering. If self-hosting isn't a fun hobby to you, go find a hobby you'll enjoy instead.</p>


This Blog Is Now Available via IPv6
2025-10-17T12:00:00+00:00
Faster speeds are the only benefit I received from my recent Internet upgrade</a>. One of my biggest gripes with having to use CenturyLink when I bought this house was the complete lack of IPv6 support. Brightspeed, not surprisingly considering their incompetency, didn't add IPv6 support when they took over for CenturyLink. Lakeland Communications, however, has full IPv6 support, which means this blog is now available via IPv6.</p>
I consider this a major milestone. It's something I've wanted for many years now. I always envied people who had an IPv6 enabled Internet connection. I also hate network administrators who have an IPv6 enabled Internet connection and refuse to utilize it. Therefore, I'm going to use this occasion to rant about those network administrators and explain why their refusal is laziness at best and idiocy at worst.</p>
Even though IPv6 has been formalized by the IETF</abbr> since 1998, there remains a lot of misconceptions about the protocol. The biggest misconception is that the only major difference between IPv6 and IPv4 is that the former has a significantly larger address space. This misconception leads to some stupid objections to implementing it. The first is that IPv6 addresses can't be memorized like IPv4 addresses. Anybody who has worked with large networks knows that IPv4 address can't typically be memorized for very long either. This is why DNS</abbr> exists. You shouldn't refer to your systems by their IP addresses regardless of the version you're using. You should have a DNS server that provides memorable names to your systems.</p>
Another objection to implementing IPv6 is that it's complicated to setup. It's actually much easier to setup an IPv6 network than an IPv4 network. My home network is a good example. IPv4 interfaces don't generate their own addresses (technically they can, but those addresses aren't useful in most cases) so you need to either statically assign an address to each device or use a DHCP</abbr> server. I use DHCP to assign addresses to my devices. I operate two Kea DHCP servers configured in high availability mode for redundancy. Meanwhile, IPv6 can utilize protocols like SLAAC</a></abbr> to automatically generate their own addresses. My ISP provides me an IPv6 prefix, which my router automatically receives and advertises. Every IPv6 client can then generate an IPv6 address for itself based on that prefix. The addresses they generate are also globally routable.</p>
The last part is important. There are no more unclaimed IPv4 addresses, which makes them a scarce commodity. Not every ISP is willing to provide a static IPv4 address. Those that do typically charge a monthly fee per static IPv4 address. I rent my single static IPv4 address and have no interest in paying for more. I need to play tricks to provide all of my services via that single IPv4 address. When you connect to this blog via IPv4, several things happen. First my router uses port forwarding to connect your browser to my reverse proxy server. My reverse proxy server then uses <abbr="Server Name Indication">SNI</a></abbr> to determine where to route the connection. The connection is then proxied to the server that actually hosts this blog. This tower of redirection is necessary to host multiple websites and other servers via a single IPv4 address.</p>
There are effectively (obviously not literally) unlimited IPv6 addresses. My ISP provides me a /48 prefix. This gives me more IPv6 address than I could ever use. I could dole out 10 IPv6 addresses to every network enabled device in my house and still not make a dent in the number of addresses available to me. And all of those addresses are globally routable. This means when you connect to this blog via IPv6, you're connecting directly to the server hosting it.</p>
This fact frightens a lot of network administrators because they have this false concept that their local network is trustworthy whereas the Internet isn't. They like all of the redirection and games IPv4 requires because they believe it establishes are strong barrier between their trustworthy network and the untrustworthy Internet. Anybody who has read the news about network exploits knows this is false. Local networks aren't trustworthy. Every system you setup should be setup as if it were connected directly to the Internet. This is how I design my network.</p>
Even though my router has a firewall, every system I setup also has a firewall. Those firewalls are configured with the minimum number of open ports necessary. I also ensure SELinux is enabled on all of my systems (many network administrators disable SELinux rather than learn how to use it). I minimize the amount of unencrypted traffic on my local network. For example, my reverse proxy has a dedicated WireGuard connection to each of my servers is proxies. All traffic between it and the proxied servers goes through those WireGuard connections. The main sources of unencrypted traffic are my DHCP servers and that's because DHCP can't be secured. My networking equipment does use DHCP Guard to ensure only my DHCP servers can provide leases through. IPv6 eliminates the need for those WireGuard connections by eliminating the need for the reverse proxy. It also eliminates the need for DHCP since devices can configure their own IPv6 addresses.</p>
I've heard a few network administrators complain that providing websites via IPv4 and IPv6 complicates setting up TLS. This might have been the case when getting signed certificates was largely a manual task, but it's no longer the case now that getting signed certificates is largely automated. I've automated the task of getting signed certificates ever since Let's Encrypt's signing certificate was added to every major browser. Originally I did this via certbot, but now that I use Caddy</a>, my HTTPS servers do it automatically (a few of my servers like my e-mail server still use certbot). Certbot and Caddy both operate perfectly well via IPv6. In fact this blog is secured by separate TLS certificates depending on if you connect via IPv4 or IPv6. If you connect via IPv4, you use the certificate obtained by Caddy on my reverse proxy. If you connect via IPv6, you use the certificate obtained by Caddy on the server hosting my blog.</p>
I'll end my rant here since this post is getting longer than I anticipated. In summary, IPv6 is better than IPv4 in every way. Every objection to implementing IPv6 is dumb. Network administrators who have the option to implement IPv6 but don't are wrong.</p>


Upgrades
2025-10-15T12:00:00+00:00
I've been more silent as of late than usual. This is because I've been spending a lot of my free time upgrading my network infrastructure in anticipation of a major Internet upgrade. Most of this involved backend work that you readers won't notice. Suffice to say that I made major edits to my Ansible playbooks and redid several parts of my home network.</p>
A bit more than five years ago my wife and I moved to this house located in the rural Wisconsin. We loved everything about the property except for one thing: the only Internet option was DSL. I had DSL when I was in college and wasn't looking forward to going back to it after having enjoyed cable Internet for a decade, but the property was good enough that I was willing to make the sacrifice. One upside is the DSL was decent at 20 Mbps down and 1.5 Mbps up. I was also able to get a static IP address so I could continue self-hosting my services.</p>
Eventually Starlink became available in my area so I signed up. It was a significant upgrade. I regularly got 200 Mbps down and between 15 and 20 Mbps up. The two downsides were that my Starlink connection went offline during severe storms and I couldn't get a static IP address. Therefore, I kept the DSL so I had a backup when the weather was bad and could continue hosting my services. My home network had two gateways and each client was assigned the appropriate gateway from my DHCP servers. My self-hosted services used the DSL gateway and everything else used the Starlink gateway unless there was severe weather. When there was severe weather, I ran an Ansible script that rebuilt my DHCP servers' configurations to assign every client the DSL gateway. Each client would start using the DSL connection when their DHCP lease expired and renewed (I use short leases for this reason). I admit it wasn't the most elegant solution, but it was good enough for how rarely the Starlink connection went offline.</p>
When I first bought this house, the DLS was provided by CenturyLink. CenturyLink are a shower of bastards. Whenever the DSL went offline, I had to suffer through a minimum of five phone transfers to get to a tech that could actually fix the issue. Eventually CenturyLink sold its DSL business to Brightspeed. Brightspeed somehow managed to be worse.</p>
About a year ago a contractor buried fiber down my road. I expected to receive some notice that an ISP would be providing fiber service in my area but no such notice ever arrived. I searched high and low for the ISP that owned the fiber but found none. A few months ago Brightspeed announced that my static IP address would change. My history with Brightspeed told me that the changeover wouldn't go well so I searched for the owner of the buried fiber once again. This time I found the ISP, which is Lakeland Communications. I gave them a call and they confirmed that they provided fiber to my area. The only downside to me was the cost of installing the fiber from the road to my house. My house is far from the road so the cost of connecting my house to the fiber wasn't cheap (it was reasonable though considering the distance).</p>
I was able to push off Brightspeed's static IP address assignment, which turned out to be a blessing. To say the static IP address change went poorly would be an understatement. They managed to fuck it up completely. I had no Internet connectivity after the change. I spent a total of two hours on the phone with their technical support, all of whom are worthless, to no avail. Fortunately, Lakeland was scheduled to complete the fiber installation two days after that so I was only without my self-hosted services for about 48 hours.</p>
Lakeland Communications proved to be competent and easygoing. Because I self-host services including e-mail, I expected to need to sign up for a business account (what I've always had to do with other ISPs), but was told that I could self-host from a residential connection without any issue. They were also more than happy to let me use my router instead of theirs, which made reconfiguration my network as easy as changing the static IP address in my UniFi Network Controller. The speeds are good enough that I have to upgrade my router since I'm running an old Ubiquiti Security Gateway 3P and my Wi-Fi access points.</p>
Now when you access this site, it should download significantly faster. I can finally make full use of a number of my self-hosted services too. It's nice to have these capabilities again after five years of DSL restricting me to making sparse use of my services when I'm not home.</p>


If You're Reading This
2025-08-30T12:00:00+00:00
If you you're reading this, I've configured my new reverse proxy correctly. I've spent the last couple of days performing a major overhaul of my network infrastructure. This overhaul gave me the opportunity to rethink a few of my servers. The biggest rework was with my reverse proxy. For years I've been using Nginx to provide TLS connections for my various self-hosted services. Many of my Nginx configuration files were nightmares to read and edit because of the complexity of some of the services I self-host. It was finally bad enough that I started searching for alternatives. I eventually came across Caddy</a></p>
Caddy fucks. Consider the Nginx reverse proxy configuration for this blog, which is one of the simplest configurations on my reverse proxy server:</p>
map $http_upgrade $connection_upgrade {
</span>    default upgrade;
</span>    '' close;
</span>}
</span>
</span>server {
</span>    listen *:80;
</span>    server_name www.christopherburg.com;
</span>
</span>    include conf.d/certbot.conf;
</span>
</span>    location / {
</span>        return 301 https://www.christopherburg.com$request_uri;
</span>    }
</span>}
</span>
</span>server {
</span>    listen *:443 ssl http2;
</span>    server_name www.christopherburg.com;
</span>
</span>    autoindex off;
</span>    access_log <path to the access logs>;
</span>
</span>    ssl_certificate <path to the certificate>;
</span>    ssl_certificate_key <path to the certificate key>;
</span>
</span>    ssl_trusted_certificate <path to the trust chain>;
</span>
</span>    # A bunch of TLS configurations to ensure old, weak ciphers aren't used.
</span>    include conf.d/ssl.conf;
</span>
</span>    location / {
</span>        proxy_pass http://<actual server hosting site>;
</span>
</span>        include conf.d/headers.conf;
</span>
</span>        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
</span>        proxy_set_header X-Forwarded-Port $server_port;
</span>        proxy_set_header X-Forwarded-Scheme $scheme;
</span>        proxy_set_header X-Forwarded-Proto $scheme;
</span>        proxy_set_header X-Real-IP $remote_addr;
</span>        proxy_set_header Host $host;
</span>
</span>        proxy_request_buffering off;
</span>        proxy_read_timeout 86400s;
</span>        client_max_body_size 0;
</span>
</span>        # Websocket
</span>        proxy_http_version 1.1;
</span>        proxy_set_header Upgrade $http_upgrade;
</span>        proxy_set_header Connection $connection_upgrade;
</span>    }
</span>}
</span></code></pre>
Now look at the Caddy equivalent:</p>
www.christopherburg.com {
</span>    reverse_proxy <actual server hosting site>
</span>}
</span></code></pre>
Caddy handles most of the heavy lifting. It ensures TLS is enabled, automatically pulls certificates for your sites via Let's Encrypt, automatically redirects HTTP to HTTPS, and has sane defaults for all the reverse proxy configurations. Writing the Ansible playbook to build my reverse proxy took me about an hour and that's with zero Caddy experience beforehand.</p>
With this change comes another. I finally shutdown the old Wordpress blog. It's URL, blog.christopherburg.com, now redirects to here. Setting up this redirect in Caddy was as simple as:</p>
blog.christopherburg.com {
</span>    redir https://www.christopherburg.com/blog/
</span>}
</span></code></pre>
Caddy is working so well that I'm wondering when the other shoe will drop. When will a weird edge case rear its ugly head and bring me hours of frustration as I try desperately to fix it? I don't know the answer to that. Until it does appear though, I'm very impressed with Caddy. If you're self-hosting websites, I strongly encourage you to check it out.</p>


Ansible Copy versus Synchronize
2024-10-31T04:00:00+00:00
I run a lot of servers since I self-host almost all of the online services that I use. To simplify my life, I automate as much of the work as I can with Ansible</a>.</p>
When I started migrating from my WordPress site to this one, I built an Ansible playbook to automate building this site's server. One step in that playbook is copying the files output by Zola, which are located on my controller system, to the web server.</p>
The first version of my playbook utilized Ansible's copy module</a>.</p>
-</span> name</span></span>:</span> "</span>Copying website files to the server."</span></span>
</span>  ansible.builtin.copy</span></span>:</span>
</span>    src</span></span>:</span> "</span>{{ website_repository_path }}"</span></span>
</span>    dest</span></span>:</span> "</span>/var/www/"</span></span>
</span>    seuser</span></span>:</span> "</span>system_u"</span></span>
</span>    serole</span></span>:</span> "</span>object_r"</span></span>
</span>    setype</span></span>:</span> "</span>httpd_sys_content_t"</span></span>
</span>    owner</span></span>:</span> "</span>nginx"</span></span>
</span>    group</span></span>:</span> "</span>nginx"</span></span>
</span>    mode</span></span>:</span> "</span>u+rx-w,g+rx-w,o+rx-w"</span></span>
</span></code></pre>
website_repository_path</code> is the path on the controller system to the website files. The server I'm using uses SELinux, hence the seuser</code>, serole</code>, and setype</code> parameters. Since the site is static, I set the permissions so the files are read-only (the web server should never write to this directory so there's no reason to give it permission to do so).</p>
I started the Playbook and went to do other things. I returned almost three hours later expecting the new website to be up and running. Instead the playbook was still copying the website files from my controller system to the web server. I logged onto the web server and verified that files were being copied, albeit very slowly. Over three hours to copy a small website obviously isn't sustainable so I started looking for another solution.</p>
My search lead me to the Ansible synchronize module</a>. The documentation told me everything I needed to know:</p>

synchronize</code> is a wrapper around rsync to make common tasks in your playbooks quick and easy.</p>
</blockquote>
I use rsync to copy files between computers all the time. I know it's fast. So I made a naive change in my playbook.</p>
-</span> name</span></span>:</span> "</span>Copying website files to the server."</span></span>
</span>  ansible.builtin.synchronize</span></span>:</span>
</span>    src</span></span>:</span> "</span>{{ website_repository_path }}"</span></span>
</span>    dest</span></span>:</span> "</span>/var/www/"</span></span>
</span>    seuser</span></span>:</span> "</span>system_u"</span></span>
</span>    serole</span></span>:</span> "</span>object_r"</span></span>
</span>    setype</span></span>:</span> "</span>httpd_sys_content_t"</span></span>
</span>    owner</span></span>:</span> "</span>nginx"</span></span>
</span>    group</span></span>:</span> "</span>nginx"</span></span>
</span>    mode</span></span>:</span> "</span>u+rx-w,g+rx-w,o+rx-w"</span></span>
</span></code></pre>
The mode</code> parameter differs between the copy</code> and synchronize</code> module. Moreover, the synchronize module doesn't support the SELinux parameters. So I made another change.</p>
-</span> name</span></span>:</span> "</span>Copying website files to the server."</span></span>
</span>  ansible.builtin.synchronize</span></span>:</span>
</span>    src</span></span>:</span> "</span>{{ website_repository_path }}"</span></span>
</span>    dest</span></span>:</span> "</span>/var/www/"</span></span>
</span>    mode</span></span>:</span> "</span>push"</span></span>
</span>
</span>-</span> name</span></span>:</span> "</span>Setting the permissions for the website files in /var/www."</span></span>
</span>    ansible.builtin.file</span></span>:</span>
</span>    path</span></span>:</span> "</span>/var/www/"</span></span>
</span>    state</span></span>:</span> "</span>directory"</span></span>
</span>    recurse</span></span>:</span> "</span>true"</span></span>
</span>    seuser</span></span>:</span> "</span>system_u"</span></span>
</span>    serole</span></span>:</span> "</span>object_r"</span></span>
</span>    setype</span></span>:</span> "</span>httpd_sys_content_t"</span></span>
</span>    owner</span></span>:</span> "</span>nginx"</span></span>
</span>    group</span></span>:</span> "</span>nginx"</span></span>
</span>    mode</span></span>:</span> "</span>u+rx-w,g+rx-w,o+rx-w"</span></span>
</span></code></pre>
The playbook ran, but when it got to the synchronize task, it stopped with an error. The error indicated that the playbook required the sudo password for the target system. I found this quite strange since I set the entire playbook to run with elevated privileges on the target system. The playbook already knows the sudo password. This is a good time to remind everyone to completely read the documentation before using something. Had I done so, I'd have seen this:</p>

Currently, synchronize is limited to elevating permissions via passwordless sudo. This is because rsync itself is connecting to the remote machine and rsync doesn’t give us a way to pass sudo credentials in.</p>
</blockquote>
That's easy enough to work around. Tell the synchronize</code> task to run with regular user permissions, which is done by including become: "no"</code> in the parameter list (assuming you set become: "yes"</code> globally in the playbook like I did). However, I could no longer synchronize the files directly to /var/www/</code> because the Ansible user doesn't have permission to write to that directory. Therefore, I had to change the workflow slightly.</p>


Synchronize the files from my controller system to a directory on the web server to which the Ansible user has write permissions.</p>
</li>

Copy the files from that location to /var/www/.</p>
</li>

Clean up the originally copied files.</p>
</li>

Set the correct permissions on the files in /var/www/.</p>
</li>
</ol>
Ansible is helpful in that there is an ansible_user</code> variable so I could write the files to /home/{{ ansible_user }}/www/</code>. The steps I described above ended up looking like this.</p>
-</span> name</span></span>:</span> "</span>Copying website files to the server."</span></span>
</span>  become</span></span>:</span> "</span>no"</span></span>
</span>  ansible.builtin.synchronize</span></span>:</span>
</span>    src</span></span>:</span> "</span>{{ website_repository_path }}"</span></span>
</span>    dest</span></span>:</span> "</span>/home/{{ ansible_user }}/www/"</span></span>
</span>    mode</span></span>:</span> "</span>push"</span></span>
</span>
</span>-</span> name</span></span>:</span> "</span>Moving the website files to /var/www."</span></span>
</span>    ansible.builtin.copy</span></span>:</span>
</span>    remote_src</span></span>:</span> "</span>true"</span></span>
</span>    src</span></span>:</span> "</span>/home/{{ ansible_user }}/www/"</span></span>
</span>    dest</span></span>:</span> "</span>/var/www/"</span></span>
</span>
</span>-</span> name</span></span>:</span> "</span>Removing files at temporary copy location."</span></span>
</span>  ansible.builtin.file</span></span>:</span>
</span>    path</span></span>:</span> "</span>/home/{{ ansible_user }}/www/"</span></span>
</span>    state</span></span>:</span> "</span>absent"</span></span>
</span>
</span>-</span> name</span></span>:</span> "</span>Setting the permissions for the website files in /var/www."</span></span>
</span>    ansible.builtin.file</span></span>:</span>
</span>    path</span></span>:</span> "</span>/var/www/"</span></span>
</span>    state</span></span>:</span> "</span>directory"</span></span>
</span>    recurse</span></span>:</span> "</span>true"</span></span>
</span>    seuser</span></span>:</span> "</span>system_u"</span></span>
</span>    serole</span></span>:</span> "</span>object_r"</span></span>
</span>    setype</span></span>:</span> "</span>httpd_sys_content_t"</span></span>
</span>    owner</span></span>:</span> "</span>nginx"</span></span>
</span>    group</span></span>:</span> "</span>nginx"</span></span>
</span>    mode</span></span>:</span> "</span>u+rx-w,g+rx-w,o+rx-w"</span></span>
</span></code></pre>
When I ran the playbook with these changes, it took only a few seconds to copy the files from the controller system to the web server. The longest operation was setting the file permissions once the files were moved to /var/www/</code>, which took no more than 30 seconds. This is sustainable.</p>
If you're using Ansible to copy a lot of files from one system to another, consider the synchronize</code> module. It's significantly faster.</p>