pfSsh.php playback pfanchordrill (when portal is active)

Gertjan

Probably this :

?

This URL points to a static IPv4, our companies web site.
The URL is resolved just fine.

marcosm

For reference:

[25.07.1-RELEASE][root@pfSense.bhf.tld]/root: pfSsh.php playback pfanchordrill

cpzoneid_2_allowedhosts rules/nat contents:

hostname_0 rules/nat contents:
pfctl: DIOCGETRULES: Invalid argument
pfctl: DIOCGETRULES: Invalid argument

I noticed this as well when testing with an allowed MAC, IP, and hostname. The error itself is harmless. The script likely doesn't handle the hostname part as you mentioned.

stephenw10

Ah OK interesting. Let me see here....

stephenw10

Yup. Also in 25.11:

[25.11-RC][admin@6100.stevew.lan]/root: pfSsh.php playback pfanchordrill

cpzoneid_2_allowedhosts rules/nat contents:

hostname_0 rules/nat contents:
pfctl: DIOCGETRULES: Invalid argument
pfctl: Anchor does not exist.

Did you open a bug for this yet?

Gertjan

@stephenw10 said in pfSsh.php playback pfanchordrill (when portal is active):

Did you open a bug for this yet?

Noop.
I only post a bug report when I know what the reason is.
Afaik, its a pfctl issue, or just the pfctl man pages not telling everything and /etc/phpshellsessions/pfanchordrill is using pfctl the wrong way.
Very view use the command line command "pfanchordrill" I guess.

edit : I looked into it a bit.
When I delete my "Allowed hostname" (see above) - I added an "Allowed IP Address" as this is for me bascilly the same,
and I have now to reboot to remove this :

a this "hostname_0" entry seems to get stuck/invalid, as I removed the "Allowed host name".
Now I get a clean :

[25.07.1-RELEASE][root@pfSense.bhf.tld]/root: pfSsh.php playback pfanchordrill

cpzoneid_2_allowedhosts rules/nat contents:

cpzoneid_2_allowedhosts/188.165.53.87_32 rules/nat contents:
ether pass in quick proto 0x0800 l3 from any to 188.165.53.87 tag cpzoneid_2_auth dnpipe 2008
ether pass in quick proto 0x0800 l3 from 188.165.53.87 to any tag cpzoneid_2_auth dnpipe 2009

cpzoneid_2_auth rules/nat contents:

cpzoneid_2_auth/192.168.2.33_32 rules/nat contents:
ether pass in quick proto 0x0800 from 8a:c0:8c:a4:be:36 l3 from 192.168.2.33 to any tag cpzoneid_2_auth dnpipe 2012
ether pass out quick proto 0x0800 to 8a:c0:8c:a4:be:36 l3 from any to 192.168.2.33 tag cpzoneid_2_auth dnpipe 2013

cpzoneid_2_auth/192.168.2.39_32 rules/nat contents:
ether pass in quick proto 0x0800 from f6:1e:a1:12:56:9d l3 from 192.168.2.39 to any tag cpzoneid_2_auth dnpipe 2014
ether pass out quick proto 0x0800 to f6:1e:a1:12:56:9d l3 from any to 192.168.2.39 tag cpzoneid_2_auth dnpipe 2015

cpzoneid_2_auth/192.168.2.48_32 rules/nat contents:
ether pass in quick proto 0x0800 from 32:e4:ee:0b:29:c8 l3 from 192.168.2.48 to any tag cpzoneid_2_auth dnpipe 2010
ether pass out quick proto 0x0800 to 32:e4:ee:0b:29:c8 l3 from any to 192.168.2.48 tag cpzoneid_2_auth dnpipe 2011

cpzoneid_2_passthrumac rules/nat contents:

cpzoneid_2_passthrumac/28704e6249e5 rules/nat contents:
ether pass in quick from 28:70:4e:62:49:e5 l3 all tag cpzoneid_2_auth dnpipe 2000
ether pass out quick to 28:70:4e:62:49:e5 l3 all tag cpzoneid_2_auth dnpipe 2001

cpzoneid_2_passthrumac/28704e6260bd rules/nat contents:
ether pass in quick from 28:70:4e:62:60:bd l3 all tag cpzoneid_2_auth dnpipe 2002
ether pass out quick to 28:70:4e:62:60:bd l3 all tag cpzoneid_2_auth dnpipe 2003

cpzoneid_2_passthrumac/9c05d6320095 rules/nat contents:
ether pass in quick from 9c:05:d6:32:00:95 l3 all tag cpzoneid_2_auth dnpipe 2004
ether pass out quick to 9c:05:d6:32:00:95 l3 all tag cpzoneid_2_auth dnpipe 2005

cpzoneid_2_passthrumac/d8b370834988 rules/nat contents:
ether pass in quick from d8:b3:70:83:49:88 l3 all tag cpzoneid_2_auth dnpipe 2006
ether pass out quick to d8:b3:70:83:49:88 l3 all tag cpzoneid_2_auth dnpipe 2007

ipsec rules/nat contents:

natearly rules/nat contents:

natrules rules/nat contents:

openvpn rules/nat contents:

tftp-proxy rules/nat contents:

userrules rules/nat contents:

which does correspond with the actual portal 'pf' working set :
A (one) IP address - the one I converted from host name to IP.
The 3 actual logged in portal visitors.
The 4 MAC Allowed entries.

So, as "host names" are just entries that will be converted to IP first before being entered into 'pf', is this process that fails.
And is "hostname_0" correct - where does the came from - my portal ID is "2" ?
Why isn't (my case) the anchor called : "cpzoneid_2_hostname" ?

stephenw10

Does the hostname actually work? Can clients access it before logging in?

I would have expected a lot more complaints by now if it didn't.