How to use bonjour (mDNS/DNS-SD) in a Qube?

[Fred]

So I have iTunes in a Qube -- the best place for it IMHO ;-).

I'd like to be able to use AirPlay. Since I'm not bridged and the
AirPlay protocol uses mDNS/DNS-SD I need a way for the multicast to work
from a Qube without violating any of the Qubes careful network design.

e.g. One idea is to have my Windows HVM have a direct non NAT'd
connection. But I'm not sure how to do this and if it's even
desirable/sensible from an isolation PoV.

Another idea is to install/enable something like avahi in fedora23
template and then on each network devices set it to reflect. I've not
used avahi before but a) it's in fedora and even seems to be in the
default template though disabled and b) seems like it's a one liner in
its config to get cross subnet multicast working. But I'm not sure what
the consequences of that are. Another service enabled in the template
just to satisfy a single Qubes requirements does seem to be a bit much.
Perhaps a third option is to create dedicated network infrastructure for
the Windows HVM to use (sys-net-avahi sys-firewall-avahi).

I thought this might be a (semi)common issue and was keen to hear others
suggestions or if not maybe a pointer in how to best solve the issue of
Qubes consuming services which require cross-subnet or multicast
support. I'd imagine this could also be a problem with other similar
services (video, voice).

[Fred]

Oh forgot to add. I did try setting the NetVM for the Windows HVM to
sys-net to no avail. Thought that might give a non-NAT'd direct connection.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, Dec 28, 2016 at 10:14:01AM +0000, Fred wrote:
>
> So I have iTunes in a Qube -- the best place for it IMHO ;-).
>
> I'd like to be able to use AirPlay. Since I'm not bridged and the
> AirPlay protocol uses mDNS/DNS-SD I need a way for the multicast to work
> from a Qube without violating any of the Qubes careful network design.
>
> e.g. One idea is to have my Windows HVM have a direct non NAT'd
> connection. But I'm not sure how to do this and if it's even
> desirable/sensible from an isolation PoV.

Direct - not-NATed network access is very hard to achieve in Qubes
architecture.

> Another idea is to install/enable something like avahi in fedora23
> template and then on each network devices set it to reflect. I've not
> used avahi before but a) it's in fedora and even seems to be in the
> default template though disabled and b) seems like it's a one liner in
> its config to get cross subnet multicast working.

As with most of network services - it will enlarge attack surface.
As for avahi - I don't know what exactly it's capable of - for example
can it be forced to remotely start other services/programs? Drill holes
in firewall (like UPNP)? Or "just" service discovery? Those are
questions to ask when you consider enabling network service.

> But I'm not sure what
> the consequences of that are. Another service enabled in the template
> just to satisfy a single Qubes requirements does seem to be a bit much.

You can start the service just in one Qube - simply start it in
/rw/config/rc.local there (remember to make the file executable!).

> Perhaps a third option is to create dedicated network infrastructure for
> the Windows HVM to use (sys-net-avahi sys-firewall-avahi).

You'll probably still need a single sys-net, unless you get multiple
network adapters. But separate sys-firewall makes some sense.

> I thought this might be a (semi)common issue and was keen to hear others
> suggestions or if not maybe a pointer in how to best solve the issue of
> Qubes consuming services which require cross-subnet or multicast
> support. I'd imagine this could also be a problem with other similar
> services (video, voice).

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYZCUmAAoJENuP0xzK19csX/8H/iF7RTy72VXcSttW2GG1GYdS
JkjIy9Q1TfSgXI5BeQS5uuqEnKTqXSKZ2TlqyGsfwwJmQWkyhbeOQ0IBK09cb8t8
bRkwcsbksecMFFjcjxHJbDgE3PpOrer0+pMN+UMRGD59Eu7fnuyCGI1Pyf3L21To
yKCF+E0yiSjhGh5KjTFh5okLH+weKz6xzUDXUAZIpaYFUa8k5d4eYnTlu8HWnweW
xis+6o2ZgNPFMjmnG+GriUTWEvhQhn9ycWuYLXNBmuqsaEp0+2bTfvOnAK+xhd+S
t1bqrzP07y2Mswaf0265rC+XD0ka3kIqX4Zp1vALK40Vk8f8kp9dFMiQNC6wbFo=
=+HnN
-----END PGP SIGNATURE-----