I understand that by default VLANs are not isolated from each other. Hence I created a traffic rule to block access to VLAN "lan" (subnet 192.168.1.x) from VLAN "ILAN" (subnet 192.168.10.x).
But after applying this rule, I still have access to 192.168.1.x
What am I doing wrong?
try adding 192.168.10.0/24 and 192.168.1.0/24 respectively.
Used these settings, but result is still the same:
VLAN is L2 data tagging, so VLAN are isolated already in hardware data management. L3 settings won’t change that.
Yes there are theoretical ways to attack VLAN systems by VLAN jumping.
But the firewall and interface settings you are doing something in right now is logical L3 routing, so do you have a data leak between different VLAN on L3 routing then you have mixed up the L2 switch settings.
Please copy the output of the following commands and post it here using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have:
cat /etc/config/network
cat /etc/config/firewall
Yes they are, as long as:
Isolation is actually the reason why the concept of VLANs was created.
VLAN at L2 doesn’t have anything to do with firewall zones at L3.
The VLAN’s work just fine totally isolated from each other with unmanaged interfaces on L3 level and with firewall not even installed in OpenWRT.
But you can make firewall rules that allow more or less specific data transmission from one VLAN to another VLAN.
But as I tried to say earlier. That doesn’t happen randomly by itself. Someone have to do that firewall rule or the switching setup on L2 is screwed up if the VLAN’s talk to eachother, which is usually the case after the introduction of DSA in OpenWRT.
BusyBox v1.33.2 (2022-02-16 20:29:10 UTC) built-in shell (ash)
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt 21.02.2, r16495-bf0c965af0
-----------------------------------------------------
xxxxxx@OpenWrt:~# cat /etc/config/network
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fdf7:6110:a14a::/48'
config device
option name 'br-lan'
option type 'bridge'
list ports 'eth0.1'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
config device
option name 'eth0.2'
option macaddr 'xx:xx:xx:xx:xx:xx'
config interface 'wan'
option device 'eth0.2'
option proto 'dhcp'
config interface 'wan6'
option device 'eth0.2'
option proto 'dhcpv6'
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '1'
option vid '1'
option ports '0t 2 4 5'
config switch_vlan
option device 'switch0'
option vlan '2'
option ports '0t 1'
option vid '2'
config device
option type '8021q'
option ifname 'eth0'
option vid '10'
option name 'eth0.10'
option ipv6 '0'
config interface 'ILAN'
option proto 'static'
option device 'eth0.10'
option ipaddr '192.168.10.1'
option netmask '255.255.255.0'
option type 'bridge'
config switch_vlan
option device 'switch0'
option vlan '3'
option ports '0t 3'
option vid '10'
xxxxxx@OpenWrt:~# cat /etc/config/firewall
config defaults
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'
option synflood_protect '1'
config zone
option name 'lan'
list network 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
config zone
option name 'wan'
list network 'wan'
list network 'wan6'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
config forwarding
option src 'lan'
option dest 'wan'
config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
config rule
option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-DHCPv6'
option src 'wan'
option proto 'udp'
option src_ip 'fc00::/6'
option dest_ip 'fc00::/6'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-MLD'
option src 'wan'
option proto 'icmp'
option src_ip 'fe80::/10'
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Input'
option src 'wan'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
list icmp_type 'router-solicitation'
list icmp_type 'neighbour-solicitation'
list icmp_type 'router-advertisement'
list icmp_type 'neighbour-advertisement'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Forward'
option src 'wan'
option dest '*'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-IPSec-ESP'
option src 'wan'
option dest 'lan'
option proto 'esp'
option target 'ACCEPT'
config rule
option name 'Allow-ISAKMP'
option src 'wan'
option dest 'lan'
option dest_port '500'
option proto 'udp'
option target 'ACCEPT'
config rule
option name 'Support-UDP-Traceroute'
option src 'wan'
option dest_port '33434:33689'
option proto 'udp'
option family 'ipv4'
option target 'REJECT'
option enabled '0'
config include
option path '/etc/firewall.user'
config zone
option input 'ACCEPT'
option output 'ACCEPT'
list network 'ILAN'
option forward 'ACCEPT'
option name 'ILAN'
config forwarding
option dest 'wan'
option src 'ILAN'
config rule
option name 'Isolate VLANs'
list src_ip '192.168.10.0/24'
list dest_ip '192.168.1.0/24'
option target 'REJECT'
list proto 'all'
option src 'ILAN'
option dest 'lan'
Hi flygarn12
I have a TP-Link Archer A7 (ath79), and as such DSA is currently not supported yet for this device.
This makes configuring the device sometimes extra confusing (for me as tech savvy, but still with basic network admin skills) since I have to combine old documentation (v19) with new ones (v21).
That is pretty much my experience also on the EAP245 and Ath79. On those devices you need to specify the hardware connectors setup in the old swconfig as “some kind of pre filter” between OpenWRT DSA and the real world. But once that is done you don’t need to care about swconfig, after that you only touch the DSA settings in OpenWRT unless you add VLAN in your network or change the usage of the connectors.
But OpenWRT internals is still DSA on all models from 21.02 and later so you need to specify the DSA settings to get the internals of OpenWRT from 21.02 and later to work.
It is probably easier to understand the dataflow if you take a look in the default network config file of your device, instead of working in luci. Then you see that swconfig first takes care of the data in and out of the port, tags it and put it in a vlan and send it onwards. Then the DSA device takes over and then if you use that function the dsa vlan filter takes over and then the interfaces at L3 level do their thing with the data.
Unfortunately it has been from my point of view some kind of black and white official message from OpenWRT in this question that you either have or do not have DSA. Well that has not been my experience, all have DSA (maybe not the hardware but the setup is there). But some still have swconfig on top of DSA.
Interesting pointers, flygarn12. If you have references I can read further on, that would be great.
If I understand correctly, VLANs should already be defined in swconfig. After looking into swconfig and noticing that the PORT/VLAN mapping is also there, I imagine that I should also map all ports that are involved in any new VLAN I want to define. But I am wondering if overlaps are allowed?
E.g. would this work:
VLAN 1:
vid: 1
ports: 0t 2 3
VLAN 2:
vid: 2
ports: 0t 1
VLAN 99:
vid: 99
ports: 0t 3 4 5
And then, once I have all my VLAN definitions, I can just use them in LuCI/DSA and apply (L3) firewall rules. And that's where your last post fits into your earlier one?
This rule isn’t actually necessary. Doesn’t hurt, but doesn’t need to be there.
How are you testing your vlan isolation, specifically?
No!
You can’t have two untagged vlan on the same port. That means vlan 99 and vlan 1 is connected to each other at port 3, or the isolation you talk about is really a short circuit in this case.
Usually in Luci VLAN 1 and 99 will be painted red if you config it like this.
Have no reference I guess, the reference is reading the default network config file, logic thinking and simple experience.
But both the DSA and “old” switch instructions in the user guide still applies for these devices.
I am able to access LuCI on 192.168.1.1 from 192.168.10.0/24
I don't want clients from one network to be able to access clients on the other
Don’t think that is a isolation problem. That is a feature since uhttpd listen to everything and every firewall zone that has input=accept is allowed to access luci.
To fix this you need all firewall zones to have input=drop/reject and to open specific input rules for port 22 (dropbear/ssl), 80 (http) and 443 (https) for the zones you like to give luci access. Also remember to open the DHCP server ports on all zones that use dhcp server!
And to make it a little nicer looking you can change the listening settings in uhttpd to only allow the routers actual IP number.
And change the dropbear setting to which interface to listening to.
As @flygarn12 stated, when you test by accessing the router (even by its address in another subnet), it is actually subject to the input rule. That is why I asked.
Try connecting from one host in one network to another host in a different network and you should see that the neetworks are in fact isolated.
The listening settings for uhttpd and dropbear will not actually secure the router itself - the input rule is the way to do this.
Not all the zones need to have the input rule set to reject/drop, but usually any untrusted zones will be setup that way. The trusted zone(s) can maintain input=accept. And you will create traffic rules to accept connections on ports udp 67-68 for dhcp and tcp +udp 53 for dns for the other networks.