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.

Gertjan

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

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

Yes.
It put in the place the IP of the hos name, and the access was fine : before the portal clients logs in, he can access this IP or host name resource (a guide, PDF, that shows the portal login password - if this wasn't working, they would have to contact the reception - and they don't).

Remove de IP, put back the host name, and it's again :

[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

edit :

$cpzoneprefix = /etc/inc/global.inc line 44 = 'cpzoneid_' + the zone ID becomes 'cpzoneid_0'

/etc/inc/captiveportal.inc, line 2623

An alias entry is created :

$aliasesnames[] = $cpzoneprefix . '_hostname_' . $id;

Example : 'cpzoneid_0_hostname_0'.

The function filter_captiveportal_aliases() is called from /etc/inc/filter.inc, line 1232694

But look at the comments above :

That's not the format return in the array !
It's 'cpzoneid_0_hostname_0'
Not 'cpzoneid_X_allowedhosts/hostname_X'
(neither 'cpzoneid_X_host_Y')

This /etc/inc/filter.inc line 1069 list probably the expected anchor names.

The thing is : after the alias array is parsed, filtered, etc, the remain items are deleted : /etc/inc/filter.inc line 1239.
Wrong stuff, or less worse, non exiting stuff gets deleted here.

stephenw10

Hmm, seems like it could be a pfctl bug:

[25.07.1-RELEASE][admin@6100.stevew.lan]/root: pfctl -sA
  cpzoneid_2_allowedhosts
  ipsec
  natearly
  natrules
  openvpn
  tftp-proxy
  userrules
  cpzoneid_2_allowedhosts
  cpzoneid_2_auth
  cpzoneid_2_passthrumac
[25.07.1-RELEASE][admin@6100.stevew.lan]/root: pfctl -vsA
  cpzoneid_2_allowedhosts
  hostname_0
pfctl: DIOCGETRULESETS: No such file or directory

Gertjan

@stephenw10

yep, as soon as the -v (verbose ?!) option is present, errors pop up.
Seems innocent, but anchordrill uses it.