OpenVPN not disconnecting user

OpenVPN roadwarrior complainging that they cannot access mapped drives or RDP to terminal servers. Remoting to them and looking at router, its not disconnecting the client. The users laptop VPN is disconnected(rebooted laptop to make sure), but router still shows them connected. Now if I stop\start OpenVPN server it shows them as disconnected, and they can connect and work. When they disconnect, same issue, they still show as connected.

2nd IPfire router now doing the same thing. first one is on ver 196, 2nd on ver 186

Do you mean the connection icon visible in the status column?

yes, and the user cannot ping anything on the LAN. I have to disconnect client, then stop\start openvpn server, the it shows user disconnected, then they work fine next time remoting in…

edit

The indicator changes status if the client is disconnected for approximately 2.5 minutes.

On which operating system and which client are the issues you describe occurring?

Win11, OpenVPNgui 2.5.8

OpenVPN for Windows currently is version 2.6.15

Worth a shot to update the client, in my opinion.

1 Like

tried that, no good. strange it happened after updates and on two different routers…

This is a sanitized OpenVPN config file that I use and works “nicely” with… another Linux Distro.

client
tls-client
dev tun
persist-key
persist-tun
proto udp
auth-nocache
remote %remote_device_ip% %remote_port%  udp
auth-user-pass %the storage file%
comp-lzo
verb 3
mute 10
float

-----BEGIN CERTIFICATE-----
snip
-----END CERTIFICATE-----

Option comp-lzo should be avoided because currently in IpFire’s OpenVPN should be disabled as default, but mostly depends on your current setup.

Consider to share your sanitized configuration for help troubleshooting.

It should be avoided because it opens you up to a CVE registered vulnerability.

Also your client, if old enough, might do compression and OpenVPN-2.6.x will uncompress it but all traffic from OpenVPN servers since 2.5.x have not compressed at all, just added the compression headers.

If you are still using compress-lzo when openvpn-2.7 is released then it will no longer recognise the option as it has been deprecated for a long time and will be removed from openvpn in 2.7

Unfortunately I cannot test this as I don’t have any windows clients at all on my network.

With my Linux and Android clients, then after the client is disconnected the status I see always changes to Disconnected. It does take a while for it to be identified. The IPFire openvpn code checks the status every 30 seconds and the clients can tend to stay connected for a while in case they have had a temporary interruption.

My Linux client changes status within a minute but the Android client can take 2 to 3 minutes but does eventually show disconnected. I can also re-connect to the Android client again both after it shows it is disconnected but also while it is still showing connected but it no longer is connected and it has no problem reconnecting.

It looks like there must be some special issue with the Windows client and your network.

Have you edited the client networks to change things that were specified by IPFire’s OpenVPN code?

If you create a new client connection in your CU196 system and connect with that, do you still see the problem?

:thinking:

What should IPFire do if we uncheck (block) an active connection?

obraz

obraz

Exactly what you have shown.

The blue Disconnected means that the server has disconnected irrespective of whatever the client is trying to do.

Adolf, could you confirm whether the Linux client still has access to the internal network (e.g., green, blue, orange) of IPFire after such a block?

No it is disconnected by the server.

Core-Update 198 Development Build: master/87ee4f87
OpenVPN client 2.6.15 on Windows

After unchecking/blocking

obraz

After many minutes, the client still shows an active connection

obraz

and can connect to internal resources.

edit

The client showed similar behavior on Linux Mint 22.2.
NetworkManager 1.34.0

edit2

The IPFire server also did not close the connection with the Android client.
version 3.7.1(10568)

Okay, I confirm what you are showing.

I have looked at the code and also done some searching on client connections with openvpn and my previous statement was incorrect. The blue disconnected does not mean that the existing connection has been blocked or closed.

OpenVPN does not have any way to close an existing authenticated connection, other than restarting the server which drops all connections. There is no option capability to close a specific client connection.

Disabling the client connection in the WUI means that the client, if it disconnects, will not be able to re-connect but it is not able to close that existing authenticated connection.

1 Like

There is a way of closing connections using the management interface. I am not an OpenVPN user so I don’t know if this is enabled, and I think it needs to be on a separate port for each OpenVPN server instance.

@bonnietwin So this is a current issue with IPfire? The original post?

I’m thinking a temporary workaround is to use a cron job to stop\start OpenVPN server at end of the day??? Won’t help if someone connects and then tries to connect hours later…but should help in the meantime…

Thanks,

Brian

This is a problem if you have a client that is connected and accessing things and you want to disconnect them. Then you have to restart the openvpn-rw daemon but that will disconnect all your clients in one go.

Maybe the option mentioned by @nickh might be possible but I have no idea currently.

However the above seems different to the issue you are having, which is that a client has disconnected and can’t get access to the green network anymore but it still shows as connected on the ipfire server end even after 10’s of minutes. Also the client cannot connect again to the server.
I have never experienced that issue.
When you have a client that experiences this issue then I think you need to get the log file info from the client and also from the server, so we can see what communication is or isn’t occurring between the client and server. Also the logs should include the period when the client tries to reconnect but fails.

OpenV{N already creates a management socket, /var/run/openvpn.sock, but it hangs if I try to connect to it with socat. I believe it is a single user socket so, as IPF created it, I think IPF is using it and is, therefore, blocking it. This suggest to me that it is a bug when the OP cannot delete a connection with the dustbin icon, unless the client is immediately reconnecting.