Inter-VLAN routing has (almost?) nothing to do with L2 HW offload.
While tagging/untagging of a frame doesn’t seem such a complex task, it seems that SoHo (at least) Routerboards struggle a bit compared to similar task without dealing with VLAN tags. And don’t forget, inter-VLAN routing also involves firewall if it’s not entirely disabled.
It’s up to your taste … you can run DNS service on MT and allow remote access (and limit access to it via firewall rules by allowing only access from clients from select VLANs) and serve “native VLAN IP address” of router in each of DHCP servers … or you can simply instruct DHCP clients to use “upstream” DNS server … the second option is, from client’s perspective, exactly the same as setting DNS server in DHCP leases to 1.1.1.1 or 8.8.8.8.
But there is: it’s vlan 10 interface:
/interface vlan
add interface=bridge name=vlan-10 vlan-id=10
(or whatever exact definition of it). It’s the interface through which router communicates with “outside world” … and to me, that’s definition of “WAN interface”.
You should not be distracted by the fact that that interface is not physical interface. E.g. if you get your internet via FO and ISP uses all-tagged … then using SFP interface directly (i.e. tagless) won’t allow your router to speak to anybody. Because device on the other end of the wire (or glass strand) will ignore all tagless frames.
Because one can not be entirely sure that’s entirely true (ISP techs are nasty bastards, right?), it’s safer to declare physical interface as WAN interface as well (so that firewall automatically drops all unsolicited traffic also from that direction). Another similar case is when you get your internet via PPPoE (via modem operating in bridge mode): your WAN interface is ppoe-out1 interface, physical interface will only allow you to connect to modem itself (usable sometimes) so it’s not really WAN interface. But it’s still recommended to treat it like one, you don’t want some unsolicited connections coming in from that device.
I’m not sure (= I really don’t know), but I have hEX S as main router at home, and it’s a long time since I tested it, but even routing involving interfaces with bridge VLAN filtering was somehow slower than expected, when compared to regular ethernet with no bridge and no VLANs. I admit that I may be completely mistaken. I plan to test if v7 changes anything, but so far it’s not stable enough for me (I have IPv6 with 6to4 and it kills v7 instantly).
Okay mkx, smarty pants.
My point is not about wan lan definitions its about usage.
Note: and still use the MT as dhcp for the other vlans, with the other vlans on the bridge etc…
My point as well. In OP’s case VLAN 10 is expressly used to pass WAN IP services from one untagged (physical WAN) to another untagged (IPTV STB) port.(Because we’re running many more VLANs over same bridge, we use pvid setting on appropriate ports so that traffic becomes tagged over bridge.) I
f RB itself didn’t need internet access, it would be simple bridge business with bridge interface not being member of that VLAN. As RB itself does need access to that VLAN (because it’s way to internet for RB and other VLANs), we configure bridge interface as tagged member of VLAN 10, then we create vlan-10 interface and use it as WAN interface … whatever that means. E.g. we run DHCP client off that interface to get WAN IP for RB or we set WAN IP statically if ISP allows … as opposed to LAN interfaces where we run (appropriately configured) DHCP servers. Etc.
I’m writing this often, but I’ll do it again: port classification (WAN vs LAN) is not done according to label on the case, it’s not done according to colour of cable attached, it’s the functionality. On a true router-on-a-stick (which has single trunk interface connected to managed VLAN-enabled switch) one can not say that that interface is either LAN or WAN … it’s the vlan interfaces that can be classified according to the functionality (WAN, LAN, DMZ, …).
Yeah I need to go back to the diagram ( please kick me if I ever try to do something so convoluted as not having the MT router run everything…)
The first thing I would do is throw the main router in the garbage and run everything from the MT and I needed a smart switch where the MT is located now, so be it.
That being said, what I forgot was the need for the main router to provide dhcp services for the clients behind the MT router on vlan10, on the three MT APs.
Proposal TrY #1 NO WAN, just switch and internal dhcp functionality.
Bridge1
vlan 10,20,30 with interface of Bridge1
Ip address/dhcp server/IP pool/dhcp-server-network for vlans20,30 ( dns-server=192.168.0.4 ip dns, allow remote, dns servers=1.1.1.2,9.9.9.9)
Interface list - LAN/MANAGE (not that I need a LAN actually)
LAN=vlan10
LAN=vlan20
LAN=vlan30
MANAGE=VLAN10
IP route
dst-address=0.0.0.0/0 gwy=192.168.10.4
Bridge port
Bridge1 port1 - access port pvid=10
Bridge1 port 2 - trunk port to AP
Bridge1 port3 - trunk port to AP
Bridge1 port4 - trunk port to AP
each AP gets an IP address on vlan10 from the main router.
Bridge vlans
Bridge1 tagged=Bridge1,ether2,ether3,ether4 vlan-ids=20,30
Bridge1 tagged=Bridge1,ether2,ether3,ether4 untagged=ether1 vlan-ids=10
neighbour discovery=MANAGE
winmacserver = MANAGE
What is missing or wrong ???
Maybe i need to explain why i use the ASUS. For me it is solid working SoHo out off the box routers.
-ASUS patch broken things fast, and release security patch too.
-There are a 4G fail-over, and it work.
-There are AiProtection by Trend Micro https://www.asus.com/Content/AiProtection. It work out of the box.
I have used pi-hole on a Raspberry pi, and some filter dns servers. Now i just use the ASUS.
There will always be better solution, but i like this one.
Therefore i don’t replace it. I just add more stuff, in this case it is the MT router and some AP.
I’ll make an exception and will write configuration for MT router (because this thread is getting stale): L2 and basic L3 configuration (with some in-line comments) … hopefully it’ll make life for everybody involved a bit easier.
# L2 configuration first
# bridge acts as a smart/managed switch
/interface bridge
add name=bridge vlan-filtering=yes
/interface bridge port
# ether1 and ether5 are access ports to main LAN (vlan 10), one is used to connect to ASUS
# ether2, ether3 and ether4 are trunk ports, carrying vlans 10, 20 and 30 and used to connect APs
add bridge=bridge interface=ether1 pvid=10 frame-types=allow-only-untagged-and-priority-tagged ingress-filtering=yes
add bridge=bridge interface=ether2 frame-types=admit-only-vlan-tagged ingress-filtering=yes
add bridge=bridge interface=ether3 frame-types=admit-only-vlan-tagged ingress-filtering=yes
add bridge=bridge interface=ether4 frame-types=admit-only-vlan-tagged ingress-filtering=yes
add bridge=bridge interface=ether5 pvid=10 frame-types=allow-only-untagged-and-priority-tagged ingress-filtering=yes
# no need to include ether1 and ether5 as untagged members of vlan 10, that's done automatically because of pvid setting above
/interface bridge vlan
add bridge=bridge tagged=bridge,ether2,ether3,ether4 vlan-ids=10
add bridge=bridge tagged=bridge,ether2,ether3,ether4 vlan-ids=20
add bridge=bridge tagged=bridge,ether2,ether3,ether4 vlan-ids=40
# now L3 setup
# router's access to vlan 10 ... as WAN port
# router's access to vlan 20 and vlan 30 as gateway for those subnets
/interface vlan
add interface=bridge name=vlan-10 vlan-id=10
add interface=bridge name=vlan-20 vlan-id=20
add interface=bridge name=vlan-30 vlan-id=30
/ip address
add interface=vlan-10 address=192.168.10.4/24
add interface=vlan-20 address=192.168.20.1/24
add interface=vlan-30 address=192.168.30.1/24
/ip route
# default route ... needed for clienrs in vlans 20 and 30 to reach internet
# needed by thus router as well (SW upgrades, anything else outside of vlans 10, 20 and 30)
add dst-address=0.0.0.0/0 gateway=192.168.10.1
# DHCP server settings for vlans 20 and 30
/ip pool
add name=pool-20 ranges=192.168.20.10-192.168.20.254
add name=pool-30 ranges=192.168.30.10-192.168.30.254
/ip dhcp-server network
# use ASUS as DNS server for all VLANs
add address=192.168.20.0/24 dns-server=192.168.10.1 gateway=192.168.20.1 netmask=24
add address=192.168.30.0/24 dns-server=192.168.10.1 gateway=192.168.30.1 netmask=24
/ip dhcp-server
add address-pool=pool-20 disabled=no interface=vlan-20 lease-time=6h name=dhcp-20
add address-pool=pool-30 disabled=no interface=vlan-30 lease-time=6h name=dhcp-30
# do you need NAT for vlans 20 and 30? If you add routes towards 192.168.20.0/24
# and 192.168.30.0/24 on ASUS with gateway address 192.168.10.4, then ASUS can do
# NAT and you don't need to do it here.
# If you don't perform NAT here and decide to allow traffic from restricted vlans towards
# main LAN, then you might get into problems of routing triangle which may upset firewall on ASUS
# interface list is to make NAT rule only one. Can be used in firewall filter rules if you want to
# control traffic to and from vlans 20 and 30
/interface list
add name=restricted-vlans
/interface list member
add list=restricted-vlans interface=vlan-20
add list=restricted-vlans interface=vlan-30
/ip firewall nat
add chain=srcnat action=masquerade out-interface=vlan-10 in-interface-list=restricted-vlans
# example of firewall filter rules
/ip firewall filter
# block access to this router from restricted vlans
# but first allow access to DHCP server (could be this is not strictly necessary but won't hurt)
# and optionally to any other services this router might offer to clients in restricted vlans
# (place accept rules before next drop rule)
add chain=input action=accept protocol=udp dst-port=67 src-port=68 in-interface-list=restricted-vlans
add chain=input action=drop in-interface-list=restricted-vlans
# block access to devices in main LAN from restricted vlans
# but do allow access to main router, it may offer some services, such as DNS
add chain=forward action=accept dst-address=192.168.10.1 in-interface-list=restricted-vlans
add chain=forward action=drop dst-address=192.168.10.0/24 in-interface-list=restricted-vlans
# block traffic between devices in different restricted vlans
add chain=forward action=drop in-interface-list=restricted-vlans out-interface-list=restricted-vlans
Yes, I was beginning to wonder if you ever have done any configs…
I will try to follow the logic…
(1) Not sure where you got
a. ether5 OR
b. that it was an access port.
The only evidence I can find above that is a trunk port with unknown purpose.
In any case lets say it was an access port to play along!!
(2) Bridge ports, look good!
(3) Bridge Vlans, hmm dont like the autogenerate method but its viable.
For some nagging reason I think you still need a rule to note that the bridge is tagged for this…
Ahh I see vlan10 is tagged in the first line by the bridge so that is covered…
/interface bridge vlan
add bridge=bridge tagged=bridge,ether2,ether3,ether4 vlan-ids=10
add bridge=bridge tagged=bridge,ether2,ether3,ether4 vlan-ids=20
add bridge=bridge tagged=bridge,ether2,ether3,ether4 vlan-ids=40
What I am saying, for example if vlan 10 was not tagged on ether2,3,4, then we would need a rule as such
add bridge=bridge tagged=bridge vlan-ids=10
Its here where manually inserting the untag makes sense or at least to make it clear why.
(4) /ip firewall nat
add chain=srcnat action=masquerade out-interface=vlan-10 in-interface-list=restricted-vlans
So this rule is designed to allow vlan20 and vlan30 traffic to reach the client computers on the vlan10 network if that the desire of the OP??
It will not allow traffic originating on vlan10 from reaching vlans20, 30 though? right?
(5) then with firewall rules you block such traffic so was a bit confusing for me… ???
add chain=forward action=drop dst-address=192.168.10.0/24 in-interface-list=restricted-vlans
(6) The rest of the rules are sweet, I gather port 68 is the source port and 67 is the destination port for traffic originating from dhcp clients on vlan10 behind the MT??
(7) Overall one of us a bit confused in the forward chain. The input chain was clear with a drop all rule at the end, why not carry through with the forward chain as well.
It could be?
add chain=forward action=accept dst-address=192.168.10.1 in-interface-list=restricted-vlans
add chain=forward action=drop
..
I invented this part. OP mentions 3 AP s, hence 3 trunk ports. OP also mentions one untagged connection towards main LAN, hence one access port. hEX has got 5 ports and I hate to waste hardware, so I thought OP could use another main LAN port.
If OP doesn’t do anything on ASUS, then ASUS doesn’t know anything about the two extra IP subnets … if devices in those two subnets require access to internet, that wouldn’t work unless RB does src-nat for those clients. Allowing traffic between these two vlans and the rest of main LAN is side effect and if it is not desired, it has to be blocked using firewall rules. If ASUS gets those two static routes, then the whole NAT stuff is not necessary any more.
You’re right, connections originating from vlan10 and targeting other two vlans are not affected by this src-nat rule.
Yup. Here’s an article on DHCP for your good-night reading.
Since this router is not on perimeter of OP’s network (not yet 
), I think this router doesn’t need a very strict firewall. It’s job is to protect itself and to protect main LAN (as far as it can). The rest is then up to ASUS. Or, depending on ASUS configuration, even up to config on this router. And, your suggestion would block clients of those two vlans from reaching internet … because dst-address of those packets is not ASUS’ address, it’s everything else…
But, as I wrote: this is only basic L3 config, I’m leaving the rest to OP’s immagination. And your suggestions …
BTW, I see you missed a typo in this line:
add bridge=bridge tagged=bridge,ether2,ether3,ether4 vlan-ids=40
Right, I missed the blocking of lan to wan traffic,so
thats easy…
add chain=forward action=accept dst-address=0.0.0.0/0 in-interface-list=restricted-vlans out-interface=vlan10
add chain=forward action=drop
Need to ask this:
I have no firewall accept to allow DHCP, and when using log tools “Torch” at the VLAN i see this, (look picture). But nothing in the fw?
Computer get nice ip. DHCP is part of the firewall input chain, right? or is it Layer2, if so how to handle that in the fw?
Firewall acts as if it had implicit last rule in each chain to accept the packet. So if you don’t have any explicit rule that would drop certain packets, they are allowed.
Now, as to DHCP packets: it seems that ROS implements DHCP server in a way that sits below normal IP stack and grabs its share of packets before IP firewall can do anything about it (I’ve seen the same behaviour with an older implementation of ISC DHCP server on linux as well). That’s why I wrote (in config example commentary) that DHCP allow rules might not be necessary.
mkx is that the same reason why two vlans cannot see each other but on MT setups can ping each others gateway? There was a rule to block that and now forget it, but really not needed I dont think…thoughts.
No. The reason for that is different: one of initial tasks router does on ingress packet is to determine if packet is targeting one of router’s own addresses. If it is, then it’s dealt with in chain=input (unless it’s subject to dst-nat, but let’s forget about this possibility for now). Obviously in-interface is not relevant for this decission. The block-vlan-to-vlan rules are part of chain=forward and hence don’t affect the packets we’re talking about. So if one really wants to block traffic targeting “non-native” router’s address, one has to construct appropriate rules in chain=input … e.g.:
# let's assume vlan-10 interface has address 192.168.10.1/24
# let's assume vlan-20 interface has address 192.168.20.1/24
/ip firewall filter
add chain=input action=drop dst-address=192.168.20.1 in-interface=vlan-10
Of course there are many ways to skin the cat … so use whatever way fitting the rest of firewall rules …
As you put it: this is purely cosmetic thing. One doesn’t gain any security by blocking access to “non-native” router addresses, it’s enough to have access to any of router’s addresses to hack it (if the rest of FW rules are not secure).