How to kill clients from the server side.

  • Hi, I’m trying to find a way to kill connection from the Pfsense side.  I tried to use “inactive” command, but idle clients seem to transmit packets all the time even when users are not using workstations. Also tried to play with “ping-restart” and “ping-exit”. Is there a way to stop client from re-connecting when I press “kill client connection”? When someone forgets to close the session from home workstation and then trying to connect from different location I can’t do anything. Thanks.

  • Banned

    Block the IP in firewall?

  • @doktornotor:

    Block the IP in firewall?

    That is very "dirty" solution to the problem imo. There is another reason I would like to do it, currently I have rang of 9 IP addresses assigned for OpenVPN and when people forget to disconnect there is no "space" for other users.

  • Banned

    We, so raise the limit to more than 9? Really dunno which miracle solution are you expecting. You cannot disable the user itself obviously when your concern is that they cannot connect from another place.

  • Sorry, I don't understand your aggressive post. There is a reason for number of connections, rising that number is not a solution but workaround. I can do that but first I would like to find a better way to do it. If it exists.

  • Banned

    Since, as you already determined, your allegedly "inactive" clients are not really inactive and they keep reconnecting anyway. So, you can either block the traffic, or disable the user account or whatever depending on what kind of authentication you are using. So, you dislike the former and cannot do the latter since your goal is not disabling the user. You also do not want to raise the number of allowed connections either for unspecified reason.

    So - open a window and scream "It suxxxxxxxx!!!"…

  • I can see how you manage to have an average 5 posts per day… ::)

    What I don't want to do is:

    • rise the number of connection
    • disable users
    • block the traffic in firewall

    What I want to do is:

    • prevent clients from reconnecting, when killed from gui.

    I have no idea why inactive user is generating traffic, I've tested it, you can connect to VPN, lock the workstation, go for a beer and "Bytes Sent/Bytes Received" keep growing.

  • LAYER 8 Global Moderator

    so you kill the connection in gui, so why would the remote client not just reconnect?

    So you kill the client, when do you want them to be able to reconnect?  Ever, in 24 hours - what?

    What sort of connections does the client create through the vpn?  Window clients are noisy by nature, they will always be sending stuff out of their interfaces normally.  Do they have mapped drives, there will be discovery stuff like SSDP, announcements for computer browsing service, etc.  how much traffic are you seeing on these "idle" connections?

  • If I could I'd like them never reconnect automatically, ideally user would have to press reconnect or log in again. I just tested, clean installation of Windows, no mapped drive:

    Connected Since             Bytes Sent         Bytes Received
    Fri Jun 12 13:42:28 2015        1.83 MB                     270 KB

  • Netgate Administrator

    I'm not really sure what you could do here. Anything you do to block the client connecting  is going to stop them connecting again which is what you want to avoid.
    You could perhaps use scheduled rules to block specific clients at night for example. OR scheduling in the authentication maybe.
    I assume you want to be able to somehow disconnect the VPN such that the users then need to manually reconnect? That sounds like it might be a setting on the client side, disable 'auto-reconnect' or similar. It might cause more problems than it's worth though.  ;)

    Edit: You answered some of that while I was typing!


  • you could try to insert the following in your client configs (it might prevent credentials from being cached and might theoretically stop auto-reconnects)


  • OK, I found the solution, that was my lack of knowledge I suppose. What I did:

    • edited server1.conf and removed "keepalive 10 30"
    • pushed "ping-exit 10" to the clients

    Now after 10 seconds from pressing "kill client connection" I can see "connection to XXX was terminated" on the user worksation.

  • @Naicc:

    • edited server1.conf and removed "keepalive 10 30"

    Don't do that. It'll be overwritten, and that part is unnecessary for the ping-exit.


    • pushed "ping-exit 10" to the clients

    Now after 10 seconds from pressing "kill client connection" I can see "connection to XXX was terminated" on the user worksation.

    That works, though it'll potentially be an annoyance for users in that it won't reconnect on its own if there is a temporary loss of connectivity. Not a big deal if the clients are behind reliable Internet connections, but could be very annoying if some of those users are at a hotel or coffee shop or something where connectivity may be a bit spotty from time to time.

  • What do you mean by "overwritten"? I just added it back and client is restarting connection on it's own as before. I've tried ping-exit on its own first place but it wasn't working. So I created this thread. As for second part we have 2 servers one for mobile users with 30+ concurrent connections.

  • Netgate Administrator

    The conf file is created by the webgui php scripts whenever you make changes to the OpenVPN server. So if you edit the conf file directly any changes you make to it will be lost the next time you make a change via the webgui.
    Try to use the advanced settings box in the webgui to make any changes that aren't directly covered. Though I'm unsure quite how you might make this particular change if it's already included.


  • So is there no way to permanently remove 'keepalive' from the server side? I rarely make changes to OpenVPN settings, I would have to remember to hash that line every time, it's not perfect but doable.

  • Banned


  • I guess I could just add # to "$conf .= "keepalive 10 60\n";" to minimize risk of breaking it. Thanks doktornotor ;)

  • Banned

    You'd better use //

  • I was thinking about something like that:

    $conf .= "#keepalive 10 60\n";

    So it would be "delivered" to config in offline state?

  • Banned

    No… Please read how to produce comments in PHP!

  • Netgate Administrator

    Hmm, I could be mistaken, I'm no coder, but that looks right if he wants to produce a conf file with that line commented out.


  • Banned

    So, you want

    #user nobody
    #group nobody
    script-security 3
    #keepalive 10 60

    in serverX.conf ? Yeah that'd work, just don't see the point.

  • Maybe just for the future reference for somebody who will take over from me,  would be easier to for him to spot hash in temp config file. That is basically same thing we can do in 2 different ways. I can't really say which one is better  ;)

    Thanks to everybody in a thread , that is what I was looking for!

    I edited one thing I changed 'ping-exit' from 10 (seconds) to 25 as it will actually disconnect the client if he is slow with typing username/password. But 25 seconds should be plenty to do that.

  • Came across this looking after finding that the VPN client (OPENVPN ios) stayed connected after I disconnected the user connection from status>OpenVPN by hitting the X next to their connection. I expected the behavior the original post was describing and was puzzled why it not only showed on the client that it was still connected, but also why after attempting to access a resource located behind the VPN connection that it connected back up and worked. Rather than disabling account or trying to change the timeout/reconnect options, I found the best way to have this control to disconnect a session is to set up authentication to another directory (Ldap) and filter approval based upon group membership (memberOf). This way one can remove the account from the LDAP group, then click the X to close the client vpn session from the server side. The client then tries to (automatically) reconnect and fails based on authentication. I found that this is the only clean way to have administrative control over the client vpn session apart from disabling the entire user account or disabling the VPN server itself.



Log in to reply