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

louis2

Hello,

pfSense has default invisible rules and anti spoofing measures. That is OK !, but I/you can not see what is exactly there

For that reason I wonder if traffic, arriving at a LAN-gateway, having a source address outside the IP-range (IPV4/IPV6) belonging to that LAN-gateway, will be blocked by default.

I expect/hope that there is an invisible deny rules like:

action: Block
interface: "this gateway"
address family: IPV4+IPV6
protocol: any
source: ^invert match^ ^"this gw" net^
destination: any
log: no??? description??

However is a default deny rule like that there !!??

Does any body know?
Where are rules like this ^perhaps present^ rule documented?

Louis

mer

@louis2
If you go to Diagnostics -> Command Prompt and then enter

pfctl -s rules

and hit execute, you will get the rules as they are loaded into pf.

pf "antispoof" rules typically expand into more than one rule, but you will see them, look for the ones that are interface bound.

So they're not really invisible, but camouflaged: you need to really look to see them.

JKnott

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

For that reason I wonder if traffic, arriving at a LAN-gateway, having a source address outside the IP-range (IPV4/IPV6) belonging to that LAN-gateway, will be blocked by default.

If the source is outside the subnet, then it wouldn't arrive there, without passing through a router. When the device tries to send a packet, it checks the destination against it's own address and subnet mask. If the destination is outside it's subnet, then the packet will be sent to whatever the default route is. About the only situation where that packet arrives directly at the interface is when that device is misconfigured, so that pfsense is within it's subnet, but it's not within pfssense's. In that case, you have problems that have nothing to do with hidden rules.

johnpoz

If your lan net is say 192.168.1.0/24 and some IP hits your lan interface with source IP other than lan net say 192.168.2.42 then yes it would be blocked by the default deny. Unless you created or edit rules on your interface or in floating that would allow the traffic.

All traffic is blocked by default, unless it is allowed by a rule. Your lan rules normally have lan net as the source. If the source IP is not lan net, then it would be blocked by the default deny rule.

Yes the default deny are hidden.. You can see the default deny via

cat /tmp/rules.debug

#---------------------------------------------------------------------------
# default deny rules
#---------------------------------------------------------------------------
block in  inet all tracker 1000000103 label "Default deny rule IPv4"
block out  inet all tracker 1000000104 label "Default deny rule IPv4"
block in  inet6 all tracker 1000000105 label "Default deny rule IPv6"
block out  inet6 all tracker 1000000106 label "Default deny rule IPv6"

Gertjan

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

pfctl -s rules

and

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

Yes the default deny are hidden.. You can see the default deny via
cat /tmp/rules.debug

Humm. Not very hidden actually.

mer

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

Humm. Not very hidden actually.

That's why I said they're "Camouflaged" ;)

johnpoz

Hidden meaning they are not shown in the gui when look at the interface rules.

louis2

Hi,

Thanx to @mer his/her tip I could analyze the default rule behavoir a bit further

I did the following to create a "rule-set-extract" related to a "GateWay 99 / VLAN99" specially created for this ^test^

created a rule dump using "pfctl -s rules" then
I defined a test vlan with two rules

the rule I described earlier, trying to block traffic coming from addresses not belonging to this vlan
some pass rule

after that I did create a second rule dump using "pfctl -s rules" again.
than I did extract the diff of those two rule dump

Below I try to understand the rule set related to the created test vlan. The rules below are in the original order. I just added clarifications

"Scrubbing"
"Introduction "Scrubbing" is the normalization of packets so there are no ambiguities in interpretation by the ultimate destination of the packet. The scrub directive also reassembles fragmented packets, protecting some operating systems from some forms of attack, and drops TCP packets that have invalid flag combinations. A simple form of the scrub directive: https://docstore.mik.ua/manuals/openbsd/faq/pf/scrub.html"
scrub on lagg0.99 inet all fragment reassemble
scrub on lagg0.99 inet6 all fragment reassemble

"Default block rules"

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

2 ) block alll traffic having an link local source address
block drop in log on lagg0.99 inet6 from fe80::6a05:caff:fe58:fb6 to any

block every thing originated by the gateway
block drop in log inet6 from 1111:2222:3333:99::1 to any
block all IPV4 having a source address not belonging to this VLAN
block drop in log on ! lagg0.99 inet from 192.168.99.0/24 to any
block every thing originated by the gateway
block drop in log inet from 192.168.99.1 to any

"Allow access to IPV4 DHCP server"
(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, which in Internet Protocol standards stands for this network, i.e. the local network. Transmission to this address is limited by definition, in that it is never forwarded by the routers connecting the local network to other networks.; 99.1 is the gateway)
pass in quick on lagg0.99 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "allow access to DHCP server"
pass in quick on lagg0.99 inet proto udp from any port = bootpc to 192.168.99.1 port = bootps keep state label "allow access to DHCP server"
pass out quick on lagg0.99 inet proto udp from 192.168.99.1 port = bootps to any port = bootpc keep state label "allow access to DHCP server"

"Allow access to IPV6 DHCP server"
(fe80:: = Link-local unicast; ff02:: = IPv6 multicast addresses; "::1 = the gateway")
pass quick on lagg0.99 inet6 proto udp from fe80::/10 to fe80::/10 port = dhcpv6-client keep state label "allow access to DHCPv6 server"
pass quick on lagg0.99 inet6 proto udp from fe80::/10 to ff02::/16 port = dhcpv6-client keep state label "allow access to DHCPv6 server"
pass quick on lagg0.99 inet6 proto udp from fe80::/10 to ff02::/16 port = dhcpv6-server keep state label "allow access to DHCPv6 server"
pass quick on lagg0.99 inet6 proto udp from ff02::/16 to fe80::/10 port = dhcpv6-server keep state label "allow access to DHCPv6 server"
pass in quick on lagg0.99 inet6 proto udp from fe80::/10 to 1111:2222:3333:99::1 port = dhcpv6-client keep state label "allow access to DHCPv6 server"
pass out quick on lagg0.99 inet6 proto udp from 1111:2222:3333:99::1 port = dhcpv6-server to fe80::/10 keep state label "allow access to DHCPv6 server"

"Reject-If-Outside-AddressRange"
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: Reject-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"

The rest is not passed, so blocked <<

Some reaction to your contributions "thanks"
@jknott

"If the source is outside the subnet, then it wouldn't arrive there". That should be the case, however assume that something is hacked, than a computer on the vlan could have (yes or no on purpose) an IP different from the expected subnet range
"When the device tries to send a packet, it checks the destination against it's own address and subnet mask. If the destination is outside it's subnet, then the packet will be sent to whatever the default route is". The traffic type I am refering to should be completely blocked and not handed over to the routing table above the gateway.

@johnpoz

"If your lan net is say 192.168.1.0/24 and some IP hits your lan interface with source IP other than lan net say 192.168.2.42 then yes it would be blocked by the default deny. Unless you created or edit rules on your interface" I assume that is not true since the default deny comes first
"or in floating that would allow the traffic." I did not investigate, but that could perhaps spoil the working of deny rules related to the gateways !?
"picture" I assume that are rules related to all gateways in the floating section. I do not yet know what they do. Perhaps! something related to the wan-gateway ?? and the block at the end of all gateway rules!?
"Yes the default deny are hidden.. You can see the default deny via ^cat /tmp/rules.debug^ .... so rules not visible via "pfctl -s rules"

I hope my analyzes are correct the five rules in the "Default block rules" section, are blocking all traffic I like to see blocked.

If that is true, then the reject rule I defined for the gateway is redundant. However ..... different .... from the rules found in the extracted rule set

Louis

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 ;)