Allowed IP Address does not work in captive portal

susobaco

Hi, I just upgraded to version 2.7.0 and encountered this error.
Until now, with the previous versions, in the dhcp server I assign static addresses within a range to some users (10.0.0.1/24) and I create a pass rule for those clients in the captive portal configuration option.
In previous versions, there was no problem, but in this new one, it asks for authorization in the portal to those clients.
The DCHP address is well assigned, but it does not work. The mac pass-through does work.

Where can I find a log on the subject that can give more information?
Thanks.

Salud!

Gertjan

@susobaco

I've added 192.168.2.6 'test' to the allowed IP list.

Then I connected my phone, it uses a DHCP static MAC assignment : it got 192.168.2.6.

No portal login page, I was connected right away.

Btw : I'm using 23.05.1, must be identical to 2.7.0 I guess.

susobaco

@Gertjan

Thank you, could you show me the configuration of some of these rules? I don't see the arrows on the left.

johnpoz

@susobaco you understand that "IP" you put in isn't really valid right 10.0.0.1/16 is a host address, not a network.. If your goal is to allow just 10.0.0.1 the mask would be a /32, if you want to allow 10.0 anything then it would be 10.0.0.0/16

But yeah you should see arrows I don't see a way to "not" pick arrows the dropdown doesn't have a none, etc.

susobaco

@johnpoz said in Allowed IP Address does not work in captive portal:

But yeah you should see arrows I don't see a way to "not" pick arrows the dropdown doesn't have a none, etc.

Yes, I have tried it with /32 for a single address, and for /24, (which is actually the range I need in passing) and it doesn't work for me. In version 2.6 it worked without problems.

johnpoz

@susobaco I tested on my 23.05.1 and get arrows.. Let me fire up my 2.7 lab box..

FSC830

Strange, some weeks ago there was a similar thread in which the arrows have been disappeared: click.
But in my test environment the arrows have always been present.

Regards

johnpoz

@FSC830 yeah that for sure looks like what they are seeing.

My 2.7 box was on an old snap 2.7.0.a.20230420.0600, it shows arrows

Its updating to current 2.7 now

edit:
Just updated to full 2.7 and still showing arrows

susobaco

if I execute the command:

pfSsh.php playback pfanchordrill

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:

cpzoneid_2_allowedhosts rules/nat contents:

cpzoneid_2_auth rules/nat contents:

cpzoneid_2_passthrumac rules/nat contents:

cpzoneid_2_passthrumac/4c02206804f5 rules/nat contents:
ether pass in quick from 4c:02:20:68:04:f5 l3 all tag cpzoneid_2_auth dnpipe 2000
ether pass out quick to 4c:02:20:68:04:f5 l3 all tag cpzoneid_2_auth dnpipe 2001

cpzoneid_2_passthrumac/4c91577ab811 rules/nat contents:
ether pass in quick from 4c:91:57:7a:b8:11 l3 all tag cpzoneid_2_auth dnpipe 2002
ether pass out quick to 4c:91:57:7a:b8:11 l3 all tag cpzoneid_2_auth dnpipe 2003

cpzoneid_2_passthrumac/4c91579f16e8 rules/nat contents:
ether pass in quick from 4c:91:57:9f:16:e8 l3 all tag cpzoneid_2_auth dnpipe 2004
ether pass out quick to 4c:91:57:9f:16:e8 l3 all tag cpzoneid_2_auth dnpipe 2005

cpzoneid_2_passthrumac/503dc6ba53a8 rules/nat contents:
ether pass in quick from 50:3d:c6:ba:53:a8 l3 all tag cpzoneid_2_auth dnpipe 2006
ether pass out quick to 50:3d:c6:ba:53:a8 l3 all tag cpzoneid_2_auth dnpipe 2007

cpzoneid_2_passthrumac/dc41a9cd4cae rules/nat contents:
ether pass in quick from dc:41:a9:cd:4c:ae l3 all tag cpzoneid_2_auth dnpipe 2008
ether pass out quick to dc:41:a9:cd:4c:ae l3 all tag cpzoneid_2_auth dnpipe 2009

cpzoneid_2_passthrumac/dcdce2415a72 rules/nat contents:
ether pass in quick from dc:dc:e2:41:5a:72 l3 all tag cpzoneid_2_auth dnpipe 2010
ether pass out quick to dc:dc:e2:41:5a:72 l3 all tag cpzoneid_2_auth dnpipe 2011

cpzoneid_2_passthrumac/dcdce241623a rules/nat contents:
ether pass in quick from dc:dc:e2:41:62:3a l3 all tag cpzoneid_2_auth dnpipe 2012
ether pass out quick to dc:dc:e2:41:62:3a l3 all tag cpzoneid_2_auth dnpipe 2013

cpzoneid_2_passthrumac/e40eee44987d rules/nat contents:
ether pass in quick from e4:0e:ee:44:98:7d l3 all tag cpzoneid_2_auth dnpipe 2014
ether pass out quick to e4:0e:ee:44:98:7d l3 all tag cpzoneid_2_auth dnpipe 2015

I get no output in the section "cpzoneid_2_auth rules/nat contents:"

Gertjan

@susobaco said in Allowed IP Address does not work in captive portal:

configuration of some of these rules?

More info Troubleshooting Captive Portal

Use

pfSsh.php playback pfanchordrill

