mDNS forwarding between two VLANs - Why is failing?/How to debug?

[sjjh]

A user with an Apple Mac (VLAN 70; IP 10.70.0.1) wants to print on a printer (VLAN 65; IP 10.64.65.203) in a different VLAN. The printer only supports Airprint (using mdns) for Mac OS (no specific printer driver, using a generic one does not print images). I installed the os-mdns-repeater and also tried the os-udpbroadcastrelay but fail to get it working. Can someone please support in how to debug. What I tried so far/my current config & information level:
Client:
$ avahi-browse -art | grep "Brother MFC-L" within the VLAN 65 provides output, within the VLAN 70 does not. Ping from client in VLAN 70 to printer in VLAN 65 works.

OPNsense:
mDNS-Repeater
GUI config

• activated
• interfaces: 65SrvIntern, 70ClientIntern

Via ssh

Code Select Expand

# cat /etc/rc.conf.d/mdns_repeater
mdns_repeater_enable="YES"
mdns_repeater_interfaces="ix0_vlan65 vlan0.70

# ps aux | grep -i mdns
root          48892   0.0  0.0   14088    2628  2  S+   17:04       0:00.00 grep -i mdns
root@fw:/home/simon.harhues # ps aux | grep -i mdns
root          51533   0.0  0.0   14004    2488  -  Ss   17:04       0:00.00 /usr/local/bin/mdns-repeater -p /var/run/mdns-repeater.pid ix0_vlan65 vlan0.70
root          57371   0.0  0.0   14088    2632  2  S+   17:04       0:00.00 grep -i mdns

# sockstat -l | grep 5353
root          mdns-repea 62350  3 udp4    *:5353                *:*                 
root          mdns-repea 62350  4 udp4    10.64.65.254:5353     *:*                 
root          mdns-repea 62350  5 udp4    10.70.255.254:5353    *:*

# ifconfig | grep -E "ix0_vlan65|vlan0.70"
ix0_vlan65: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
vlan0.70: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500

# tcpdump -i ix0_vlan65 -n 'udp port 5353' -v | grep "Brother MFC-L"
tcpdump: listening on ix0_vlan65, link-type EN10MB (Ethernet), snapshot length 262144 bytes
    10.64.65.203.5353 > 224.0.0.251.5353: 0*- [0q] 1/0/1 Brother MFC-L9570CDW series._uscans._tcp.local. (Cache flush) TXT "txtvers=1" "vers=2.62" "adminurl=https://BROTHERMFCL9570CDW.local./net/net/airprint.html" "representation=https://BROTHERMFCL9570CDW.local./icons/device-icons-128.png" "rs=eSCL" "ty=Brother MFC-L9570CDW series" "note=Stiftung" "pdl=application/pdf,image/jpeg" "UUID=e3248000-80ce-11db-8000-b42200665636" "cs=binary,grayscale,color" "is=adf,platen" "duplex=T" (435)
16:50:36.026741 IP6 (hlim 255, next-header UDP (17), payload length 443) fe80::b622:ff:fe66:5636.5353 > ff02::fb.5353: [udp sum ok] 0*- [0q] 1/0/1 Brother MFC-L9570CDW series._uscans._tcp.local. (Cache flush) TXT "txtvers=1" "vers=2.62" "adminurl=https://BROTHERMFCL9570CDW.local./net/net/airprint.html" "representation=https://BROTHERMFCL9570CDW.local./icons/device-icons-128.png" "rs=eSCL" "ty=Brother MFC-L9570CDW series" "note=Stiftung" "pdl=application/pdf,image/jpeg" "UUID=e3248000-80ce-11db-8000-b42200665636" "cs=binary,grayscale,color" "is=adf,platen" "duplex=T" (435)
    10.64.65.203.5353 > 224.0.0.251.5353: 0*- [0q] 2/0/3 _ipp._tcp.local. PTR Brother MFC-L9570CDW series._ipp._tcp.local., _ipps._tcp.local. PTR Brother MFC-L9570CDW series._ipps._tcp.local. (1437)
16:54:01.317889 IP6 (hlim 255, next-header UDP (17), payload length 1445) fe80::b622:ff:fe66:5636.5353 > ff02::fb.5353: [udp sum ok] 0*- [0q] 2/0/3 _ipp._tcp.local. PTR Brother MFC-L9570CDW series._ipp._tcp.local., _ipps._tcp.local. PTR Brother MFC-L9570CDW series._ipps._tcp.local. (1437)
###SHORTEND###
^C58979 packets captured
7589695 packets received by filter
0 packets dropped by kernel

# tcpdump -i vlan0.70 -n 'udp port 5353' -v | grep "Brother MFC-L"
tcpdump: listening on vlan0.70, link-type EN10MB (Ethernet), snapshot length 262144 bytes
^C511099 packets captured
13203846 packets received by filter
0 packets dropped by kernel

Running mdns-repeater manually in the foreground (mdns-repeater -f ix0_vlan65 vlan0.70) did not make a difference. It showed forwarding lots of packages from VLAN 70, but non from VLAN 65.


Firewall rules
positioned as top most interface rules:
1) rule VLAN 65

• active: yes
• interface: 65SrvIntern
• quick: yes
• action: pass
• direction: incoming
• version: any
• protocol: udp
• source: any
• source port: any
• target: 70ClientIntern network
• target port: single port -> 5353
• protocol: yes

2) rule VLAN 70

