I`m trying to make CRS326 process VLANs on chip not CPU.
I`ve created VLAN10 for office and user is connected to ether15
VLAN interface has IP 192.168.10.1/24. DHCP server configured, but computer doesnt get address. If I assign static address to PC, it cant ping 192.168.10.1.
Id like to start from short sample config. On this page Im looking at section “3.3.1 Port Based VLAN”.
Reading there “The configuration for CRS3xx switches is described in the Bridge VLAN FIltering section.”
And there I can see this config:
Ah, right, I forgot that CRS3xx is the only Routerboard series which has bridge-VLAN setup actually HW-offloaded (read: fully executed by switch chip).
The rest of the rooster either needs different setup (devices that do have switch chips) or it has to be done by CPU because switch chip desn’t exist (CCR series).
So actually your setup is conceptually right, just fix the errors.
One thing that is moot and often confuses innocent newcomers: every bridge has twin personnalities:
“something like a switch” where it (intelligently) forwards traffic between member ports
“L2 interface” (or port), allowing router to interact with network. Automatically member of personnality #1
When configuring IP address (and services, such as DHCP server), the personnality #2 is used. And if there are VLANs in play, the “port personnality” has to be set up among other ports, members of “switch personnality”. Thus setting bridge as tagged member of self.
Probably official Wiki documents behaviour of CRS as a switch. You only need these when used as router and for management.
Router by default will route between all of its interfaces with IP address assigned. If you don’t want it, you have to block it. My approach is to use firewall for that.
Firewall rules would be something like these … order is important, but you can have some more rules in between … just make sure they don’t get in the way. Some of those rules you might already have as they come from default setup.
/interface list
add comment="guests" name=guest
add comment="sysadmin interfaces" name=sysadmin
/interface list member
add interface=vlan-guests list=guest # enter corect VLAN interface here
add interface=vlan-sysadmin list=sysadmin # enter correct VLAN interface here
/ip firewall filter
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=accept chain=forward comment="allow connections from guest to WAN" in-interface-list=guest out-interface-list=WAN
add action=drop chain=forward comment="drop connections from guest to anywhere else" in-interface-list=guest
add action=drop chain=forward comment="drop connections towards guest subnet" out-interface-list=guest
add action=drop chain=forward comment="drop any connection targeting sysadmin subnet" out-interface-list=sysadmin
The rules above fulfill your wishes #1 and #2:
guest VLAN is isolated by first two drop rules … one rule per connection direction. Note that guests are allowed to access internet by preceding rule.
in the config example above last filter rule serves this purpose, but the logic is reverse: because so far all inter-vlan connections are allowed (except for guest VLAN, see point #1), it is enough to drop connections from other directions towards sysadmin. This also includes connections from WAN (so DST-NAT connections can not be terminated in sysadmin subnet).
Point #3 needs some debate: do you want to generally permit inter-vlan communication or not? If yes, then it’s already enabled and you might want to drop some connections you don’t want to happen. If not, then you’d either construct another interface list with all VLAN interfaces as members … and a filter rule add action=drop chain=forward comment=“drop any inter-vlan communication” in-interface-list=all-vlan out-interface-list=all-vlan (note that this filter does not apply to switched traffic between bridge ports members of same vlan, only to router traffic). Preceeded by rule which allows some particular connections, e.g. add action=accpet chain=forward comment=“allow http from LAN towards server” protocol=tcp port=80 in-interface=vlan10 out-interface=vlan70 …
And don’t forget to protect your router from evil VLANs (use chain=input for that).
I know, @anav. That’s why wish #3 is so much debatable. I didn’t want to post full firewall setup, just shown minimum rules that fulfill OP’s requirements.
Thank you, @mkx! You were very kind to explain this topic in detail. I appreciate it very much.
It took some time to test this configuration and I`m very glad to see it workes well!
Sorry to say, I didnt get. Can you illustrate this point or give some link? If you mean to drop traffic of alien vlans then I couldnt find argument PVID in firewall rule.
Firewall knows nothing of VLANs, it only knows interfaces and IP addresses. And it doesn’t know about physical interfaces but rather last interface before packet landed in firewall (e.g. when a tagged packet enters through ether3, which delivers it to bridge and bridge pushes it to vlan interface, firewall will know about vlan interface and nothing more).
So when rejecting connections from evil VLAN to router itself, you’d use something like one of following rules:
Typically the only one that needs access to the router (input chain) is the admin, but in case your setup is such that DNS from the subnets to the router is what occurs, then allowing those on the LAN access to the router input chaing for only port 53 (UDP&TCP) is normal.