Kill OVPN client connection

Gil

Update to 2.4.3; the error message no longer occurs - but the OVPN Connection does not get killed.
Still a bug

Gil

The "Error occurred" pop-up on the dashboard is caused by a race condition where the widget is requesting status from a resource that no longer exists. Annoying no doubt but it should not affect functionality.

Fixed in the next snapshot

The error message is "fixed", but the ability to kill the OpenVPN Connection remains non-functional.

Raffi_

I tried killing a remote client that forgot to disconnect. The GUI appears to kill the connection but according to the logs, the client automatically logs back in.
I don't think it matters but, I'm not having luck with killing the connection via SSH. The kill command with common name or source IP:port both give me the following message,
kill: Arguments should be jobs or process id's.

My bigger concern is that I added this user's certificate to a revocation list, killed the connection via GUI and it's still reconnecting. I hope I'm doing something wrong.

Edit: My certificate revocation is working. I just forgot to add it to the list to the actual OpenVPN server setting.

Gil

@Raffi.:

I tried killing a remote client that forgot to disconnect. The GUI appears to kill the connection but according to the logs, the client automatically logs back in.

I'd suggest checking your client settings; does it contain "resolv-retry infinite" - The client will reconnect automatically.

Raffi_

@Gil:

@Raffi.:

I tried killing a remote client that forgot to disconnect. The GUI appears to kill the connection but according to the logs, the client automatically logs back in.

I'd suggest checking your client settings; does it contain "resolv-retry infinite" - The client will reconnect automatically.

Thanks Gil, I do see that in the client config. Can I address this on the server side rather than having to reissue new client configs? Also, how would I fix it? Would it be an advanced configuration option of "resolv-retry 0"?

Gil

@Raffi.:

Thanks Gil, I do see that in the client config. Can I address this on the server side rather than having to reissue new client configs? Also, how would I fix it? Would it be an advanced configuration option of "resolv-retry 0"?

I've not tried it because I always want the VPN connected. The 0 would indicate 0 seconds to be the time period that the client continues connection attempts.
Keep in mind that a remote client may not be contactable after this period; AND you will also need a means of establishing the VPN at some point.
If you have access to the client router, why not enable and disable the VPN client directly as needed?

Raffi_

I don't think the resolv-retry option is the answer in my case. According to the OpenVPN manual, it seems like that is a option is for resolving the hostname.
Here is the section on the option.

–resolv-retry n
If hostname resolve fails for --remote, retry resolve for n seconds before failing.
Set n to "infinite" to retry indefinitely.

By default, --resolv-retry infinite is enabled. You can disable by setting n=0.

I don't think I have a hostname resolution issue. The client connects to the server via IP address in my case so I don't believe it has anything to do with hostname resolution.

I know there must be an option for this on the OpenVPN server side I can configure which would be pushed to all clients. I just don't know what that option is or how to set it up properly.

Pippin

The client needs to stop the connection by itself.
There is no function/directive/command on server side that i know of to stop a client from auto reconnecting.
The kill command`s purpose is for reconnecting a client whose client specific override was modified.
You could however revoke the client certificate and then kill the connection after which the client can no longer reconnect.

The commercial version OpenVPN Access Server can shut the client down based on total transfered bytes over time but that`s not any help off course.

Raffi_

Thanks Pippin, I was able to use the method you mentioned to revoke the cert and then kill the connection. I confirmed that works. I thought there might be a way to disable automatic reconnects. I guess even if it was possible, doing so could cause more harm than good since the connection could get lost in a normal use case and the user would want it to automatically reconnect.

maxpfs

It might be I have found either the reason or the similar bug. I was not able to kill client after switching from udp4 to multihome. If I change multihome back to udp4 I can kill client again.

pfs 2.4.3.

maxpfs

Has anyone tried to reproduce the bug?