Trying to find a solution to this as well. It doesn't seem OpenVPN has an option to forward headers which basically makes it impossible to use openvpn as the primary on port 443 if you need to see client IP addresses on haproxy..

As an alternative, I wondered if it might make sense to set haproxy listening on 443 and OpenVPN as a backend on a different port. Has anyone tried this yet? Does this cause double encryption (slow down the connection too much)? Here is an example of one guy who claims to have got it working:
https://discourse.haproxy.org/t/haproxy-with-openvpn-over-tcp-443-on-pfsense/4731/2

EDIT

It looks like he create a TCP frontend on 443 with a default backend going to OpenVPN:TCP:1194 and an acl that checks for SSL and sends SSL traffic to an HTTPS Backend set to localhost:9443. Then he configured localhost:9443 as a Frontend that handles the forwarded Web Traffic.

That looks like it should work, but It's a bit too complicated for me to test on my live server right now and I don't have a lab setup. Happy to help anyone else who might have a lab environment setup for testing.

@aiden21c Good! I still think that some good came out of this whole situation, though.

For one, even if your current setup works well, the ideal setup for your whole company network is still with VLANs The order of the firewall rules needs to be held in mind (PfSense processes firewall packet rules from top to bottom):
1c9cfaf5-771e-4d8c-959e-e798596807bd-image.png
Rule 3 catches all traffic filtered by rules 4, 5, 6. It needs to be last. Rules 5 and 6 have destination address "Any" instead of "LAN Address". A way that helps (me personally) to keep fw rules tidy is to add 4 separators, the top one named "GENERAL BLOCK" (for entire protocols, for example, no need to allow GRE, ESP, AH, OSFP... on a LAN with interconnected servers if there is no explicit need), a second separator named "INCOMING", a third separator named "LOCAL TO FW" and a fourth one named "OUTGOING". I also add separators named "PASS" and "BLOCK", with that order, under each main separator. Even if no further network changes seem necessary, it is best to avoid NAT. In the future, in order to reduce latencies or enable certain UDP services that cannot be NATed, you can check if the Cisco Router can do PPPoE passthrough for PfSense. Because PPPoE is a separate interface in PfSense, you can have both a PfSense-to-Cisco connection (OFFICE - 192.168.20.40/24, not as a Gateway) and a PPPoE adapter as a direct PfSense Gateway (because PPPoE is a Layer 2 protocol, doesn't use IPs, that is why its Point-To-Point, so it doesn't interfere with the 192.168.20.0/24 subnet at all) with a public IPv4 for PfSense. At some point, instead of having separate rules for each gateway and traffic type, you might want to implement Multi-WAN Load Balancing and Traffic Shaping to control which traffic type uses what Gateway. It is best to set static IPs for LAN through the DHCP server (without a dynamic address pool) and set your private IPs as Static Mappings. That way, you can use Host Overrides on Unbound, which would allow you to use hostnames (and no IPs) in your setups, and avoid unnecessary config nightmares in case, say, you want to put everything in Docker. You can just change the IPs in the Static Mappings of PfSense Unbound, add a BIND container to Docker (just to handle the inter-container IPs using the same hostnames) and be done with it.

@adamitj
DoT requests which are redirected to another server won't work anyway, because the SSL verification will fail.

Therefore I simply block all DoT and DoH in my network. Hence the clients have to do unencrypted DNS requests, which I can redirect as needed.

@Aba

Никогда не использовать сети 192.168.(0|1).x в продакшене. Меняйте адресацию на 10.10.10.0, например. Это первое, что говорит об "уровне" админа.

Не пользовать DNS Forwarder на пф. Разрабы по умолчанию его откл., задействовав DNS Resolver. Но нет, все еще есть люди, не ищущие легких путей.

Выдавать DNS по ОВПН можно прямо в настройках ОВПН. Возможно, настройки появляются при смене типа овпн.

Зы. Смотрю в связи с #самизнаетечем на пф и аналогичные продукты спрос вырос (удаленный доступ etc).

After a bunch of googling:

unbound is not ever authoritative dnsmasq CAN be authoritative. I'm working on it...