Question on overlaping rule for additional LAN
-
Regarding the setup manual here for adding additional LAN:
https://docs.netgate.com/pfsense/en/latest/solutions/xg-7100/opt-lan.html#firewall-rules
For the isolated "mode,"
after allowing DNS and ICMP, to block other traffics it first creates a reject rule to block traffics with destination as this firewall;
then it creates another reject rule with destination PrivateNets (which is just a custom name for the 3 private ranges in RFC1918).It appears that the block-to-firewall is unnecessary unless someone in the LAN is trying to access the firewall via the WAN side with NAT reflection somehow on, or the firewall address on the "LAN" interface somehow has an address not within RFC1918?
Any other exceptions that the reject-to-this-firewall rule is useful while there is already a reject-to-RFC1918 rule below?
Thanks
-
@jay668 “This firewall“ includes all IPs on pfSense itself. Accessing those doesn’t require NAT, as I recall.
-
@steveits Yes but how would the other address from another interface reach the specific LAN interface with the In direction.
For example:
LAN1 is 192.168.1.0/24 with the usual 192.168.1.1 as interface address, LAN2 is 192.168.2.0/24 with 192.168.2.1 as interface address.For the additional LAN (LAN2) The setup manual recommends putting two reject rules should I want this LAN2 internet-only.
1st rule is reject all to this firewall,
2nd rule is reject all to RFC1918, which should already include all 192.168.x.x stuff.With the 2nd rule in place, when will the 1st rule become necessary?
Clients in LAN1 from 192.168.1.0/24 can access 192.168.2.1 regardless of whatever rule under LAN2 since this direction is controlled by rules under the LAN1 interface.
Basically I can't seem to emulate a scenario how a client from another interface can go through LAN2's interface to reach the firewall.I mean the rule is under LAN2 interface,
so the the client has to be hanging below LAN2 in order to "utilize" this rule; but anything under this interface will be covered by the 2nd rule, which states Source-any, destination RFC1918 (which includes the LAN2 interface address, as well as other LAN interfaces' addresses).Having an additional rule doesn't seem to hurt anything, but for it to make any good use, I'm guessing "This firewall" must have an address that is not inside RFC1918, and that interface address doesn't have other block rule by default. Now I'm scratching my head emulating what could that be.
The WAN interface has a non-RFC1918 address, so a client in LAN2 can indeed bypass the reject-all to RFC1918 rule, and try to reach the WAN interface address, but now the WAN interface rejects all private, etc.. so it stops here.
Any tips?
Thanks -
@jay668
Basically you can access a network device with any of its IPs, no matter on which interface the access packet comes in. This is not only pfSense related.
So you can access the firewall for instance by its public WAN address from an isolated network segment, even if you block access to all RFC 1918 ranges. Hence additional to the RFC 1918 reject rule you need to block access to "This firewall". This alias includes all IPs which assigned to pfSense, also the loopback address. -
@jay668 said in Question on overlaping rule for additional LAN:
ut now the WAN interface rejects all private, etc.. so it stops here.
It rejects all rfc1918 coming into its interface from the WAN, it does not filter traffic coming in from a lan side interface.
Keep in mind traffic is evaluated as it enters pfsense from the network an interface is attached too.. So while yes the block rfc rule on the wan stops traffic coming into the wan from the wan or beyond.. It does not filter traffic coming in say lan interface.
The lan interface is what would filter that traffic. So yes if you want to stop a client on the lan from talking to the public wan IP you would need a rule on lan to stop that, which is where the "this firewall" alias comes in handy.
-
@viragomann Ah the loop back address is an interesting one, though it appears that the loop back will direct the package back to the source, so it's a loop back?
I understand that "This Firewall" can include addresses that are not within RFC1918 (the WAN address for example), but don't these interfaces all have default block-all rule?
I mean the Web GUI is listening on all interfaces, including the WAN, but WAN has default block all, and default block private, so that's not a problem.
Guessing I will just follow the best practice to include the additional rule just in case
-
@jay668
The loopback address is basically meant to access a service on itself, but there is also the possibility to forward incoming traffic to the loopback address. If you do this without an associated firewall rule, no rule is shown up on the tab, but the allow-any-to any rule at the bottom would pass the traffic without a reject access to "This firewall" rule, since it is not covered by the RFC 1918 reject rule.I understand that "This Firewall" can include addresses that are not within RFC1918 (the WAN address for example), but don't these interfaces all have default block-all rule?
Note that the access to the destination is evaluated on the incoming interface.
So say your WAN is 9.9.9.9, no rule on the LAN2 would block access to it apart from the "This firewall" and the any-to-any would pass it. Hence LAN2 devices would have access to any service on pfSense using the WAN IP. -
@johnpoz Ah okay, so the package gets one screening only when it first hits the firewall on its LAN interface, not a 2nd time when it hits the WAN interface (or other interface with a non-local address). Then the "this firewall" rule makes sense, especially when a firewall with multiple public addresses without NAT.
Thanks for the clarification anyway.
-
@viragomann Got it, I thought the package would be re-evaluated by the WAN again
Thanks for the clarification.
