Kill OVPN client connection
-
Small clip of the GUI behaviour
-
Hello,
I am receiving this same error message as well. I am running OpenVPN Remote-Access on pfSense 2.4.2. I am connected through my LAN, not through VPN. When also receive "An error occurred (-1)" when attempting to kill a connection. Tried on both the widget at Status -> OpenVPN. Also tried on IE and Chrome.
-
I did some tinkering on the "openvpn.inc" page, and found I was receiving "ERROR: Common Name (client IP) not found". When I changed the client IP to the username field, then I was able to kill the client. I am guessing this is the case because I use user certificates in which the username is the CN. Not sure if this is the case for the original poster.
-
I use user certificates in which the username is the CN. Not sure if this is the case for the original poster.
I also have matching CN & User Name
When I changed the client IP to the username field, then I was able to kill the client
Are you saying this is an IP address? Or simply some other text to identify a user?
-
@Gil:
Are you saying this is an IP address? Or simply some other text to identify a user?
There is a function on the file "openvpn.inc" called openvpn_kill_client(). It creates a TCP socket to the management port on the server, and then issues the command "kill {client IP}". When you click the "X" to kill a client on the OpenVPN widget or Status page, it is passing the user's public IP that they are using to connect to the VPN. I did some debugging and was receiving that Common Name does not exist. I knew that Common Name was the "username", as I enforce user certificates, which use the username as the Common Name field. So, for my case (and most likely yours), if we pass the username field instead of their public IP, it could kill the VPN connections.
-
Nice piece of debugging.
Is there something that the developers should note regarding this?
-
Will this bug be fixed in the next updates of pfSense?
-
Update to 2.4.3; the error message no longer occurs - but the OVPN Connection does not get killed.
Still a bug -
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.
-
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.
-
@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.
-
@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"?
-
@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? -
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.
-
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.
-
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.
-
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.
-
Has anyone tried to reproduce the bug?
