-
-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] - Auto-tunneling not reliable #198
Comments
Hello! Thank you for reporting the issue. Are you able to send me any logs related to this issue? That would be very helpful. If you could send them to the support email that would be great! Thank you. This is the exact situation that restart on ping failure should be solving so I am interested to see why it is not working. |
I've just sent you the logs. Let me know if these do not cover the failure |
Thank you for sending the logs. Unfortunately, I did not see the issue in those logs. |
I got the same problem and will send you my log file. Now I got another problem. I will just post my errors here: ERROR WireGuard/GoBackend/User1: message= UAPIOpen: mkdir /data/data/com.wireguard.android: permission denied ERROR OpenGLRenderer: message= Unable to match the desired swap Also another problem I now get is that the app tries to get a handshake and fails but the ping request is successful. |
Thanks for sharing this! Those errors are not a concern. I am not sure why the app is not recognizing gmail as able to accept an email intent. For reference, the support email is [email protected]. You can also find it on my GitHub profile. I am thinking maybe it would be better to ping a random IP (like cloudflare 1.1.1.1) instead of pinging the wireguard server. I'll make some tweaks to this and see if it improves things. |
I am not sure if cloudflare would have made a difference in my case because I use duck dns to direct the client to my server. Maybe the problem was also my split tunnel setup: |
Yeah, I was thinking that the split tunneling might make this an issue. Would it solve the problem if there was a setting that allowed the user to enter a specific ping target for each tunnel? |
I think so. |
Hi @zaneschepke 'Restart on ping fail' option is not working on our Google TV. when my target DDNS IP changes, it is not re-resolving. wireguard_watchdog on our openwrt router is working fine for same situation. please see if same code can be used here |
Please try this prerelease build that I'm hoping fixes this issue: https://github.com/zaneschepke/wgtunnel/releases/tag/auto-tunnel-reliability-testing |
Now I do not get any connection at all. The VPN symbol appears but I cannot access the Internet.
04.08.2024 01:29:11 Zane Schepke ***@***.***>:
…
Please try this prerelease build that I'm hoping fixes this issue: https://github.com/zaneschepke/wgtunnel/releases/tag/auto-tunnel-reliability-testing
—
Reply to this email directly, view it on GitHub[#198 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/BIKH7ZKTWH6AEGTW46JWVYDZPVRUNAVCNFSM6AAAAABHKDWOZGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRXGE4TENZSGA].
You are receiving this because you authored the thread.
[Verfolgungsbild][https://github.com/notifications/beacon/BIKH7ZI4XKJSYPWJUGVHUT3ZPVRUNA5CNFSM6AAAAABHKDWOZGWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTUHEKOZA.gif]
|
Describe the bug
Auto-tunneling does not work reliably: Over night internet access gets unreachable and in the morning I need to reconnect manually to my WG VPN server; the option "Restart on ping fail (beta)" is activated.
Smartphone (please complete the following information):
Additional context
My WG VPN server runs in my local home network, connected via a DSL connection to the internet. Every night the connection gets reset by the internet provider and a new IPv6 address gets assigned to the server. I suspect this to be the reason for the disconnect of the WG tunnel.
The WG VPN server gets its own FQDN hostname via an DynDNS server; the associated IPv6 address gets updated after each reset; thus my VPN server is reachable via its associated hostname
The text was updated successfully, but these errors were encountered: