Bug #13140
closed
Cisco-AVPair - anchor entries incomplete / GUI and command line show different results
0%
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:
- Status -> OpenVPN -> Click the i for user100
All the above rules are listed correctly - [22.01-RELEASE][root@host] more /tmp/ovps_ovpns1_user100_1194.rules
All the above rules are listed correctly - [22.01-RELEASE][root@host] pfSsh.php plyaback pfanchordrill
Only some of the rules from above are listed - [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
Updated by Michael Mercier over 2 years ago
At lease one other thing I have noticed while trying to debug the issue:
- 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.
Updated by Michael Mercier over 2 years 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
Updated by Jim Pingle over 2 years 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.
Updated by Michael Mercier over 2 years 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.
Updated by Jim Pingle over 2 years 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
Updated by Michael Mercier over 2 years 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:
Updated by Jim Pingle over 2 years 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!
Updated by Jim Pingle over 2 years ago
Michael Mercier wrote in #note-1:
At lease one other thing I have noticed while trying to debug the issue:
- 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.
Updated by Viktor Gurov over 2 years 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:
- 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