Firewall settings for Wireless Speakers

I am trying to make some Wireless Speakers work I bought today.
I have a home server with two NICs (internal for WAN and external for LAN).
I installed the speaker, downloaded the app and I can install it properly.
The only thing I cannot make happen is streaming of internet radio stations.
I spoke to google and only found the following:

HEOS speakers and controllers (apps, professional controllers) require communication with each other. Therefore, specific ports must be opened to allow this communication:

80 : HTTP
554: RTSP

49152: MediaRenderer UPnP “listening”
49153: Configuration UPnP “listening”
49154: MediaServer UPnP “listening”

Open range between 50000 to 64999 for MediaRenderer and 60006 for Media Server.
Furthermore, all UPnP requires multicast access to the 239.255.255.250:1900 along with the appropriate IGMP messages and control for multicast.

How do I translate this into firewall-cmd?
1.) Adding service rtsp to my internal zone
2) Opening ports 50000-64999 (tcp, upd or both?)
3) Opening ports 49152, 49153, 49154 (tcp, udp or both?)
3.) What is multicast access to 39.255.255.250:1900 along with the appropriate IGMP messages and control for multicast?

Thanks for your insight.

Wolfgang

First, is there a firewall on your WiFi router that is in play? I found this article as well (same source):
https://support-uk.denon.com/app/answers/detail/a_id/1159/~/network-ports
It specifies the ports over the network that must be on and whether they are TCP or UDP, but, it isn’t the same list of ports that you have in the first article (which I also found and does not mention the port type, just the number.

If the article that I found is more specific to the firewall on your WiFi router and the link that you found is more specific to the firewall ports that need to be open on your machine (which I suspect) then you may need to play with both. Since there is no mention of which port types the link you found, I’d go with both. RTSP is a known service type.

firewall-cmd --zone=internal --add-service=rtsp --permanent
firewall-cmd --zone=internal --add-service=http --permanent
firewall-cmd --zone=internal --add-port=50000-64999/tcp --permanent
firewall-cmd --zone=internal --add-port=50000-64999/udp --permanent
firewall-cmd --zone=internal --add-port=49152-49154/tcp --permanent
firewall-cmd --zone=internal --add-port=49152-49154/udp --permanent

As for the multicast and IGMP message control, you may have to add a rich rule for this. Take a look at this discussion. It’s a little old, but may still apply:

If you are like me and don’t want to allow ports needlessly, you can start with just the TCP rule types in the above firewalld rules, and then add in the UDP rules if the they are needed. My guess is that these are speakers, and that you will need connection and not connectionless ports (TCP rather than UDP), but that is just a guess.

Good Luck!

Thanks for the insight. Will try to apply when Igost some time.
My setup is such that I run a home server with two NICs and three zones active.

drop
  sources: ipset:blacklist
external
  interfaces: enp3s0 ppp0
internal
  interfaces: enp2s

I will apply all these rules on zone=internal only.
Will report back what finding is.

Wolfgang

I opened all the ports in zone-internal, added igmp protocol to the same zone and added this to enable multicast traffic:

firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -m pkttype --pkt-type multicast -j ACCEPT

It is not working.
What would be a good tool to monitor my network and report/monitor the dropped packages?
I looked at ethtool and netstat, but I believe none of them shows me realtim what is dropped.

Thanks
Wolfgang

Wolfgang,
It will depend on “where” the packets are being dropped. I’ve not used this feature of firewalld before, but you can try this to log denied traffic and see if that will give you a clue as to what is not being allowed:

https://www.cyberciti.biz/faq/enable-firewalld-logging-for-denied-packets-on-linux/

Steve

I just made the test to confirm that the problem is related to the firewall. I stopped the server and activated the router from the ISP. And voila I could stream radio stations on the speakers.
I did already what you suggest, but did not find conclusive glues there. I found some packages dropped but don’t see from where they come I only see that they were dropped at my Wifi Router (identified through their IPs) that is connected to the LAN NIC of my server.
I have an Mesh Router and additionally two wireless super mesh points connected to it.
Their IP shows up when I run dmesg | grep -i REJECT
[AmpliFi HD Mesh Router – Amplifi Wi-Fi]

I cannot find in the app anything that is related to firewall. Nevertheless I will send them a note to see what they have to say.

Thanks, Wolfgang

I am still trying to figure this out. What is mist completely in the speaker’s instruction is was this sentence:

Furthermore, all UPnP requires multicast access to the 239.255.255.250:1900 along with the appropriate IGMP messages and control for multicast.

After doing quite some searching and readings I stumbled over a few threads that could bring me hopefully the breakthrough… But before keying in wanted to check with the experts…
Solution one:

firewall-cmd --permanent --new-ipset=upnp --type=hash:ip,port --option timeout=3
firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 0 -d 239.255.255.250/32 -p udp -m udp --dport 1900 -j SET --add-set upnp src,src --exist
firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -p udp -m set --match-set upnp dst,dst -j ACCEPT

or the simpler solution by creating /etc/firewalld/direct.xml

<?xml version="1.0" encoding="utf-8"?>
<service>
   <short>UPNP</short>
   <description></description>
   <port protocol="udp" port="1900"/>
   <destination ipv4="239.255.255.250"/>
</service>

Could that work?

Woflgang

Finally some time to further investigate an try. Still not working btw.
I opened all the ports mentioned in the thread here. I also created a upnp.xml service in /etc/firewalld/services/ (see above), but I still cannot stream.
I enabled package drop logging and find these rejected packages for I239.255.255.250.
Not sure why they show IN=ppp0 (my external NIC, connection to IPS) when the speakers are connected to the LAN NIC?

an 20 18:50:34 home.wo-lar.com kernel: FINAL_REJECT: IN=ppp0 OUT= MAC= SRC=83.51.248.132 DST=239.255.255.250 LEN=160 TOS=0x00 PREC=0x00 TTL=4 ID=47647 DF PROTO=UDP SPT=1900 DPT=1900 LEN=140 
Jan 20 18:50:34 home.wo-lar.com kernel: FINAL_REJECT: IN=ppp0 OUT= MAC= SRC=83.51.248.132 DST=239.255.255.250 LEN=160 TOS=0x00 PREC=0x00 TTL=4 ID=47648 DF PROTO=UDP SPT=53354 DPT=1900 LEN=140 
Jan 20 18:50:34 home.wo-lar.com kernel: FINAL_REJECT: IN=ppp0 OUT= MAC= SRC=83.51.248.132 DST=239.255.255.250 LEN=160 TOS=0x00 PREC=0x00 TTL=4 ID=47649 DF PROTO=UDP SPT=1900 DPT=1900 LEN=140 
Jan 20 18:50:34 home.wo-lar.com kernel: FINAL_REJECT: IN=ppp0 OUT= MAC= SRC=83.51.248.132 DST=239.255.255.250 LEN=160 TOS=0x00 PREC=0x00 TTL=4 ID=47650 DF PROTO=UDP SPT=53354 DPT=1900 LEN=140

How can I open my all ports on my LAN so that no package whatsoever gets dropped?

Wolfgang

So sorry @Smoky ! Just realized that no one has responded to this. I’m not sure if the issue is still outstanding, but you should be able to allow all traffic on your LAN with a rule like this:

firewall-cmd --zone=internal set-target=ACCEPT --permanent

You would want to go back and remove the rules we created earlier:

firewall-cmd --zone=internal --remove-service=rtsp --permanent
firewall-cmd --zone=internal --remove-service=http --permanent
firewall-cmd --zone=internal --remove-port=50000-64999/tcp --permanent
firewall-cmd --zone=internal --remove-port=50000-64999/udp --permanent
firewall-cmd --zone=internal --remove-port=49152-49154/tcp --permanent
firewall-cmd --zone=internal --remove-port=49152-49154/tcp --permanent

Then reload the firewall

firewall-cmd reload

Technically, the rules being there wouldn’t necessarily foul things up, but I never want to have things there that don’t make sense anymore. (clutter = problems trying to figure out things later)

If you added any other rules to your “internal” zone, you will want to also remove those.

Hope this helps, or at least I hope you have your problem solved by now!
Steve

1 Like

Hello @sspencerwire

thanks for responding. And yes it is still outstanding and very very important! (ask my wife and kids…)
I tried what you said but no luck.
I removed all the ports mentioned in the script to “reset” the firewall so to speak.
I need to do something else first and will pick this it again
Still, I enabled logging of dropped packages.
Here is what I am seeing (udp packages only, I think this traffic is udp, right?)

IN=ppp0 OUT= MAC= SRC=79.152.10.78 DST=239.255.255.250 LEN=157 TOS=0x00 PREC=0x00 TTL=4 ID=6113 DF PROTO=UDP SPT=43031 DPT=1900 LEN=137
IN=ppp0 OUT= MAC= SRC=5.161.93.136 DST=79.152.10.78 LEN=53 TOS=0x00 PREC=0x00 TTL=114 ID=54701 PROTO=UDP SPT=50394 DPT=69 LEN=33
IN=enp2s0 OUT= MAC=ff:ff:ff:ff:ff:ff:18:e8:29:c3:37:9c:08:00 SRC=10.5.2.147 DST=255.255.255.255 LEN=143 TOS=0x00 PREC=0x00 TTL=64 ID=9027 DF PROTO=UDP SPT=47842 DPT=10001 LEN=123
  • IP 79.152.10.78 belongs to my Internet Service Provider Telefonica ESPANA; I got thousands of REJECTS in the file from this IP
  • IP 5.161.93.136 belongs to a data center operator
  • enp2s0 is my internal NIC
  • IP 239.255.255.250 is used for UPnP. I found this info:
Organization:   Internet Assigned Numbers Authority (IANA)
RegDate:        1991-05-22
Updated:        2013-08-30
Comment:        Addresses starting with a number between 224 and 239 are used for IP multicast.  IP multicast is a technology for efficiently sending the same content to multiple destinations.  It is commonly used for distributing financial information and video streams, among other things.
OrgName:        Internet Assigned Numbers Authority
OrgId:          IANA

Maybe there is an easy fix?
Thanks,
Wolfgang

  • So to make sure I’m understanding, the enp2s0 is assigned to your “internal” zone, is that correct?
  • You are correct that these dropped logged packets are UDP.
  • Is ppp0 assigned to any zone?

The reason I ask those questions, is by default, if the “internal” zone doesn’t have an interface assigned those packet drops are going to be coming from the default “public” zone. Do this to be sure that your interfaces are assigned to the correct zone:

firewall-cmd --zone=internal --change-interface=enp2s0 --permanent 
firewall-cmd --zone=public --change-interface=ppp0 --permanent
firewall-cmd reload

Before you add any other rules, see if the dropped packets changes at all after doing the above.

Also, it might be helpful for you to list out both the “internal” and “public” zones so we can see if anything else might be missing. You can do this with:

firewall-cmd --list-all --zone=internal
firewall-cmd --list-all --zone=public

Just paste the results of both of those commands in your reply.

Steve

Hello Steve,

this is the the setup of the linux home server:
image

enp2s0 is the LAN side and assigned to the internal zone
enp3s0 is the WAN side and assigned to external zone (ipv4.method disabled)
ppp0 is a pppoe connection linked to enp3s0 (pppoe.parent enp3s0)

[root@home wp.rauchholz]# firewall-cmd --zone=internal --list-all
internal (active)
  target: default
  icmp-block-inversion: no
  interfaces: enp2s0
  sources: 
  services: cockpit dhcp dhcpv6-client dns emby-server http https imap imaps mdns ntp rtsp samba samba-client smtp smtp-submission smtps
  ports: 8080/tcp 1900/udp <sshport>/tcp
  protocols: 
  forward: no
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 
root@home wp.rauchholz]# firewall-cmd --zone=external --list-all
external (active)
  target: default
  icmp-block-inversion: no
  interfaces: enp3s0 ppp0
  sources: 
  services: dns http https imap imaps smtp smtp-submission smtps
  ports: <sshport>/tcp 8920/tcp
  protocols: 
  forward: no
  masquerade: yes
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 

The firewalld policy to bind internal and external together.

[root@home wp.rauchholz]# firewall-cmd --policy=lan_www --list-all
lan_www (active)
  priority: -1
  target: ACCEPT
  ingress-zones: internal
  egress-zones: external
  services: 
  ports: 
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules:

Wolfgang

That was a ghost chase! I have no explication as to why. Just the symptom.
But good news is that it works.

I checked the IP addresses of the radios and when running nmap -sn I could not see them in the listed.
When you look at the picture. For whatever reason, the radios got an IP and DNS assigned, but no DNS.
I changed the mode from DHCP to manual and radios now work.

All other clients on the LAN work fine. Why would the system assign IP but not dns?

Thanks for spending the time helping

Wolfgang

I’m so glad this is finally working! :slight_smile: I’m assuming that your router serves DHCP and DNS? If so, I couldn’t answer that question. I’m glad that statically assigning those devices (which allows for the static assignment of the DNS) works though!

Cheers,
Steve

Interesting finding.
I replaced dhcp/bind with dnsmasq.

dnsmasq assigns the gateway IP to the loudspeakers correctly.
Why wold dnsmasq assign the gateway but dhcp not?

Wolfgang