VLAN communication issue

Installing and Using OpenWrt
1

I’m having an issue with VLANs being able to ping other VLANs on v25. I have what I think is the same setup on v19 and no device on any VLAN can ping any other VLAN (as I want). My use case is very simple: I have three hard-wired computers and I want them to not be able to in any way see or communicate with the others. One port (port1) will be used for Luci access only, and will be unplugged when not working in Luci.

Here’s how I have this set up. I followed all the DSA documentation here, and also the video by onemarcfifty mentioned in the docs, as well as the two videos and web article from opensourceisawesome. They both basically follow the same procedure but the latter goes slow enough for me to better follow when he does the steps.

I have a Cudy WR3000S, bought on recommendations from people here. All four lan ports were bridged on br-lan by default. I set up four VLANs using the VLAN filtering tab, calling them 10, 20, 30, and 40. I set one (different) port as untagged for each VLAN i.e. port1 is u for 10, port2 is u for 20, etc. I created interfaces for the VLANs and set them up for DHCP.

I created firewall zones for the four VLANs. Here is how I set them up. All of this is exactly what I did in v19 (I understand this uses DSA and so on, I meant the configuration details).

VLAN10 192.168.10.1 lan ==> wan (reject all others) accept accept reject
VLAN20 192.168.20.1 comp1 ==> wan (reject all others) reject accept reject
VLAN30 192.168.30.1 comp2 ==> wan (reject all others) reject accept reject
VLAN40 192.168.40.1 comp3 ==> wan (reject all others) reject accept reject
Wan ==> reject accept drop (drop was default and not reject)

My understanding, and this may not be correct, is that the zone forwards are used to stop traffic between VLANs and Intra zone forwarding is to stop traffic between devices in the same VLAN. Although I don’t have more than one device in a given VLAN I still wanted it set so nothing in a VLAN could talk to another device in the same VLAN, in case say I put a wireless device in that same VLAN in the future. I would group that so they are ‘related’ uses i.e. both work devices, but no need to communicate with each other.

The problem here is when I ping another IP on v19 all pings fail (as I want) from any device pinging any IP address in another VLAN. Now, with this new v25 setup, any device can ping any IP in any VLAN. That’s exactly what I am trying to stop. I did test and confirm that only the lan port (port 1) can access Luci, so that part is working.

Did I configure something incorrectly? This will show my ignorance here, but I at first thought because all the ports are bridged together that’s why this is happening. But opensourceisawesome showed in his article, after he set up his firewall rules, that he could only ping that which he allowed, and couldn’t ping that which he didn’t allow. His bridge looks similar to mine. So, that couldn’t be the reason.

I figure some rules could be written somewhere to stop this, but why is that not needed for my v19 setup, or for the setup (which I just about cloned, at least for the parts I needed) done by opensourceisawesome? Any help here would be greatly appreciated, since I am completely stuck at this point, just when I thought I was done.

2

There have been massive changes since OpenWrt 19.07. If the config was migrated directly from 19.07, it's probably not valid anymore. Especially if you moved this config from a previous device.

Let's take a look at your configuration.

Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button (red circle; this works best in the 'Markdown' composer view in the blue oval):

Screenshot 2025-10-20 at 8.14.14 PM

Remember to redact passwords, VPN keys, MAC addresses and any public IP addresses you may have:

ubus call system board
cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall
1 Like
3

I did this using a new router and following the instructions on the page for that model. It's the second Cudy I've done so I was familiar with the interim firmware step from Cudy. I built the configuration from scratch. My reference to the v19 was that I set it up the basically the same way but am getting different ping results.

I have since filled out some potential wifi so I can test them at some point, but nothing is/has been enabled. This router has not been hooked up to the Internet yet at all. Also, when I wrote DHCP and DNS firewall rules I combined them (DHCP and DNS) into one rule each time. Normally I do them separately (one rule for DNS and one for DHCP), but saw it done this way so I thought I'd try it. Just in case you wonder what the heck that is...

Here is the requested information. I hope I didn’t mess anything up with my redactions, or trying to use the </> tags.

