how to stop openvpn and get 'normal' public ip back?


I have a vpn account with that I use for anonymity/security

I connect to their server(s) by running:

openvpn /etc/openvpn/vpnclient.conf

vpnclient.conf looks like this:

dev tun
proto udp
remote 1194
resolv-retry infinite

user nobody
group nobody

ca /etc/openvpn/ca.crt
auth-user-pass /etc/openvpn/
ns-cert-type server
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

Can anyone help?

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.

cheers for the reply Miuku

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

ecky@linux:~> ps -au | grep openvpn
root     29604  0.0  0.0  92688  6828 pts/0    S    18:51   0:00 sudo **openvpn** /etc/**openvpn**/vpnclient.conf
nobody   29606  0.2  0.0  45484  6832 pts/0    S    18:51   0:00 **openvpn** /etc/**openvpn**/vpnclient.conf
ecky     29638  0.0  0.0  10540  1620 pts/0    S+   18:56   0:00 grep --color=auto **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

I’m surprised that a commercial VPN provider can’t or doesn’t switch networks automatically and completely by itself.

In any case, after stopping your openvpn service, you should be able to reset your network by restarting your network service, eg with the following

systemctl restart network


Thanks for tsu2

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

Sorry I was bad at explaining things :slight_smile:

Let’s imagine you have a setup like this;

You have a file where you store all your configuration, called; /etc/openvpn/server.conf

To start / stop or restart this openvpn connection, you would use;

systemctl start openvpn@server

If you had another configuration for another service in /etc/openvpn/ called myisp.conf, you would use:

systemctl start openvpn@myisp

Catch what I’m explaining here? The openvpn@configfile refers to your /etc/openvpn/ configuration files, minus the .conf at the end.

Note: this won’t fix anything if you run openvpn manually instead of using the systemd service file to connect.

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.

SDB: OpenVPN Installation and Setup


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?

dig +short

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

If only I’d found that information some days ago!

Yes, it can really have been only an ISP-related issue, (which is why I was wondering about your focus on the VPN client).

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

So it’s all good now :wink:

Thanks to those who tried helping me