LAN net (<<interface name="">> net) doesn't include static route networks.</interface>

[ipodgorny]

Hello guys,

I'm having a little problem with firewall rules. I think that I'm not understanding "LAN net" correctly under firewall source/destination section.
According to https://doc.pfsense.org/index.php/Firewall_Rule_Basics
LAN net - The subnet configured on the LAN interface under Interfaces > LAN. On pfSense 2.2+, this also includes static route networks on that interface.

Here is what setup looks like, and what I'm talking about:

LAN IP: 172.16.1.1 /24

LAN_GW: 172.16.1.2 /24

Static routes
Network: 10.0.0.0 /24 Gateway: LAN_GW
Network: 10.0.10.0 /24 Gateway: LAN_GW
Network: 10.0.20.0 /24 Gateway: LAN_GW

Routing and all communication functions as expected when inspection is off, floating rule any-any is in place, default rules modified, and so on…
But any rules where "LAN net", or another "<interface name=""></interface> net" is selected either as source or destination don't seem to apply to any static route networks, including Default rules created by pfSense. pfSence can't be pinged from, or pass traffic to outside world from any hosts on any of the static route networks (10.0.0.0 /24 for example), unless I create a separate rule for each network, or use any as source. However, automatic NAT rules are created for static route networks.

The question is. Is it expected behavior and I'm not understanding "LAN net" option correctly, or am I doing something wrong, or it's a bug?

Thank you.

[cmb]

That's how it's supposed to work. LAN net is strictly for the directly-attached networks. That wiki edit was meant to clarify the use of IP aliases, which are added to the net aliases in 2.2+. I fixed it.

[johnpoz]

Curious why would you make a transit network /24??

And you created a gateway for that right, you didn't actually put the gateway on the interface..

[ipodgorny]

@cmb:

That's how it's supposed to work. LAN net is strictly for the directly-attached networks. That wiki edit was meant to clarify the use of IP aliases, which are added to the net aliases in 2.2+. I fixed it.

Thank you for clarifying:) Which leads me to suggestion that I should probably place in a feature request somewhere…

Ability to create static and dynamic (wishful thinking here) network objects. A single entity for set of networks, IPs, hosts for static, and some rules to populate dynamic (static route networks, OSPF, BGP networks, or something like that). Something similar to Interface groups. I can probably think of at least 3 scenarios where it would enhance experience:

1. Firewall rules - something that I've started his whole thread with.

2. NAT - Multi-LAN each with Multi-VLAN scenario where user doesn't want to use NAT. Single "Do not NAT", or NAT everything if destination "is not" rule would eliminate some headaches.

3. IPSec / OpenVPN - Automatic stage 2 creation to include all members in a Network object. Push all object network members to OpenVPN clients.

Well, going a bit of topic here... Once again thank you very much for clarifying this.

[ipodgorny]

@johnpoz:

Curious why would you make a transit network /24??

And you created a gateway for that right, you didn't actually put the gateway on the interface..

The network is actually /29, sorry, I didn't think that it was of much importance in this particular case.
It's isn't /30 only because there are other devices on this particular network. There is a web filter, router to another set of networks, and a few other things.
Gateway IP is IP of device using which those networks can be reached.

172.16.1.2 is a Layer 3 switch. As well as there is a separate gateway for the router I've mentioned earlier, and static routes to networks behind it (should probably change to OSPF on this one.)

[johnpoz]

Sure /29 is very common for a transit network, leaves you some IPs to play with ;)

I am curious to your desire to run OSPF or any routing protocol to be honest. While I fully understand the need for routing protocols in a very fluid and dynamic environment..  I fail to understand their use when the networks never change, or a network gets added once a year or something.  Are you in a very fluid setup… Does your downstream router/l3 switch get networks added/removed all the time.. Are they not all in specific range where you could just create one summary route that even if networks got added they would still be routed to the downstream device, etc..

As to creating network "objects" you can already, those are aliases, if you use something that resolves then it would be dynamic in nature if that fqdn changes to resolve to a different IP...

As to creating an alias based upon a route you get from a routing protocol.. To be honest not sure that is a really good idea.. What if you had a rule that allowed access or from network 1.2.3.0/24, and they start advertising some new network 1.2.4.0/24 as well..  You sure you want that network to have the same access??

[ipodgorny]

@johnpoz:

Sure /29 is very common for a transit network, leaves you some IPs to play with ;)

I am curious to your desire to run OSPF or any routing protocol to be honest. While I fully understand the need for routing protocols in a very fluid and dynamic environment..  I fail to understand their use when the networks never change, or a network gets added once a year or something.  Are you in a very fluid setup… Does your downstream router/l3 switch get networks added/removed all the time.. Are they not all in specific range where you could just create one summary route that even if networks got added they would still be routed to the downstream device, etc..

As to creating network "objects" you can already, those are aliases, if you use something that resolves then it would be dynamic in nature if that fqdn changes to resolve to a different IP...

As to creating an alias based upon a route you get from a routing protocol.. To be honest not sure that is a really good idea.. What if you had a rule that allowed access or from network 1.2.3.0/24, and they start advertising some new network 1.2.4.0/24 as well..  You sure you want that network to have the same access??

Sorry for delayed reply, I didn't check forums in a while.
I've found an "alias" after posting last reply, and functionality is very helpful.

Reason for OSPF as those networks have same level of access. So if there are any additions / removals of VLANs - routes would be advertised via OSPF and added to a routing table. Also additions of networks on our end would need a static entry at all other locations. We have multiple locations, and a quite dynamic setup I simply don't have time or desire to maintain static routes.