`system board

{
	"kernel": "6.12.71",
	"hostname": "Cudy",
	"system": "ARMv8 Processor rev 4",
	"model": "Cudy WR3000S v1",
	"board_name": "cudy,wr3000s-v1",
	"rootfs_type": "squashfs",
	"release": {
		"distribution": "OpenWrt",
		"version": "25.12.0",
		"firmware_url": "https://downloads.openwrt.org/",
		"revision": "r32713-f919e7899d",
		"target": "mediatek/filogic",
		"description": "OpenWrt 25.12.0 r32713-f919e7899d",
		"builddate": "1772496855"
	}
}


network

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	list ipaddr '127.0.0.1/8'

config globals 'globals'
	option dhcp_default_duid 'xxxx'
	option ula_prefix 'xxxx'
	option packet_steering '1'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'lan4'
	option bridge_empty '1'

config interface 'lan'
	option device 'br-lan.10'
	option proto 'static'
	option ip6assign '60'
	list ipaddr '192.168.10.1/24'
	option multipath 'off'

config interface 'wan'
	option device 'wan'
	option proto 'dhcp'

config bridge-vlan
	option device 'br-lan'
	option vlan '10'
	list ports 'lan1'

config bridge-vlan
	option device 'br-lan'
	option vlan '20'
	list ports 'lan2'

config bridge-vlan
	option device 'br-lan'
	option vlan '30'
	list ports 'lan3'

config bridge-vlan
	option device 'br-lan'
	option vlan '40'
	list ports 'lan4'

config interface 'Comp1'
	option proto 'static'
	option device 'br-lan.20'
	option ipaddr '192.168.20.1'
	option netmask '255.255.255.0'
	option multipath 'off'

config interface 'Comp2'
	option proto 'static'
	option device 'br-lan.30'
	option ipaddr '192.168.30.1'
	option netmask '255.255.255.0'
	option multipath 'off'

config interface 'Comp3'
	option proto 'static'
	option device 'br-lan.40'
	option ipaddr '192.168.40.1'
	option netmask '255.255.255.0'
	option multipath 'off'


wireless

config wifi-device 'radio0'
	option type 'mac80211'
	option path 'platform/soc/18000000.wifi'
	option band '2g'
	option channel 'auto'
	option channels '1 6 11'
	option htmode 'HT20'
	option cell_density '0'
	option disabled '1'

config wifi-device 'radio1'
	option type 'mac80211'
	option path 'platform/soc/18000000.wifi+1'
	option band '5g'
	option channel '36'
	option htmode 'HE80'
	option cell_density '0'
	option disabled '1'

config wifi-iface 'wifinet2'
	option device 'radio1'
	option mode 'ap'
	option ssid 'comp150'
	option encryption 'sae'
	option isolate '1'
	option key 'xxxx'
	option ocv '0'
	option network 'Comp1'
	option disabled '1'

config wifi-iface 'wifinet3'
	option device 'radio0'
	option mode 'ap'
	option ssid 'comp124'
	option encryption 'sae'
	option disabled '1'
	option isolate '1'
	option key 'xxxx'
	option ocv '0'
	option network 'Comp1'

config wifi-iface 'wifinet4'
	option device 'radio1'
	option mode 'ap'
	option ssid 'comp250'
	option encryption 'sae'
	option disabled '1'
	option isolate '1'
	option key 'xxxx'
	option ocv '0'
	option network 'Comp2'

config wifi-iface 'wifinet5'
	option device 'radio0'
	option mode 'ap'
	option ssid 'comp224'
	option encryption 'sae'
	option disabled '1'
	option isolate '1'
	option key 'xxxx'
	option ocv '0'
	option network 'Comp2'

config wifi-iface 'wifinet6'
	option device 'radio1'
	option mode 'ap'
	option ssid 'comp350'
	option encryption 'sae'
	option disabled '1'
	option isolate '1'
	option key 'xxxx'
	option ocv '0'
	option network 'Comp3'

config wifi-iface 'wifinet7'
	option device 'radio0'
	option mode 'ap'
	option ssid 'comp324'
	option encryption 'sae'
	option disabled '1'
	option isolate '1'
	option key 'xxxx'
	option ocv '0'
	option network 'Comp3'


dhcp

config dnsmasq
	option domainneeded '1'
	option boguspriv '1'
	option filterwin2k '0'
	option localise_queries '1'
	option rebind_protection '1'
	option rebind_localhost '1'
	option local '/lan/'
	option domain 'lan'
	option expandhosts '1'
	option nonegcache '0'
	option cachesize '1000'
	option authoritative '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
	option nonwildcard '1'
	option localservice '1'
	option ednspacket_max '1232'
	option filter_aaaa '0'
	option filter_a '0'

config dhcp 'lan'
	option interface 'lan'
	option start '10'
	option limit '100'
	option leasetime '12h'
	option dhcpv4 'server'
	option dhcpv6 'server'
	option ra 'server'
	list ra_flags 'managed-config'
	list ra_flags 'other-config'
	option ra_preference 'medium'

config dhcp 'wan'
	option interface 'wan'
	option ignore '1'

config odhcpd 'odhcpd'
	option maindhcp '0'
	option leasefile '/tmp/odhcpd.leases'
	option leasetrigger '/usr/sbin/odhcpd-update'
	option loglevel '4'
	option piodir '/tmp/odhcpd-piodir'
	option hostsdir '/tmp/hosts'

config dhcp 'Comp1'
	option interface 'Comp1'
	option start '10'
	option limit '100'
	option leasetime '12h'
	option dhcpv4 'server'

config dhcp 'Comp2'
	option interface 'Comp2'
	option start '10'
	option limit '100'
	option leasetime '12h'
	option dhcpv4 'server'

config dhcp 'Comp3'
	option interface 'Comp3'
	option start '10'
	option limit '100'
	option leasetime '12h'
	option dhcpv4 'server'


firewall


config defaults
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option synflood_protect '1'

config zone
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'
	list network 'lan'

config zone
	option name 'wan'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'DROP'
	option masq '1'
	option mtu_fix '1'
	list network 'wan'

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 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 zone
	option name 'Comp1firewall'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	list network 'Comp1'

config forwarding
	option src 'Comp1firewall'
	option dest 'wan'

config rule
	option src 'lan'
	option name 'lan DHCP and DNS'
	option dest_port '53 67 68'
	option target 'ACCEPT'

config rule
	option src 'Comp1firewall'
	option name 'Comp1 DHCP and DNS'
	option dest_port '53 67 68'
	option target 'ACCEPT'

config rule
	option src 'Comp2firewall'
	option name 'Comp2 DHCP and DNS'
	option dest_port '53 67 68'
	option target 'ACCEPT'

config rule
	option src 'Comp3firewall'
	option name 'Comp3 DHCP and DNS'
	option dest_port '53 67 68'
	option target 'ACCEPT'

config zone
	option name 'Comp2firewall'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	list network 'Comp2'

config forwarding
	option src 'Comp2firewall'
	option dest 'wan'

config zone
	option name 'Comp3firewall'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	list network 'Comp3'

config forwarding
	option src 'Comp3firewall'
	option dest 'wan'`
