Yes I know some people enable a lot of WG tunnels but do not bring it up to easily switch tunnels.
But the interface is enabled that is why PBR tracks the tunnel and sets a trigger on it, as soon as it comes up PBR will set the associated routes.
But now that interface is not working as it is not up and PBR is warning you about it.
It is a warning and not an error so everything still works but we think it is prudent to warn if you have an interface/device which is not working, in your case it is intended not to work (yet) so all good.
If a reboot does not correct it then it probably is the browser cache.
If you empty the browser cache or use another browser or incognito mode it should display correctly
I did both...Rebooted and cleared cache...Was still showing r79...So that's why I uninstalled and then reinstalled...Good now...Going to do my Flint 1 now...
I am using domain-based policy-based routing (PBR) to route traffic for specific sets of domains through different interfaces.
Currently, I have configured dnsmasq to forward DNS queries for these domains to 1.1.1.1 (for example: abc.com/xyz.com/1.1.1.1 and set up PBR accordingly:
Here are my questions:
Interface-Specific DNS Routing:
I have two WireGuard interfaces (wg1 and wg2). I want traffic for certain domains to route through wg1 and others through wg2. How can I configure dnsmasq and PBR so that DNS queries for each set of domains are always resolved through the specific interface assigned to them?
DNS Server Clarification & Dummy IPs:
When I specify 1.1.1.1 in dnsmasq, does it actually send the queries to Cloudflare's public DNS server over that interface, or is 1.1.1.1 just acting as a placeholder/target name to route DNS traffic? Can I use an arbitrary IP like 1.2.3.4 instead of a real DNS server address just to direct the queries to the selected interface? (Also, if I am connected to a VPN like Proton, will it resolve via Proton's DNS or Cloudflare?)
Regarding your first question see if this covers what you want:
Regarding the second question if you tell DNSMasq to use server 1.1.1.1 with the server= (of for OpenWRT list server) then OpenWRT will indeed send out the query for DNS to that server among other upstream resolvers from e.g. the resolve file or otherwise in the config.
Note upstream DNS resolvers can be found in many places in the DNSMasq config and all are used unless you specifically set a resolver for a specific domain as answered in question 1
It's strange... I followed the instructions including the IPv6 default route, then created a rule at the top of the list with source MAC addresses which should go directly to the ISP and not the VPN, but I'm still getting odd behavior. My Homey can't seem to establish a connection with the server, so is unavailable in the app on my phone, while it works within seconds if I hook it directly to the ISP. And an MMO I play every so often can log me on but when it tries bringing me into the game world it kicks me right back out. And once again, directly connected to the ISP it works fine.
Shouldn't having a rule at the top with MAC addresses create a firewall rule to route them directly out?
I am also curious, if Strict Enforcement is on and the VPN goes down, shouldn't rules which bypass the VPN still work?
It is so frustrating how IPv6 has been holding me back from finishing up my network configuration for about 3 years now. Every single time there is just that tiny little thing which may or may not be related to IPv6.
If you use the wan as interface then traffic of this MAC address should go out via the wan.
Make sure the MAC address is correct and is not changing
Just run a traceroute from this server and see where the traffic is going.
Sure only traffic for that interface will stall other traffic will just keep working
IPv6 has many pitfalls but I have it reliably working on several routers.
But your setup of the router regarding IPv6 and of e.g. wireGuard must of course be correct.
For WireGuard see: WireGuard Client Setup Guide
All correct, IPv6 shows the ISP's domain name in the first few hops, IPv4 shows the ISP's router only but IP display on sites is that of my ISP.
And yet... weirdness which disappears as soon as I plug them directly into the modem.
By the way, does uppercase/lowercase matter in MAC addresses? Sometimes it does.
Followed all your instructions. Added the 8000::/1 last time and that has resolved some issues definitely, but not all of them. Which is why I figured I would just throw some systems in those MAC rules above.
My keepalive is 15 per default apparently (not 25) but surely that doesn't matter, does it?
"It doesn.t work" makes it very difficult to determine the cause.
The routing seems correct so next step see if it is related to other settings on the router (MTU etc)
To do set default route to the WAN interface and disable the PBR policy you have made as everything now goes via the wan.
If it then "works" you have ruled out a lot of potential problems
if it does work then set default route again to VPN and enable the PBR policy again, next up to check is DNS as the culprit, as DNS presumably will use the VPN and your homey is now using the wan
Believe me, if I could tell you more I would. Homey is a closed system so I can't see what it does and so is that game.
I did traces to google.com both on OpenWRT and on the modem with IPv4 and 6. Apart from the extra hops at the start from the system through OpenWRT they follow the exact same path with the exact same output. I have not yet changed default routing as that has impact on the entire network.
I am observing an issue with domain-based routing policies on Android devices after restarting network services.
Whenever I restart dnsmasq or the pbr service, traffic routed via domain-based policies stops working on Android devices. Surprisingly, iOS devices continue to work perfectly without any disruption.
On Android, domains under PBR rules fail to load right after the restart. However, as soon as I disconnect and reconnect Wi-Fi on the Android device, all domain-based policies instantly start working again.
