Project

General

Profile

Actions

Bug #13140

closed

Cisco-AVPair - anchor entries incomplete / GUI and command line show different results

Added by Michael Mercier 3 months ago. Updated 3 months ago.

Status:
Not a Bug
Priority:
Normal
Assignee:
-
Category:
OpenVPN
Target version:
-
Start date:
Due date:
% Done:

0%

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

Description

pfSense+ version 22.01 on Netgate 7100 1u

I have run into an issue where users connecting to OpenVPN using a RADIUS backend for authentication/authorization are not having the correct rules installed in pf when the RADIUS server responds using Cisco-AVPair(s).

As an example, I have the following Cisco-AVPair response configured in Freeradius

Cisco-AVPair += "ip:inacl#1=permit udp host {clientip} host 10.100.0.1 eq 53" 
Cisco-AVPair += "ip:inacl#2=permit ip host {clientip} host 10.100.0.1" 
Cisco-AVPair += "ip:inacl#5=permit tcp host {clientip} host 10.120.0.1 eq 22" 
Cisco-AVPair += "ip:inacl#230=permit ip host {clientip} host 10.121.0.0 0.0.0.255" 
Cisco-AVPair += "ip:inacl#100=permit ip host {clientip} host 10.122.0.0 0.0.0.255" 
Cisco-AVPair += "ip:inacl#1000=permit ip host {clientip} host 10.123.0.0 0.0.0.255" 
Cisco-AVPair += "route=10.0.0.0 255.0.0.0",
Cisco-AVPair += "route=172.16.0.0 255.240.0.0",
Cisco-AVPair += "route=192.168.0.0 255.255.0.0" 

NOTE: The above is dynamically generated based on LDAP group membership.

When the user (user100) connects to OpenVPN, I see the following:

  1. Status -> OpenVPN -> Click the i for user100
    All the above rules are listed correctly
  2. [22.01-RELEASE][root@host] more /tmp/ovps_ovpns1_user100_1194.rules
    All the above rules are listed correctly
  3. [22.01-RELEASE][root@host] pfSsh.php plyaback pfanchordrill
    Only some of the rules from above are listed
  4. [22.01-RELEASE][root@host]/tmp: pfctl -a openvpn/ovpns1_user100_1194 -s rules
    The output is the same as the pfSsh.php plyaback pfanchordrill for the specific user

This could possibly be related to:
https://redmine.pfsense.org/issues/12982

Actions #1

Updated by Michael Mercier 3 months ago

At lease one other thing I have noticed while trying to debug the issue:

  1. The file(s) containing the 'route' options for the users are not being removed from the '/tmp' directory.
    e.g. The file '/tmp/user100' is never deleted once the user has connected to OpenVPN at least once.
Actions #2

Updated by Michael Mercier 3 months ago

As I do a little more digging...

Once a user who is not receiving the correct rules has connected, from the command line attempt the following:

pfctl -a openvpn/ovpns1_user100_1194 -F rules
pfctl -a openvpn/ovpns1_user100_1194 -s rules

<empty output>

cat ovpn_ovpns1_user100_1194.rules | sed s/{clientip}/<ip address>/g' | pfctl -a openvpn/ovpns1_user100_1194 -f -
pfctl -a openvpn/ovpns1_user100_1194 -s rules

<output with rules missing>

Another question:
I am seeing '<__automatic_XXXXXXXX_0>' as part of the output for users with problems.

https://mwl.io/archives/1049 claims that these are pf tables, but if I try to find one:

pfctl -t __automatic_b7dd7ebe_0 -T show

pfctl: Table does not exist

It seems that some of my rules are being put into a table, but that table doesn't exist?

Thanks

Actions #3

Updated by Jim Pingle 3 months ago

Please show the actual contents of the rules file and the contents of the `pfctl` output for the anchor. You can substitute the IP address but we need to see the full content in question here to speculate about what might be causing it.

Actions #4

Updated by Michael Mercier 3 months ago

Output below, if there is something additional you need please let me know.

