Two tech issues today, which caused a bit of debugging fun:

Firstly, I powered up an old iPhone SE to see if I could replicate a problem that a friend had been seeing. It was having some TLS issues and, as I dug further, it turned out to be all TLS issues rather than some. All connections to Apple services failed (so no updates, no synching, etc) and I couldn’t even unsubscribe it from iCloud in order to do a factory reset. For those who aren’t already familiar, one of the protections Apple puts in place to effectively make a stolen phone a brick is that wiping the phone requires disconnecting it from the Find My Phone service.

Unfortunately, if TLS is broken, so is the ability to remove it from iCloud. Originally, I thought this was probably a corrupted certificate store, but manually adding root certificates didn’t fix it. Turned out to be our old favourite: time. Once I had reset the time on the device, it had somehow ended up disabling automatic synchronisation, it worked just fine. So, if you find yourself with a flurry of TLS errors, check that the phone has the correct time and that synchronisation is enabled. This is under general -> date & time -> Set Automatically.

For anyone curious as to how you manually install a root certificate:

• Store the certificate as a PEM on a webserver you can access
• Use Safari to browse to that URL
• It’ll ask you if you want to add the profile: Accept
• Settings will have a new tab for Profiles, where you need to go and install the certificate.
• Enable the certificate in Settings > General > About > Certificate Trust

The other one was that I had added IPv6 to my Strongswan configuration and suddenly IPv6 would stop working after an hour or so in the FreeBSD jails on the machine. Turns out there’s a race condition and PF will pass packets for a bit before the state times out. This, of course, lead me down several rabbit holes and quite a bit of frustration trying to work out what was dropping packets. I had thought that maybe it was routing, but a few packet dumps showed that packets were moving just fine and I eventually found that it was the base host packet filter (rather than the jail, which is where I’d been spending most of my focus time given that it’s VNET and should have a separate stack). Turns out that I had /72 instead of /80 in the filter rules for the VPN subnet and that swallowed the jail subnet.

I was expecting VNET to route first and all the filtering to be done in the jail, but it turns out that the base system can and will impact VNET interfaces which are bridged to an external interface (in my case, the VNETs are bridged to em0). Be careful of your subnets, always double check them with subnetcalc or a similar tool rather than doing them in your head. Doubly true for IPv6.