Hello,
i'm splitting my computers' lan from my "iot-and-other-stuff" lan, where there are also my TVs, home theater and so on. The iot lan is obviously very closed and firewalled
Eventually, i got it working so i'm now trying to setup also the "non core" part: multicast!
I'm now trying to get the home theater (denon, on br-iot) to be found by the phone app (on br-lan)
So i installed smcroute and got the multicast messages on br-lan to be forwarded to br-iot (simple config, and i also increased by 1 the TTL of multicast messages)
mgroup from br-lan group 239.255.255.250
mroute from br-lan group 239.255.255.250 to br-iot
And also this seems to work, since i can see with tcpdump that the HT is TRYING to answer:
15:11:08.680138 IP 0005CD90B77A.lan.3911 > 192.168.1.178.39400: UDP, length 286
15:11:08.680264 IP 192.168.111.1 > 0005CD90B77A.lan: ICMP 192.168.1.178 udp port 39400 unreachable, length 322
with no success, since br-iot has obviously no free access to br-lan.
So i'm now wondering if this is a problem with a possible solution or not. I will not allow connections from br-iot to br-lan, so is an answer to a multicast message processed as a new connection?
This is also going to impact on DLNA server working, i assume, and this is not good at all 
Have i done something wrong?
Thanks!
really hard for me to understand how this could be managed properly.
if the answer to the multicast search message (that comes from a random port to port 1900) is a unicast message to the original address and port, coming from a random port, how can this be managed without opening, well. every possible udp connection?
(and ssdp seems to work in this way, afaik)
If i take this two examples, incredibly it seems easier the management of second one than of the first one:
- Denon Receiver in the "segregated" lan, client in the "good" lan. Client multicasts a search, the answer from the Denon can't reach the client (unicast) because of firewall rules. So the "true" connection (client to denon) can't be made.
- client in the segregated lan, dlna server in the good lan. Client multicasts the search, the dlna server CAN connect to the client via unicast. The "real" connection can be made via a dedicated firewall rule opening just the dlna port (which seems acceptable).
really, can't se a proper management of the unicast connection toward the "good" lan..
Sorry @anon50098793 , as you can see my config was not complex enough
1 Like
fwiw... i'm interested in your findings and wish to implement similar stuff.. (and i'm guessing alot of other people are too)
I guess the point I was trying to make earlier is
- IOT != anything in particular (well it means alot of things)
- this also feeds into when you refer to 'connections'
so your question is really two or more questions...
if think we may benefit from a forum-sticky or just a thread fingerprinting each INDIVIDUAL 'IoT' device traffic patterns... that way 'IoT' can actually be translated into more tangible practical information...
yes, sure, just tell me what you want me to do lol
i think the starting point you helped me to achieve in the other topic is a very good starting point, but then every device is a different fight..
for example, MAX Cube! and Hue bridge were almost trivial to add to the segregated network
The dyson Pure Cool a little bit harder
Also the SkyQ was quite easy to add
Alexa devices damn, a lot of domains, and i'm not still sure they work totally
But when it comes to upnp and discovery well, the playing field changes a lot.
But well, if you will help me (first of all, you will have to correct all the big errors i'll make LOL) i can try starting an "how to" topic on a properly "segregated" lan for IOT devices.. is this what you were referring to?
It has already been discussed multiple times like here:
Hello,
i fear i'm giving up trying to get the Denon receiver detected cross different zones.
on the other side, i had no problem at all getting DLNA to work cross zones (using mcroute and just opening the direct connection to the dlna server), that is what was already discussed
the denon protocol is just too stupid (or more probably, i'm far from good enough to understand it)
as far as i have understood, DLNA servers and receivers search for each other on multicast 239.255.255.250:1900, then the proper connection is receiver -> server
Denon discovery is different: the client searches the "server" on the same multicast address, but the "server" is answering trying to connect to the client on the (random) port it searched on. It seems to me this is unmanageable in a secure way..
i'm living without this, but i'm always sad when i can't get something done