Hello all, bit of an OpenWRT noob here so I appreciate your patience in advance.
My current set up is as follows:
ISP Modem <--> Raspberry Pi 4 (running OpenWRT) <--> TP-Link Archer A7 (running OpenWRT as dumb AP)
I have no issue accessing my network wired or wirelessly on the primary net, which I set up as VLAN1. However, I'm unable to connect to the SSID I set up which is connected to my secondary guest VLAN, VLAN2.
I have configured an additional firewall zone for this guest net.
Any help is appreciated, here are my network and firewall configs.
Router Firewall:
config defaults
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'
option synflood_protect '1'
config zone 'lan'
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list device 'tun+'
list network 'lan'
config zone
option input 'ACCEPT'
option output 'ACCEPT'
list network 'GUEST'
option name 'guest'
option forward 'ACCEPT'
config zone 'wan'
option name 'wan'
option output 'ACCEPT'
option masq '1'
option mtu_fix '1'
option input 'REJECT'
option forward 'DROP'
list network 'WAN'
list network 'WAN6'
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 rule 'ovpn'
option name 'Allow-OpenVPN'
option src 'wan'
option dest_port '1194'
option proto 'udp'
option target 'ACCEPT'
config forwarding
option dest 'wan'
config forwarding
option src 'guest'
option dest 'wan'
config rule
option name 'Allow-GuestDHCP'
list proto 'udp'
option src 'guest'
option dest_port '67-68'
option target 'ACCEPT'
I went ahead and made some configuration changes based on that script, as well as the following videos: video 1, video 2, video 3
My current setup has an untagged VLAN on ID 1, which is my primary LAN. This is what my primary WiFi SSID is on, and it works as expected. My interface to this is a DHCP Client which retrieves its IP properly from the main router.
My issue comes when trying to use the other VLANs. If I create a new interface on the AP, it does not receive an IP from the main router. If I set it as static, I still cannot connect to the SSID on the guest net. My phone's error is "Cannot get IP Address" so I'm assuming this is a DHCP issue, but I can't seem to figure it out. If there is no clear answer here, I will go ahead and start from scratch but as I have my main network working on a VLAN, I feel like there is one or two things that I am missing. Thanks again
Your AP does not need to have an address on the extra VLANs... only one address is necessary (the one that will be used to manage the AP).
Before going too far with the AP config, have you validated that the Pi is setup correctly with the VLANs. Is there anything between the Pi and the A7 (such as a switch)?
I'm not entirely sure that the VLANs are correctly configured, but they all appear on LuCI and are assigned IPs as expected. What would be the easiest way to test that my VLANs are we properly configured? I am directly connecting the Pi to the Archer.
Let's review the following files from the pi. If there are issue with the config there, you'll be banging your head against the wall trying to troubleshoot it on the wrong device.
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:
That looks okay except for one thing (that I am actually not sure about)...
The network configuration you have basically has VLANs off br-lan. I'm not sure if it is supposed to be done like that, or just simply device eth0.3 and device eth0.4. In previous version of OpenWrt, it would be eth0.x, but with DSA (on some targets), this has changed. I haven't tried OpenWrt on a Pi, so I'm not sure about the correct syntax here.
I think @anon50098793 may be able to answer this one. Once that config is right, then you can move on to the other device.
I know it's at least somewhat functional to set it up this way because I'm running my LAN on br-lan.1, and I have internet working (on the Pi, and coming through my AP to my client devices).
The videos I linked in my earlier comment were explicit about doing it this way, creating VLANs off of br-lan, but as you said, perhaps this is not the approach necessary for a Pi.
@psherman I have a bit of an update, I believe that the Pi is working as expected (more or less). I decided to test the VLANs on the Pi using its onboard WiFi. I confirmed that I'm able to receive an IP address on 192.168.1.x, 192.168.3.x, and 192.168.4.x for lan, guest, and IoT respectively.
One thing I think was getting in the way of that working was my NextDNS service running on the Pi, but once I turned that off and back on, everything worked as expected (with the exception of guests being able to access the router page but that's a small issue to deal with later).
I'm still struggling to get this access point connected, however. On my TP-Link, the Network > Switch section is available, I know this was used before 21.02 to configure VLANs, so I was wondering if that might be the key/the issue? Again, my br-lan.1 DHCP client seems to work, but I can't get an IP for br-lan.3 or br-lan.4.
Edit: It seems like there’s definitely some other issues here as well, not sure how helpful this will be but my chrome cast no longer can connect to the Wi-Fi at all, at my iPad wasn’t receiving a dns server. Once I set the dns to 192.168.1.1, however, it works fine. Other devices seem totally unaffected.
This actually does not test the Ethernet interface. While this test was useful to verify the dhcp and firewall configuration, it does not answer the question about the way that VLANs should be tagged on the Ethernet interface.
The more I think about this, though, the more I am convinced that the current config on the pi is wrong. It should simply be eth0.x. So for example, the section below is wrong.
The bridge-vlan stanza should be removed and the guest interface should be defined with: option device 'eth0.3'
If this is the case, you will be using swconfig and not dsa. Reset your ap to the default config because there was a mixture of syntax in that system and it will not work. Once it is reset, please post the network config file.
Also, on the ap, take a look at the switch page to understand the physical to logical port number mapping. You will see an indication of when a link is up or down on a port - you can then look at the number of the port on the case and compare it against the number on the switch page. This is important because we also need to know which port is your trunk (to the pi) in order to ensure the VLANs are setup properly on the right ports.
Alright, I configured my VLANs using eth0.x on the Pi. I also wiped and reinstalling OpenWrt on my TP-Link, only changes I made were to point br-lan at 192.168.1.1 (the Pi), and to set up WiFi networks.
config defaults
option syn_flood 1
option input ACCEPT
option output ACCEPT
option forward REJECT
# Uncomment this line to disable ipv6 rules
# option disable_ipv6 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
# We need to accept udp packets on port 68,
# see https://dev.openwrt.org/ticket/4108
config rule
option name Allow-DHCP-Renew
option src wan
option proto udp
option dest_port 68
option target ACCEPT
option family ipv4
# Allow IPv4 ping
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
# Allow DHCPv6 replies
# see https://dev.openwrt.org/ticket/10381
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
# Allow essential incoming IPv6 ICMP traffic
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
# Allow essential forwarded IPv6 ICMP traffic
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
# allow interoperability with traceroute classic
# note that traceroute uses a fixed port range, and depends on getting
# back ICMP Unreachables. if we're operating in DROP mode, it won't
# work so we explicitly REJECT packets on these ports.
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 false
# include a file with users custom iptables rules
config include
option path /etc/firewall.user
### EXAMPLE CONFIG SECTIONS
# do not allow a specific ip to access wan
#config rule
# option src lan
# option src_ip 192.168.45.2
# option dest wan
# option proto tcp
# option target REJECT
# block a specific mac on wan
#config rule
# option dest wan
# option src_mac 00:11:22:33:44:66
# option target REJECT
# block incoming ICMP traffic on a zone
#config rule
# option src lan
# option proto ICMP
# option target DROP
# port redirect port coming in on wan to lan
#config redirect
# option src wan
# option src_dport 80
# option dest lan
# option dest_ip 192.168.16.235
# option dest_port 80
# option proto tcp
# port redirect of remapped ssh port (22001) on wan
#config redirect
# option src wan
# option src_dport 22001
# option dest lan
# option dest_port 22
# option proto tcp
### FULL CONFIG SECTIONS
#config rule
# option src lan
# option src_ip 192.168.45.2
# option src_mac 00:11:22:33:44:55
# option src_port 80
# option dest wan
# option dest_ip 194.25.2.129
# option dest_port 120
# option proto tcp
# option target REJECT
#config redirect
# option src lan
# option src_ip 192.168.45.2
# option src_mac 00:11:22:33:44:55
# option src_port 1024
# option src_dport 80
# option dest_ip 194.25.2.129
# option dest_port 120
# option proto tcp
Cool. So your networks are br-lan (which maps to eth0), eth0.3, and eth0.4 on the Pi?
Did you check the physical to logical port mapping on the AP? (i.e. is physical LAN 1 = logical 1 or logical 4, etc.). Some devices have them directly mapped, some are reversed, and a few here and there are a bit more strange).
Finally, what port (physical and logical) on the AP will be used to connect to the Pi?
config device
option name 'br-guest'
option type 'bridge'
list ports 'eth0.3'
config interface 'guest'
option device 'br-guest'
option proto 'none'
And then create a wifi SSID and link it against the guest network.
Repeat for your IoT.
Another quick test you can run, if this doesn't work, will be to use the switch to verify the trunk is working by setting up access ports for each of the 3 networks that you can literally just plug a cable into to test that you end up on the right network.
Wow, I think that is 95% of the way there. I am able to connect to the network, but it appears that DNS servers are not distributed properly to the client devices. If I set my DNS to be 192.168.3.1 on the guest net, it works perfectly.
It looks like I'm not receiving an address. I had forgotten that many of my devices were already using custom DNS, and that a lot of IoT devices have hardcoded DNS, because if I turn off my custom DNS service, I do not receive any DNS servers on guest or lan.
Edit: From my AP, I can ping 8.8.8.8 but I can't ping google.com so it looks like the AP itself is not resolving DNS queries either.
