I'm trying to get some VLANs up and running on a no-switch router (LAN port connected to managed switch)
As of now, I have 3 VLANs defined (.100, .90, .80) as devices and interfaces in LUCI. On the managed switch, the ports are tagged for the client devices. For the trunk/tagged port to the router) PVID is 100. For the trunk/tagged port to the wireless AP PVID is 100 as well.
Router is accessible on 192.168.1.1 to a device attached to the .100 VLAN, I think because they're both in the same LAN firewall zone - the other 2 VLANs are on their own firewall zone. But my managed switch admin interface becomes un-reachable, because it's not being assigned an IP address on the .1.x subnet (or the .100 subnet) from what I can tell. AP web admin is reachable on a .100 subnet, but I'm concerned that's not right since it's then sending all wireless traffic (even on different vlans) through the .100 vlan?
Also, the LAN interface still exists and seems to take all the traffic for each of the VLANs - in other words, no clients are attached to the LAN interface, but it seems to be sending all the data from a VLAN device/interface to LAN (and then to WAN or wherever). Is that correct behavior?
I also cannot connect to the Guest VLAN (via the AP that has the appropriate SSID for a vlan) and have it resolve DNS addresses (I can ping an IP address but not the corresponding ".com"). I have permitted input on port 53 from the guest vlan zone to the router, however.
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:
Let's also see the config from your managed switch.
In the vast majority of cases, the client devices require 'access ports' which carry just a single untagged/PVID network. You don't want tagged networks on those ports unless they go to other VLAN aware equipment like another managed switch, an AP, or rarely a VLAN aware end device.
This may be okay. Some people will tell you that a trunk should only have tagged networks (and no untagged networks). The standard does allow you to use an untagged network. The reality is that most of the time it is fine to have an untagged network (aside from personal/professional opinion and best practice), but there are some devices that don't play well when you do this.
In the vast majority of cases, the client devices require 'access ports' which carry just a single untagged/PVID network. You don't want tagged networks on those ports unless they go to other VLAN aware equipment like another managed switch, an AP, or rarely a VLAN aware end device.
I misspoke, sorry. I meant they're "tagged" in the sense that they're assigned to one and only one VLAN via "untagged" and a PVID assignment to the correct VLAN. [tagged and untagged stick in my brain as opposite of what they are in reality]
Printouts attached:
/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 '[reacted]'
config interface 'LAN'
option proto 'static'
option device 'eth0'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
config device
option name 'eth0'
option ipv6 '0'
config device
option type '8021q'
option ifname 'eth0'
option vid '100'
option name 'eth0.100'
option acceptlocal '1'
option ipv6 '0'
config interface 'VLAN_100'
option proto 'static'
option device 'eth0.100'
option ipaddr '192.168.100.1'
option netmask '255.255.255.0'
config device
option type '8021q'
option ifname 'eth0'
option vid '90'
option name 'eth0.90'
option acceptlocal '1'
option ipv6 '0'
config device
option type '8021q'
option ifname 'eth0'
option vid '80'
option name 'eth0.80'
option acceptlocal '1'
option ipv6 '0'
config interface 'VLAN_90_GUEST'
option proto 'static'
option device 'eth0.90'
option ipaddr '192.168.90.1'
option netmask '255.255.255.0'
list dns '1.1.1.1'
list dns '1.0.0.1'
#This was me trying to play with DNS settings to try to get guest vlan to work
config interface 'VLAN_80'
option proto 'static'
option device 'eth0.80'
option netmask '255.255.255.0'
option ipaddr '192.168.80.1'
config interface 'WAN'
option proto 'dhcp'
option device 'eth1'
Now /dhcp
config dnsmasq
option domainneeded '1'
option localise_queries '1'
option rebind_protection '1'
option rebind_localhost '1'
option local '/lan/'
option domain 'lan'
option expandhosts '1'
option authoritative '1'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
option localservice '1'
option ednspacket_max '1232'
option dnsforwardmax '2300'
option min_cache_ttl '270'
option cachesize '5000'
list address '/router/192.168.1.1'
config dhcp 'wan'
option interface 'wan'
option ignore '1'
config odhcpd 'odhcpd'
option maindhcp '0'
option leasefile '/tmp/hosts/odhcpd'
option leasetrigger '/usr/sbin/odhcpd-update'
option loglevel '4'
config dhcp 'LAN'
option interface 'LAN'
option start '100'
option limit '150'
option leasetime '12h'
config dhcp 'VLAN_100'
option interface 'VLAN_100'
option start '100'
option limit '150'
option leasetime '10m'
config dhcp 'VLAN_90_GUEST'
option interface 'VLAN_90_GUEST'
option start '100'
option limit '150'
option leasetime '10m'
config dhcp 'VLAN_80'
option interface 'VLAN_80'
option start '100'
option limit '150'
option leasetime '10m'
config host
#i have about 20 static leases listed next, i took them all out but they all have the same format
option name {name}
option dns "1"
option mac {mac address}
option ip {my chosen static ip, this varies according to which vlan the device is on}
option leasetime {my lease time}
last /firewall
config defaults
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'
option synflood_protect '1'
config zone
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'LAN'
list network 'VLAN_100'
config zone
option name 'wan'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
list network 'wan'
list network 'wan6'
list network 'WAN'
config forwarding
option src 'lan'
option dest 'wan'
config rule
#i truncated all of the "default" traffic rules. i can re-add via edit if you need them. they are unmodified
config include
option path '/etc/firewall.user'
option reload '1'
config zone
option name 'VLAN_GUEST'
option input 'REJECT'
option forward 'REJECT'
list network 'VLAN_90_GUEST'
option output 'ACCEPT'
config forwarding
option src 'VLAN_GUEST'
option dest 'wan'
config zone
option name 'VLAN_80'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'
list network 'VLAN_80'
config forwarding
option src 'lan'
option dest 'VLAN_80'
config forwarding
option src 'lan'
option dest 'VLAN_GUEST'
config rule
option src 'VLAN_GUEST'
option target 'ACCEPT'
option name 'GUEST_ALLOW_DHCP'
list proto 'tcp'
list proto 'udp'
option src_port '53 67-68'
option dest_port '53 67-68'
config rule
option name 'VLAN_GUEST_ALLOW_WAN'
option src 'VLAN_GUEST'
option dest 'wan'
option target 'ACCEPT'
#i added this as i was trying to get WAN access to VLAN_GUEST, but i'm pretty sure it's duplicative of the forwarding rule
How do I go about doing that? I can't access the web interface on the switch(es). The last time I was able to connect I downloaded a config file, but it's not plaintext.
I can give you the tagging/untagging/pvid for each port though?
ok.hopefully i did this right
"PVID assigned to" means that the VLAN id (in that row) is assigned to the listed ports, so on switch 1 only port 1 has pvid '80' and the rest have pvid '100'
Switch 1:
VLAN | Port 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | PVID assigned to
1 | | | | | | | | T | (none)
80 | U | T | | | | | T | T | 1
90 | | T | | | | | T | T | (none)
100 | | T | U | U | | | T | T | 2,3,4,5,6,7,8
Port 2 is the wireless AP
Port 7 goes to Switch #2
Port 8 goes to the openwrt router device
Switch 2:
VLAN | Port 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | PVID assigned to
1 | | | | | | | | T | 3,4,7,8
80 | U | U | | | | | | T | 1,2
90 | | | | | | | | T | (none)
100 | | | | | U | U | | T | 5,6
Port 8 is from Switch #1
Let's only worry about the switch that is directly connected to the router.
For that switch:
What is the brand/model of the switch?
Do you recall if you changed the management VLAN for the switch? (some switches don't have the capability of defining a management VLAN, but if it does have this, it's important to know which VLAN it is using)
What is the address of the switch?
Did you give it a static IP? If so, what address?
Or is it still using the default address?
or is it set to get an address using DHCP?
Your router currently has VLAN 1 untagged (eth0), but the switch has it tagged. This is theoretically why you are unable to access your switch, assuming that the switch has VLAN 1 as it's management VLAN (and ideally has an address on this network). You should be able to fix this by changing the lan's eth0 to eth0.1
See if you can re-establish connectivity with the switch... if not you might have to reset the switch and start from a clean slate.
PVID should only be assigned to a port that is an untagged member of the VLAN. So only ports 3 and 4 apply here for PVID 100.
Meanwhile, my recommendation would be to set each VLAN such that there is an access port for each (just while you're configuring/testing). This way you can actually plug in a computer into each VLAN one at a time just by moving the ethernet cable from port to port.
As an example:
Port 8 is the trunk to the router
VLAN 1 can be set to untagged/PVID on port 5
VLAN 80 is already set for an access port on por 1
VLAN 90 can be set this way on port 6
and VLAN 100 is already set this way on ports 3 and 4.
Ok, I was playing around and I gained access to the first switch by changing the PID on Port 8 to VLAN1 (but it is still tagged on all vlans, including vlan 1) and then telling it to renew its IP address via DHCP server.
I don't really know why that worked though.
It's a Netgear GS108PE switch; I don't think i changed a management VLAN though, but there is something about IGMP snooping on vlan 1 (i have no idea what that means)
You should be able to fix this by changing the lan's eth0 to eth0.1
is this by essentially changing the device type from eth0 to a vlan eth0.1 as with all the other vlan devices i set up?
Is there a problem if i have no "real" network devices and/or interfaces attached, i.e. can they all be virtual/vlan devices?
PVID should only be assigned to a port that is an untagged member of the VLAN. So only ports 3 and 4 apply here for PVID 100.
my switch requires a PVID be assigned to every port, i think?
Maybe i'm getting ahead of myself, but is this (assuming you can have all virtual devices on the router) essentially then creating a management vlan - by making the default LAN interface, which contains the DHCP server and DNS server for all of the other vlans, essentially another VLAN, but because there's something about the "LAN" interface that's special in this regard?
because that's essentially where i want to wind up - i'd like the router, switches, and AP on a separate vlan that can only be accessed by directly plugging into "a" port on the switch.
No, not at all. It would be a perfectly valid config (and some would say preferred).
No, there's nothing special about lan, except that it is associated with the most permissive access (no restrictions like on some of your other networks), so it should 'just work.' But the others could be made to work just the same. it is also the one that was untagged... tagging it on VLAN1 is simple. but unnecessary if you have access again.
Are you referring to a management network? In other words, a network that is exclusively used for managing your network infrastructure devices and nothing else? Sure, that's a common use case, and very easy to accomplish. You can also selectively allow access to the management network from another network, so a host on the trusted lan could be allowed to access the devices on the management network.
Meanwhile, are things now beginning to work as you'd like? Do you have more questions or issues?
Yes, switch 2 - the downstream one - does not behave the same way.
I left that switch unchanged (so Port 8 connected to Switch 1 was Tagged but also had PVID of 1)...
originally, it defaulted to its own default IP address - 192.168.0.239, but i was able to set a static IP in the same subnet on a computer attached to that switch directly to gain access... i switched it to auto assign an IP via DHCP and... no dice, it reverts back to the fallback 0.239 IP. (i'm using a netgear utility to "find" it again)
it's like it doesn't know how to reach the DHCP server, or it's tagged wrong so it gets confused?
there's an option to set a static IP on the switch, so i tried an address on the 192.168.1.x subnet (listing 192.168.1.1 as the gateway) but that didn't work either.
For what it's worth, while i tagged the "accept local" box when creating the eth.xx vlan devices, the eth0 "og" device does not have this option ticked off. does that matter?
Ok... so do you have proper access to switch 2, or is it still not working properly?
If switch 2 is not accessible, you should set VLAN 1 on port 7 to tagged.
Switch 1:
VLAN | Port 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | PVID assigned to
1 | | | | | | | T | T | 7,8
80 | U | | | | | | T | T | 1
90 | | T | | | | | T | T | (none)
100 | | T | U | U | U | U | T | T | 2,3,4,5,6
Port 2 is the wireless AP
Port 7 goes to Switch #2
Port 8 goes to the openwrt router device
Switch 2 is unchanged as far as i can tell - i'll try to log in (via the .0 subnet) and confirm and edit this post if it's different.
Switch 2:
VLAN | Port 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | PVID assigned to
1 | | | | | | | | T | 8
80 | U | U | | | | | | T | 1,2
90 | | | | | | | | T | (none)
100 | | | U | U | U | U | U | T | 3,4,5,6,7
Port 8 is from Switch #1
edited above - i now moved ports 3,4,7 off of vlan1 completely. so now there's only port 8 (which goes to switch 1) with any membership in vlan 1 whatsoever and pvid 1
You don't have a .0 subnet in your main router. Therefore, your computers will not be able to reach the switch on its default address (192.168.0.239) if the switch is indeed still using that address. Do you know if it is set to get an address via DHCP? If so, rebooting the switch should make it work (pull the power for a few seconds, plug it back in).
