it might make the most sense to make a backup and then reset the router to defaults
hopefully not but yeah it might just come to that. I have taken detailed notes of each process in case I have to do it again so it's not too bad since ive done the research already.
If it does come to that I will report back here.. as I install each package I can see which one breaks the guest interface.
you might follow outdated guides, e.g. 23.05 firewall is fw4 which is based on nftables instead of iptables. thus the firewall rules you are referring to cannot be used.
i think better approach would be:
- reset to defaults
- create guest network
- verify if lan and guest networks works as expected, i.e. you can access wan from both. e.g. as i said you might have a routing misconfiguration based on the failed pings.
- add adguard (*) , verify if dns requests work from both networks as expected,
- add dns hijack (**),
- add vpn, verify if routing works as expected.
(*) adguard can be installed in couple of ways. it can be installed onto your owrt router or to a separate host. it can be installed as a dhcp server too not just as dns server. it can be installed as a replacement for default dnsmasq or an upstream to the default. check the guide you follow which approach it uses and verify if it works as per the expected method. for example very common setup is to use adguard as a replacement dns while keeping default dnsmasq as dhcp server. in this case adguard will listen on the default port 53, all clients will talk to it, and dnsmasq's dns part is set to port 54. if you want to access an own host on your network by name then adguard will ask dnsmasq as dnsmasq "owns" your lan/guest etc networks, as dnsmasq keeps track the local host name-ip mapping because of being the dhcp server. rDNS is a bit different as it tells the hostname based on ip address input, normal dns does the opposite: for a hostname input tells the corresponding ip address(es). so rDNS will require additional settings, in your case, again, to point back to dnsmasq in case of ip ranges you use in your networks.
(**) the firewall rules you are referring is called dns hijack method, it is supposed to overrule client attempt to use a different dns server, to get around your controlled dnsmasq/adguard and let's say go directly to google's 188.8.131.52 dns server. the firewall rule in this case will force dns traffic to your controlled dnsmasq/adguard.
and if i may ask: please copy your configuration files instead of pictures as configuration files usually tell more and more precisely. with the usual filter on: obscure any sensitive data (such as passwords, or keys in vpn configs, or things which can be misused remotely) but you can leave ip addresses of your internal network (e.g. 192.168.1.0/24 is not unique to you, technically speaking rfc 1819 ip addresses can be left in).
you might follow outdated guides
its very possible. I tried avoiding that by going to the source documents.. and comparing the article release dates to be the most recent...
I think better approach would be... reset to defaults...
Ive backed up, reset and first setup the guest network based on the same guide I used prior. It's working as expected.
I have not had time to add packages and verify just yet due to time constraints but I can verify at this point that some unknown config in the prior setup was preventing the guest interface from working properly.
please copy your configuration files instead of pictures
will do, thanks for the suggestion. I originally posted the config files but since we were getting stuck decided to throw the screenshots as well.
Thank you again for your time. I wish I could have found the culprit in the original setup but doing so would likely waste needless time.
happy to hear there is definite progress!
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.