Since my Vpn provider uses Dns entries for the endpoints whose Ip addresses are regularly rotated, I have made a small script which adds these Dns entries to /etc/hosts to avoid Dns problems. Therefore the script should be executed regularly with cron to get the latest entries. Since the script rebuilds the hosts file to avoid invalid entries, there is the possibility to include a custom address list in the creation. I hope someone finds it useful.
trigger script execution using hotplug event, every time tunnel goes down ?
You mean that the IP address of the VPN server can change while you are connected?
No, there are scripts for that. The problem, at least for me, is that when the tunnel is interrupted the Dns is also interrupted, so it does not get the IP address to set up a new tunnel, because my Vpn provider works with Dns entries and not with Ip addresses. The script should read the IP addresses of the endpoints of the Vpn provider and enter them in the /etc/hosts so that the tunnel can be re-established in case of an interruption and no Dns is available.
Yes the Dns entries are changed they give out different Ip addresses for the same Dns names I hope that's what you meant?
I.e., hostnames, yes yes, most if not all VPN providers do, as do many phone-home VPNs by way of DynDNS. Which VPN protocol are they using that does not re-resolve an endpoint's hostname? (Is it WireGuard?)
1 Like
Yes, it is Wireguard. But this has nothing to do with Wireguard the problem is that by default the Dns requests are also routed via the tunnel and if the tunnel breaks down Openwrt is usually too “stupid” to send the Dns requests via the normal Wan port so that the tunnel can no longer be established. Maybe this is because I use unbound as Dns resolver.
If unbound's primary DNS servers are within the VPN, that would do it, yes. Have you tried excluding the VPN endpoints' hosts from being resolved within the VPN (using local-zone rules)? Then wireguard-watchdog could do its job.
1 Like
No, I wouldn't know how to do that and whether Unbound can do that and redirecting Unbound to the Wan port would be exactly the reason why I use Unbound - a Dns leak. With the script it also works, also has the advantage that the Vpn connects faster when booting up because it does not have to wait for the Dns resolver to start.
Noone's talking about unconditionally redirecting unbound to WAN. You'd specify exactly which hosts unbound is allowed to look up outside of the VPN tunnel. The four hosts you need to look up outside of the VPN tunnel. The very same four hosts your script is looking up outside of the VPN tunnel.
But fair enough, you solved the problem you created for yourself with a workaround you created for yourself. Some people would prefer to remove the problem, but different strokes for different folks.
I now doubt that I caused the problem. I thought about it and came to the conclusion that Openwrt probably has a problem with setting the default route, I deactivated the wireguard device to simulate the failure, normally Openwrt should then take the other route via the wan port, but it doesn't, even if you restart the network with service network restart it works at most in 2 out of 10 cases, which indicates a bug. Obviously the default route with the device is insufficiently checked to see if it is available at all, which also explains the strange problem I had after a power failure, although the Internet was not yet available because the provider remote station was not yet ready, the default route was set to the Vpn although it was logically not connected and did not even have an address, while the wan port was connected to the router in front of it and therefore had a local address.
Not how it works. Routing tables are static lookups that, once set, don't check or care whether an interface is available, they don't act as automatic fallback/fall-through/failover. While such a behaviour is absolutely possible, it requires the assistance of fairly elaborate scripting (look up "PBR" if you're so inclined). But since you don't want "DNS leaks" you probably wouldn't want an automatic fallback sending everything via the default non-VPN route either.
1 Like
I'd say user error or incorrect assumptions.
or MWAN3.
2 Likes
@takimata @frollic Do you two realize that I use PBR?
@takimata but if I restart the complete network with “service network restart” the system should behave like booting first set the default route via the wan port so that the vpn endpoint name can be resolved, then the route via the vpn when the connection is established, but this usually does not happen and that is the BUG.
Of course! Usually we can smell such information, right after we hear our crystal ball bark.
So in the course of a few posts we went from "DNS problems" via "unbound problems", "routing problems" and "OpenWrt bug" to "PBR bug". I can't shake the feeling the actual problem is that you've got an ever so slightly misconfigured setup, and instead of finding the problem you keep on adding to the configuration, eventually ending up at custom scripted workarounds.
I mean, seriously, routing through a VPN with a fallback to WAN is one of the primary use cases for PBR. If that were inherently buggy, you'd think someone would already have noticed that.
2 Likes
no, we're not mind readers ...
1 Like
I did not mention PBR because it is not worth mentioning in this case as it has nothing to do with the problem. It is not a PBR problem, the problem is that when the network is restarted with “service network restart”, the system does not reset the default route or sets it to a device (Wg0) that does not yet exist at that time. I can't say exactly what happens of the two, but in any case the requests run into nothing and it doesn't matter whether PBR was running or not.
I disagree. PBR deeply influences routing, and you are having problems with routing. It may be misconfigured or misbehaving, especially if previous experiments have not been properly cleaned up.
"The system" could not possibly set a route to a device it doesn't know about. So it must be configured somewhere where it is, wittingly or not, picked up upon network (re)start.
Pbr uses nftables rules to manipulate the routing, if the service is not started no nftables rules are loaded. That's why I wrote it doesn't matter if PBR is started or not, I tested both because I also suspected PBR, because there are also problems if PBR is started too early at boot time and the developer is not very cooperative in this regard.
But it seems to do it normally a network restart should behave the same as a reboot, but it doesn't and the fact that it still works from time to time as it should indicates that something is wrong, which also excludes a configuration error because the problem would then always occur. As I said, my script avoids the problem for now, but the developers should perhaps take a closer look.