Closed seidnerj closed 2 years ago
Anyone?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been closed as no further activity has occurred.
Current Situation
I'm dealing with what seems to be a well-known issue, I have services on network A that are advertised via mDNS and I want them to be "seen" by devices on network B. As is well known, mDNS does not propagate to network B, as is by design. There are various solutions to this problem all based on retransmission of the relevant packets within network B (avahi reflection, mdns-repeater, mdns-tunnler to name a few). In most scenarios these solutions work pretty well.
In my particular scenario however, network B is not a "real" network, but rather a group of VPN clients connected to a VPN server running OpenVPN within network A. Trouble is, in this scenario, most VPN implementations (as does OpenVPN) simply discard multicast packets, so even within network B, no services can be advertised between the various clients, let alone service from network A. The only solution is to bridge the network (e.g. via TAP on OpenVPN for example), but this in not available on Apple devices (iOS/Mac OS X etc.).
Doing some more research, it seems the mDNSResponder service on Apple devices binds itself to 0.0.0.0, so in theory one could take the original multicast UDP packets and "convert" them to multiple unicast UDP packets with the same information, then re-send them, thereby overcoming said issue. Looking at Ciao's code it looks like this should be possible and even relatively easy.
I also did in fact confirm via Wireshark that such mDNS messages are received by the target even if sent by unicast UDP and not just when sent by multicast UDP.
Does the above make sense or am I barking up the wrong tree here?
Thanks in advance
Logs
Configuration
Environment
Process Supervisor
not applicable
Additional Context
No response