How to include multiple subnets in "LAN net"?
-
GomezAddams, you're going to run into big trouble sooner or later with that kind of network. Although it will work for some time, keep in mind that Ethernet was designed to be used in a different way than this.
To make a comparison, your network topology looks pretty much like having a Ferrari at each location, trying to achieve maximum speed using the gearshift only in position 2.
-
So you want multiple properties all connected by some sort of WAN technology all on the same broadcast domain in one big, flat network, and depend on proxy arp to get traffic from each property to the others with multiple layer 3 networks on top of it.
All I can say is, "Good luck with that."
What? No.
It is all routed. I don't understand why you would think it is all one big broadcast domain. I have a number of locations with a /16 for each location.
-
GomezAddams, you're going to run into big trouble sooner or later with that kind of network. Although it will work for some time, keep in mind that Ethernet was designed to be used in a different way than this.
To make a comparison, your network topology looks pretty much like having a Ferrari at each location, trying to achieve maximum speed using the gearshift only in position 2.
I must not be making myself clear. I'm not using ethernet in any strange way. I just have multiple locations with a /16 for each location. Each location is routed.
-
I did find a rather sneaky way of accomplishing the same thing: set the mask on my LAN interface to 255.0.0.0 and then let the router proxy arp for all the routed subnets. Ugly, but it does work as long as all my internal networks are 10.x.x.x
Yes. Yes you are.
-
Keep your LANnet with the proper mask for its real local range.
Assuming the other subnets in your intranet are reachable through some internal router that is connected somewhere to pfSense, add a gateway that is the internal router, and static routes on pfSense to tell pfSense how to reach those other subnets.
Add rules to allow traffic from those subnets into pfSense on the interface where it arrives, with destination whatever you want to allow (reaching all of LANnet, going through pfSense out to the internet or whatever you need…).For the rules you can make aliases to make it very easy to add all those subnets in 1 rule.
In static routes you can also use the alias, and you pick the gateway from a list.
So actually if your subnet list changes in future you just change the alias and it should take effect auto-magically in both rules and routes.
-
I did find a rather sneaky way of accomplishing the same thing: set the mask on my LAN interface to 255.0.0.0 and then let the router proxy arp for all the routed subnets. Ugly, but it does work as long as all my internal networks are 10.x.x.x
Yes. Yes you are.
AH, I think I see the misunderstanding. The place this hack would be in place is ONLY on the pfsense LAN interface. Everything else would have proper subnet masks. By setting the pfsense LAN interface mask to 255.0.0.0, pfsense thinks everything 10.0.0.0 is "LAN net" (as far as rules go). This would cause pfsense to think the whole internal network was on the local segment, but turning on proxy ARP on the router interface that pfsense is connected to would fix that. Everything else would use the normal routing mechanisms to communicate.
It sounds like the solution to this problem is to create an alias wit hall the internal subnets and use that when creating rules instead of "LAN net". I was just somewhat surprised to find that pfsense doesn't have a built-in mechanism for expanding the scope of "LAN net" to more than just the subnet pfsense is connected to.
In other words, it seems odd to me that pfsense equates the LAN subnet mask to the scope of what are internal networks.
-
pfSense comes with a default configuration that makes it easy to get up and running with a very basic setup. 1 WAN, 1LAN, no routed subnets. In that config then, yes, the LAN subnet is the extent of the internal network. If your network is more complex than that, as yours is, then you have tell pfSense about it. I'm not quite sure what you expected to see. I guess there could be a wizard maybe that added gateways, routes and firewall rules appropriately.
Since this obviously wasn't what you expected to happen please let us know what you think could be done to improve matters. What back ground are you coming from etc. :)
Steve
-
LAN net is an automatic pf alias for the network configured on interface LAN.
Your other networks are not "LAN net." Just accept that.
You are wrapped around the axle insisting on using "LAN net" to the point of configuring your network in a completely unorthodox and broken manner when the mechanism exists to easily create aliases containing anything you want.
I was just somewhat surprised to find that pfsense doesn't have a built-in mechanism for expanding the scope of "LAN net" to more than just the subnet pfsense is connected to.
Why should it? It is automatically changed when you change the interface address and netmask. If you COULD edit LAN net it would be the same as creating and editing an alias anyway so just do that.
Now what WOULD be nice would be the ability to include "LAN net" in the alias networks so it would be automatically included and tracked with interface changes. You can nest aliases, but not these automatic interface network aliases.
-
pfSense comes with a default configuration that makes it easy to get up and running with a very basic setup. 1 WAN, 1LAN, no routed subnets. In that config then, yes, the LAN subnet is the extent of the internal network. If your network is more complex than that, as yours is, then you have tell pfSense about it. I'm not quite sure what you expected to see. I guess there could be a wizard maybe that added gateways, routes and firewall rules appropriately.
Since this obviously wasn't what you expected to happen please let us know what you think could be done to improve matters. What back ground are you coming from etc. :)
Steve
I guess what I'm getting at is that the current "LAN Net" built-in alias (if that is the right term) becomes useless in any scenario other than the simple case of one internal subnet. To improve usability, "LAN Net" could be renamed "Internal Net" or "Trusted Net", and would be an alias that defaults to the subnet that contains the pfsense LAN interface but could be edited to contain all of your internal subnets.
I agree wholeheartedly that pfsense has a perfectly usable default. But pfsense is obviously designed to handle non-trivial cases, and the interface usually does that quite well. I think that's why I was mildly surprised to find there isn't a way to add your internal networks into the "LAN Net" alias that the default rules are built from.
I come from a Cisco ASA background. Cisco, being Cisco, defaults to ultimate security - no network objects defined, and no rules. You set up an object with your internal networks, and create your "allow" rules. At least I think that's the way it works - it has been a long time since I've set one up from scratch.
Again, I'm not complaining. The solution of creating an alias for my internal subnets and building rules from there is perfectly acceptable.
-
Ah, interesting. It never occurred to me to try to change the scope of the system alias 'LAN net'. In fact it never occurred to me that this is an alias that might be changed at all! Although I see that it is an alias I always read it as more of a label, a shortening of 'LAN interface subnet'. Given that it isn't an alias that can be changed I think changing it to "Internal Net" or "Trusted Net" is pretty much the opposite of what might be done, it would only increase confusion. Changing it to read "LAN subnet" doesn't seem unreasonable. Hmm, I wonder how many people have been thrown by this. :-\
Steve
-
I guess what I'm getting at is that the current "LAN Net" built-in alias (if that is the right term) becomes useless in any scenario other than the simple case of one internal subnet.
It does not become useless. It refers to the connected subnet on the LAN interface. You likely want to treat it differently than the non-connected (routed) subnets behind the other router in certain cases.
The first one that comes to mind is the route to the other routed for your other subnets.
Mothership: 10.10.0.0/16
Ultima Thule: 10.20.0.0/16
Timbuktu: 10.30.0.0/16If LAN net is 10.10.0.0/16 you will need routes to 10.20.0.0/16 and 10.30.0.0/16. If all three networks were in one alias, you could not use it to define the necessary route. If you created an alias, say, routed_internal containing 10.20.0.0/16 and 10.30.0.0/16 you could create a gateway to your internal router and create one route entry to routed_internal and you're done. Otherwise you would be creating ANOTHER alias or multiple routes, etc.
I can't see that containing connected and routed networks in the same alias will end well - certainly not automatically.
A better network design would be carving your internal networks out of a specific subnet. Take 10.10.0.0/16, 10.20.0.0/16 and 10.30.0.0.16. If you were to, say, make those 10.32.0.0/16 10.33.0.0/16 and 10.34.0.0/16 you could cover them all with one rule and minimize your collision possibilities with other sites with 10.32.0.0/14 (or /13, or /12 etc.) Assuming you really need to route /16s to the other sites.
-
I guess what I'm getting at is that the current "LAN Net" built-in alias (if that is the right term) becomes useless in any scenario other than the simple case of one internal subnet.
It does not become useless. It refers to the connected subnet on the LAN interface. You likely want to treat it differently than the non-connected (routed) subnets behind the other router in certain cases.
The first one that comes to mind is the route to the other routed for your other subnets.
Mothership: 10.10.0.0/16
Ultima Thule: 10.20.0.0/16
Timbuktu: 10.30.0.0/16If LAN net is 10.10.0.0/16 you will need routes to 10.20.0.0/16 and 10.30.0.0/16. If all three networks were in one alias, you could not use it to define the necessary route. If you created an alias, say, routed_internal containing 10.20.0.0/16 and 10.30.0.0/16 you could create a gateway to your internal router and create one route entry to routed_internal and you're done. Otherwise you would be creating ANOTHER alias or multiple routes, etc.
I can't see that containing connected and routed networks in the same alias will end well - certainly not automatically.
A better network design would be carving your internal networks out of a specific subnet. Take 10.10.0.0/16, 10.20.0.0/16 and 10.30.0.0.16. If you were to, say, make those 10.32.0.0/16 10.33.0.0/16 and 10.34.0.0/16 you could cover them all with one rule and minimize your collision possibilities with other sites with 10.32.0.0/14 (or /13, or /12 etc.) Assuming you really need to route /16s to the other sites.
I'm not talking about routing. I'm talking about rules. Routing is easy enough to cover by either creating explicit routes in pfsense to each subnet, or simply configuring pfsense to use my router as a gateway.
-
Actually with your network you need both rules and routing if you're not going to hack it with your proxy arp "fix.".
With a different subnet structure you could make one rule (Pass rule on LAN, NAT rule, etc) for 10.32.0.0/14.
You are observing that LAN net doesn't fit your specific use case, when LAN net fits the VAST majority of installs and the aliases function is there for the more advanced cases.
-
Actually with your network you need both rules and routing if you're not going to hack it with your proxy arp "fix.".
With a different subnet structure you could make one rule (Pass rule on LAN, NAT rule, etc) for 10.32.0.0/14.
You are observing that LAN net doesn't fit your specific use case, when LAN net fits the VAST majority of installs and the aliases function is there for the more advanced cases.
Yes, I understand about the routing. As I said in my last post, my question was about rules, not routing.
I don't need a different subnet to do everything with one rule - I can do that now by creating my "general user" rules for 10.0.0.0/8 , then creating more specific subnet rules if needed.
While the majority of pfenses installs may indeed have only one intranet subnet, my case is far from unique. I'd imagine there are many people running pfsense hanging off a router with clients on multiple intranet subnets.
Pfsense has suitable defaults for simple networks. And, the interface is clearly designed with great forethought into accommodating more complex networks easily. My observation is simply this: "LAN Net" doesn't scale above the trivial use case of one intranet subnet.
I'm not saying that's wrong, and I understand there is a way to accomplish the same thing with aliases.
But I think you'd have to admit, it would be a nice touch if there were a button on the interface somewhere that says "Add networks to LAN Net".
-
But I think you'd have to admit, it would be a nice touch if there were a button on the interface somewhere that says "Add networks to LAN Net".
Actually, I think it's perfectly acceptable to have LAN net mean the connected LAN subnet.
-
The described scenario is common, there are many scenarios where there are networks behind one or more other routers. The "$interface net" selections aren't for that circumstance, they refer to exactly what they say, the network assigned to that interface.
-
I think you'd have to admit, it would be a nice touch if there were a button on the interface somewhere that says "Add networks to LAN Net".
I'd have to disagree with this but I understand where you're coming from. The issue here, if an issue exists, is simply one of nomenclature. The 'LAN net' alias is the LAN interface subnet and no more and it shouldn't be anything else. It needs to remain only that so that it's available for use.
Now it might be possible to have an autogenerated alias that represented the LAN subnet plus any routed subnets attached to it. I could imagine it being a logical nightmare to code though. ;)Steve