The tunnel IP of OpenWrt will never be used to establish the connection over the internet with the other endpoint.
But why is that not covered by:
14000: from 10.5.0.2 iif lo lookup wan
Or is that source not used to establish tunnel?
My reason for wanting to use source is what happens if the peer changes? I then need to keep changing all the entries. Whereas the source is fixed. So if it can be done that way it seems desirable.
Hope this makes sense.
How about set a rule that says anything from your lan subnet goes via the wire guard tunnel and everything else goes by the wan. Then the routers traffic itself will go on the wan.
Then you need to use a matching condition that will be always true, even if the peer changes.
Not really, I still don't understand why you are trying to reinvent the wheel, when I already mentioned pbr package which does already what you are trying to do.
The PBR maintainer apparently has no interest in facilitating establishing single interface upon which to apply SQM, so for those of us who want single interface that sees both VPN and non-VPN traffic to apply SQM to combined flows it's a case of DIY'ing it. Happily because of the recent LuCi changes it's really easy anyway.
But to capture DNS queries from the router I think I need everything from router except for setting up WireGuard tunnel.
I'm just not yet sure what the rule should be without fixing it to WireGuard peers that change. Any thoughts?
15000: from all iif lo lookup vpn
Won't that fail when vpn is down such that the traffic to set up tunnel goes through wan?
But what are you going to do differently to achieve that and in what sense is PBR limiting you?
One idea is to have dynamically changing rules depending on the peer address. But this requires some up/down WG scripts, or hotplug scripts.
It will fail if there is no other rule with precedence to use main routing table for setting up the tunnel with the WG peer. My suggestion is to use main routing table for router and allow explicitly only what is needed to go through the vpn, like dns, https, etc.
I really appreciate your expertise here, @trendy, thank you.
To effectively apply CAKE in case of VPN PBR you need a single interface that sees combined flows (in my case 'veth-lan'). You can't do that in the LuCi VPN PBR implementation. In fact there is no good way to handle SQM with the standard LuCi VPN PBR implementation and the developer has no interest in this (I asked).
Hmm, how about this angle. Regarding:
uci set network.lan.ip4table="1" uci set network.lan.ip6table="1" uci set network.wan.ip4table="2" uci set network.wan6.ip6table="2" uci -q delete network.lan_wan uci set network.lan_wan="rule" uci set network.lan_wan.in="lan" uci set network.lan_wan.lookup="2" uci set network.lan_wan.priority="40000" uci -q delete network.lan_wan6 uci set network.lan_wan6="rule6" uci set network.lan_wan6.in="lan" uci set network.lan_wan6.lookup="2" uci set network.lan_wan6.priority="40000" uci commit network /etc/init.d/network restart
Sets up the appropriate rules somehow? Since it mentions failover to wan.
What I'd like to understand is how the failover works.
If you have a rule to route traffic over VPN and VPN is down, does it then look to the next priority rule?
So if I have rule priority 100 to go through VPN and rule priority 200 to go through WAN. If VPN is down will the rule with priority 200 apply?
If not, how does the failover in the code above work?
Yes maybe I just put the DNS servers with rules to go via VPN. I only have three so that's just three rules.
Again if VPN is down will the lower priority rules capture DNS queries so that they go via WAN?
These concern routing lan, not OpenWrt itself.
Failover works by assigning lower priority to the wan rules.
Ah OK thanks.
So in that case how about:
15000: from all iif lo lookup vpn 16000: from all iif lo lookup wan
Wouldnt that work?
But I thought we established there is a failover. If the VPN is down it goes to the next priority rule. So why won't that work for setting up the VPN? In other words if VPN is not set up won't it failover to the next rule and set up through WAN?
You are confusing the wiki example which is for forwarding lan traffic to your example which is for the router generated traffic.
So if VPN is down the next priority rule kicks in for LAN but for some reason the same does not apply for 'lo'? Why?
Ah yes I see now.
Use a rule for the DNS destination? Or use DNS over TLS and don't worry about the DNS?
OpenWrt has already received a response to a query and has closed the listening port, so the second response gets the unreachable.
it looks like you're trying to access udp port 54057 but the other end is saying "this port isn't open"
Hmm, right. But why do the DNS queries trigger this I wonder? Should I lose sleep over this? In any case, I'm curious to understand what's going on.