Bug #13140
closed
Cisco-AVPair - anchor entries incomplete / GUI and command line show different results
Added by Michael Mercier over 2 years ago.
Updated over 2 years ago.
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
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.
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
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.
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.
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
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:
- 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!
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.
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
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by Viktor Gurov