I choose Input reject to avoid the Guests to reach the LAN. (but even trying accept did not solve my problem)
When trying to connect any device to my Guests network, the device trys to get an IP from DHCP but it waits for ever, dont get the ip and eventually falls back to the LAP wifi.
Can someone help me understand what do I do wrong?
If you need more screenshots or logs, let me know.
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:
Start with the default configuration (just copy on the guest network what you have on the LAN). See that you can get an IP address and reach the internet.
Then try to reach LAN from the guest network (you will probably won't be able), and check that forwarding from guest to LAN is disabled.
That configuration looks correct. Building a DHCP server on a new interface won't start up from the usual "restarting network". Either go to the Startup page and restart dnsmaq, or reboot.
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
config device
option name 'br-lan'
option type 'bridge'
list ports 'eth1.1'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option netmask '255.255.255.0'
option ip6assign '60'
option ipaddr '192.168.21.254'
list dns '192.168.21.60'
config interface 'wan'
option proto 'dhcp'
option device 'eth0.300'
config interface 'wan6'
option proto 'dhcpv6'
option reqaddress 'try'
option reqprefix 'auto'
option device 'eth0'
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 description 'LAN'
option ports '1 2 3 4 6t'
config switch_vlan
option device 'switch0'
option vlan '3'
option ports '0t 5t'
option vid '300'
option description 'WAN-Internet-IPTV'
config device
option name 'eth0.300'
option type '8021q'
option ifname 'eth0'
option vid '300'
config interface 'PIA_VPN'
option proto 'none'
option device 'tun0'
config switch_vlan
option device 'switch0'
option vlan '4'
option vid '3'
option description 'IoT'
config switch_vlan
option device 'switch0'
option vlan '5'
option vid '4'
option description 'Guest'
option ports '4t 6t'
config interface 'GUEST'
option proto 'static'
option ipaddr '192.168.40.40'
option netmask '255.255.255.0'
option type 'bridge'
option device 'eth1.4'
Wireless (dont mind about the IoT, I chosen network lan to make sure my IoT would have internet access. eventually they have the same issue as guests ... about receiving dhcp lease)
I made the correction but the guest network keeps not giving ip. (I am testing the wifi connection.)
Why the option interface 'guest' was in lower case?
I user LUCI (web interface) for the all configuration.
Additional info:
even before the change to upper cases, when trying to connect to guest wifi network, I can see under /network/wireless associated stations that it seems the association did happen:
PS
if you notice, in the attempt association you notice the MAC address and again a mac address (I assume is ip6 version), no IP at all. Strange sort of association
Have you tried hardwired. Remove port 4 from the LAN and then set port for as untagged VLAN 4 (your guest network). Then plug in a device and see if it gets an IP in the correct subnet.
No, I have not tried. Something I cant do tonight as the router in in a odd place in the house.
Would it make a difference?
Wouldn't it be the same issue as the wifi would follow the same configuration of the wired (and vice versa)?
Yes, in theory. But given that things aren't working that way, I'd recommend testing explicitly on port 4.
but while we are at it -- what is downstream of port 4 right now? Assuming it is a managed switch, you could just configure one of the ports on that managed switch as an access port for VLAN 4 (i.e. untagged VLAN 4, no tagged networks).
If you have an unmanaged/dumb switch or something that is not VLAN aware, unplug it and see if that resolves the issue (unmanaged switches should never be tasked with handling tagged networks).
