Using DHCP option 121 as aide for inter-VLAN routing on switch
-
I'm redesigning the network and I've been over and over undecided how should I go about routing among subnets, currently it's handled by the firewall but there are devices with 10-gig interfaces exceeding pfSense's single-gig interface. There are no special needs for the subnets other than not to share a broadcast domain. It makes sense to offload the routing to a switch.
Browsing through the forums I found this thread explaining that I should just use a single interface on the firewall and add its IP address to the switch's default route. I, on the other hand, would like to keep things as they are and just remove from each interface's ruleset the one destined to RFC1918, leave the next rule with destination !RFC1918 as is (there are different rules for in/out because it's a multi-WAN setup) and to help inter-VLAN traffic find its way I'd like to use DHCP option 121.
Would this work? I've never tried this option before and I don't know if it's well-known (if any device will honor it). The other option I found was option 33 but from what I understand that's for single host destinations and that does seem to be ignored in modern networks, I'm paraphrasing.
Have you tried this? Do you have any advice? I'm open to anything. :)
Thanks!
-
@umademelosemyusernamepfsense said in Using DHCP option 121 as aide for inter-VLAN routing on switch:
There are no special needs for the subnets other than not to share a broadcast domain.
And how many devices do you have exactly that your worried about broadcast domains but not any other concerns?
If you want to route at your switch, then route at your switch... But trying to do host routing via dhcp options is going to scream asymmetrical problems more than likely.
If you want to use your switch for routing, then do that - connect from your L3 to your edge via a transit network..
-
@johnpoz Thanks for answering!
There wouldn't be any rule that allows traffic with destination for RFC1918 address space. I could even, instead of disabling/deleting the existing rule that allows this, change its action to block/reject. Will I still have asymmetric routing?
If the firewall has direct access to each of the subnets in any random route but is itself not routing traffic between them, that's enough to cause asymmetric routing?
I will do the transit network(s) if this doesn't work out; I'm adding an extra uplink on a second interface on the firewall for the public/guest networks. It seems pretty straightforward. And the devices are just a handful, but that's enough to max out the link every few hours for backups and other everyday tasks.
I guess more than just setting it up I want to learn a little about this.
-
@umademelosemyusernamepfsense said in Using DHCP option 121 as aide for inter-VLAN routing on switch:
And the devices are just a handful,
If you only have a handful of devices and you don't care about firewall rules why and the F are you segmenting them in the first place? Makes zero sense to worry about different broadcast domains when you have a handful of devices... If you had say 1000 of them ok yeah that is a lot of broadcast traffic for single L2.
Any time you don't use a host route and hit your default gateway, ie pfsense to get to one of the other networks your going to run into asymmetrical return traffic. Its a asymmetrical mess waiting to happen... And host routing is very messy!!!
Why would you have transit networks? There should only be 1.. From your downstream L3 to your Edge router.. Why were there be more than 1.. Do you have more than 1 downstream router?
-
Yeah, I know it's messy, but it only takes a single host to max out the link.
Oh, you meant static routes when you said transit network right? I went another way. That makes makes much more sense from what I initially thought, sounds awesome to implement too. I'll get on it right away, get it working and then find some book on this because I'm crazy curious about it.
I was under the impression that by using option 121 I'd be basically assigning a second gateway, not that much different from assigning a list of gateways on a regular DHCP scope except that this gateway would only work for certain networks, so a default gateway minus the default. And, with the firewall out of the equation unless traffic's going 0.0.0.0/0 I didn't think it would matter. Seems easy on paper.
Anyway, that's for helping me out; and sorry for the delay, some things came up. :) But on the bright side while stuck waiting I found this book on Amazon about
networking on FreeBSDTCP/IP networking illustrated, I'll learn at a third-grade level.
Better than being completely clueless I guess. -
Static routes? No that is not what a transit network is..
You have a downstream router.. With networks hanging off of it... The default route for clients is always the downstream routers SVI in their vlan.
The downstream router talks to pfsense via on different network, there are no hosts on this network... Its a transit network from 1 router to another router.. Or it could be the network that connects multiple routers together...
The only default route the downstream router has is pfsense.. In knows how to get to all the other local networks since they are directly attached.
So again lets ask - why do you need more than 1 network? You have a handful of devices? Saturating the link to the internet? Yeah in your current setup where your pfsense is routing traffic between vlans your local traffic could be a problem for internet traffic since they share the same path. But if your devices are all on the same L2.. The only traffic going to pfsense IP would be internet bound traffic - host A talking to B would only be over their switch ports..
And you remove the need for downstream router, etc.
-
@johnpoz said in Using DHCP option 121 as aide for inter-VLAN routing on switch:
am router talks to pfsense via on different network, there are no hosts on this network... Its a transit network from 1 router to another router.. Or it could be the network that connects multiple routers together...
Yup, that's what I thought, it came out wrong sorry. It's similar to the transit network used for OpenVPN, and I got it right away but I was thinking on another thing I was getting on a sentence at the moment and it got out all wrong.
The devices aren't all on the same L2 network, they are in different subnet because they mirror Active Directory Sites, several subnets, are long-distance outdoor wireless links, adding considerations for latency, and keeping the voice network stable and quiet over the are some other reasons why all the hosts aren't on the same broadcast domain. It was kinda chaotic before and several methods were used to make it work, and they did work fine, but none scaled as effortlessly as simply sorting out broadcast domains. And yeah, I do have more than one downstream router, though I hadn't thought of them as "downstream" before, there are a couple more that do routing, one of them is also pfSense-like appliance. It maintains several OpenVPN tunnels, most outgoing traffic is proxied through that. pfSense used to do that but on the 2.4.4 update it broke and was never able to make it work again; I found it just days ago—two weeks tops—it's supposed to be a fork of pfSense, a little Ubuntu-ish looking but handles the tunnels like nobody's business.
Cheers!
-
Sounds like you have some clean up for sure.. Or your going to have all kinds of asymmetrical problems.. The core router is where the routes are decided upon, if you have other routers that go to other networks other than the internet.. Then they could all be on connected to the same transit, or they could have their own transit networks, etc.
How about you draw up this network and we can figure out best way to do it.. But you shouldn't be routing on hosts... Its messy and overly problematic!!! if you have to do routing on your hosts for shit to work - then your doing it wrong ;)
