I'd previously added lines to the end of my config files to bypass the VPN for certain connections, including
Code: Select all
route 192.168.1.1 255.255.255.255 net_gateway #LAN
Unfortunately, every time my computer would lock (not logoff or sleep, just lock), which it likes to randomly do on its own fairly often when idle, even for a short time, it would get disconnected. I'm not sure if the Wi-Fi connection is disconnecting, making it a Windows issue, or if OpenVPN is, making it an issue with that, but I suspect it's OpenVPN. I also found that after this happened, even after reconnecting, everything went to s*** (programs and Windows stopped responding, and even Task Manager wouldn't open), and I had to reboot to get things working again. After some more tinkering, I discovered that after it happened, VeraCrypt took forever to load an encrypted container file and even longer to decrypt/open and then close it. So some more troubleshooting led me to find that opening file explorer to "This PC" where it lists the drives, the mapped drive I had set up (one of the drives connected to R2, the one with the VeraCrypt container on it) was no longer displaying the bar showing the used space, and accessing the drive took far longer than usual. Once I disconnected from the VPN, the used space bar showed up, the drive opened immediately, and VeraCrypt worked normally again. At this point, it occurred to me I hadn't added R2's IP as an excepted route in the config file, so it must be going through the VPN, which was causing the file transfers to break when the VPN disconnected. So I added it, restarted OpenVPN, and everything started working properly (drive displayed properly and opened quickly in file explorer and VeraCrypt accessed and opened the file quickly) and I haven't had any more issues with my file transfers, until now...
When adding R2 to the config file, I did 192.168.0.* and 192.168.1.* just to avoid having similar issues in the future. Then I thought, why not just do 192.168.*, though I wasn't sure if it would work. So I decided to remove the LAN routes, test to make sure I was having problems again, then add 192.168.* and see if they went away. And that's when the latest problem started, which is that even with them removed, everything was still working fine. So at this point, I have a list of questions:
1) How broad can the wildcards be, and in what format, i.e. would 192.168.* work, or would it have to be 192.168.*.*? Or does it even support wildcards? Because I thought I removed the 192.168.0.101 and just had 192.168.0.* after which I didn't have any more issues, but I just tried adding 192.168.0.* again and it wasn't showing in the status, then when I changed the * to 101 it showed.
2) Assuming that's possible, is it even a good idea (to except an entire subnet or more (192.168.*), or is it asking for trouble somehow?
3) If I have 192.168.0.1 excepted, and I get on a public Wi-Fi which uses that for it's IP, does that mean I'm unprotected between me and the router and other devices on the network, or does it only apply for direct connections to the router, i.e. can others on that network see and tamper with my data?
4) Sort of along the same lines, is it necessary to add each device on the network separately, or is adding the hub (router) enough. And what about the inverse? Basically, does it only bypass the VPN if the terminal IP is the one in the config file? It seems like it must, since otherwise by adding the router's IP anything going through it wouldn't go through the VPN, which clearly isn't the case.
5) Why was I able to access and login to R1 and R2 while connected to the VPN when I only had 192.168.1.1 excepted? And after removing all LAN exceptions?
6) Why would it be disconnecting when the computer is locked?
7) Why is Windows being completely wiped out when it disconnects during a file transfer?
8) Related to #7, why was I not having issues at first (namely that file explorer was properly displaying the drive's used space and the drive was quickly accessed by file explorer and VeraCrypt), despite not having it set up to bypass the LAN, and therefore going through the VPN for file transfers, then even after removing the exceptions those things worked fine, until it disconnected during a file transfer, at which point everything broke again? In fact, until that happened around the time I started this post, I was going mad trying to figure out why it seemed to still be bypassing the LAN even after removing the route exceptions (and I was quitting OpenVPN, saving the config file, then relaunching it, and even disconnected and reconnected the Wi-Fi and rebooted the computer).
9) Is the only thing necessary to get it to use the routes defined in the config file to reconnect? I wasn't sure, but looking at the status, it seems to reflect the changes just by doing that, in which case OpenVPN doesn't need to be exited and relaunched, correct?
10) After I set it back up with 192.168.0.101 (R2), and verified that was bypassed, I was still having issues. I figured it was because I was using net_gateway, which was sending it through 192.168.0.1 (R1), which wasn't bypassed, then back to R2, but it still seems it shouldn't have had any issues. I changed net_gateway to 192.168.0.101 and the problem went away. What exactly is going on with that?
I'm clearly misunderstanding bypass routing. On the one hand, I've needed to use it before to be able to do things over the network, and it's clearly getting in the way now when I don't have it done, but at the same time things still work without it being set up, they're just highly prone to breakage. Ultimately, it seems the primary issue here is that OpenVPN dropping the connection during a file transfer trashes everything, for whatever reason, and only then do I experience the other issues, and so the answer is to simply bypass the LAN and be done with it, but this whole mess just got me trying to figure out exactly how that works and why I was having issues when not bypassing it that went away when bypassing it then seemed to stay gone when removing the bypass, which made me think it was still bypassing it, though I'm guessing based on it breaking again that's not the case.