Ethernet rules on two networks

[JonathanLee]

It should have worked thoe from the experimental side "testing puzzle side of things" right no reason it shouldn't have

[johnpoz]

https://en.wikipedia.org/wiki/KISS_principle

I know its not just a Navy thing - but that for sure where I picked it up.

Here is the take away "simplicity should be a key goal in design, and unnecessary complexity should be avoided"

So again - the main point of the principle "complexity should be avoided"

Having multiple rules in multiple locations - one designed for layer 2, when all you need to accomplish the goal is a simple L3 rule sure doesn't follow KISS..

If you want to play with the ethernet rules - that is great, play with doing something they are meant to do, block a specific mac or something.. This could come into play if your not doing reservations, or your worried some slightly brighter 5 year old on your network might know how to change an IP ;)

[keyser]

@JonathanLee said in Ethernet rules on two networks:

@johnpoz I guess that's why it is experimental something is mixed up. Those rules should work right? I agree it's pointless as IP layer 3 is blocked already, but arp storms is also what I want to stop.

But Ethernet rules are L2 rules, and since you need L3 to pass from your WLAN to LAN Those rules does not make sense. You are blocking all Ethernet frames coming in on your interfaces with rules like that. Think of your destination selection (an interface net) as the ARP table for that interface. That table includes the firewall interface on that interface - aka the firewall Ethernet MAC Address - and thus No One can pass any traffic to the firewall MAC which is needed for all L3 forwarding and local Firewall management.

[JonathanLee]

WLAN is yes is on the firewall LAN, and OPT1 is a internal pcie card both MACs only need to access WAN and not each other as they have two different interface MAC addresses.

I have OPT1 set up as Guest WiFi.

I think in this situation as I can access GUI on 10.0.0.1 and on 192.168.1.1 and both subnets have a different outbound NAT it's different. They don't need to talk, I already have the WAN's MAC approved to talk to "any" from WAN MAC inbound and from the two other interfaces back with their MACs outbound to WAN's MAC on the rules lower down with my ISP address. (This is not shown in the photo)

It worked for 23.05.01 too.

[JonathanLee]

@johnpoz my Dad says that all the time KISS

[johnpoz]

@JonathanLee said in Ethernet rules on two networks:

both subnets have a different outbound NAT it's different

What? You have more than 1 wan interface - your outbound nat of any of your local networks should be to your wan IP.. Unless you have more than 1 and or your connecting to a vpn and routing traffic out that connection for specific clients or networks.

have the Mac already approved to talk to any from WAN

Huh?? From your wan? That makes zero sense.. The only mac address you would see on your wan, is the mac address of the device your wan is connected too.. Is your wan connected to a switch or something and you have other devices on this switch? The only mac address that ever comes into my wan, is the mac address of my "modem"

I would again highly suggest you read the link I provided about the ethernet rules - and what they can be used for..

edit, example here is some L2 arp traffic.. From 2 different IPs because my isp runs multiple L3 on the same L2

if you are plugged into your isp device for pfsense wan, the only mac you should see is from the isp device.. Now if your isp wasn't doing isolation and it was just a switched/bridged network you might see some other macs.. But your isp is doing it freaking wrong if that is the case.. Unless you have some L2 network between your pfsense wan and your isp device with other devices on it, pfsense wan should only ever see the 1 mac coming from your isp device.

[JonathanLee]

2 interface MACs one for guest wifi card(OPT1) and second for firewall LAN(WLAN).

1 MAC address for one WAN interface

1. Rule Guest WiFi MAC address approved to talk to WAN MAC address direction any pcie card OPT1

2. Rule LAN or WLAN MAC address approved to talk to WAN MAC address outbound/inbound direction any

3. Rule WAN MAC address approved to talk to any, plus the WAN gateway MAC

There is really no need for guest wifi MAC address to talk to LAN MAC address at all ever here. They never need to ARP out to each other ever.

[johnpoz]

@JonathanLee said in Ethernet rules on two networks:

Rule Guest WiFi MAC approved to talk to WAN MAC outbound

Completely utterly pointess!!! because it doesn't work that way at all..

None of those rules make any sense at all!!! There is no scenario that mac from device on 1 layer 2 network would ever talk to a mac on another layer 2 network..

You seem to have a lack of understanding of L2..

[JonathanLee]

@johnpoz I know that's what makes the puzzle fun right? Why does the block rules from subnet to subnet work for 23.05.01 but not 23.09.01. In 09 it's like the merged to using the marvel switch and before the ath0 didn't it was on its own. That's what it acts like anyway. It's a mystery.

[johnpoz]

@JonathanLee Have no idea what your trying to accomplish.. But mac abc on layer 2 A, doesn't ever talk to mac xyz on Bs layer 2 network..

It doesn't work that way!!!

You need to do some research on how macs are used and what a layer 2 network actually means.. Because your completely off base, or are explaining it horribly.. There is no scenario ever where some mac address on my lan would ever need or care or even trying to send traffic to my wan interfaces mac address. or the other direction, it doesn't work that way!!!

[JonathanLee]

@johnpoz I know it's a good experiment right? Why did this work for 23.05.01? It shouldn't have from your knowledge? It's the layer 2 mystery machine rules. ..

[johnpoz]

@JonathanLee said in Ethernet rules on two networks:

I know it's a good experiment right?

No!! its completely pointless and meaningless waste of time because it just doesn't work that way.. There is no point in trying block or allow any of such traffic - because the traffic never happens, ever!!!

[JonathanLee]

@johnpoz I bet it's my broadcast MAC is missing in the rules. Are you also doing puzzles with the experimental rules also?

I had ARP broadcast storms in the past all the time randomly.

[JonathanLee]

@johnpoz

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

[johnpoz]

@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..

[JonathanLee]

@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.

[johnpoz]

@JonathanLee said in Ethernet rules on two networks:

Yes I understand.

You keep saying that - yet clearly you don't!!

[JonathanLee]

@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

[johnpoz]

@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..

[JonathanLee]

@johnpoz

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