client
dev tun
proto udp
remote server.privateinternetaccess.com 1194
resolv-retry infinite
nobind
user nobody
group nobody
persist-key
persist-tun
ca /etc/openvpn/ca.crt
auth-user-pass /etc/openvpn/user.info
ns-cert-type server
comp-lzo
verb 3
I connect to the server(s) with no issues whatsoever, the problem I have is stopping the connection and getting my ‘normal’ isp assigned public ip address
Openvpn doesn’t start as a service the way I’m using it, at least it doesn’t show up in ‘systemctl list-units’ so the only way I’ve found that I can stop openvpn when it’s running is: kill [pid number]
What happens though is the ip address the vpn server assigns me doesn’t get ‘dropped’, when I stop openvpn I’m still using the ip assigned to me by the vpn
At present I’m only able to get my ‘normal’ ip back by rebooting the computer, there must be a way to disconnect from the vpn server and get my ‘real’ ip but have been unable to find anything on this after many web searches, nothing on it in the openvpn docs that I can find either
OpenVPN now supports multiple clients and configurations, so if your configuration is named woot.conf, the systemd file would also follow that naming convention, f.ex:
systemctl status openvpn@woot
This also means you can use it to launch the actual openvpn instance;
systemctl start openvpn@woot
And stop it with the normal stop command. This should be the ‘least obstrusive’ way of using openvpn.
I tried systemctl list-units to find out what the openvpn service shows as so that I could try stopping it with systemctl but openvpn doesn’t show in there at all when I have it running
It also doesn’t show when I do systemctl -a, whether openvpn is running or not
As it isn’t there I don’t know what appears after the @ in openvpn@woot, I don’t know how else to find that out other than the systemctl list-units and/or systemctl -a commands
I do see these processes when I do ps -au | grep openvpn
Isn’t of much help, just confirms that openvpn is actually running when Im trying the systemctl commands, as per the config file it runs as user nobody and group which explains the root and nobody entries
However I’ve tried and yes the network restarts ok, but my public ip doesn’t change
I.E my public ip is still that provided by my vpn provider and not the one provided by my isp
I'm surprised that a commercial VPN provider can't or doesn't switch networks automatically and completely by itself.
What I don’t get about this is, as I understand it, when I stop openvpn I ‘should’ no longer be connected via their vpn server
When I start openvpn it creates a connection called: tun0 and when the tun0 adapter gets ‘taken down’ it should be impossible to connect through it
The behaviour is almost as if I’m still connected via their server in that my public ip is still theirs, and what puzzles me is that my internet still works even though there should be no route through their server
I don’t see how it’s possible for there to still actually be a connection to their server when both the openvpn service and the tun0 adapter are no longer active, which leads me to think that either my system isn’t doing something it should be in order to revert my ip back to my ‘normal’ one when openvpn is stopped, or there’s something it needs to be made to do in order to achieve that (something in my vpnclient.conf file maybe?)
I don’t know what’s supposed to happen ‘under the hood’ when one disconnects from or stops openvpn so I can’t really check what’s going on
I can only suspect that you’re not killing the OpenVPN app/process properly when you kill the Pid (systemd can spawn child processes, maybe you’re killing a child process and not the apex parent process).
The following SDB: OpenVPN was updated as recently as late last year, so it should be current. I highly recommend you remove what you’ve configured and setup following the steps in the article. You’ll properly set up implementing a systemd Unit file, which means that you should expect to properly stop/start it using common systemctl commands.
Cheers for the link tsu2, about to head out for work so will look when I get home
I am definitely killing any and all openvpn processes though … especially when I shut the machine down completely
That definitely killed all processes, and openvpn does not run on startup when the machine boots, so I don’t think it’s a case of openvpn still running
Had a look at the SDB, only a couple of things differed from what I had, these being:
script-security 2 <— I didn’t have that, added now
#resolv-retry infinite <— SDB doesn’t mention that, but I’d previously disabled that one anyway because I wondered if that might be contributing to my ip being ‘locked’ to the vpn one
verb 3 <— SDB doesn’t mention that, I have it in there so I can see the msgs whilst I’m having this issue, will comment it out later
remote-cert-tls server <— SDB says to use that but the connection is very slow and unstable if I use that option
ns-cert-type server <— so I use that, connection is then fast and stable, it’s also the line that’s in the account provider’s sample config
So, the only difference in what the SDB suggests you have in your config file to what I have in mine is the line script-security 2
Still have the issue with my public ip being ‘stuck’ at the vpn one, I am going to try turning my isp router off for a while tomorrow, long enough for them to recycle my ip in the hopes that may change something
Turned off my broadband router and shut the computer with this issue down for 3 hours yesterday, still no change
I know it’s a bit of a drastic step to fix just one small issue in an otherwise working system but I’ve been starting to think I might as well just wipe the system and reinstall it
I’m struggling to get a handle on this. Your public IP address is the one your router gets from your ISP. That won’t change just because you started a VPN connection though. When you drop the VPN connection, how are you determining the public IP address in use?
For example, what is reported by the following before the VPN connection, during the VPN connection, and after the connection has been deactivated again?
I’ve done a bit more research and discovered it’s an issue with my isp that a number of their other customers are experiencing and the consensus seems to be that requesting a static ip from them fixes it
Never had this issue before deano, completely baffled me tbh
Then it occurred to me that I hadn’t been using openvpn for this account since a recent isp change due to moving to a different area, so I started searching for people on the same isp having the same issue and discovered a lot of other customers had the same issue
I’ve also switched from using udp to using tcp which seems much more stable so far
