This is a guide on how to configure cOS Core to work with Multicast DNS (mDNS). This information given has been tested with a Linux client + Mopria, however, the same principals should be applicable to other client and mDNS traffic combinations. For reference, the mDNS RFC can be found at: https://tools.ietf.org/html/rfc6762

DNS-SD typically runs on top of mDNS but it can also query a regular DNS server provided that the server is configured to hand out these records. However, this is unusual.

It is important to understand that mDNS traffic mostly consists of UDP multicasts to address 224.0.0.251, port 5353. An example mDNS query is illustrated in the output below which comes from the Linux tool “mdns-scan”:

The mds-scan example below shows the mDNS response from a multifunction printer/scanner:

Could IGMP Rules be used?

It is possible to set up cOS Core for mDNS using IGMP Rules (these are found under Routing in the WebUI). However, this assumes that all network components will process IGMP correctly. Using IGMP could also mean difficulties troubleshooting since nothing would work until the firewall receives the IGMP rebroadcasts.

A simpler alternative to IGMP is to use Multicast Policy entries in the IP rule set. These will always forward multicasts, regardless of any IGMP traffic.

Using IGMP is more suited to high traffic levels, where the amount of traffic flowing may need to be limited and mDNS packets need to be received.

Using Transparent Mode with Multicast Policies

Transparent mode should be enabled

cOS Core transparent mode needs to be enabled on the interfaces. Without this, TTL=1 multicasts will be dropped (although a possible workaround would be that all systems use a higher TTL). Note also that the “Forward Broadcast Traffic” option does not need to be enabled on interfaces for this to work (mDNS uses multicast, not broadcast).

Can using transparent mode be avoided?

Yes, it is possible. Static routes could be configured instead. However, having transparent mode on the sending interface is currently a requirement for leaving the TTL value unaltered by cOS Core.

With transparent mode compared to static routes, the only 2 differences will be:

• MAC addresses are not hidden.
• We can leave the IP TTL alone.

Create Multicast Policy entries for mDNS traffic flowing in both directions

Can you use interface groups to create a single rule set entry? Yes, it will work, but unfortunately the firewall will also duplicate the packet back out on the interface it came from, which is possibly dangerous if there is another network component doing the same thing.

As can be seen in the packet traces, mDNS responses are not sent to the IP address that sent the query. Instead, they are sent out to the multicast address. Therefore, mDNS multicasts have to be allowed in both directions using two rule set entries. Below is a screenshot showing a first Multicast Policy being created for traffic in just one direction.

“Destination: any” is used in the policy filter since it does not make sense to filter according to the routing table. The Require IGMP setting on the policy should be disabled. Leaving the IP address empty in the destination translation means that no translation will be performed.

A second, similar Multicast Policy must now be created that also allows mDNS traffic in the opposite direction.

cOS Core defaults to adding a route for 224.0.0.0/4 to "core" so you could also set the destination interface to "core".

Allowing the Internet Printing Protocol

If the Internet Printing Protocol is being used, rule set entries must allow traffic to the printer’s IP address, TCP port 631. A wide port range could be used to be safe.

Make sure the Decrement TTL setting is disabled

In case a network component sends mDNS packets with IP TTL=1, we may want to make sure we don’t decrement it to 0 and it is dropped. There may also be mDNS clients that check for TTL still being 255 on receipt since this can indicate if the packet traversed a network boundary. Therefore, make sure that the Decrement TTL option in Routing Settings is disabled, as shown below in the cOS Core WebUI:

It should be noted that the mDNS RFC says this about the TTL value:

11. Source Address Check
   All Multicast DNS responses (including responses sent via unicast)
   SHOULD be sent with IP TTL set to 255.  This is recommended to
   provide backwards-compatibility with older Multicast DNS queriers
   (implementing a draft version of this document, posted in February
   2004) that check the IP TTL on reception to determine whether the
   packet originated on the local link.  These older queriers discard
   all packets with TTLs other than 255.

Additionally, there are recommendations in the RFC for dropping mDNS packets if the source IP address does not belong on the local network.

If you find an mDNS implementation that refuses to cross the firewall boundary, you may have to renumber your IP ranges to match.

For example, Microsoft’s mDNS implementation ** might have problems because of the Windows Defender Firewall. In that case, you can simply re-configure the Defender rules, as illustrated in the screenshot below.

FAQ

Question: What happens if you leave the “destination IP address” field empty in the multiplex list?

Answer: The result is exactly the same as writing the same destination IP address. Core treats it as “no translation”.

Question: What happens if transparent mode is not used and the TTL=1?

Answer: Packets will be dropped. SAT multiplex makes copies of the original packet, so TTL=1 will become TTL=0 without transparent mode enabled and DecreaseTTL=False.

The mDNS RFC says that the TTL SHOULD be set to 255. But it also says that hosts should check on receipt that the TTL is still 255 to prevent remote injection. Therefore we need  transparent mode so the DecreaseTTL option can disabled.

Related articles

No related articles found.