• active: yes
• interface: 70ClientIntern
• quick: yes
• action: pass
• direction: incoming
• version: any
• protocol: udp
• source: any
• source port: any
• target: 65SrvIntern network
• target port: single port -> 5353
• protocol: yes

info to each rule (live log) shows 0 hits.

[Patrick M. Hausen]

Try source/destination any/any. mDNS is multicast.

[viragomann]

Firewall rules
positioned as top most interface rules:
1) rule VLAN 65

• target: 70ClientIntern network
• target port: single port -> 5353

The target of the mDNS packets is the multicast IP 224.0.0.251. So you have to allow this here.

[Patrick M. Hausen]

@viragomann Probably better than "any" - thanks!

[IsaacFL]

You will also need firewall rules to allow printing in addition to the MDNS. MDNS just locates the printers address.

[sjjh]

Thanks for all your replies!

Firewall rules
positioned as top most interface rules:
1) rule VLAN 65

• • target: 70ClientIntern network
  • target port: single port -> 5353

The target of the mDNS packets is the multicast IP 224.0.0.251. So you have to allow this here.

Makes sense. So I changed it to:

• interface: 65SrvIntern
• target: IP address -> 224.0.0.251
• target port: single port -> 5353

Unfortunately it still doesn't work. tcpdump and avahi-browse show the same result as before. I'm probably overlooking something very obvious here... :-/

I temporarily tried out to broaden the rule to:

• interface: 65SrvIntern
• direction: in
• version: IPv4
• protocol: UDP
• source: any
• source port: any
• target: any
• target port: any

But even then it did not work... So should I look somewhere else?

You will also need firewall rules to allow printing in addition to the MDNS. MDNS just locates the printers address.

Yes, I already have a more generic rule, which I assume should work (just added the other rule as I wanted to rule out other side effects):

• active: yes
• interface: 70ClientsIntern
• action: allow
• direction: in
• version: IPv4
• protocol: any
• source: any
• source port: any
• target: 65SrvIntern network
• target port: any

[nero355]

A user with an Apple Mac (VLAN 70; IP 10.70.0.1) wants to print on a printer (VLAN 65; IP 10.64.65.203) in a different VLAN.

The printer only supports Airprint (using mdns) for Mac OS (no specific printer driver, using a generic one does not print images).

As someone who really hates mDNS forcing devices like that I would like to suggest the following :
- Setup a CUPS Printer Server by using something like a Raspberry Pi 2B/3B or a small Intel Atom NUC running Linux.
- Let the MacOS Clients talk to that CUPS Printer Server directly via the VLAN Gateway without all the mDNS mess :)



And for random people passing by in the future =>

Here is a list of protocols that I would use and my printer currently has as Enabled Protocols :
- Raw TCP/IP Printing Protocol - Port Number - 9100
- LPR/LPD Protocol - Port Number - 515
- IPP Protocol - Printer URI: ipp://10.x.x.x/ipp/printer

Currently used from : Android/Linux/Windows
And would probably work with Apple stuff too! :)

[julsssark]

Use Firewall->Log Files->Live View and watch traffic going to and from the printer. Confirm that the traffic is not being blocked. You may need a rule to allow the printer to open a connection to the device that wants to print. I don't use AirPrint but Airplay devices need to be able to open connections.

[sjjh]

As someone who really hates mDNS forcing devices like that I would like to suggest the following :
- Setup a CUPS Printer Server by using something like a Raspberry Pi 2B/3B or a small Intel Atom NUC running Linux.

While I do understand your rationale and agree with your dislike, I'm still hoping that it should be easier and less maintenance to allow mDNS between two VLANs than administering yet another device on the net.

Use Firewall->Log Files->Live View and watch traffic going to and from the printer.

That might have brought me one step closer. I activated logging for all rules on the firewall. One hit (using port 5353) caught my eyes, as it was passed by a rule I didn't have on my mind: We're using following rule to allow outgoing internet traffic:

• type: global rule
• description: allow internet
• interfaces: <basically all>
• quick: yes
• action: pass
• direction: in
• version: IPv4
• protocol: any
• source: any
• source port: any
• invert target: yes
• target: single host or network -> 10.0.0.0/8
• target port: any
• section: source routing
• gateway: WAN_gateway

Obviously negating 10.0.0.0/8 also catches multicast 224.0.0.251. A side-effect I didn't have on my mind. I'm assume that the wan gateway prevents to get it working. Thus I'm wondering what is best practice?

• Adding another rule covering mDNS/mutlicast and more than one interface (to make it a global rule) and moving it above the allow internet rule
• Altering the allow internet rule to not match mDNS/multicast (not sure how)
• Something completely different

I'm happy about a hint.

[viragomann]

Obviously negating 10.0.0.0/8 also catches multicast 224.0.0.251.

Sure.

On my wifi interface for mobile clients I have a rule allowing any to any but RFC 1918 networks and mDNS works great. However, I use UDP Broadcast relay and I don't use it for Airprint.

Thus I'm wondering what is best practice?

• Adding another rule covering mDNS/mutlicast and more than one interface (to make it a global rule) and moving it above the allow internet rule

Should work. So why not?
I just don't know if you really need to allow mDNS on multiple Interfaces.

• Altering the allow internet rule to not match mDNS/multicast (not sure how)

Should work as well, but requires a following rule,  which allows mDNS.
You could add the 10.0.0.0/8 and 224.0.0.251 to an alias and use this one in the rule as destination with 'invert'.

But I would rather add an additional rule for mDNS.