How to include multiple subnets in "LAN net"?
-
How would one install or configure pfsense if you have multiple subnets connected to a router, and that router connects to pfsense?
For example, if you have the following subnets connected to a router:
10.10.0.0/16
10.20.0.0/16
10.30.0.0/16
10.100.0.0/22pfsense LAN interface is connected on subnet 10.100.0.0/22
The router has ip address 10.100.0.1 on the interface pfsense is connected to, and pfsense has the ip address 10.100.0.2
Everything on the subnets have the router as their default gateway, the router has pfsense as its default gateway.
I can get pfsense communicating with the whole network by manually creating a route in the command line, or I can create a gateway of 10.100.0.1
What I can't figure out how to do is get the pseudo-interface "LAN network" to include all of my subnets (10.10.0.0, 10.20.0.0, etc). What am I missing?
-
Why on Earth would you do that? Why the multiple /16s on one interface?Nevermind.
Umm. I just answered this somewhere else…
https://forum.pfsense.org/index.php?topic=83402.msg456853#msg456853
See if that's not enough info.
-
You don't need a pseudo interface.
What you need to do is edit your firewall rules on LAN to pass traffic not just from LAN net but from the other networks as well.
If you want to NAT them you need to set manual outbound NAT and duplicate the rules for LAN for the other networks.
-
I was hoping there was a way to consider all my internal subnets "LAN net" so that I didn't have to create umpteen versions (one for each subnet) of each rule for every rule I want.
-
You can create an alias to include all the subnets.
Steve
-
Thanks Steve.
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
-
-
No kidding. Wow… bad, bad, BAD idea.
It'd be faster, easier, and not require absurdly bad hacks to just use an alias instead of "LAN net".
-
Ha. At least you recognise that as an ugly hack. ;)
It's the sort of thing that can come back to bite you in the future though.Steve
-
It's the sort of thing that can come back to bite you in the future though.
If it's anything like the circumstances I end up getting into with support customers cleaning up disasters like this, it probably won't bite him. It'll bite his unfortunate successor after he moves on elsewhere in a few months or a year, and we'll probably get a frantic new support/professional services customer and have to clean up the mess when it explodes.
That's true dating back into my career years before this project existed, back when I did general network consulting. Cleaning up patched together messes that sort of worked…until they didn't.
-
So you are planning to have around 200,000 clients behind your pfSense box ? (this based on your subnets)
What kind of hardware are you using for this ? I'm just curious what would be required for that.
How much bandwidth will you be pushing ? -
I don't have that many class B subnets because of the number of clients. I have it because of my routing design.
The company I work for has a datacenter, and several remote locations connected by MPLS and/or Internet VPN. To keep routing simple, each site has a 10.X.0.0/16 subnet assigned to it. For example:
Mothership: 10.10.0.0/16
Ultima Thule: 10.20.0.0/16
Timbuktu: 10.30.0.0/16And so on.
At each location, their /16 subnet is subnetted into /22 networks for local use. For example:
10.10.0.0/22: network equipment
10.10.4.0/22: wireless access points
10.10.8.0/22: Servers, workstations, and printers
10.10.12.0/22: Wireless SSID #1
10.10.16.0/22 Wireless SSID #2Because of company policy, all remote locations' Internet access must come back through the mothership for filtering, which is where I would put pfsense.
-
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."
-
Why would you use a /22 on transit network?? wouldn't something like a /30 be better? If you used a segment outside the 10 range, you could just create 1 route 10/8 to your downstream router. And then your lan rules could be something as simple as 10/8 as source as well.
Does pfsense have other other connections that lead to other 10.x networks?
So for example pfsense has 192.168.1.1/30 - your other router is 192.168.1.2/30, all its other networks are in the 10.whatever networks. Your pfsense lan source allows 10/8 and you create an outbound nat that source is 10/8 as well. You have 1 route on pfsense that says hey your going to 10/8 go to 192.168.1.2
-
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
