Hi all,
I have followed that tutorial to set-up my Wireguard VPN connexion:
I would like to temporary stop to go through Wireguard VPN.
To do so, I modify the firewall rules as below.
But when I do that, I don't have any internet connexion.
Could you please help me, I don't know at all how to solve my issue
Thanks
Can you get a response when you ping known IP addresses such as 8.8.8.8 or 1.1.1.1 ?
If the answer is Yes, then it may simply be a DNS issue. ie. your devices may be trying to access mulvad DNS servers?
If the answer is No, then fwiw, I've encountered the same behaviour when there is just lan -> wan zone forwarding defined as shown in your posted image, where wireguard is installed.
The only time I found lan to wan forwarding does work (ie. normal internet access), is immediately after installing a newer OpenWrt sysupgrade.bin image and choosing to KEEP SETTINGS, and BEFORE the wireguard packages have been reinstalled.
Removing all the wireguard packages may be only way to reinstate normal internet access? This is not an ideal solution.
I've not investigated why this issue occurs. I don't use mulvad btw.
Thanks @bill888
I have tested to ping 8.8.8.8 but no response.
Very strange.
How did you managed this situation on your side, you don't use Wireguard anymore?
Correct, I do not use Wireguard but this is because my VPN provider's Wireguard implementation is 'unstable'. ie. I think they frequently expire the keys rendering it unusable. (Keepsolid's VPN Unlimited)
OpenVPN is more reliable, but slower. Also, stopping OpenVPN instance and changing zone forwarding so lan -> wan to restore normal internet access works too.
Have you disabled the wireguard interface or just changed the firewall?
I believe I had run into this issue, too. I will have to check to confirm the details about how I solved it, but I recall that I set the gateway metric on the WAN and the WG interfaces.
IIRC, the issue is that when WG comes up, it overwrites the default routes. Then, when it goes down (on OpenWrt), it does not reset those routes to the previous state. By setting the metric values, the pre-WG-up routes are preserved while WG is up, and thus the routing table stays intact when the WG interface goes down.
EDIT: I just checked and the gateway weight was indeed my solution. I found that I could set both the WAN and the WG interfaces to a value of 1 and everything works properly both when WG is up and after it has gone down. Setting this value ensures WAN's default route doesn't get removed when WG is torn down.
@ krazeh
Blockquote
Have you disabled the wireguard interface or just changed the firewall?
No i didn't, I have done it and it solved part of the issue.
Indeed, Peers/"Allowed Ips" was set to 0.0.0.0/0 and I have seen it is a kill switch.
So disabling WG interface probably avoids that rule; I have replaced by 0.0.0.0/1 & 128.0.0.0/1
Then I had a DNS issue described by @bill888 (1.1.1.1 ping OK but no internet), as in Mullvad guide they recommand to edit LAN interface with:
Now it works very well, Thank you all for your help!!
So I see that setting both the WAN and WG to a value of 1 is inadvisable, but it did seem to work. Does this suggest that my setup was working by chance and likely to fail?
Regarding the metric, I assume lower number is higher priority? In the example from the custom metric, it sets 1024. Is there any downside to using such a high value? And should my WG interface simply not be set with a metric value (I think default/unspecified ends up as 0)?
If it matters, my specific application is the road-warrior context where the my travel router connects to my home VPN to transparently tunnel all of my devices back through my home network. I actually have 3 locations (my house, my dad's, and my in-laws) that I can tunnel through when traveling, and I have OpenVPN and WG configured on both my travel router and the VPN endpoints at the houses (only one VPN tunnel is ever established at a time). With OpenVPN, the default route of the WAN would be re-enabled when the tunnel is stopped, but WG ended up overwriting and not restoring the default route. That is when I started playing with the gateway metric. I have the ability to do a VPN kill-switch via the firewall (i.e. don't allow LAN > WAN forwarding), but if I want to have network connectivity after taking down the tunnel, I think that the metric is the simple route.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.
