I have set up a Pfsense box with a TP-Link Access Point for my wireless interface to which I have connected a Sonos speaker. The issue I’m having is that we cant search for any songs via the Sonos android/iphone app on our phones. I think that somewhere it is being blocked from connecting to the internet.
I can see on the page below that the app and the speaker use multiple ports to function, but how do I open these up in Pfsense and keep it secure?
https://support.sonos.com/s/article/688?language=en_US (see bottom of the page)
Is the wireless access point on the LAN network or on it’s own interface, and if it’s on a different interface have you made any firewall rules for that interface?
@Dexter_Kane Yes, it is on its own interface and there is the following rule:
Pass
IPv4
Any
Destination: Invert Match LAN Net
And your phone is presumably on the same (wireless) network? Is the source set to any on that rule (it should be)? That should work so just to test it can you change the destination also to any and see if that works?
@Dexter_Kane Yes its on the same network.
The source is set to the name of the wireless interface OPT1 net. I changed the source and destination to any but the problem remains.
are you running squid or snort or anything else like that?
I have Suricata running with several rule sets, but on the WAN interface only. I tried searching for sonos related IPs being blocked, but I cant identify any (yet).
Have you tested if it works with suricata disabled? (and any blocks cleared). If you’re seeing some priority 3 alerts in suricatta those may be causing the problem, it’s generally safe to disable any priority 3 rules as they’re usually logging or policy rules, rather than threats.
The list mainly shows priority 2 alerts and a couple of priority 3.
I turned blocking off and removed the current blocked ips in the list, restarted my phone as well and now it can connect to services via the sonos app (Soundcloud for example).
I turned blocking back on, also changed the firewall rule back to what it was before and one priority 3 comes up but the app still functions. The prio 3 Src was this ip: 172.217.168.202.
In the alerts tab it will give you a description of the rule so you can decide for yourself if it’s something you need, but generally I’d just remove any priority 3 alerts and they’re usually just malformed packets or policy stuff. You can click the red X on the alert to disable that rule. Or if it stops working again you can unblock each IP one at a time until you find the one which was blocking it and then disable that rule.
You can also whitelist IPs but I imagine there would be a lot of them to try and find
For now I turned the rules off creating the prio 3 alerts, they relate to stuff like:
SURICATA STREAM Packet with invalid timestamp
SURICATA STREAM CLOSEWAIT FIN out of window
SURICATA STREAM TIMEWAIT ACK with wrong seq
The source or destination ips are things like Google LLC and Twitter.
It seems to work for now. Thank you for the help. But is there anything I should worry about though? Like the firewall rule I use on the wireless interface?
No the rule is fine, you’ll spend some time disabling rules in suricata but eventually you won’t have to worry about it
Just another tip for you. It’s not necessary to have suricata block on both WAN and LAN interfaces, as the traffic will be blocked either way and it’s best to run it on WAN to catch the stuff which would be blocked by the firewall anyway.
But it can be useful to run suricata on LAN with blocking disabled, with the same rules as the WAN instance, just to log the alerts. That way if you’re having problems like this you can check the LAN alerts and look for the LAN IP of whichever device isn’t working, then you can fix that rule on the WAN interface to allow the traffic though.
If you’re using pfsense you probably have your IoT crap segregated to a separate VLAN. Sonos needs IGMP snooping and STP enabled on your switches for that to work.
1 Like