Ethernet rules on two networks

[JonathanLee]

Hello fellow Netgate community members,

Can you please help?

I have two networks one is 10.0.0.1 wireless card internal on the firewall and one is 192.168.1.1 for the lan side

Why does the Ethernet rules like this stop all traffic?

IPv6 is not an issue it's opt and WLAN

[johnpoz]

@JonathanLee where is your allowed rules? Those rules all look disabled, they look greyed out to me. What are you trying to accomplish with ethernet rules.. Those are for L2..

I would suggest you read over for what your trying to do..

https://docs.netgate.com/pfsense/en/latest/firewall/ethernet-rules.html#ethernet-layer-2-rules

[JonathanLee]

I would like to

1. block all layer 2 ethernet OPT1 traffic to WLAN

2. block all layer 2 ethernet WLAN traffic to OPT1

I should be allowed to do this as it's a different subnet with a different interface but when I activate the rules it blocks everything.

When I enable those rules I loose internet and GUI access.

10.0.0.0/24 should only access the 10.0.0.1 for default route

192.168.1.0/27 should only access the 192.168.1.1 for default route.

I can access the firewall GUI on 192.168.1.1 and 10.0.0.1 (now blocked)

my interface assignments are here

why does those two rules block all access when enabled?

[johnpoz]

@JonathanLee said in Ethernet rules on two networks:

block all OPT1 traffic to WLAN

1. That is a simple rule on opt1

2. Same but on the wlan interface

Rules are evaluated as traffic enters an interface from the network its attached to.. Top down, first rule to trigger wins, no other rules are evaluated.

There is zero need for the "experimental" L2 rules to do such a simple thing..

I would use an alias for rfc1918 and allow what you want, then block.. Here is baseline example rules for locking down a network.. Edit to your needs.

The use of the alias for rfc1918 allows you to add future other networks that this network will not be able to get to, unless you create an allow rule for what you want to allow above the block rfc1918

I use reject vs block because this is local, and why let something keep trying to retrans to get somewhere where can just let it know with the reject - hey buddy you ain't getting there.

[JonathanLee]

@johnpoz I do have the firewall IP layer 3 rules already working for the guest network and it blocks access pings everything. I just wanted to also block out the layer 2. In 23.05.01 I never had traffic showing on those two layer 2 rules 23.09.01 when I activate them it blocks everything when you turn them on. I don't understand why.

(layer 3 rules secure subnet interface WLAN external AP)
First rule block out all WLAN to OPT1

(layer 3 rules guest non filtered interface ath0 wireless interface subnet)

I negate it allow anything except WLAN and block firewall GUI 10.0.0.1:8080 as you can access it with that also.

Yes this does work, I just wanted to play with Layer 2 rules but I got something mixed up, that's why they are greyed out. IPv6 is disabled at ISP level, and it works when I have that layer 2 rule active.

[johnpoz]

@JonathanLee said in Ethernet rules on two networks:

I just wanted to also block out the layer 2

Pointless rule for zero reason, you already have a rule to block.

BTW your rule there to block 10.0.0.1 for the webui, doesn't stop from accessing the wan IP.. Which isn't wlan so your ! rule allows it.. If you don't want a network talking to pfsense for anything other than what you want, then use the "this firewall" alias..

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