to see

cpzoneid_2_allowedhosts/192.168.2.6_32 rules/nat contents:
ether pass in quick proto 0x0800 l3 from any to 192.168.2.6 tag cpzoneid_2_auth dnpipe 2012
ether pass in quick proto 0x0800 l3 from 192.168.2.6 to any tag cpzoneid_2_auth dnpipe 2013

net-mas

The whole thing is a bug starting with PfSense+. I wrote a bug for this - unfortunately it was rejected - but I am very sure that it is a bug, because it has been proven that the whole thing works with PFSense 2.6 - with PFSense+ (and presumably) 2.7 it no longer works. Downgrade (reinstall and restore the settings) to 2.6 gets the whole thing up and running again.

my bug: https://redmine.pfsense.org/issues/14454

This is justified in my forum post with "2.6.0 is ipfw based", PfSense+ (and 2.7.0?) no longer. I think that the setting options should then be adjusted accordingly or the functionality should be restored.
I would therefore like to appeal to reporting this issue as a bug as well, maybe someone else can articulate it better than me and the developer understands that this bug is a "regression" according to the bug tracker record page.

susobaco

Does anyone know how these entries can be entered manually (by editing a file)?

"pzoneid_2_allowedhosts/"

Gertjan

@net-mas said in Allowed IP Address does not work in captive portal:

because it has been proven that the whole thing works with PFSense 2.6 - with PFSense+ (and presumably) 2.7 it no longer works

The major difference between 2.6.0 and "current pfSense" like 2.7.0 and 23.05.1 is that the portal's firewall has been changed completely.

Before : ipfw was used.
These days, a more modern version of "pf" is used, as it can now also handle MAC.
These page Troubleshooting Captive Portal, changed a lot.

What I want to say : you've found probably something that was possible before, and now not anymore.

I guess "Allowed IP Address" ≠ "Allowed IP Network".

net-mas

@Gertjan

why can I then enter IP networks in the mask?:

susobaco

@net-mas said in Allowed IP Address does not work in captive portal:

why can I then enter IP networks in the mask?:

I have tried both /32 and /24 and /16 masks and it does not work either way.

net-mas

@susobaco
here - my picture:

the functionality is contained directly in the upper right corner of the GUI. So more precisely, the developer cannot point out that he supports IP networks

susobaco

As far as I could observe, the script (I guess php) to configure the "Allowed IP Address" page does not correctly save the configuration in the corresponding "rule" file. This would explain, in my case, that no output is obtained when executing "pfSsh.php playback pfanchordrill" in the "pzoneid_2_allowedhosts" section.

net-mas

@susobaco said in Allowed IP Address does not work in captive portal:

As far as I could observe, the script (I guess php) to configure the "Allowed IP Address" page does not correctly save the configuration in the corresponding "rule" file. This would explain, in my case, that no output is obtained when executing "pfSsh.php playback pfanchordrill" in the "pzoneid_2_allowedhosts" section.

Unfortunately, none of that means anything to me, I'm not that deep into the PFSense system. I would only be interested here if you can manipulate it: Can you find a variant of how it is stored correctly and thus used correctly with the subnet specification? In other words, is it just a GUI error or a firmware error because of the exchanged ipfw?

susobaco

@net-mas said in Allowed IP Address does not work in captive portal:

@susobaco said in Allowed IP Address does not work in captive portal:

As far as I could observe, the script (I guess php) to configure the "Allowed IP Address" page does not correctly save the configuration in the corresponding "rule" file. This would explain, in my case, that no output is obtained when executing "pfSsh.php playback pfanchordrill" in the "pzoneid_2_allowedhosts" section.

Unfortunately, none of that means anything to me, I'm not that deep into the PFSense system. I would only be interested here if you can manipulate it: Can you find a variant of how it is stored correctly and thus used correctly with the subnet specification? In other words, is it just a GUI error or a firmware error because of the exchanged ipfw?

I don't know the system that well either, I am researching, if I find something, I will write it here.

Gertjan

@net-mas said in Allowed IP Address does not work in captive portal:

here - my picture:

Hummm.

I never actually saw that one.

If I select /30 as shown, I obtain :

cpzoneid_2_allowedhosts/192.168.2.100**_30** rules/nat contents:
ether pass in quick proto 0x0800 l3 from any to 192.168.2.100**/30** tag cpzoneid_2_auth dnpipe 2012
ether pass in quick proto 0x0800 l3 from 192.168.2.100**/30** to any tag cpzoneid_2_auth dnpipe 2013

That 'looks' correct.
I guess : you subject is wrong ?

It's not "Allowed IP Address does not work in captive portal"
but "Allowed IP Network does not work in captive portal" as an IPv4is a /32, and smaller then /32 is a network.

I'm even not sure. Something like this :

Address: 192.168.2.100 11000000.10101000.00000010.011001 00
Netmask: 255.255.255.252 = 30 11111111.11111111.11111111.111111 00
Wildcard: 0.0.0.3 00000000.00000000.00000000.000000 11
=>
Network: 192.168.2.100/30 11000000.10101000.00000010.011001 00 (Class C)
Broadcast: 192.168.2.103 11000000.10101000.00000010.011001 11
HostMin: 192.168.2.101 11000000.10101000.00000010.011001 01
HostMax: 192.168.2.102 11000000.10101000.00000010.011001 10