Multicast video stream not being blocked despite deny rule
-
In a client's network has been installed a kit with security cams and nvr but those cams use a multicast stream to send video to the nvr.
Those cams and nvr has a strange ip setup that is out of the LAN range i setup for the network, i think is a cheap chinese kit.
The problem is that this multicast is beign passed trough the firewall and in the internet using all the upload bandwith.Using ntopng i narrowed the ip destination of the stream that is 226.2.2.2 (a multicast address) so i setup a rule to block traffic towards this address but is not working... or better: is logging the traffic that is beign passed even if the rule is set to block:
I tried to enable block bogon networks and no effect whatsoever.
In the same LAN interface i have a squid transparent proxy but the traffic is not passing trough it (strange).
The device is not configurable. What i have to do to block the traffic except cutting the device off the network? -
Not sure where you got the idea that pfsense would route multicast out the internet?
As to strange IP? If the devices were not using the lan network, then the default rules would block them from going anywhere anyway since the default lan rules are lan net as source.. So some other IP range outside of this would not be able to go anywhere, Also if they were not using the lan network... How would they talk to pfsense IP on lan net to use as gateway, etc. etc..
Lets see some of this traffic.. Simple packet capture on your wan and lan interfaces will show what is being sent out, etc. Under diagnostic...
Lets see your lan rules.. Where did you place that rule in the order on the lan interface? Rules are evaluated top down, first rule to trigger wins, no other rules evaluated... So lets see the FULL rules on your lan interface.
-
Maybe i was not clear...
In the traffic graph i see that my upload bandwith is capped at max and is difficult even to browse internet. When i cut off the device everything goes normal and my upload goes back to standard values.
The device that is mutlicasting is connected in the same network as the LAN interface but with a ip on its own, doesnt get a dhcp.
I get the idea that the traffic is beign routed out because if i disconnect this device everything goes normal.
In ntopng i see this:And the traffic graph's upload is capped when is connected.
Those are my rules:
Graph:
LAN network is 192.168.1.0/24
GUEST 192.168.50.0/24
WAN 192.168.10.0/24 gateway 192.168.10.1 and then internet
I have no control on the gateway because its provided by the isp but i can confirm that even there the multicast traffic goes out to the internetIt is strange that even with a block rule set up the traffic is going trough as nothing is there
-
Multicast should have a TTL of 1, it can not be routed.. Please take a packet capture of this traffic your seeing out out the wan.
If the dest address was 226.2.2.2 and IPv4 then per your rule it would be blocked.. What is the dest port on that traffic? Please sniff this traffic so we can see exactly what it is. Its quite possible your proxy is sending it out..
I would GUESS that with dest of 226.2.2.2 its hdmi over ethernet.. Since your saying this cam related traffic, is possible its is that as well, and if it is being routed then the TTL is not 1..
Do you have any sort of floating rules that would allow this traffic? Or states that still exist that would allow for it to be passed? Look in your state table.
Change your rule to protocol ANY vs IPv4... We would know for sure what is going on with a packet capture. Please do a sniff on lan interface for this dest IP 226.2.2.2 and download the pcap and post it so we can see exactly what is going on with this traffic.
but with a ip on its own
What is this IP.. If I haven't stated it enough a packet capture ;) Will give us all the details we need..
With that amount of traffic, even if pfsense dropped it at the lan interface your going to want to isolate that traffic on its own layer 2 and prevent it from eating up traffic for your other devices even on the lan.
Do you have a make and model of this device? So we can look at its manual, etc. Both the camera's and the NVR..
Lets say it wasn't IPv4, then the default lan deny should block it.. Very ODD.. Please post packet capture ;) And validate you have no floating rules that would allow, and no active states with this 226.2.2.2 in it..
BTW from your rule you can see 806MB have triggered that block rule.
-
That was stupid of me.
I reloaded the states and voila the rule works.
From what i understand, yes it is a hdmi to network device with no brand/model whatsoever.
Thank you for pointing the states, i completely forgot about that.
-
@exico said in Multicast video stream not being blocked despite deny rule:
with no brand/model whatsoever.
WTF?? Got to have something on it... What does it say when you access the NVR?
If it is pushing that much data to multicast address.. You for sure are going to want to isolate it to its own L2 and keep it away from your normal lan traffic. Multicast is going to go out every port on your switch on your same L2.. Is your switch capable of running IGMP snooping to limit the traffic?
Your going to want to make sure you keep that traffic away from your normal clients on its own L2, not just stop it from eating up your internet bandwidth which is why that sort of traffic is suppose to have ttl of 1 set on it.. So routers won't do that, etc.
-
@johnpoz said in Multicast video stream not being blocked despite deny rule:
Multicast should have a TTL of 1, it can not be routed.
There are routed multicasts, in addition to those that are intended for the local LAN only. On IPv6, multicasts that aren't intended to be routed have a hop count of 255, which means it could not have been routed. A packet with a hop count of 0, which would be needed to decrement to 255, would be discarded by the router. Multicasts from my Yamaha AV receiver have a TTL of 3.
IPv4 multicast addresses in the range 224.0.1.0 - 238.255.255.255 are global and may pass through routers. The range 239.0.0.0 - 239.255.255.255 are for local networks only. So, 226.2.2.2 is a global multicast address and may be passed by routers. The destination address of my AV receiver multicasts is 239.255.255.250, which is within the local network range.
-
I already thought of that route (isolate the traffic on a network on its own) but unfortunately its a mix and match of switch of different model and manufacturer and only the primary is managed. Good thing is that those hdmi extender are capped at 10 mb and doesnt eat a lot of traffic in the lan. Sure when the time to update those dumb switches comes ill isolate that network
-
Thanks for the clarification jknott, I was trying to keep it simple in terms of multicast should normally not be routed out the wan, etc. And it shouldn't be since it wouldn't actually be sent to the gateway.
Router doesn't just take a multicast packet and say, hey I should send this out my wan to help get where its going.. If so then all the nonsense multicast SSDP traffic windows clients send would get sent out the wan, etc.