4

I did use the preformatted text tags as asked for, but I got a warning that I was posting code and I needed to use them. So, if this is unusable please tell me what I did wrong and I can post that part again. I tried to do exactly as you showed...

5

Ok... so the config mostly looks good -- and it's easy to get the forwarding that you want.

If you want to be able to reach comp3 from lan, you'll add a forwarding rule like this:

config forwarding
	option dest 'Comp3firewall'
	option src 'lan'`

You can of course create rules similar to those but with more granularity. For example, you can limit by source or destination IPs, you can use destination ports, etc... the options are endless. You can also achieve the reverse where you have something wide open except for specific hosts and/or ports. But fundamentally, the forwarding from one network to another is only permitted if you specifically allow it.

The intra-zone forward rule (in the zone definition) affects the default forwarding between two or more networks that are contained within the same zone. Obviously ACCEPT will allow forwarding, DROP / REJECT will not. The same options for granularity exist here, too.

All other inter-zone forwards are allowed by means of forwarding rules and/or traffic rules.

A few minor things to note. These are all nit-picks, so not a big deal and they won't break anything

  1. You may have noticed that 25.12 uses a new method to define the IP address and subnet -- CIDR notation. That is, the IP address 192.168.10.1/24 defines both the IP and the subnet size/mask, instead of using two lines (one for ipaddr and the other for ntemask). 25.12 does still support the 2 line method, so it's not a problem, but you might consider using that same notation for the other networks.

  2. I recommend explicitly indicating that each port is untagged+PVID. That is done by adding :u* to the end of each port -- for example: list ports 'lan1:u*'would be the method for below:

  1. On the wireless, you have isolation enabled on each SSID. That is fine, but may not be ideal if you find that you need to be able to have devices talk to each other (for example, using AirPlay or ChromeCast doesn't work if isolation is enabled).

  2. This rule is unnecessary for the lan (since it has input set to ACCEPT) and you can delete it:

  1. For the other networks, you only need 53 (DNS) and 67 (DHCP). You can remove 68.

Now

1 Like
6

Thanks for the detailed reply. I may be reading this incorrectly, but maybe I didn't make my problem clear given how long my post was. Right now shouldn't the configuration I have block communications between networks in different zones? It appears there is full communication between zones and my setup should not be allowing this. That's my issue. In my v19 router that is set up just like this there is, as expected, no communication from one zone to another. So, why do I need to write more firewall rules to stop traffic from one zone to another when I already have the zone forwarding set for each zone only to go to wan and nowhere else?

Thanks for the nits. I am aware of CIDR notation, so I was a bit confused when it forced me to CIDR notation for the lan, but defaulted to offering the netmask option for all the rest. I will change them to CIDR. I do have a question on using u*, but I don't want to distract from my primary question above. I read somewhere that using PVID is unnecessary if you only have one u on a given port, so that's why I didn't use it. It's no problem for me to add that, but am I only doing that so if I do have more than one u on a port in the future it will know which is the one I want the u traffic to go to? I'm just wondering about the why of it here. As for the wireless I checked isolate because right now I don't want any communication between devices, but it's a good reminder for me that if I do in the future I need to uncheck that. I will make the last two changes. Again, I appreciate the nits.

7

I agree that your config should not allow it.

With that in mind, please provide the details of the specific tests you are performing. For example:

  • what are the source and the destination IP addresses?
  • what is the test method? (ping, traceroute, accessing a service like http/https, etc.)
1 Like
8

I have been doing some more extensive testing using ping and tracert/traceroute. The problem is odder than I at first thought, but it appears the problem is also smaller, too. First I made sure this effect happens whether I was using a Windows machine or a Linux machine, and found that doesn't change the results, so ping/ tracert or ping/traceroute works the same on both OS. I now realize that when plugged into the lan port (my 'management only' port) I can ping all the 'gateway' addresses i.e. 192.168.10.1, 192.168.20.1, 192.168.30.1, and 192.168.40.1, as well as the IP address assigned to that computer (let's say 192.168.10.78).

If I try to ping 192.168.30.55 it fails. When I run tracert on it the first hop is always the gateway address for whatever computer I'm using, and then it reports destination protocol unreachable. For example if I'm on the lan 192.168.10.1 network, with an IP address of 192.168.10.78 and I try to tracert (or traceroute) 192.168.40.50 the first hop is 192.168.10.1, and then that's it.

Now, when I am on any other port the only thing I can get through is a ping to myself. If I try any other address it will show the default gateway for that network as a hop and that's it, as mentioned above. Since that is discoverable just doing ipconfig /all on Windows or equivalent in Linux, this is no issue. That means all the VLANs/Zones except the lan are working as expected.

I only did my initial testing on the lan/management/port1 area since I assumed they would all behave the same given my v19 setup does. This reduces my problem to one of network discovery (and my own curiosity). If the lan area got accessed one could just run some type of script/program that pings everything and quickly discover the gateway addresses for the entire network. I honestly don't know what theoretical risk that presents, but if lan was being used for any other purpose besides as my ‘management only and then unplug’ zone I wouldn't be comfortable with this ability for someone to discover the entire network’s gateway addresses.

So, at this point I'd really like to understand why this happens only on this VLAN/Zone/port, and is there any way to block that. My concern is that someone (let's say a teenager for example) decides to switch ports while I'm not home, well, I'd rather not have this avenue open like this. Yes, if said teenager might be wanting to hack my system I have bigger problems. My goal is to have each area unable to see anything about the other areas so if something in that area gets hacked via a security vulnerability when say surfing, the other areas are less likely to also be compromised.

I hope this helps. You can ask me for more specific tests if needed. Any advice on how to stop this limited gateway pinging would be great. And if you can explain why only this one VLAN/Zone/port can do this, that would be highly appreciated since it’s kinda frustrating to not understand why it's able to do this only in this one zone. Thanks for all the help so far.

9

This is expected. The multiple addresses on the gateway are almost like "nicknames" in a way -- the singluar device holds multiple addresses and will respond to any/all of them by default. It will, however, only respond when the request is coming from a network/zone that is allowed input.

Of course, you can awalys ping your own computer's IP.

Yup. This is also expected because you're not currently allowing forwarding between any of the VLANs.

19.07 should have behaved the same way.

You need some way to manage your router, so be very careful about any changes you make here.

Setting the input rule to reject or drop from any given zone/network will block all access to the router itself (ping, ssh/web, etc.) except for the services that you specifically allow (usually DHCP and DNS).

Typically you'll want at least one network that has input set to ACCEPT so that you can indeed manage the device. There are a number of ways you can lock it down, depending on how tech savvy your 'adversary' is. The simple ways (such as disabling the DHCP server, only allowing one IP and/or MAC address to access the administrative surfaces, using a really obscure network address, etc.) are not necessarily the most robust ways, but will deter the casual/opportunistic attacks.

Also, if the 'attacker' has physical access, they could just simply engage failsafe mode and go from there.

1 Like
10

Thanks for the immense help here. I think I now understand all the areas where I wasn't clear before. I apologize that a lot of the issue was me not understanding some simple concepts that you clarified, like being able to ping other 'gateway' addresses if you have input set to accept. If I had understood that I would have known why this ping was going through. You mentioned that my v19.07 should act the same, and knowing what you have taught me here, it should. I was going by my notes, since it's been awhile since I have messed with v19. So, I went back and repeated the tests I mentioned above with the old v19 router, and you were right (and my notes were wrong), it behaves exactly the same way on all counts.

I feel a bit bad because it turns out there really was no issue, both setups were acting the same. I should have confirmed this with more rigorous testing first. I still would have posted the question about why it is able to do these pings, but it would have taken a lot less time. But I have a much better handle on all this, so thanks for all the very patient help you have given me. And I am really glad you looked over my config settings and gave me some nits on that. I'm much better off now.

Lastly, you said:

"There are a number of ways you can lock it down, depending on how tech savvy your 'adversary' is. The simple ways (such as disabling the DHCP server, only allowing one IP and/or MAC address to access the administrative surfaces, using a really obscure network address, etc.) are not necessarily the most robust ways, but will deter the casual/opportunistic attacks."

Can you point me to any docs where I can read up on that? The one thing I have done is change the uHTTPd file to bind only to the lan port, and with a different listen port number. I can change the network address to something obscure (what I have now isn't set in stone), but I am not sure how to only allow one IP address, and if that is in any way related to or conflicts with what I have done with uHTTPd. So do I assign the management comp a static IP address, and then use that as the only address that is accepted for access? I would assume that is via a firewall rule? I'm not asking you to answer all this unless it is fairly simple, as I've already asked a lot, but if you can point me in the right direction I'll do the research.

11

I tried to use the CIDR notation with the other interfaces and it wouldn't let me, the text turned red and warned me 'Expecting: valid IPv4 address'. Deleting the netmask first still threw the same error. With the lan it would only accept CIDR. So, I expect I'll have to leave this as is.

Can you, or someone, let me know why you use the * (PVID)? I asked above "I read somewhere that using PVID is unnecessary if you only have one u on a given port, so that's why I didn't use it. It's no problem for me to add that, but am I only doing that so if I do have more than one u on a port in the future it will know which is the one I want the u traffic to go to?" So, is it correct that it isn't necessary in this limited use case I have, but good form and may be needed in the future, so just do it now? Or am I missing the point?

12

(DSA and Primary VLAN and local?)
(DSA and PVID usage examples)
(https://openwrt.org/docs/guide-user/network/dsa/converting-to-dsa#untagged_tagged_and_pvid)

Good form. If you want to pursue advanced vlan topics and the absolute headaches that may result, you will use it. For 99% of use cases, * will be used on U* and if you have a tagged trunk vlan blackhole T*.

1 Like
13

Thanks for the info, that helps.

14

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.