Captive portal doesn´t work after upgrade to 2.2

uaxero

hi. i´ve upgrade my pfsense firewall from 2.1.5 to 2.2 version, since the captive portal has stopped working ,
worked well at first , but when i configure the ssl mode the captive portal stopped working and now does not work with ssl shutdown mode
gave errors in use port 8003 , these errors are gone now but still not working. may be a problem with dns forwarder ?

thank you very much

sorry for my bad English

uaxero

I think I found the solution and explanation to the problem.
my captive portal uses a virtual address to use as gateway for customers. This virtual address is not adding ipfw rules automatically. I had to manually add the rules affected are those that allow access to the gateway before the user has logged on the captive portal. I do not know if it 's a bug, in previous versions it worked perfectly.

the rule are

65310 allow ip from any to { 255.255.255.255 or 10.131.0.3 or 10.131.0.30 } in
65311 allow ip from { 255.255.255.255 or 10.131.0.3 or 10.131.0.30 } to any out
65312 allow icmp from { 255.255.255.255 or 10.131.0.3 or 10.131.0.30 } to any out icmptypes 0
65313 allow icmp from any to { 255.255.255.255 or 10.131.0.3 or 10.131.0.30 } in icmptypes 8

i have add manually the ip 10.131.0.30 that is my ip virtual.

Gertjan

Hi.
@uaxero:

…..
65310 allow ip from any to { 255.255.255.255 or 10.131.0.3 or 10.131.0.30 } in
65311 allow ip from { 255.255.255.255 or 10.131.0.3 or 10.131.0.30 } to any out
65312 allow icmp from { 255.255.255.255 or 10.131.0.3 or 10.131.0.30 } to any out icmptypes 0
65313 allow icmp from any to { 255.255.255.255 or 10.131.0.3 or 10.131.0.30 } in icmptypes 8

Both 10.131.0.3 and 10.131.0.30 are portal interfaces ?
On the same network 10.131.0/24 ?

