Just installed the release; Something wrong with multicast !!!
-
@louis2 said in Just installed the release; Something wrong with multicast !!!:
"239.255.255.250:1900" showing up in vlans, where they definitively do not belong!
Is the source IP in the correct vlan.. for example your 192.168.100.15 - is that showing up on the 192.168.100 interface, or are you seeing it on a different interface, like your 192.168.200 network?
-
John,
After upgrading I was a bit overwhelmed by the large number of alarms in the logs. Far more then there used to be. A lot of them are probably correct.
However the large group related to "239.255.255.250:1900" where absolutely not OK.
The reason for that is quite simple.
'VLAN A' has e.g. IP-range '192.168.100.0/24' and 'GW-A' and
'VLAN B' has e.g. IP-range '192.168.200.0/24' and 'GW-B'What I large scale saw was IP-sources. 192.168.100.x arriving on GW-B. Unless the routing on your network is absolutely NOT OK. That should never be the case!
And I never saw that before. The only thing I changes was the pfSense release.
What ever, I decided to turn off Avahi and PIMD since that are packages which could trigger "1900" messages (but of course then can not change the source IP-address of devices in a vlan
) .What ever a couple of minutes later the alarm avalanche stopped, probably not because I solved the problem, bur due to the fact that I stopped the trigger for this type of messages.
I also noticed a lot of IGMP towards 224.0.0.1 which I never saw before. Perhaps that is correct. Note that I saw them on my (unused) IPTV WAN
And I saw a surprisingly high number ssh and https attacks over the WAN towards my WAN-gateway. Since you can not access the FW from the internet. They can not harm, but never the less I was suprised. I stopped logging them ....
My first impression is that the rest of the alarms in the log are mainly "normally expected" burglary attempts.
I did not have time to dig deep, however I was especially surprised by the first mentioned set of alarms.
-
@louis2 said in Just installed the release; Something wrong with multicast !!!:
surprisingly high number ssh and https attacks over the WAN towards my WAN-gateway. Since you can not access the FW from the internet. They can not harm, but never the less I was suprised. I stopped logging them
If they are logged by the default block rule, you can turn off that logging (we always do). If they are logged "attacks" or failed logins then pfSense would not be able to log that if the port was not open, and in that case you should double check your WAN rules, or floating rules.
-
@louis2 said in Just installed the release; Something wrong with multicast !!!:
However the large group related to "239.255.255.250:1900" where absolutely not OK.
The reason for that is quite simple.
'VLAN A' has e.g. IP-range '192.168.100.0/24' and 'GW-A' and
'VLAN B' has e.g. IP-range '192.168.200.0/24' and 'GW-B'What I large scale saw was IP-sources. 192.168.100.x arriving on GW-B. Unless the routing on your network is absolutely NOT OK. That should never be the case!
Is your switch configured for multicast forwarding or routing?
What ever, I decided to turn off Avahi and PIMD since that are packages which could trigger "1900" messages (but of course then can not change the source IP-address of devices in a vlan ) .
Port 1900 is SSDP, to which Avahi has no relationship. Avahi is an mDNS service, which is port 5353.
-
@louis2 said in Just installed the release; Something wrong with multicast !!!:
192.168.100.x arriving on
If your seeing source IPs of .100 on your .200 interface then you do not have isolation at L2.. plan an simple... There is no way for interface 192.168.100 to see traffic a device that is 192.168.200 and on a different L2 network... The only way you could see such traffic is if your not isolated at layer 2.
Or as mentioned you got something forwarding multicast traffic in your network.
Or you have something multihomed in your network, ie a leg in both networks and its sending traffic out the wrong interface. Which again would be lack of isolation at L2 ;) Anything that has legs in multiple networks better be a "router" or clearly know what your doing so it is not a security issue. And that it handles routing of its own traffic correctly.
My pc has legs in 2 networks.. But the 2nd leg is a SAN network between it and NAS.. There are only those 2 devices on that network, and that network is completely isolated from the rest of the network... Now it is possible that one of those devices for example might throw traffic out its normal LAN connection with a source IP of the SAN network.. But yup pfsense would not like that traffic, and prob throw up some logs about it.
-
Related to your switch routing remark:
- I have no multicast routing on my switches
- my network "short" is pfSense on top with two star-networks towards the devices
- one 1G network "star" and one 10G "star"
There is one network device having a 10G trunk containing many vlans. That are my TrueNas system. And recent TrueNas versions seems to behave correctly (in regard to vlan routing). Apart from that the problem I saw was also on a combination of 1G en 10G network parts.
The PIMD deamon I installed on pfsense and is normally running I stopped, The deamon is there to allow audio streaming across vlans.
However it should not, and I never noticed in the past, lead to traffic which seems to come from a different vlan.Yep, related to Avahi
- you are right. I enabled it.
-
@johnpoz
Im going to def agree with you that this smells like state policy changed here.
IGMP is being sent out multiple vlans and i am surmising that Source IP , 192.168.100.15 is appearing in multiple vlans [which is fine and can happen]. State changes introduced will block this of course. -
@michmoor said in Just installed the release; Something wrong with multicast !!!:
192.168.100.15 is appearing in multiple vlans [which is fine and can happen].
No it shouldn't... There is no reason at all that some source IP on network X should ever be seen on network Y.. If it is there is no isolation at layer 2.. Your just running multiple L3 on the same L2. This is not "fine" - does it happen, can it happen.. Yeah but unless your running the multiple L3 on purpose - maybe transition transition from one L3 to a different L3.. Some sort of loopback address over a different network, etc.
Multicast sure be seen on any interface in an L2.. But your interfaces at L3 should be in different L2s - or your not actually isolating anything.. And you might as well just get some dumb switches and just run multiple L3s on them and call it hey look ma I am segmenting ;)
The only time you should see multiple different source L3 networks hit a interface on an L2 is if that interface is a transit network.. But that L2 is different than your source networks L2, and you wouldn't see multicast on it.
You have something odd in your network, be it by design or accident is the question. Are you for some reason running multiple L3s on the same L2?
-
@johnpoz said in Just installed the release; Something wrong with multicast !!!:
No it shouldn't... There is no reason at all that some source IP on network X should ever be seen on network Y..
actually, no.
I am interpreting the problem statement that the OP is seeing a multicast source appearing on different VLANs and its getting dropped.
A LAN with an IGMP querier with the same source address can in fact and does appear on multiple VLANs and hence my statement that its fine.
If this was happening before and they are noticing it now but its not causing any problems than its fine.
Generally speaking this isnt really an issue other than a noticed one by the OP. -
@michmoor said in Just installed the release; Something wrong with multicast !!!:
Generally speaking this isnt really an issue
Unless the user has on purpose setup something to send multicast across L2 segments, then it is an issue. Because they don't actually have the isolation they think they do.
If they for some reason want to circumvent the L2 barrier by design, then sure its not really an issue in the fact they are doing it on purpose. But if they have not done it on purpose, then yes it is a issue.
What I am trying to determine is this by design, or by accident. But I agree if I am sending multicast across L2 boundaries then yeah I would expect to see multicast hit a interface with a different source IP.. Just disable logging of that noise..
But if pfsense is the forwarder of this multicast, its interfaces shouldn't be seeing it..
X -- pfsense -- Y
If pfsense forwards multicast on X to Y.. Where how would pfsense be seeing multicast to its own interface from a different source network? So if X is seeing multicast from Y, points to the L2 barrier being circumvented elsewhere in the network.
Once pfsense send on the multicast to the Y network, the Y interface shouldn't be seeing X as source into Y interface, unless there is a loop in the Y network.
-
Most likely this:
Hard to tell from the GUI at the moment but it would be easy to spot in the actual firewall log:
https://redmine.pfsense.org/issues/15415
See also: https://redmine.pfsense.org/issues/15400
-
J jimp moved this topic from Plus 24.03 Development Snapshots (Retired) on
-
D dennypage referenced this topic on
-
D dennypage referenced this topic on
