Have you allowed multicast (IGMP) traffic (see the article linked above by Noris)?
Yes i also tried enabling the multicast but it failed, the 851N zone wasnât present after a core reboot.
The only thing that seems to work is to allow a wide range of udp local ports for incoming connections from my 851Nâs ip.
Thatâs why i asked for a more precise range if possible.
Port 1900 udp should be sufficient but donât restrict it to your local network (192.168.1.0/24) â multicast doesnât use this network. The rule seems to effectively block multicast from accessing port 1900 udp.
Or to sum up the thread Noris linked:
Allow IGMP
Allow connections to port 9003 udp (optionally restrict access to 192.168.1.0/24)
Allow connections to ports 9100-9200 tcp (optionally restrict access to 192.168.1.0/24)
Thatâs exactly what i did (with the option on) and as i told that doesnât worked.
What i saw in ufw logs is that connexion from 851Nâs ip to my NUC (no broadcast ip but 851N explicit ip) were blocked because trying to reach unallowed udp ports between 30000 and 60000.
But enabling a big range of udp ports like that by example :
30000:60000/udp ALLOW IN 192.168.1.20
where 192.168.1.20 is the 851Nâs ip address make it works (without multicast on).
Itâs not what you showed.
and
isnât it the same that :
with the optionnally local restrict acces to on ?
Did i miss something ?
Yes, you missed to quote the whole section of your post:
My rule is less restrictive than the one used in the previously linked thread :
sudo ufw allow from 192.168.1.0/24 to any port 1900 proto udp
it allows 2 more ports.
Port 1900 (SSDP) is multicast. You block multicast by restricting access to 192.168.1.0/24. Itâs best to drop that line and allow IGMP instead.
I see your point but thatâs not what was in linked thread.
Ok so to check your point, i just tried enabling ports without local restriction :
9100:9200/tcp ALLOW Anywhere
9003/udp ALLOW Anywhere
1900/udp ALLOW Anywhere
and
IGMP
-A ufw-user-input -s 224.0.0.0/4 -j ACCEPT
-A ufw-user-input -d 224.0.0.0/4 -j ACCEPT
-A ufw-user-input -s 240.0.0.0/5 -j ACCEPT
-A ufw-user-input -m pkttype --pkt-type multicast -j ACCEPT
-A ufw-user-input -m pkttype --pkt-type broadcast -j ACCEPT
in user.rules
=> and that doesnât work.
I still see incoming rejected connexions from my 851Nâs ip to udp ports above 30000 in logs.
So i think the problem is here.
After searching in the forum I was able to dig up the thread that I used as a guideline back in the days:
I see but my problem is not exactly the same and the solution given doesnât seem to solve it.
I use ipads an iphones as remotes and they work well, even if the roon core is restarted they find it.
The problem is that once the core is restarted i lost the 851 sound zone as a roon endpoint.
I also found earlier that when I have the problem and go in 851N settings and change « DSD mode compatible with Roon » value to PCM and back to DoP that makes the 851N endpoint visible again in Roon.
It seems itâs because when doing this, the 851N sends UDP requests to the core, one on port 1902 (NOTIFY ALIVE) and on port 9003 with some informatons related to roon service running on 851N.
It seems to have the same effect as rebooting the 851N and makes the 851N endoint visible again by the roon core.
But if i donât do this trick and reboot roon server, i canât see the 851N zone anymore and i only see udp requests on random ports above 30000 rejected. If i allow them, the 851N is visible again âŠ
Normal firewall operation is to block all incoming packets â unless they belong to a previously established connection. All outgoing packets are allowed.
AFAIK there is no service belonging to Roon listening on random ports above 30000. If there is incoming traffic that makes a difference, then itâs most-likely belonging to an established connection. It seems you are running a firewall in an uncommon setup. None of the firewall setup examples in the forums are meant for such a scenario. Youâre maybe best off to allow all incoming packets to any port if the originate from your 815N. Additionally allow igmp, multicast and eventually also broadcasts if they get blocked otherwise â or adapt the common firewall approach outlined above.
Iâm not a firewall expert. The example setup (adapted to my network situation) given in the last thread I linked worked â and still works â for me. Nothing more should be needed for common firewall setups.
Sorry that I canât be of more help for your situation.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.