IPv6

Perhaps most exciting, I got IPv6 up and running! Hurricane Electric was satisfied with their ability to ping me, and I was able to set up an SIT/6in4 tunnel through their tunnel broker service, with the router holding down this end; with a little minor tweaking, I got it routing packets and making router announcements for our /64, and incredibly my desktop just picked up an address immediately.

Unfortunately, our ISP happened to go down just as I was starting to work on routing and firewalling for IPv6, which led me to chase a ghost for a while. Once I realized the problem, I was in the interesting situation of knowing IPv6 was working over the Internet and over the LAN, but not knowing if the two would be able to talk to each other. Once the ISP did come back, it did in fact Just Work, so the whole network now has IPv6!

Except that I couldn't actually talk to my server from the Internet (though I could talk to my desktop). It was a slog to figure out what was wrong, and I fought with two firewalls pointlessly for several hours before finally realizing they were both actually passing the packets. It turns out they were being dropped by a Linux feature I wasn't familiar with, rp_filter. rp_filter is a bit of kernel code that implements RFC 3704; specifically, it checks incoming packets against the routing table, and if they're not coming from where the kernel's routing code would expect to send packets going to that origin, they get dropped. It turned out that my old Wireguard tunnel, which I had been using for IPv6 on that machine in particular, was still running, and the kernel had decided it was a better route to the Internet than the Ethernet link; thus, it would only accept packets on Ethernet if they came from LAN addresses. I shut down the tunnel, and everything started working.

ACME and mod_md

One of the other things I wanted to accomplish was to finish the process of getting rid of the stand-alone unpackaged Go programs I was using for a couple things. I had previously removed Gitea in favor of cgit (which, by the way, dropped my load averages considerably), which left only Caddy as a target. With Gitea removed, Caddy's only job was to terminate TLS and reverse-proxy everything to Apache, which seemed rather pointless. The main reason I'd been using Caddy was due to its extremely convenient ACME support, which allows it to get certificates from Let's Encrypt or another similar certificate authority automatically.

It turns out Apache can actually do this too, and has been able to for quite some time. mod_md provides integrated ACME support, as well as a few convenience features such as automatically redirecting unencrypted HTTP requests to HTTPS. It's still more typing than Caddy, but I was able to get my six sites with their mildly varying configurations up in a couple hours, with a couple of hitches. And with that, I deleted Caddy and am now back to entirely packaged software that gets upgrades with zero effort.

XMPP

Another thing I've wanted to do is switch to my own XMPP server; I've heard running one isn't very difficult, so using someone else's server doesn't strike me as all that necessary. I installed ejabberd and fiddled around with the config file to make it talk to LDAP and PostgreSQL (why not, right? I have the database server anyway), then after some firewall fiddling I was able to connect with my LDAP account and send and receive messages to/from my account on my previous server. After that, I had to hook up Apache to proxy its HTTP(S) ports. I still haven't completely finished XMPP setup yet; I have to fix a certificate issue with Apache for the XMPP site, and make some minor additions for full compliance with the recommended suite of XEPs (mostly to support Web-based clients, which I don't use, but 100% is a shiny number). Once I have all of this done, I'll switch over to the new XMPP account (you'll know when I do because I'll change the XMPP address on my profile, and I'll probably post a note).