[22.01-RELEASE][root@host]/tmp: more ovpn_ovpns1_user100_1194.rules
pass in quick on ovpns1 inet proto udp from 172.30.8.2 to 172.30.8.1 port = 53
pass in quick on ovpns1 inet proto tcp from 172.30.8.2 to 192.168.1.204 port = 80
pass in quick on ovpns1 inet proto tcp from 172.30.8.2 to 192.168.138.13 port = 443
pass in quick on ovpns1 inet proto tcp from 172.30.8.2 to 192.168.138.13 port = 2222
pass in quick on ovpns1 inet from 172.30.8.2 to 10.200.10.0/24
pass in quick on ovpns1 inet from 172.30.8.2 to 10.200.20.0/24
pass in quick on ovpns1 inet from 172.30.8.2 to 10.200.30.0/24
pass in quick on ovpns1 inet from 172.30.8.2 to 10.200.40.0/24
pass in quick on ovpns1 inet from 172.30.8.2 to 192.168.144.0/20
pass in quick on ovpns1 inet from 172.30.8.2 to 192.168.1.244
pass in quick on ovpns1 inet from 172.30.8.2 to 10.10.2.0/24
[22.01-RELEASE][root@host]/tmp: pfctl -a openvpn/ovpns1_user100_1194 -s rules
pass in quick on ovpns1 inet proto tcp from 172.30.8.2 to 192.168.138.13 port = https flags S/SA keep state
pass in quick on ovpns1 inet proto tcp from 172.30.8.2 to 192.168.138.13 port = 2222 flags S/SA keep state
pass in quick on ovpns1 inet proto tcp from 172.30.8.2 to 192.168.1.204 port = http flags S/SA keep state
pass in quick on ovpns1 inet proto udp from 172.30.8.2 to 172.30.8.1 port = domain keep state
pass in quick on ovpns1 inet from 172.30.8.2 to <__automatic_36199b31_0> flags S/SA keep state
[22.01-RELEASE][root@host]/tmp: pfctl -t __automatic_36199b31_0 -T show
pfctl: Table does not exist.
[22.01-RELEASE][root@host]/tmp:

It looks like the entries are added to the anchor until I hit a subnet.

Actions #5

Updated by Jim Pingle 3 months ago

I suspect it's using a table to simplify those last few and you aren't dumping the contents like it expects:

Try:

: pfctl -a openvpn/ovpns1_user100_1194 -t __automatic_36199b31_0 -T show
Actions #6

Updated by Michael Mercier 3 months ago

Ahh... see output below.

So the end result of all this is that I put the wrong IP entries in the Cisco-AVPair response! I didn't notice until the output below. I apologize for the noise! Everything is working as expected. Please close the ticket.

[22.01-RELEASE][root@host]/tmp: pfctl -a openvpn/ovpns1_user100_1194 -sTables 
__automatic_82dbb93_0
[22.01-RELEASE][root@vhost]/tmp: pfctl -a openvpn/ovpns1_user100_1194 -t __automatic_82dbb93_0 -T show
   10.10.2.0/24
   10.200.10.0/24
   10.200.20.0/24
   10.200.30.0/24
   10.200.40.0/24
   192.168.1.244
   192.168.144.0/20
[22.01-RELEASE][root@host]/tmp:
Actions #7

Updated by Jim Pingle 3 months ago

  • Status changed from New to Not a Bug
  • Priority changed from High to Normal

No worries, there were recent changes in that code so it was entirely possible there was a gremlin lurking there. Glad to see it wasn't, though!

Actions #8

Updated by Jim Pingle 3 months ago

Michael Mercier wrote in #note-1:

At lease one other thing I have noticed while trying to debug the issue:

  1. The file(s) containing the 'route' options for the users are not being removed from the '/tmp' directory.
    e.g. The file '/tmp/user100' is never deleted once the user has connected to OpenVPN at least once.

This is worth a separate Redmine entry to fix, though. It shouldn't be leaving files behind like that.

Actions #9

Updated by Viktor Gurov 3 months ago

Jim Pingle wrote in #note-8:

Michael Mercier wrote in #note-1:

At lease one other thing I have noticed while trying to debug the issue:

  1. The file(s) containing the 'route' options for the users are not being removed from the '/tmp' directory.
    e.g. The file '/tmp/user100' is never deleted once the user has connected to OpenVPN at least once.

This is worth a separate Redmine entry to fix, though. It shouldn't be leaving files behind like that.

see #13145

Actions

Also available in: Atom PDF