Broadcast storm
-
@kpa:
As it is set up now, you don't have any separation between LAN and DMZ because they are on the same switch effectively nullifying any firewalling you have on the pfSense.
Yes, but that is not the purpose of this post. And what is currently looks like even separting the switches do not have any effect if the broadcasts are being forwarded. But that is just speculation, I have to debug more to see what broadcasts are being forwarded.
-
/16 has 65K hosts… You have that many servers?? That is one freaking huge broadcast domain.. Nobody would ever have that many hosts on the same broadcast domain.. So 10 in the rfc1918 space a /8 -- you think its good idea to use a /8 mask on your interfaces.. You don't think that might have issues with overlap somewhere?
It is bad practice to use an unrealistically large mask because of pure laziness yes.. Do you need that in a rfc somewhere to know its a bad idea?? And bad practice?
-
/16 has 65K hosts… You have that many servers?? That is one freaking huge broadcast domain.. Nobody would ever have that many hosts on the same broadcast domain.. So 10 in the rfc1918 space a /8 -- you think its good idea to use a /8 mask on your interfaces.. You don't think that might have issues with overlap somewhere?
It is bad practice to use an unrealistically large mask because of pure laziness yes.. Do you need that in a rfc somewhere to know its a bad idea?? And bad practice?
True, current network is around 500 ip adresses. Thats also why im setting this up because we are going to split the subnets. It's not that I do not agree but was just curious if there is any best practice for subnet sizes.
-
i doubt there are any "official" rules, but imho, it's best to limit to /23 or /22 (thats around 512/1024 available ip's)
I have a /22 on a public wifi hotspot because i don't wish to run the same SSID on multiple vlans to split it up / it's not an ideal situation, but for sake of simplicity i keep it like that -
Best practice would be correct size ;) That allow for room for growth.. and its good idea if possible to leave adjacent networks open so that you could expand even more or bring up a new subnet in the same logical block, for lots of reasons one of which is the ability to summary route, etc..
If you have 500 servers then a /23 would be most likely enough.. But doesn't leave a lot of room.. Do you really have all your servers on same subnet now?? These servers all do the same thing for the same people? Quite often servers would be broken up into their own subnets based upon location/function/dept etc. etc.. 500 on the same broadcast domain seems high to me to be honest..
You sure wouldn't put servers that serve public or other parts of the network on same subnet as say your database servers or print servers or AD servers, etc.. So that can firewall traffic.. Sure I could see if small location with a handful of servers, and nothing to the public might be easier to just put everything on one network..
But a location that has 500 servers, unless your talking 500 of the same thing I don't see those being on the same network anyway..
-
Best practice would be correct size ;) That allow for room for growth.. and its good idea if possible to leave adjacent networks open so that you could expand even more or bring up a new subnet in the same logical block, for lots of reasons one of which is the ability to summary route, etc..
If you have 500 servers then a /23 would be most likely enough.. But doesn't leave a lot of room.. Do you really have all your servers on same subnet now?? These servers all do the same thing for the same people? Quite often servers would be broken up into their own subnets based upon location/function/dept etc. etc.. 500 on the same broadcast domain seems high to me to be honest..
You sure wouldn't put servers that serve public or other parts of the network on same subnet as say your database servers or print servers or AD servers, etc.. So that can firewall traffic.. Sure I could see if small location with a handful of servers, and nothing to the public might be easier to just put everything on one network..
But a location that has 500 servers, unless your talking 500 of the same thing I don't see those being on the same network anyway..
Yes, 500 servers in one broadcast domain. That's why im going to split it up now before it's to late haha . It's very easy to split it up because there are a lot of different servers.
-
Ok, I did some more research. I found out that the storm is a L3 storm, a netbios storm.
I did a wireshark capture, and this is the line that keeps coming back:
source 172.16.1.1 destination 172.16.255.255 protocol NBNS info name query NB ISATAP<00>This is an example, but the info part changes according to other names.
I found this post that looks like a similar issue:
https://forum.pfsense.org/index.php?topic=95379.0Is it normal behavior to forward netbios request between interfaces? If so, what's the use of it?
Edit:
The equivelant of cisco is "no ip directed-broadcast" is this possible with pfsense? And so not, isn't pfsense vulnerable for a smurf attack? -
And the weird thing, if I turn of the gateway in the default lan to * rule this is not happening.
-
I am not aware of pfsense forwarding directed broadcast or broadcast traffic.. But maybe since you say that ANYTHING send it to this gateway… But if you didn't have those 2 different layer 3 on the same layer 2, then you wouldn't have an issue would you??
-
I am not aware of pfsense forwarding directed broadcast or broadcast traffic.. But maybe since you say that ANYTHING send it to this gateway… But if you didn't have those 2 different layer 3 on the same layer 2, then you wouldn't have an issue would you??
Yes, that's right. Going to seperate it in vlan's anwyay. But maybe it's an idea to include an option in the interfaces like cisco's "no ip directed-broadcast".
-
When I get a chance I will test, but AFAIK it should not forward direct broadcast or broadcast anywhere. I have never it seen it do such a thing.. It shouldn't could test by creating a gateway and then creating a rule to send everything down that gateway and see what it does..
-
route-to (rules specifying a gateway) doesn't necessarily follow the rules of routing traffic that normal routing of the OS will. If passing broadcast traffic with a rule with a gateway, it will forward that traffic as instructed. Where your architecture is poor and you have HA, that can result in a routing loop that's akin to a broadcast storm.
Block broadcast traffic before matching pass rules specifying a gateway in that case.
