Bug #11699
closed
OpenVPN does not clean up parsed ``Cisco-AVPair`` rules on non-graceful disconnect
0%
Description
There is a difference between a graceful and not graceful disconnect. We tested it last night where I just turn off my WiFi adapter, then disconnected from VPN when logged in as TEST1 (with TEST1 related Cisco-AVPair ACLs). If I turned my WiFi adapter on and log in as my account with IT access, I get TEST1 access. However, if I disconnect my account, then log in as TEST1, click the disconnect, and log back into VPN using my account again, it appears to work.
It definitely seems like the VPN server hangs on to the account that didn't "gracefully" disconnect.
Updated by Jim Pingle about 3 years ago
According to the OpenVPN docs and other posts I see, the disconnect script should be run even on ping timeout / unclean disconnects, so perhaps there is something else amiss here.
There was one user who said it didn't work in some cases, but it's an old post and they didn't follow up if they were ever able to resolve it: https://forums.openvpn.net/viewtopic.php?t=21869
Updated by Viktor Gurov about 3 years ago
Jim Pingle wrote:
According to the OpenVPN docs and other posts I see, the disconnect script should be run even on ping timeout / unclean disconnects, so perhaps there is something else amiss here.
There was one user who said it didn't work in some cases, but it's an old post and they didn't follow up if they were ever able to resolve it: https://forums.openvpn.net/viewtopic.php?t=21869
It works
After connecting:
# pfctl -a openvpn/ovpns1_raduser1_5558 -sr pass in quick on ovpns1 inet proto udp from 3.3.3.3 to 7.7.7.7 port < 566 no state pass in quick on ovpns1 inet proto udp from 3.3.3.3 to 7.7.7.7 port != 899 no state
Disconnect by timeout (inactive 100):
Mar 18 20:02:40 pf41 openvpn[76775]: TCP/UDP: Preserving recently used remote address: [AF_INET]192.168.88.42:1194 Mar 18 20:02:40 pf41 openvpn[76775]: UDPv4 link local (bound): [AF_INET]192.168.88.41:0 Mar 18 20:02:40 pf41 openvpn[76775]: UDPv4 link remote: [AF_INET]192.168.88.42:1194 Mar 18 20:03:40 pf41 openvpn[76775]: Inactivity timeout (--ping-restart), restarting Mar 18 20:03:40 pf41 openvpn[76775]: SIGUSR1[soft,ping-restart] received, process restarting Mar 18 20:03:42 pf41 openvpn[60506]: CA41client/192.168.88.5:5558 Inactivity timeout (--inactive), exiting
Result:
# pfctl -a openvpn/ovpns1_raduser1_5558 -sr pfctl: DIOCGETRULES: Invalid argument
Updated by Viktor Gurov about 3 years ago
I think it is better to set the inactive timeout to the default value (like 300 seconds) for new instances
to cleanup ACL and DNS entries for non-graceful disconnected clients
Updated by Viktor Gurov about 3 years ago
Set default OpenVPN inactive timeout to 300:
https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/204
Updated by Jim Pingle about 3 years ago
- Status changed from New to Pull Request Review
- Target version set to CE-Next
- Affected Version deleted (
2.5.0)
Updated by Anonymous almost 3 years ago
- Status changed from Pull Request Review to Feedback
Updated by Jim Pingle almost 3 years ago
- Subject changed from OpenVPN doesn't cleanup parsed Cisco-AVPair rules on non-graceful disconnect to OpenVPN does not clean up parsed ``Cisco-AVPair`` rules on non-graceful disconnect
Updating subject for release notes.
Updated by Jim Pingle almost 3 years ago
- Target version changed from CE-Next to 2.5.2
Updated by Jim Pingle almost 3 years ago
- Status changed from Feedback to Closed
Updated by Viktor Gurov almost 3 years ago
This is not enabled for new servers created by the Remote Access Wizard.
fix:
https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/280
see also #11684#note-7
Updated by
Updated by Marcos M over 2 years ago
- File playback_output.txt added
- File active_users.txt added