colucci-web.it

Hi,

Thanks again for engaging with me on this.

I just sent you an email with the two tcpdumps attached.

Please confirm you received them.

Look forward to any insights this additional information may provide.

You're welcome.
I checked the results of the tcpdumps you sent me and the Android one doesn't have mDNS multicast packets.
I've done some testing with the Android emulator and the multicast packets are forwarded just fine, so it seems that the device you are using is not forwarding the multicast packets to the VPN interface.
If you have already added the 224.0.0.251/32 route as I suggested previously, unfortunately I don't think there is any other solution.

Thanks for the prompt reply...

Curious... how come the OpenVPN server is correctly sending the multicast packets to the Windows OpenVPN client and the same OpenVPN Server is not sending the multicast packets to the Android OpenVPN Client? The is no configuration difference I'm aware of that should affect one connection and not the other.

Are you saying is something on my specific phone - something that this particular version of Android or the Samsung changes to it is preventing?

(Sorry likely a noob question -- trying to wrap my head around this)

I just found this post https://stackoverflow.com/questions/372 ... id-devices - which does seem to suggest it is device specific.

I installed the "Mutlicast Tester" app mentioned in the stackoverflow post, but don't know enough to know how to use it to verify it is a device problem. The app is asking for a multicast IP and port, and then a "message to send". What could I put in these fields in my case to see if the packets are being sent / recieved?

It is not the server that does not send multicast packets but the client that does not send them.
In practice, the app that needs to connect to the iTunes server sends mDNS multicast packets, but the Android system on your device doesn't forward them to the VPN interface. I think this problem is due to some modifications made to the Android system by the manufacturer.
This behavior has already been confirmed by the tcpdump results.
The post you found on stackoverflow is still about multicast packets, but that's a different issue.