Allowed IP Address does not work in captive portal
-
@susobaco I tested on my 23.05.1 and get arrows.. Let me fire up my 2.7 lab box..
-
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
-
@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 -
-
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:"
-
@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
-
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. -
Does anyone know how these entries can be entered manually (by editing a file)?
"pzoneid_2_allowedhosts/"
-
@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".
-
why can I then enter IP networks in the mask?:
-
@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.
-
@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
-
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.
-
@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?
-
@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.
-
@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 2013That '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 -
@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
-
-
-
Hi,
I had the same problem.Look at my post
maybe it helps. -
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 -
-