At the moment, as we 'speak', there is some work in progress in that code-neighborhood ( https://github.com/pfsense/pfsense/commit/98bf4991dc31f97fc7315a6b8aba433de9d39cea#diff-a58872487907e38eb2b46bb3e0f1cd5a ), the list is move to a table, but selecting the IP's that should be added to "allow ip from any to (any to)" and "allow icmp from (any to)" is still the same.

uaxero

10.131.0.3 is the phisycal interface and 10.131.0.30 is the virtual carp interface

uaxero

I tried the new configuration as shown in (https://github.com/pfsense/pfsense/commit/98bf4991dc31f97fc7315a6b8aba433de9d39cea#diff-a58872487907e38eb2b46bb3e0f1cd5a) and what I've done is you have not redirect the captive portal.

Gertjan

@uaxero:

I tried the new configuration as shown in (https://github.com/pfsense/pfsense/commit/98bf4991dc31f97fc7315a6b8aba433de9d39cea#diff-a58872487907e38eb2b46bb3e0f1cd5a) and what I've done is you have not redirect the captive portal.

Be carefull. That GIT link is based on master, not 2.2.

The actual captiveportal.inc is here https://github.com/pfsense/pfsense/blob/RELENG_2_2/etc/inc/captiveportal.inc (2.2)
Check out lines 496-517.
Look at line 499 - if the interface is found ($tmpif), $cpipm will be assigned … and add to $cpipm (line 513).

The array $cpipm will be parsed (lines 545 - 552) and used to build the firewall that you was using before.

	$ips = "{ 255.255.255.255 or {$ips} }";
	$cprules .= "add {$rulenum} pass ip from any to {$ips} in\n";

So, start to debug the foreach loop 496-517 to see why your carp interface IP recognized as such.

uaxero

sorry for me ignorance, how i can start to debug the foreach loop 496-517?

thanks

Gertjan

@uaxero:

sorry for me ignorance, how i can start to debug the foreach loop 496-517?

You noticed that the captive portal is its own log ? (Status => System logs => Portal Auth)

Now, look at captiveportal.inc, line 195:
captiveportal_syslog("Reconfiguring captive portal({$cpcfg['zone']}).");

The captiveportal_syslog(…...); function is just great to 'debug'.
Note: it has 4 strings as parameters - look up the actual function definition first.

uaxero

i can see this in the log

php-fpm[50532]: /services_captiveportal.php: The command '/sbin/ipfw zone 2 mdel ' returned exit code '64', the output was 'ipfw: bad arguments, for usage summary ``ipfw''

Gertjan

This is not good at all.

The ipfw command-option (part of) 'mdel' does NOT exist - it doesn't mean anything to 'ipfw'. ipfw complains badly. PHP logs the error. There is something not good.

Can you list this file:
/tmp/ipfw_xxxxx.cp.rules
where xxxxx is the name of your zone.
(There should be a file with the extension 'rules' in the /tmp directory.)

Can you give the result of this SSH command:
grep 'mdel' /etc/inc/*

Btw: when I lauch this:
grep '/sbin/ipfw zone' /etc/inc/*
I have this

/etc/inc/captiveportal.inc:             mwexec("/sbin/ipfw zone {$cpzoneid} destroy", true);
/etc/inc/captiveportal.inc:     mwexec("/sbin/ipfw zone {$cpzoneid} create", true);
/etc/inc/captiveportal.inc:                                             mwexec("/sbin/ipfw zone {$cpzoneid} madd {$cpcarp}", true);
/etc/inc/captiveportal.inc:                     mwexec("/sbin/ipfw zone {$cpzoneid} madd {$tmpif}", true);

uaxero

this is ssh ipfw_lan.cp.rules

flush
add 65291 allow pfsync from any to any
add 65292 allow carp from any to any

layer 2: pass ARP

add 65301 pass layer2 mac-type arp,rarp

pfsense requires for WPA

add 65302 pass layer2 mac-type 0x888e,0x88c7

PPP Over Ethernet Session Stage/Discovery Stage

add 65303 pass layer2 mac-type 0x8863,0x8864

layer 2: block anything else non-IP(v4/v6)

add 65307 deny layer2 not mac-type ip,ipv6
add 65310 pass ip from any to { 255.255.255.255 or 10.131.0.3 or 10.131.0.3 } in
add 65311 pass ip from { 255.255.255.255 or 10.131.0.3 or 10.131.0.3 } to any out
add 65312 pass icmp from { 255.255.255.255 or 10.131.0.3 or 10.131.0.3 } to any out icmptype 0
add 65313 pass icmp from any to { 255.255.255.255 or 10.131.0.3 or 10.131.0.3 } in icmptype 8
add 65314 pipe tablearg ip from table(3) to any in
add 65315 pipe tablearg ip from any to table(4) in
add 65316 pipe tablearg ip from table(3) to any out
add 65317 pipe tablearg ip from any to table(4) out
add 65318 pipe tablearg ip from table(1) to any in
add 65319 pipe tablearg ip from any to table(2) out

redirect non-authenticated clients to captive portal

add 65532 fwd 127.0.0.1,8002 tcp from any to any dst-port 80 in

let the responses from the captive portal web server back out

add 65533 pass tcp from any to any out

block everything else

add 65534 deny all from any to any

repeats the ip 10.130.0.3 that it is the ip of physical interface, but the ip 10.130.0.30 does not appear that it is the virtual carp ip

nothing happened when i launch grep 'mdel' /etc/inc/*

and this is the result of grep '/sbin/ipfw zone' /etc/inc/*

/etc/inc/captiveportal.inc: mwexec("/sbin/ipfw zone {$cpzoneid} destroy", true);
/etc/inc/captiveportal.inc: mwexec("/sbin/ipfw zone {$cpzoneid} create", true);
/etc/inc/captiveportal.inc: mwexec("/sbin/ipfw zone {$cpzoneid} madd {$cpcarp}", true);
/etc/inc/captiveportal.inc: mwexec("/sbin/ipfw zone {$cpzoneid} madd {$tmpif}", true);

Gertjan

Seesm all normal to me.

I found the '/sbin/ipfw zone 2 mdel' … it was right in front of my nose.

Here : /usr/local/www/services_captiveportal.php - line 411.
It tries to remove an interface {$removeif} but it seems to me that $removeif = get_real_interface($removeif); on line 410 return an empty string …... so things blow up.

These lines are called when I REMOVE an interface (so at least having 2 !) on a captive portal instance.
This is an exceptional thing.

Can you detail you setup please - interfaces - portal settings ? (image !!).

uaxero

the configuration of captive portal is default configuration

![captive portal.jpg](/public/imported_attachments/1/captive portal.jpg)
![captive portal.jpg_thumb](/public/imported_attachments/1/captive portal.jpg_thumb)

uaxero

the rest of configuration

![interface lan.jpg](/public/imported_attachments/1/interface lan.jpg)
![ip virtual carp.jpg](/public/imported_attachments/1/ip virtual carp.jpg)
![interface lan.jpg_thumb](/public/imported_attachments/1/interface lan.jpg_thumb)
![ip virtual carp.jpg_thumb](/public/imported_attachments/1/ip virtual carp.jpg_thumb)

Gertjan

This is correct (?):
Your Captive portal interface run on LAN [is selected] (why not a separate OPTx interface ?)
Your LAN IP = 10.131.0.4 (why not 10.131.0.1 ?)
Or, the firewall rule mention: 10.131.0.3 (why not 10.131.0.1 ?)
This:

add 65310 pass ip from any to { 255.255.255.255 or 10.131.0.3 or 10.131.0.3 } in
add 65311 pass ip from { 255.255.255.255 or 10.131.0.3 or 10.131.0.3 } to any out
add 65312 pass icmp from { 255.255.255.255 or 10.131.0.3 or 10.131.0.3 } to any out icmptype 0
add 65313 pass icmp from any to { 255.255.255.255 or 10.131.0.3 or 10.131.0.3 } in icmptype 8

10.131.0.3 or 10.131.0.3 == "10.131.0.3"
You changed something here. It was different before.
This was CARP related - is it possible that you put your Captive portal interface on its dedicated interface - leaving this CARP thing else where and NOT in this network segment.

Not related, but curious: a radius server an WAN :o (I saw that identification is set to None right now - better test your box first with some locally define users in the User manager).

Please double check : "Idle timeout" and "Hard timeout". Leaving both non initialized (as is the case right now) == playing with fire.

uaxero

i haven´t a radius server in wan. in RADIUS NAS IP attribute you can see all the ip of all yours interface.

the configuration of captive portal is by default like i say before.

in previous version 2.1.5 of pfsense all work perfectly, is in the version 2.2 when i have the problem of ipfw, the problem is that the virtual carp ip not is inserted in ipfw rule.

add 65310 pass ip from any to { 255.255.255.255 or 10.131.0.3 or 10.131.0.3 } in
add 65311 pass ip from { 255.255.255.255 or 10.131.0.3 or 10.131.0.3 } to any out
add 65312 pass icmp from { 255.255.255.255 or 10.131.0.3 or 10.131.0.3 } to any out icmptype 0
add 65313 pass icmp from any to { 255.255.255.255 or 10.131.0.3 or 10.131.0.3 } in icmptype 8

the gateway 10.131.0.3 10.131.0.4 or 10.131.0.1 is exactly same.

is true that in old post my gateway was 10.131.0.3 i have changed to try with other ip, but the result is the same. (sorry i forgive have said in the previous post).

we controll the idle and hard timeout by radius.

thanks

Gertjan

As said before: remove the CARP IP from the LAN segment (or ditch the carp for the time during tests).
Or: do what pfSense somewhat advices : use the Portal on a dedicated interface.

uaxero

hello good morning .

see you've now changed the way in which the virtual interface is managed. if I do a ifconfig , appeared before the vitual interface as an interface but now the virtual ip interface appears within the interface to which it belongs .

before in version 2.1.5

em3: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
options=9b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum>ether xx:xx:xx:xx:xx:xx
inet 10.131.0.3 netmask 0xffff0000 broadcast 10.131.0.255
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active

lan_vip15: flags=49 <up,loopback,running>metric 0 mtu 1500
inet 10.130.0.30 netmask 0xffff0000
carp: MASTER vhid 15 advbase 1 advskew 200

now in version 2.2

em3: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
options=9b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum>ether xx:xx:xx:xx:xx:xx
inet 10.131.0.3 netmask 0xffffff00 broadcast 10.131.0.255
inet 10.131.0.30 netmask 0xffffff00 broadcast 10.131.0.255 vhid 15
nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
carp: BACKUP vhid 15 advbase 1 advskew 0

this is a possible cause of this issue.

before in ipfw_context

captive: em3,lan_vip15,

now in ipfw zone list

captive: em3,

i´ve tryed all kind of configurations and i continue with the problem.

thanks sir Gertjan for your effort</full-duplex></performnud,auto_linklocal></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum></up,broadcast,running,promisc,simplex,multicast></up,loopback,running></full-duplex></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum></up,broadcast,running,promisc,simplex,multicast>

michaelschefczyk

Dear All,

uaxero is not alone with such issues of keeping captive portal up after upgrading to 2.2 on a system with CARP.

I have a similar setup where the two pfSense machines are 192.168.4.78 and 192.168.4.79 sharing a CARP VIP of 192.168.4.1. Before 2.2, I used unbound as a package. I had the portal (internal) domain name resolve to 192.168.4.1 via local data and have DHCP provide 192.168.4.1 as DNS and gateway. That did work well. After the upgrade, a PC connecting to the guest network can see 192.168.4.78, 192.168.4.79 (and any other IP on the guest network), but not 192.168.4.1. Hence DNS and forwarding does not work. Obvious changes, such as having DHCP provide 192.168.4.78 as DNS and gateway instead, for example, do not help.

Any explanation in plain English (or pictures) regarding how to handle CARP now would be highly welcome.

Regards,

Michael Schefczyk

doktornotor

Dunno how many times does this need to be said: Use the Captive Portal on a dedicated interface.