Weird Openvpn/firewall established/related problem

Using OpenWrt 22.03.0 x86 64 as a VM with Openvpn client.
I have a simple vpn server that I can use to communicate via client to client connections to remote routers etc. It's worked well for years.
Now I have an issue with connecting to the router after the connection is up unless I access Luci on port 80. Once I do that I can then use ssh and https. It's like there's an established/related rule in the firewall that gets activated once I use port 80.
This initial access seems to time out if I don't keep Luci active or leave an ssh connection open.
I've reverted all the firewall back to default and tried MTU MSS settings etc that usually plague VPNs but this is different.
The only thing that makes it work is a connection to Luci on port 80 and then it works perfectly. I don't even have to log in to Luci, most times I can just access the login page or refresh it.
This config works fine on v19 and on an old Lede router.
I've tried increasing the verbosity in Openvpn on the router and get nothing really helpful.
Anyone have any idea on what is allowing access on port 80 so I can try and replicate that on port 22?

Still having issues with this and hoping someone can shed some light on it.
It's not just port 80 that makes this work but whatever port I put the nonssl uhttpd port on will trigger a rule somewhere and make this work when accessed.
I've tried creating the tun interface and firewall zones no changes.
I installed openssh server and get the same result but with better logging.
It fails when the ssh server on the router sends this
Wed Sep 28 04:33:57 2022 auth.debug sshd[6954]: debug1: SSH2_MSG_KEXINIT sent [preauth]

If I access the luci admin from the same client I get this reply and all the rest of the debug.
Wed Sep 28 04:33:57 2022 auth.debug sshd[6954]: debug1: SSH2_MSG_KEXINIT received [preauth]

I can also ping through to the ssh server from the ssh client.

The routing table is exactly the same (exept for client IPs) as any other working Openwrt clients on the VPN.
Nothing shows up as an error in logs for dropped packets at all if I enable logging for the tun interface.