Ethernet rules on two networks

[JonathanLee]

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

[johnpoz]

@JonathanLee They sure are not going to work when they are not enabled. And you didn't have quick set on them either..

What I can tell you is they are pointless.. Why would you create rules in another location when you can just create them on the interface for what your wanting to do.. Now 6 months from now when you want to allow something, your going to be scratching your head because the rule you place on the interface isn't working because you have a rule on the ethernet tab..

Follow the principle of KISS..

Also ! rules are not KISS.. Use explicit allow or deny rules - not some rule you have to work out what it allows or doesn't allow.. A simple explicit rule is Simpler! which is in line with KISS!

[kiokoman]

@johnpoz

KISS ?

[JonathanLee]

@kiokoman HAHAH!!! I was already scratching my head with this was working last version

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