You’ve only uncovered a small bit of the puzzle. What you found is the brute force way Roon attempts to identify core after all other discovery methods have failed. Sending a broadcast storm onto the network is certainly “caveman” (I like that, well said).
However, even if you did forward/leak this to the other broadcast domain what you’ll find is things still don’t work. Part of the negotiation for remote is that the core actually creates a TCP socket back to remote (turning core into the client / remote into the “server”). This socket is used to push all of the configuration information of that client (services, endpoints, etc.) Roon uses a range of ports in order to do this so you’d have to open that entire range for this to work.
I’m still reverse engineering this but from what I’ve gathered so far, and in my head, the only reliable way I can determine to make this work is using NAT + some multicast relay service. I can configure my router to NAT the inside Roon IP to an outside IP on the non-local lan segment. What I’ve not gotten deep enough into my reverse engineering though is if Roon core/remote embeds it’s IP in any of the communication which would then require the NAT is “Roon aware”. This is a mess and way too time consuming. I’ve actually just put some tablets on the “Roon network” and have called it good at this point until I can get back into figuring this out.
The other suggestion I got, which is excellent, is to use Roon Extension: Roon Web Controller v1.2.0 This is a web interface into Roon requiring nothing more than the http socket to function. My limitation is extensions don’t work directly with ROCK so, again, I’ve got some work to do.
Good luck. You may just want to pluck a $100 Fire 10 off Amazon and call it good for now. There is way too much music to listen to to be distracted by this amount of work to get Roon functional across LAN segments.