You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
VPN is set to connect on boot. I was at hotel over the weekend and i was unable to connect to the wifi. Its one of those hotel wifi's that has no password but when you connect to it. It takes you to a hotspot login panel, confirms some details then gives you network access.
This feature is controlled by local DNS. However as the local DNS was being overridden by the non functional Wireguard DNS. It never loaded up the page for me to type in my details so remained on no internet. Manually disabling the VPN and retrying to my connection to the hotel wifi worked.
I can also see this being a issue on other public hotspots. My suggestion as a fix to this is below.
When the client first loads. Perform a network connection check. If connectivity is not available then delay the VPN connection for 30s and repeat. This way the VPN will not interfere with any odd network setups users might have. Also if during a live connection the network drops. Pause the VPN till the network connection is back up at least from a DNS perspective.
In a ideal world. the client should confirm it is able to establish a connection to the wireguard server prior to attempting any connection. I use a enterprise VPN for work so im going to do some digging to see what method they use to identify hotspot / guest networks as i didn't have a issue when using my work laptop. I believe they use the logic i have described above.
This caveat to this solution is the potential for increased resource consumption. If this ability can be integrated within WireSock instead of TunnlTo then we have a solution that's much closer to kernel and therefore can have logic thats efficient.
Having studied network engineering for 4 years. I hate how often the term its always DNS ends up being accurate haha
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I came across a odd one.
VPN is set to connect on boot. I was at hotel over the weekend and i was unable to connect to the wifi. Its one of those hotel wifi's that has no password but when you connect to it. It takes you to a hotspot login panel, confirms some details then gives you network access.
This feature is controlled by local DNS. However as the local DNS was being overridden by the non functional Wireguard DNS. It never loaded up the page for me to type in my details so remained on no internet. Manually disabling the VPN and retrying to my connection to the hotel wifi worked.
I can also see this being a issue on other public hotspots. My suggestion as a fix to this is below.
When the client first loads. Perform a network connection check. If connectivity is not available then delay the VPN connection for 30s and repeat. This way the VPN will not interfere with any odd network setups users might have. Also if during a live connection the network drops. Pause the VPN till the network connection is back up at least from a DNS perspective.
In a ideal world. the client should confirm it is able to establish a connection to the wireguard server prior to attempting any connection. I use a enterprise VPN for work so im going to do some digging to see what method they use to identify hotspot / guest networks as i didn't have a issue when using my work laptop. I believe they use the logic i have described above.
This caveat to this solution is the potential for increased resource consumption. If this ability can be integrated within WireSock instead of TunnlTo then we have a solution that's much closer to kernel and therefore can have logic thats efficient.
Having studied network engineering for 4 years. I hate how often the term its always DNS ends up being accurate haha
Beta Was this translation helpful? Give feedback.
All reactions