I’ve been running a RB750GR3 with my internet modem plugged into a physical ethernet port, but I’m considering relocating the RB to the central location in my home that most LAN traffic passes through. That location currently houses a switch. Doing so would mean that the modem and RB won’t be colocated though, and internet traffic will have to travel over a VLAN trunk to the RB alongside LAN traffic (in its own VLAN of course). I’ve successfully mocked up how I think this would work in the RB, but I’m wondering if there’s some reason why I shouldn’t set it up this way and would like to vet it with those of you far more knowledgable than me.
The mock up treats the WAN port as an untagged VLAN access port on the same bridge used for the LAN (i.e., physical port on the bridge, physical port included as untagged on a bridge VLAN, logical VLAN interface on bridge), and the DHCP client is configured on the logical VLAN interface associated with the WAN’s VLAN. Of course, the WAN’s VLAN would have to be tagged on the trunk port if I did the relocation. All NAT, mangle, firewall, and queue rules were updated to refer to the VLAN interface, but no new rules were added. The VLAN interface was assigned the external IP address as expected, and internet access including the queue seems to work just fine. Considering the WAN interface typically wouldn’t be bridged with the LAN, I’m wondering if this config sets me up for trouble. Absent filtering, I can see how it might, but I’m thinking the default routing table coupled with the firewall rules I’ve been using will address that assuming they were/are reasonable. Am I missing something?
VLAN1 replaces the previous ether-port (ether1) as WAN connection.
All ethernet ports are bridged and belong to the LAN functionality.
The untagged ethernet port (ether1) with the VLAN, or the other VLANs belong also to the LAN functionallity
All NAT, mangle and filter rules in the default Firewall configuration and other settings in the default config use “interface list” WAN and LAN to indicate on what interfaces they apply.
Traditionally ether1 is in the WAN interface list, and the other ethernets (actually the LAN bridge) are in the LAN interface list. This is the setup for a typical home gateway.
Changing the ethernet port ether1 to be a port of the bridge will make it part of the LAN . (ports on a bridge make slave interfaces, they follow the bridge settings. For clarity ether1 should be in the LAN interface list)
So I suppose
putting VLAN1 in the WAN interface list. (and VLAN1 can have the DHCP client)
Adding ether1 to the bridge (and eventually also other LAN based VLANs)
Would be all that is needed to convert an ether1 WAN connection, into a VLAN1 WAN connection.
What you described is the gist of it. I created an actual VLAN instead of using VLAN1 partly in case a VLAN interface assigned to VLAN1 would create strange tagging/untagging behavior. So it sounds like there’s nothing inherently “bad” or sketchy about the approach. Said differently, I shouldn’t need additional firewall filter rules above and beyond what I’d normally use to secure the router and LAN? As you pointed out, everything gets routed based on IP address anyway, so the only thing that (automatically) changes in the main routing table is the default route is associated with a gateway on a VLAN interface instead of a physical port (dst 0.0.0.0/0 → gateway x.x.x.x on if_wan_vlan).
This seems fairly straightforward - what am I missing??
As long as you are working with a managed switch, in between, isn’t this as simple as creating one bridge and multiple vlans?
The switch accepts untagged packets from the modem on the port coming from the modem and tags them with vlan 5.
The switch moves vlan 5 tagged traffic to the ethernet cable going to the router.
The switch accepts return traffic on vlan 5 from the router and sends it to the modem (and strips the tags)
The switch accepts tagged traffic coming from the router for vlans 10,15,20 and moves traffic to associated ports (some stripped and maybe some not).
The switch accepts traffic from same ports and sends back to router (adding tags back in where appropriate)
bridgeport
add bridge=bridgewanlan interface=ether1 {Trunk port carrying vlan 5 (WAN), vlan 10 home (wired and wifi), vlan 15 (wifi guests, vlan 20 (smart devices}
bridgevlan
add bridge=bridgewanlan tagged=bridgewanlan,ether1 vlanids=5,10,15,20
Lets say you, on the router, you had ether2 going to a PC and eth3 going to a smart device, Then it would look like.
bridgeport
add bridge=bridgewanlan interface=ether1 ingress-filtering=yes
add bridge=bridgewanlan interface=ether2 pvid=10
add bridge=bridgewanlan interface=ether3 pvid=20
add bridge=bridgewanlan tagged=bridgewanlan,ether1 untagged=ether2 vlan-ids=10
add bridge=bridgewanlan tagged=bridgewanlan,ether1 untagged=ether3 vlan-ids=20
add bridge=bridgewanlan tagged=bridgewanlan,ether1 vlan-ids=5,15
I’d meant to put a diagram together in between pool cleaning sessions but didn’t get around to it. Thanks, that’s pretty much what I was planning on. When I originally set up the 750 I saw various guides and posts that specifically said to not put the WAN on the bridge, so when I figured out that it’s workable for what I want to do, I thought there might be some gotcha I don’t know about.
I am not aware of a such a rule.
What I am pretty sure of is that you cannot have two bridges on the same port…
So my original thought of bridge for wan and bridge for lan would probably not work, although cleaner.
So I went back to one bridge with many vlans.
What I am not clear on is who initiates traffic when first talking with the modem.
If its the modem no problem as the switch will add the tag to the modem traffic before it sends it to the router.
If its the router, then I am not sure if the router tags the initial traffic on the vlan outgoing with the vlan tags.
We state ether1 is a trunk port and thus its not likely to add or remove tags…
Tagging shouldn’t be an issue with logical VLAN interfaces. I took a few minutes and did a rough example diagram and parts of a script to match the diagram. It sounds like I don’t need to worry about doing anything special once it’s up and running.
Your idea is a completely valid. Only a remark about your setup code: consider adding settings frame-types=admit-only-vlan-tagged ingress-filtering=yes to /interface bridge port, these should add security.
Thanks all for confirming. I’ve been running the test config for a day (ether1 on bridge, untagged on modem specific VLAN), and it indeed seems to be working without issues.
Excellent point. I actually have ingress filtering going on all ethernet trunk ports and the bridge right now but hadn’t added it into that code. I’ll make sure to change that when I put the full script together.