Anchor rules

michmoor

Is there a way to clear anchor rules? I have the following

 pfSsh.php playback pfanchordrill

ipsec rules/nat contents:

miniupnpd rules/nat contents:

natearly rules/nat contents:

natrules rules/nat contents:

openvpn rules/nat contents:

tftp-proxy rules/nat contents:

userrules rules/nat contents:

cpzoneid_2_auth rules/nat contents:

cpzoneid_2_auth/192.168.11.27_32 rules/nat contents:
ether pass in quick proto 0x0800 from 32:13:57:3c:c5:6c l3 from 192.168.11.27 to any tag cpzoneid_2_auth dnpipe 2000
ether pass out quick proto 0x0800 to 32:13:57:3c:c5:6c l3 from any to 192.168.11.27 tag cpzoneid_2_auth dnpipe 2001

I have no Captive Portal configuration in play yet there is a mac address there that was added last night.

stephenw10

Huh, that's odd. I assume you previously had the captive portal active?

And that added when it was still active?

Steve

michmoor

@stephenw10 that is correct. Tried removing then adding then restarting the service but it’s still there. Are you aware of how to clear it manually?

stephenw10

You should be able to do that using the -a flag with pfctl. So:

pfctl -a "cpzoneid_2_auth/192.168.11.27_32" -Fe

Should flush the ether rules for that anchor.

Steve

michmoor

@stephenw10 Nice. This worked. Thank you. Lately, I have been utilizing more of the captive portal features available but I am finding these strange bugs. This one seems interesting as it didn't clear itself up. Any reason for it? I didn't find an existing redmine.

Appreciate you Stephen!

stephenw10

22.05 was the first pfSense version to switch from using ipfw for layer2 filtering to doing everything in pf. This is better in a number of ways including not having to pass all traffic through two packet filters. So throughput under heavy loads is better. But that was a significant change, a lot of code had to be re-written. 23.01 has a lot of bug fixes for the captive portal.

Steve

Gertjan

@michmoor said in Anchor rules:

I have no Captive Portal configuration in play yet there is a mac address there that was added last night.

I presume you've had a portal activated, a user with "32:13:57:3c:c5:6c l3 from 192.168.11.27" was logged in, and then you de activated the portal.

Yes, I can see that also : the cpzoneid_2_auth anchor doesn't get emptied when you de activate the portal.
The "pfSsh.php playback pfanchordrill" command still lists them all.
The pipes, like 2000 and 2001 in this example, are destroyed.

@stephenw10 said in Anchor rules:

You should be able to do that using the -a flag with pfctl. So:
pfctl -a "cpzoneid_2_auth/192.168.11.27_32" -Fe

Should flush the ether rules for that anchor.

Or : before de activating the captive portal, visit Status > Captive Portal > CPZONE and hit the big red button at the bottom of the page. This will disconnect all users properly.

I've found the issue, corrected it.
I presume that this is already correct in the future 22.0x.

Edit : Forgot to mention what I did.
When the a portal zone is de activated, this (/etc/inc/captiveportal.inc) happens :

Line 414 will destroy the :
/* delete MAC passthru entries /
/ delete Allowed IP entries /
/ delete Allowed Hostnames entries */

and of course

/* delete authenticated clients rules */

To get the list of connected portal users, the captive portal connected database list is read, and for every user, the 'auth' rules are destoyed.

But wait, look at the image again : line 408 : the database for ur captive portal zone is already wiped / removed / unlinked ! So no users are found => no 'auth' anchor rules are deleted.

Solution : move line 414 to 406 - before the first 'unlink'.

stephenw10

Whilst that line is still in the same place I'm not able to replicate that in 23.01.
When I disable the CP instance the rules associated with it are removed:

[23.01-DEVELOPMENT][admin@1100.stevew.lan]/root: pfSsh.php playback pfanchordrill

ipsec rules/nat contents:

miniupnpd rules/nat contents:

natearly rules/nat contents:

natrules rules/nat contents:

openvpn rules/nat contents:

tftp-proxy rules/nat contents:

userrules rules/nat contents:

cpzoneid_2_allowedhosts rules/nat contents:

cpzoneid_2_allowedhosts/192.168.15.25_32 rules/nat contents:
ether pass in quick proto 0x0800 l3 from any to 192.168.15.25 tag cpzoneid_2_auth dnpipe 2002
ether pass in quick proto 0x0800 l3 from 192.168.15.25 to any tag cpzoneid_2_auth dnpipe 2003

cpzoneid_2_auth rules/nat contents:

cpzoneid_2_passthrumac rules/nat contents:

cpzoneid_2_passthrumac/001e33a86d7d rules/nat contents:
ether pass in quick from 00:1e:33:a8:6d:7d l3 all tag cpzoneid_2_auth dnpipe 2000
ether pass out quick to 00:1e:33:a8:6d:7d l3 all tag cpzoneid_2_auth dnpipe 2001
[23.01-DEVELOPMENT][admin@1100.stevew.lan]/root: pfSsh.php playback pfanchordrill

ipsec rules/nat contents:

miniupnpd rules/nat contents:

natearly rules/nat contents:

natrules rules/nat contents:

openvpn rules/nat contents:

tftp-proxy rules/nat contents:

userrules rules/nat contents:

Steve

Gertjan

@stephenw10

Your test isn't valid ?!

These will get deleted :
MAC passthru entries
Allowed IP entries
Allowed Hostnames entries

But not the 'auth' anchor.

Your example doesn't show an 'auth' (captive portal logged in user) , like this one :

cpzoneid_2_auth/192.168.11.27_32 rules/nat contents:
ether pass in quick proto 0x0800 from 32:13:57:3c:c5:6c l3 from 192.168.11.27 to any tag cpzoneid_2_auth dnpipe 2000
ether pass out quick proto 0x0800 to 32:13:57:3c:c5:6c l3 from any to 192.168.11.27 tag cpzoneid_2_auth dnpipe 2001

and it is the 'auth' anchor that are not removed.

See also the first image in the first post from @michmoor

If the function call is in the same place, and that function didn't change, then it's implantation is wrong, as enumerating the connected users database from a database (file) that was deleted just before won't work out very well.

stephenw10

Ah, I see what you mean. The function removes all the rules for all types but the db is only used for auth'd users.
Retesting....

stephenw10

Confirmed: https://redmine.pfsense.org/issues/13756

stephenw10

I expect line 412 to need to be moved also so that 'pipes_to_remove' is populated.