I know this is an edge case, but in a general sense it looks like Roon is not using mDNS responses correctly. This causes what appears to be random connectivity issues for anyone that has a mult-homed core server and a router that is acting as an mDNS reflector.
The Basics
If you have a multi-homed core server and an mDNS reflector on the network, then endpoints can intermittently stop responding. When you try to press play it will just stop and never stop. if you look in the log you will see Roon is trying to connect to the mDNS reflector instead of the endpoint. I have only tested this on a Mac Core.
Why Does it Happen?
It depends which interface Roon picks up the mDNS packet on the last time it refreshed. If Roon gets the packet on the subnet the end-point is on, then Roon works as expected. If it gets a reflected packet on a different interface, then it fails as described above.
It appears Roon is trying to connect to the source address of the mDNS packet instead of the address in the A record in the mDNS packet. This is not proper behavior. This should be very easy to fix. Roon is already pulling the A record address from the packet as it shows in the interface. It is not clear why that same address is not used for the connection.
For those of us doing implementations for folks in higher end residential settings this is a huge pain. A google search reveals I am not the first person to experience the problem, but I have never seen A resolution posted. I know only flat networks are supported officially, but this really is a bug in the way the core server is using mDNS and it would be great if we could get it fixed eventually.
I am new to Roon and yes this is my first post. It did appear that if I posted this anywhere else it would have been moved here anyway 
. I am not sure if anyone at Roon reviews this particular forum, but I would love any suggestions on how to request a fix for a bug that doesn’t really affect people in supported configurations.
Have a great day!
Matt
edit: Adding this packet for a quick example.
192.168.60.1.mdns > core.mgmt.local.63938: [udp sum ok] 51313*- q: PTR (QM)? _raop._tcp.local. 1/0/3 _raop._tcp.local. [10s] PTR 0005CD7183B4@Denon AVR-X4300H._raop._tcp.local. ar: 0005CD7183B4@Denon AVR-X4300H._raop._tcp.local. [10s] SRV Denon-AVR-X4300H.local.:57415 0 0, 0005CD7183B4@Denon AVR-X4300H._raop._tcp.local. [10s] TXT “cn=0,1” “da=true” “et=0,4” “ft=0x445F8A00,0x1C340” “fv=p20.1.544.240” “md=0,1,2” “am=AVR-X4300H” “sf=0x4” “tp=UDP” “vn=65537” “vs=366.0” “pk=945614443fc45acbd083465d84b5befab1ae7f4196c64fa172f1e0d749fe2cc2”, Denon-AVR-X4300H.local. [10s] A 192.168.110.249 (327)
If Roon core sees this reflected packet first it will try to connect to 192.168.60.1 to play music instead of 192.168.110.249. It will properly show 192.168.110.249 in the UI, but the log shows it trying to connect to 60.1.