Ethernet rules on two networks
-
Checkout the traffic, it works. All they do is ARP out, with who has this, and who has that without the ability to ARP there is no broadcast storms, I see the need as I hate broadcast storms.
I am talking to you right now with those rules. So they do work, or did at one time. Yes they should never talk so why does this rule list block everything in 23.09.01 it should never attempt to even try like 23.05.01 does, not one state established for those block rules, I change over to 23.09.01 and the rules need to be grayed out or they fill up with states and I am blocked out. I have log on with a putty session and run pfctl -d to get to the GUI with 23.09.01 using these rules.
Yes I didn't use KISS here as each rule has its specific MAC address for every device. Took forever, yes it's over the top. But it's a good 🧩 puzzle. Long story short XBOX 360 loved to create broadcast storms. IoT devices also makes broadcast storms sometimes. Remember those bot net broadcast strom denial of service attacks that were occuring a couple years ago with every IoT devices all at once?
I didn't have the FF broadcast address rule I need to fix that still in the rules just don't know where to put it, I have no default block so everything else after my list is approved. If I add a block all on the last this also blocks me out of the GUI, it needs a FF broadcast rule too.
layer 2 rules under constitution 
-
@JonathanLee not sure what your talking about.. A device on the lan network would not arp for an IP another network.. Arp doesn't work that way! A device is only going to arp for an IP on its own network..
You clearly do not understand how arp works.. Or where mac addresses are used..
There is no scenario where a device on lan nework say 192.168.1.0/24 would arp for the mac of say your wan interface 1.2.3.4.. It wouldn't because it doesn't work that way.
And so what even if it did, it would never get an answer because your wan interface is not on the same L2 as your device on the lan network.. So even if it did arp, it would never get an answer..
There is no scenario where a device on your lan would ever send traffic to the mac address of your wan address.. Even if did, it wouldn't get anywhere because the mac of your wan interface is NOT on the lan L2 network..
-
@johnpoz Yes I understand. Again, when I install my SSD with 23.09.01 those two rules block everything, there should be like you say still no layer 2 frames being sent between the two different interfaces. I just understand why the all the sudden show states in 23.09.01 when in 23.05.01 those two rules did nothing and didn't matter. What changed here the ff:ff:ff:ff:ff broadcast? How ath0 driver is implemented to the firewall by way of the marvel switch? It should still show no traffic and I would hope it would not block out everything. But it does, I have been experimenting with it for a while now, it's just the OSI data link layer. So why all the sudden do I need to disable rules that should never have traffic. That means 23.09.01 has a broadcast storm vulnerability no matter what vlan or interfaces are used layer 2 arp requests hit everything in 23.09.01.
Me I am back on 23.05.01.
23.09.01 also removed my cryptoID it cant find it.
23.09 needs some work end of story layer traffic should not do this. Yours now does it too, and the firewall will respond to it.
-
@JonathanLee said in Ethernet rules on two networks:
Yes I understand.
You keep saying that - yet clearly you don't!!
-
@johnpoz I can show you the logs that prove the layer 2 broadcast domain no longer is separated, but I have to install the SSD again. I will do it tonight, it shows states for it and locks out the GUI. It should be two separate layer 2 broadcast domains like it is in 23.05.01 not one like 23.09.01. It is now grouped the pcie card and the lan switch as the same broadcast domain. Again the size of 23.09.01 image is a smaller also. I had the two rules as a just in case to track them, in 23.05.01 they never hand traffic between them and they never needed to be disabled to access the GUI. It was simplified in 23.09.01 but in doing so made one big layer 2 broadcast domain. Do some experimenting with it and you will be scratching your head if you have a pcie card.
I will show you the logs for it tonight. It shouldn't do it but it does. Many states get established on a fresh firmware install.
I will get a screenshot with logs tonight showing the weird broadcast domain issue in 23.09.01 it shouldn't show any layer 2 traffic between the two different interfaces/IP subnets as one is a hardware pcie card versus an external AP on a firewall lan port. But all the sudden now I have to have those rules deleted for the firewall to even work, like your saying that shouldn't ever happen. It should only talk to 10.0.0.1 for guest WiFi (OPT1 interface) or 192.168.1.1 for external AP (WLAN interface)
"I have not failed, I have just found 10,000 ways that won't work." -Thomas Edison
-
@JonathanLee I have no desire to see anything your messing with because you clearly do not understand how a firewall works at even a basic level, nor how mac addresses work..
There is NO scenario where a device on your lan would ever arp for or talk to the mac address of your wan interfaces mac - ever!!
What changed here the ff:ff:ff:ff:ff broadcast
If your blocking at layer 2 arp completely,ie the ff:ff address then pfsense would never even answer an arp for its lan IP.. If a device can not find the mac of its gateway then no its not going to be able to get off its network at layer 3.
Here.. as you can see my vm can see the mac of its gateway (pfsense) on its 192.168.2.0 network.. The 192.168.2.253 address
I then create a rule to block at layer 2 my box from talking to ff:ff - so now pfsense would never see the arp to be able to answer.. Other devices on that same layer 2 would not be effected.. Only pfsense seeing the arp to be able to answer.
So now if I delete the arp cache, and then try to arp - you see it comes back incomplete.. So now that device would never be able to talk to anything not on its local network..
And sure you can see that rule triggered - because guess what my test box, sent out an arp to ff:ff -- that is where arps are sent!! But ONLY!!!! devices on the same L2 would ever see those.. And the device would never send a arp looking for the mac address of some IP that is not on its local network.. And even if it did there would be nothing that would answer..
You clicking random shit in the new ethernet interface is yeah prob going to lead to you breaking shit..
-
The WAN side I mixed that up sorry. Thanks for clearing that up.
I am only talking about issues with WLAN(Firewall LAN port interface) talking to OPT1(ath0 pcie card internal in firewall interface)
What would make those interfaces want to talk with each other in 23.09 and not have this issue with 23.05 same firewall rules you see here. If I turn them on I have no Internet or GUI it won't even give out DHCP addresses. That makes no pfSense sense to me.
Each rule has MAC address attached to the device and allows any for destination.
The only blanketed one is the subnet rules have issues in 23.09
That ruleset above works perfectly in 23.05.01
-
On 23.09.01 it kills GUI and all traffic when the two rules are enabled. Right after states start.
Experimental issues?? It should not have layer 2 traffic between them right? But there is is attempting it and after no GUI
23.05.01 no issues I can have them enabled. Just in case you want to look at what was changed with broadcast domains.
-
J JonathanLee referenced this topic on
-
https://redmine.pfsense.org/issues/15104
-
@johnpoz I know KISS but I think the issue is I have Mac for all source and none for ffffffffffff broadcast set up….. maybe it’s now blocking that in 23.09
So I should have each interface have a approve ffffffffff MAC address also
