Are devices with an source-IP outside "the interface range" blokked by default !?

johnpoz

You can put in a reject rule if you want.. That is different, a block is only drop.. a reject will tell them with an answer go away ;) You almost never would want just a rule external. But internal - if you want to keep your clients or hope from keeping your clients from banging their heads against something that isn't going to work with retrans, etc. Then yeah a reject would be the way to do that.

But all interfaces default are block - if you do not have a rule that actually allows the traffic, or there is not a hidden rule that allows it.. Then yeah its dropped.. For example of another hidden sort of rules are rules for dhcp. If you enable dhcpd on say opt1, then even if you have no rules on that interface dhcp would still work for clients on that network.

mer

@louis2
If you search the forum you should be able to find a link to the pfSense documentation. It has a good explaination on the different places rules are defined and the order they are processed.
If I'm remembering correctly, the order is:
Floating Rules
Interface Group Rules
Interface Rules

The important thing to remember is pf is last match wins unless a "quick" key is encountered. As you saw in the pfctl output, all the user defined rules have "quick" in them. If they match, nothing after is looked at.

I agree with @johnpoz about block/reject: block on the external interface because I don't care about being nice to anyone trying to get in, reject on internal, because I'll be nicer to my systems.

johnpoz

Here are some good links for rule order and the like

https://docs.netgate.com/pfsense/en/latest/firewall/rule-methodology.html

https://docs.netgate.com/pfsense/en/latest/nat/process-order.html

JKnott

@louis2 said in Are devices with an source-IP outside "the interface range" blokked by default !?:

block all IPV6 having a source address not belonging to this VLAN
block drop in log on ! lagg0.99 inet6 from 1111:2222:3333:99::/64 to any

Create a rule allowing only what you want, then block all else.

block alll traffic having an link local source address

That will break IPv6.

A special definition exists for the IP address 255.255.255.255. It is the broadcast address of the zero network or 0.0.0.0

There should never be a source address 255.255.255.255 or destination address 0.0.0.0. However, both of those are used with DHCP, so be careful.

Take a look at my guest WiFi rules, for some examples.

louis2

@jknott

Thanx, I do agree that I should have used block and not reject. However the main reason of this thread is to check if the firewall is blocking traffic coming from the vlan having a source address which should not be there!

I do agree with your guest wifi vlan set-up. Mine are a bit more complicated since I do allow access to my media server and my public web and sftp server.

@mer
In my post you can see which rules are in the "pfctl -s rules" and also in which order. The five deny rules I see there are in the beginning and I thought that would imply that the rest of the rules where irrelevant.
However .... you write ^important thing to remember is pf is last match wins unless a "quick" key^ and that confuses me. If that is really true in this case ..... then they are overruled by user rules further on .... check

Below a picture of my "test-vlan-gateway-rules"

Louis

louis2

@jknott said in Are devices with an source-IP outside "the interface range" blokked by default !?:

Create a rule allowing only what you want, then block all else.

block alll traffic having an link local source address

That will break IPv6.

A special definition exists for the IP address 255.255.255.255. It is the broadcast address of the zero network or 0.0.0.0

There should never be a source address 255.255.255.255 or destination address 0.0.0.0. However, both of those are used with DHCP, so be careful.

John, be aware that these rules where automatically created! They are not mine.

What is possible is that my interpretation of the rule set is wrong!

Louis

mer

@louis2
Let me try and simplify. I'll cut out a lot, try and make it easier to follow.
Near the top of the pfctl output on has the default deny rules (here IPV4).
block drop in log inet all label "Default deny rule IPv4"
block drop out log inet all label "Default deny rule IPv4"

if you then have something like:
pass in quick inet proto tcp from any to any
block drop in inet proto tcp from any port ssh to any

incoming ssh traffic works because of the quick on the pass rule, it never hits the block rule. If you reorder them, ssh is blocked.
That's what the quick does.

Your rules wind up as you show under Reject-if-outside-addressrange. If a packet matches the first (the reject) it never gets evaluated by the second (destination of !192.168.11.11).
So a packet in on lagg0.99 sourced from 192.168.99.5 dest 192.168.11.11 does not match the first, so it gets to the second where it gets blocked and dropped.
lagg0.99 src 192.168.99.5 dst 192.168.11.12 does not match first rule, and matches second so passes.
lagg0.99 src 192.168.42.37 dest 192.168.11.12 matches first rule and is rejected, never gets to the second rule.

If the quick keyword is not on a rule, a packet can match the rule, but all rules following get looked at for a match.

louis2

@mer

Oeps! Reading you replay I noticed my example pass rule has a not intended negation

This change does not change the intention but never the less

So this changes

I added (the combined IPV4/IPV6 rule is translated into two separate rules)

block return in log quick on lagg0.99 inet from ! 192.168.99.0/24 to any label "USER_RULE: Reject-If-Outside-AddressRange"
block return in log quick on lagg0.99 inet6 from ! 1111:2222:3333:99::/64 to any label "USER_RULE: Block-If-Outside-AddressRange"

"Some Pass Rule I defined (in favor of this overview)"
pass in log quick on lagg0.99 inet from any to ! 192.168.11.11 flags S/SA keep state label "USER_RULE: Pass This Destination"

OK going back to your reaction

block drop in log inet all label "Default deny rule IPv4"
block drop out log inet all label "Default deny rule IPv4"
block drop in log inet6 all label "Default deny rule IPv6"
block drop out log inet6 all label "Default deny rule IPv6"
& for understanding I should add these to my "rule overview mail

pass in quick inet proto tcp from any to any
block drop in inet proto tcp from any port ssh to any
& that is not 1:1 but something like that

block drop in inet proto tcp from any port ssh to any

incoming ssh traffic works because of the quick on the pass rule, it never hits the block rule. If you reorder them, ssh is blocked.
That's what the quick does.
& OK as expected

Your rules wind up as you show under Reject-if-outside-addressrange. If a packet matches the first (the reject) it never gets evaluated by the second (destination of !192.168.11.11).
& that is exactly as intended!

So a packet in on lagg0.99 sourced from 192.168.99.5 dest 192.168.11.11 does not match the first, so it gets to the second where it gets blocked and dropped.
lagg0.99 src 192.168.99.5 dst 192.168.11.12 does not match first rule, and matches second so passes.
& I agreed, but that was to my rule def fault

Most important, I plan to have the ^Block-if-outside-address-range^ rule as very first user rule. Than it should do the job.

However what I do not yet understand, is if this rule is necessary OR that the rules as described under "Default block rules" are already blocking this kind of unexpected traffic.

Louis

mer

@louis2 said in Are devices with an source-IP outside "the interface range" blokked by default !?:

However what I do not yet understand, is if this rule is necessary OR that the rules as described under "Default block rules" are already blocking this kind of unexpected traffic.

default deny rules are at the top.
If there are no other rules after that to explicitly pass the traffic, it is blocked.

johnpoz

Not exactly sure what your trying to accomplish here... The default lan rules already do exactly what you want..

your lan net is allowed, if its not lan net as source.. Then its blocked..

Also its your lan - why would there ever be anything other than lan as source on the lan? If there was, its not going to work anyway ;)