Skip to main content
I'm trying to put my Sonos network in its own VLAN (security and better multicast control), however, I've noticed periodically I'm getting blocked high port number connections back to by devices running the controller software.



My firewall rules are configured to allow established and related connections, but for some reason these connections aren't being considered as related.



Does anyone have any idea what they are? It doesn't seem to be affecting the network at all dropping them.



Jun 20 16:19:57 SecureGateway kernel: [LAN_IN-2008-D]IN=eth0.200 OUT=eth0 MAC=80:2a:a8💿52:61:5c:aa:fd:e5:7d:fc:08:00:45:00:00:3c SRC=10.2.1.253 DST=10.0.1.16 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=1400 DPT=58735 WINDOW=5792 RES=0x00 ACK SYN URGP=0

Jun 20 16:20:20 SecureGateway kernel: lLAN_IN-2008-D]IN=eth0.200 OUT=eth0 MAC=80:2a:a8💿52:61:b8:e9:37:88:fc:00:08:00:45:00:00:3c SRC=10.2.1.245 DST=10.0.1.16 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=1400 DPT=58885 WINDOW=5792 RES=0x00 ACK SYN URGP=0
It looks like the control device has moved from 10.2.1.* to 10.0.1.16 whilst the Sonos app is still open. It's trying to stay in touch with players at 10.2.1.253:1400 and 10.2.1.245:1400.
This is the return packets from a control command (since source port is 1400), but I see no indication that these are blocked? Or is this a log of purely blocked packets?



If you don't experience any problems, I would not worry about it. If the firewall is silently dropping them, I assume that they are retransmitted from the originating TCP stack, hence might be why you don't experience problems. If they get through a second time, it sounds like the unifi firewall is misbehaving.
It looks like the control device has moved from 10.2.1.* to 10.0.1.16 whilst the Sonos app is still open. It's trying to stay in touch with players at 10.2.1.253:1400 and 10.2.1.245:1400.



It's definitely not this because 10.2.0.1/24 is Sonos players only, while the contollers are in the default VLAN of 10.0.0.1/23
Yes it could be, as per jishi's comment that what you're seeing is return traffic. Player discovery (usually) requires that all devices be on the same subnet. However once the controller knows the player IP it may still try to communicate even when moved between subnets.
This is the return packets from a control command (since source port is 1400), but I see no indication that these are blocked? Or is this a log of purely blocked packets?



If you don't experience any problems, I would not worry about it. If the firewall is silently dropping them, I assume that they are retransmitted from the originating TCP stack, hence might be why you don't experience problems. If they get through a second time, it sounds like the unifi firewall is misbehaving.



I had a feeling they were return packets as well, so either the Zone Player isn't reporting they're related packets, or something is timing out on the firewall I guess.



Maybe I need a rule that's ALLOW 10.2.0.1/24 TO 10.0.0.1/23 SPORT: 1400 DPORT: 32768-61000 network performance is good though, and I hate having rules like that to my main network.
No, related,established rule is supposed to allow that. The high port you are seeing is ephemeral port assignments which is always used as return port on the initiator side of a connection.



What is considered "related" packets is not the responsibility of the zone player, that is a firewall task and if they aren't considered related, then that is a firewall issue. I have ran sonos successfully in a similar environment so I'm certain it should work. It might be possible to tweak how the firewall relates packets, but I don't have any good suggestions on how. The ACK SYN in that log indicates that it might be the connection acknowledgment that seems to be blocked... I would forward the question to a forum specialized in your firewall setup to see if someone can shed some light into the matter.
Terms & ConditionsCookie settings