Allowed IP Address does not work in captive portal

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

net-mas

@Gertjan That's correct - it wasn't my topic either, it was originally from someone else. I just stuck around here because I think it was/is similar. If that's wrong, we'll just have to open a new topic.

https://forum.netgate.com/topic/180480/ip-or-mac-passthrough-didn-t-work

here was the original post - but I didn't open it myself. In it, susobaco wrote to me that he probably has a similar problem - hence the cross reference

susobaco

link text

wtasin

Hi,
I had the same problem.

Look at my post
maybe it helps.

susobaco

It seems to be solved by putting the configuration page in English. If you do it that way it worked for me, it seems to be an error with the translation of the "Bold" "From" and "To" options. If you enter them in English, the rules seem to work.
link text