VLANs Multicast Isolation

johnpoz

Why are you passing multicast traffic from iot to where you chromecast is? Why would you not just put your chromecast on the same iot vlan? I would for sure classify chromecast box as IOT.. And would isolate the shit out of that sort of box from my normal network..

mikekoke

@johnpoz said in VLANs Multicast Isolation:

Why are you passing multicast traffic from iot to where you chromecast is? Why would you not just put your chromecast on the same iot vlan? I would for sure classify chromecast box as IOT.. And would isolate the shit out of that sort of box from my normal network..

Sorry, I expressed myself badly is just what I did.
EDIT: So multicast traffic doesn't trade unless there is someone like Avahi?

johnpoz

@mikekoke said in VLANs Multicast Isolation:

chromecast via Avahi

Confused as to what your doing here? You want your devices on your normal vlan to cast to chromecast? Why not just connect the devices that need to cast to chromecast on the chromecast vlan?

I currently have my chromecast in a drawer ;) But when was using it, It was just on my iot (roku) vlan - when I needed to cast something to it for example just connected my ipad/phone to the roku ssid.

If your just going to allow devices to use multicast across your vlan boundaries, you have pretty much just created 1 L2.. So why would you not just use a flat network and put everything on the same L2 in this case, etc.

mikekoke

For now, the devices that must receive are on the IOT such as the SmartTV and the Sony speaker, through the rules and Avahi I can connect without problems, but I wanted to know if the multicast of one vlan could affect another vlan.

johnpoz

Well if your passing multicast across your vlan boundaries, you have in general terms just defeated the whole point of the firewall. And just created 1 L2 network... So why not just put everything on the same L2 ;)

Unless you have setup multicast filtering on your switching environment, since multicast is sent to group address, the switch can and does flood those to all ports on the switch..

Now you can get fancy with and do some IGMP snooping on your switches, so clients that want to get specific multicast traffic get this traffic, and devices that don't want to join this group, will not get this traffic. But until you set this sort of thing up the switch will just flood the multicast to all ports..

The easy thing to do is just not pass multicast traffic across your vlans.. So now multicast traffic in vlan X is limited to ports on your switch that are in vlan X, and don't get flooded to ports that are in vlan Y.

mikekoke

I thank you for the details, I think I understand. So if I used IGMP Snooping set on the id 1 of the main lan from which I transmit to the iot would it be more correct?

johnpoz

To the details of your setup and your switch I am not sure or what your looking to accomplish exactly... But correctly setting up IGMP, or multicast filtering so the multicast traffic only goes to the ports and devices you want it to go to, or that devices that join a group via IGMP yes would be better setup than flooding multicast to all ports in multiple vlans.

Not sure what your specific switch allows - but I personally filter multicast at the noise generators ;) Plex for example - has a issue with sending out multicast, even though your suppose to be able to turn off that feature - but still every 10 seconds sending out shit ;) So I just blocked the multicast from entering the switching fabric at the port the plex is connected too.. So those packets do get flooded to the rest of the ports - since have ZERO use for that noise on my network. And the other boxes on the network have zero use to try and process those packets.

Windows boxes for example can be noise generating machines ;) They love to send out crap!! Broadcast and Multicast out the kazoo..

example... Here is the multicast noise the plex box is sending out... I know for a fact its the plex service, since if I turn off plex server - this noise stops.

ash-4.3# tcpdump net 224.0.0.0/4
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
08:02:23.727038 IP uc.local.lan.ssdp > 239.255.255.250.ssdp: UDP, length 292
08:02:23.727079 IP uc.local.lan.ssdp > 239.255.255.250.ssdp: UDP, length 263
08:02:23.727236 IP uc.local.lan.ssdp > 239.255.255.250.ssdp: UDP, length 254
08:02:28.810992 IP nas.local.lan.34016 > 239.255.255.250.ssdp: UDP, length 101
08:02:38.811172 IP nas.local.lan.34016 > 239.255.255.250.ssdp: UDP, length 101
08:02:48.811355 IP nas.local.lan.34016 > 239.255.255.250.ssdp: UDP, length 101
08:02:58.811534 IP nas.local.lan.34016 > 239.255.255.250.ssdp: UDP, length 101

So I just block that at the port.. So it doesn't go out to the vlan plex is attached too. That noise from uc.local.lan is VM running on the nas... So it is also filtered from going out to the rest of the network..

JKnott

@mikekoke

I gather English is not your first language, which is making it difficult to comprehend what you're saying. Multicasts should never pass between VLANs, unless specifically enabled. IGMP is often used to enable multicast to pass through a router and sometimes a switch.

johnpoz

I can understand they want to make it easy for your home user to plug shit in and just "find" the device they want to connect to via a discovery process.. Works ok when user is on 1 flat network..

But would it really be that difficult to allow for simple directed unicast connection to the device as well.. Where you just put in the IP of the device, or for that matter the fqdn..

Roku App allows for just putting in the IP of the device.. Plex allow for manual entry of the server you want to connect too.

They can hide such setup in an advanced menu location so you typical user won't ever see them... But you shouldn't have to circumvent your networks security to use a chromecast device ;) Or understand networking protocols like multicast or igmp.. Put in the IP of the device on the client/server and there you go... A nice listing of the ports actually used -- is it really that hard to list this stuff in the documentation?

