tl;dr
Does anyone use an OpenBSD router for their internal network? If so, are you using either a BiNAT or split–horizon DNS system? How is it working out, and is there any additional overhead for management that you notice?
Background
I am currently shifting the router(s) for my internal network from EdgeOS–based EdgeRouter X and EdgeRouter Lite over to a PC Engines apu4c4 running OpenBSD.
EdgeOS
On EdgeOS, hairpinning is handled quite nicely with a single checkbox used on the router's web UI on the Firewall/NAT > Port Forwarding tab, or through the equally simple:
set port-forward hairpin-nat enable
from the command line. This makes so that when accessing my internal Channels DVR instance using its public FQDN (i.e. https://a0b1c2d3e4f5.channelsdvr.net), the router automatically translates that to its local address on the internal network. In this way, the only information that leaves the internal network is the DNS request to get the network's external public IP. Then, whenever any client inside the network tries to access the public IP, the router applies its port forwards and NAT to redirect the connection to the internal host.
OpenBSD PF
BiNAT
This type of situation is handled a little bit different by pf, OpenBSD's packet filter. The first is similar to what EdgeOS does, by handling the NAT functions in combination with a rdr-to rule force internal requests to the public IP address to be redirected to the local host without ever leaving the internal network.
(This type of setup is well documented in the pf FAQ under Traffic Redirection: Redirection and Reflection – rdr-to and nat-to Combination. Additionally, pf also has a binat-to rule that combines these two rules into one.)
While it is a little more work to maintain BiNAT rules, they can easily solve the problem hairpin problem when the internal network is NATed.
Split–Horizon DNS
The second option for solving this situation is running a split–horizon DNS on the internal network. This is the option I was originally considering. This would allow me to manage my own redirections to external domains. However, since the ACME client in the DVR server is DNS–based, I'm not sure if that would impact the DVR server's ability to renew its certificates.
Maintaining a few additional entries on an internal DNS would not be much more overhead than what would normally be happening on the network. I had already planned to manage a separate unbound server to act as both a caching resolver, as well as allow me to maintain my own certificates for internal servers and services that only operate over HTTPS (such as my Unifi Controller and Unifi Video NVR).
Differences
Maintaining either a BiNAT or split–horizon solution requires roughly the same amount of work. In the end, it's only a couple of extra lines in either pf.conf or unbound.conf to facilitate each. Also, since both pf and unbound will already be running on the router, this extra duty will not require any additional software either way.
Experiences
Is anyone running a similar setup? If not OpenBSD, perhaps something based on FreeBSD like pfSense or OPNsense. While FreeBSD's version of pf was forked from OpenBSD's some time ago, I believe they are still similar enough that rulesets could easily be translated between the two.
Since I am leaning more towards the split–horizon DNS option, I am most curious to hear if this type of setup affects Channels DVR, specifically with it obtaining/renewing its certificates.