Project

General

Profile

Actions

Bug #11699

closed

OpenVPN does not clean up parsed ``Cisco-AVPair`` rules on non-graceful disconnect

Added by Viktor Gurov 7 months ago. Updated about 2 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
OpenVPN
Target version:
Start date:
03/18/2021
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
21.05
Release Notes:
Default
Affected Version:
Affected Architecture:

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.

Actions #1

Updated by Jim Pingle 7 months 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

Actions #2

Updated by Viktor Gurov 7 months 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

Actions #3

Updated by Viktor Gurov 7 months 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

Actions #4

Updated by Viktor Gurov 7 months ago

Set default OpenVPN inactive timeout to 300:
https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/204

Actions #5

Updated by Jim Pingle 7 months ago

  • Status changed from New to Pull Request Review
  • Target version set to CE-Next
  • Affected Version deleted (2.5.0)
Actions #6

Updated by Jim Pingle 6 months ago

  • Plus Target Version set to 21.05
Actions #7

Updated by Steve Beaver 6 months ago

  • Status changed from Pull Request Review to Feedback
Actions #8

Updated by Jim Pingle 6 months 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.

Actions #9

Updated by Jim Pingle 5 months ago

  • Target version changed from CE-Next to 2.5.2
Actions #10

Updated by Jim Pingle 5 months ago

  • Status changed from Feedback to Closed
Actions #11

Updated by Viktor Gurov 5 months 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

Actions #12

Updated by Renato Botelho 4 months ago

  • Assignee set to Viktor Gurov
Actions #13

Updated by Marcos Mendoza about 2 months ago

  • File playback_output.txt added
  • File active_users.txt added
Actions #14

Updated by Marcos Mendoza about 2 months ago

  • File deleted (active_users.txt)
Actions #15

Updated by Marcos Mendoza about 2 months ago

  • File deleted (playback_output.txt)
Actions #16

Updated by Marcos Mendoza about 2 months ago

Moved possibly related issue to #12332

Actions

Also available in: Atom PDF