mikekoke

I apologize for my English, but the only reason I use Avahi is that so I can share the sound of Chrome cards with the Sony speaker.
However from what it seems to me is that Chrome searches for devices via Avahi traffic between the iot and the lan and then connects to the cashier via port 8009.

johnpoz

While that might be true.. And while it might only be the search and then a unicast connection. How much "search" traffic is it sending? Does it only send the search when you call for it - or is there in the background sending out multicast every X seconds ;) Or have seen even multiple times a second nonsense..

These companies would be better off just allowing you to put in the IP or fqdn of the device, vs having to hope the users network is flat, or allow for multicast across vlans via the likes of avahi, which is just the lame ass mdns nonsense.. If I want something to resolve, then I will put in my DNS ;) hehehe

chpalmer

There are very valid reasons to cross Vlans with multicast. While it might not make sense in every case I have a very specific reason for doing so.

Broadcasting audio streams seems to be a quite common need for such.

Just hate to see "Multicast should never cross between VLANs" when someone brings up the idea because "never" is just not true.

johnpoz

What is your specific reason? Curious.. While I agree in a corp environment I could see a few reasons - pushing images to multiple machines, while the server is in a different vlan - this would be very controlled setup. And the client could join the multicast group when it ready to receive the image, etc.

Streaming multiple audio to speakers or something ok - yup that is great for multicast use.. Why does the streamer and the streamies have to be in different L2s?

I don't think I ever said NEVER... But if your thinking passing multicast from vlan x into vlan y you should really be clear on what your doing..

Say user machines in a corp setup, viewing a muticasted video stream - again would be valid.. But again should be controlled where the client joins the specific multicast group to view the stream.

avahi being used to send mdns from one vlan into another - seems like a hack from just doing it correctly.

mikekoke

I have analyzed the requests of Chrome and the sony speaker with wireshark and it seems that only the speaker continues to report its presence, while Chrome sends requests only when necessary. The sony speaker is on the vlan iot because it connects to the internet for updates.
Even if there is multicast traffic between the LAN and the IOT I think that the IOT devices cannot connect to the LAN because of the denial rules, am I wrong?

JKnott

@chpalmer said in VLANs Multicast Isolation:

Broadcasting audio streams seems to be a quite common need for such.

This is one of those specifically enabled situations I mentioned. In this situation, the client would contact the server, to be put on the multicast list. IGMP would then be used to enable passing the multicast traffic down to the client. Don't forget, multicasts use addresses that are not normally routeable. The router, through IGMP, has to be enabled to pass the mulitcast destination address towards the client. This is something that a router otherwise would not do.

Typically, on a LAN, multicasts are local network only. In fact, on IPv6, multicasts can use the hop count to ensure the packet didn't come from beyond the router.

johnpoz

If you forward multicast traffic from 1 L2 into a different L2... In "theory" that could be used for bad things..

Are you sending it in such a way that all devices on the dest L2 are seeing this traffic, even if they don't need too? Ie didn't join the group. Or have you limited this on your switches acls to only allow the multicast to the device that needs to see this and act upon this traffic?

When you create a boundary, you need to be aware of what can cross that boundary is all.. You would be the only one that can determine if crossing that boundary with traffic X is acceptable to you. A vlan is a boundary, where you can limit what passes between from who to whom..

What I find troublesome in the whole thing is just passing everything to everyone on the other L2.. If that is the case - they might as well just be on the same L2, ie no boundaries. Even if only a discovery method, a compromised system could use it to discover stuff that is different network than itself, and then direct attack to that IP which may or may not be open, etc. etc. I could be used for discovery, that if boundary was in place would not be possible.

This might be an interesting read for you?
https://www.cisco.com/c/en/us/about/security-center/multicast-toolkit.html

Could this be considered over the top for home network - more than likely yes ;) But good security practices are good no matter what the network.

chpalmer

@johnpoz said in VLANs Multicast Isolation:

While I agree in a corp environment I could see a few reasons

Then "never" is the wrong word to use.

We use mulicast for simulcast audio in multi site radio systems. The system is designed to use multicast addresses. We deal in microseconds. .000001 of a second.

Again.. My only issue is the word "Never!" Sometimes it is needed.

johnpoz

@chpalmer said in VLANs Multicast Isolation:

never

Ah your comments are directed at @JKnott but they seem directed at me.. Sorry. I never stated never ;)

chpalmer

@johnpoz said in VLANs Multicast Isolation:

@chpalmer said in VLANs Multicast Isolation:

never

Ah your comments are directed at @JKnott but they seem directed at me.. Sorry.

Still trying to get ahead of this forum software..

johnpoz

So your doing multicast over a wan? I don't see multi sites being over a lan ;) Are you using a tunnel sort of method to connect these sites?

Really don't see how you could be multiple sites, and be worried about microseconds ;)

While sure you can have extended L2s -- this is really a whole different ball of wax when what someone does in their home or even most enterprises.. If you worried about timing at a high level, your going to want minimal "hops" in the wire, etc.. So I would assume where your sending the data would be in some sort of extended L2 where the devices you sending the audio to is in the same L2, you sure and the F are not using avahi ;)