Firewall rule source address
-
Hello!
I am writing a firewall rule for the LAN interface.
When would I not use "LAN Net" a the source for that rule?I see many example LAN rules using "*" as the source.
Is that the same as "LAN Net"?John
-
Of course, it's not the same. "LAN net" is the network you've assigned to the LAN interface, while "*" means really any address.
"LAN net" as source in a rule will fit in most cases, since the rule is for device within the LAN network.
However, there may be rare cases, where you need any. For instance if there is another router connected to the LAN, which routes traffic from another subnet or from the internet to the pfSense LAN interface meant for a device connected to a further pfSense interface. The source address of theses packets will be out of the LAN net range. -
Hello!
I think I understand. I am not great with routing.
If another router is connected to my LAN Net, wouldn't its WAN address have to be an address in my LAN Net, and any packet it sends through my LAN would then have a LAN Net address as its source address? If not, how would I reply or respond back to it?
I guess my primary concern would be suppressing any packets that try to enter the LAN interface with a forged source address. I feel like one of the first rules for a LAN interface should be to drop/reject any packets that don't have a LAN Net source address (!LAN Net).
Maybe that wont work.
John
-
If your downstream router is doing nat, then yes its "wan" address would be in your lan net and you would have no issues.
It almost every case the source network is going to be the networks net, ie lan, opt, dmz net, etc.. Whatever other networks you create.
Where its not the case would be when you have downstream router(s) and they are not doing nat... But in this case it should be a transit interface in pfsense (no host actually on this network - or you could have asymmetrical routing issues).. So your source would need to include whatever downstream networks your routing to and from via this transit interface. Any would just be a lazy way to include all of them, etc..
example: Say you had something like this
In such a case on your firewall rules for source you would want to include all of thos downstream networks, so you could do an alias that contained them, or you could use a mask that included all of them say 192.168.0/22, or just easy with any..
You could do this in 1 rule, or you could do it in multiple rules.. And more than likely you would also want to include the transit network as well. 172.16.0/30 in this example.
Another example might be if your running vip on this interface that is not inside your networks IP range - but this is almost always a bad idea to run multiple L3 networks on the same L2.
edit2: To your dropping !net - this would be taken care of by the default deny at the end (not shown).. Any traffic that is not explicitly allowed by rules would automatically be dropped.. Now if you want to do specific rejects, that is fine too - keep in mind that rules are evaluated top down, first rule to trigger wins, no other rules are evaluated.
Also use of ! rules or negate rules can be problematic - if say your doing any sort of vips.. It is normally better practice to use explicit rules vs ! sort of allow rules. But sure they can be used depending on your needs.. Just make sure you actually validate they are working how you think they should be working.
-
Hi Folks,
I see the post is almost a year old but i couldn't find a better place for my "problem".
I had the thought of scooping off all traffic that is not intended to be there in the first place before passing it through all the filtering. (getting rid of it at earliest convenience i guess).
So, i implemented the Rule "Block !LANNet to ANY" and put it right underneath the anti lockout rule.To my surprise, the second it was active it started blocking legit LANNet traffic.
I know that the Default Deny should deal with that stuff anyway, but nevertheless according to the docs Interface Net should contain all IP subnets, addresses, VIP etc assigned to that inferace and therefore the rule (in my theory and my case) should never match anything.
LANNet only consists of IP Addresses known to the Interfaces DHCP. in that case 192.168.144.0 /24
a few aliases, which dont point to the IP but only to the FQDNs and one VIP (10.10.10.1) used by pfBlockerNG.As reality does not match my expectation, i'm clearly missing something and would be thankful for any help that could end up in me understanding what's going on here 🤪
Thanks
P
-
You have vips set - yeah those can be problematic with ! rules..
This comes up now and then... Let me see if I can dig up the redmine
here you go
https://redmine.pfsense.org/issues/6799And here is post about it..
https://forum.netgate.com/post/758272Why would you think there is anything but lan IPs on your lan net?
In your dnsbl setting, what interface did you put the 10.10.10.1 vip... I believe setting it to localhost removes the issue with vips and ! rules..
-
Thanks for your remarks.
If i have a look at the redmine, and also on the filter created by my rules (thanks to the command posted on the second link), then i can see the problem.
block drop in log quick on igb1 inet from ! 192.168.144.0/24 to any label "USER_RULE: BLOCK ANYTHING NOT LAN" block drop in log quick on igb1 inet from ! 10.10.10.1 to any label "USER_RULE: BLOCK ANYTHING NOT LAN"
The first block is okay, as it does not match any traffic coming from LAN net, the second however - the one active for the VIP - is clearly matching everything coming from LAN net (or not coming from the VIP) and therefore blocks the traffic.
If my rule was written as an pass (referenced to derelict and his position on that pass/block) instead of block, it would just pass anything from LAN and the VIP but never apply following rules... --> is there a way to not have quick applied on this? i guess that doesn't make sense at all, as a "notQuick" rule would not have any effect after all.
Why would you think there is anything but lan IPs on your lan net?
I dont. As I said I didn't expect to ever have any matches for this rule. This rule is not meant to stay in place as it is perfectly covered by the default deny. it was only meant to check or prove that my understanding of what is going on is correct.
I didn't - but i learnt from that, so this (technically) nonsense-rule has totally fulfilled it's purpose ;-)But as the problem was caused by the VIP not being part of LAN net, i wonder if it would be a good idea to place it inside the LAN subnet to circumvent this problem.
I do have IP's left between 144.1 and 144.9Thanks again
P
-
I don't use pfblocker in that way, so not exactly sure if you can put the vip on the lan. I believe the reasoning for using something outside your local networks ranges is to allow for it to work on all of your vlans.
I would hope that setting it to localhost for where the vip is should correct the ! rules issue?
I only use pfblocker to manage some geoip based aliases that I then manually use in my rules - not really a fan of anything auto managing my rules ;)
-
nah! doesn't do a thing!
As long as the VIP is existing, the second filter gets created and therefore applies the Block to anything not coming from whatever the VIP's IP is.
The VIP itself is created automatically by pfBlocker. So no way around the !Net Problem. However - it should'nt have any impact as the rules effect is applied by default deny anyway.--> geoIP... another topic for another day. ;-)
take care
P