My home network uses a highly available default gateway, using VMs on 2 separate machines sharing a floating IP which is the default gateway IP.
Internal lan → gateway cluster → dmz lan → final gateway → internet
I’ve tried several OSes for this role.
I started out with 2 Debian VMs using keepalived. Works fine.
For awhile, I tried 2 RHEL 10 VMs using keepalived. After some time, the behavior changed. Internal hosts could still reach the internet, but could not reach any host on the other side of the gateway, in the dmz lan, as it it was walled off.
Switch back to Debian, everything works fine.
Try FreeBSD and carp - everything works fine.
So something in a RHEL 10 update broke access to the DMZ lan. Any ideas?
Your design is in a good place. The fact that Debian with keepalived and FreeBSD with CARP both work exactly as expected shows the topology itself is sound and that your routing approach is solid.
When two different OSes handle the same layout with vary like this, it usually means the issue lies in something RHEL 10 changed under the hood rather than anything in your setup.
RHEL 10 shifted a few defaults that can block routed traffic between your internal networks even when internet access still works. The main ones showing up lately are stricter nftables forward rules and tighter rp_filter behavior, either of which can drop DMZ-bound packets in a VRRP setup.
Since your other OS tests work cleanly, the architecture itself is likely fine. On RHEL, a look at rp_filter and the forward chain may reveals which new default walled off the DMZ.