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
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…
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?
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.
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…
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.