Problem with multiple Interfaces since Version 22.05

Gertjan

I hope this is not an urgent thing for you - and I hope to be wrong here.
IMHO, you didn't find a bug, but a functionality that doesn't exist, except for the documentation. Implementing will be far more complex as putting out a simple simple patch.

edit : just maybe : the doc is ready for the upcoming version that does contain multiple interfaces support.

edit2 : I had to edit my post above :
I created some more LZAN interfaces, assigned it and IPv4 like 192.168.100.1/24 and 192.168.200.1/24 and added these interfaces to my captive portal zone.

I found this in the nginx config file :

		if ($http_host ~* 192.168.100.1) {
			set $cp_redirect no;
		}
		if ($http_host ~* 192.168.2.1) {
			set $cp_redirect no;
		}
		if ($http_host ~* 192.168.200.1) {
			set $cp_redirect no;
		}

so that part looks good.

OpIT GmbH

@gertjan
i think its a Bug, when you look at the /tmp/rules.debug File. It will create 4 Entries with # Captive Portal. As you can see, its adding my selected interface BUT not on every setting. In version 22.01 all was working fine.

You can see that just 1 Interface ist listed, but it should be 2, as can can see below.

Captive Portal

table <cpzoneid_2_cpips> { 10.5.50.1 }

Captive Portal

ether pass on { igc0 igc0.50 } tag "cpzoneid_2_rdr"
ether anchor "cpzoneid_2_auth/" on { igc0 igc0.50 }
ether anchor "cpzoneid_2_passthrumac/" on { igc0 igc0.50 }
ether anchor "cpzoneid_2_allowedhosts/*" on { igc0 igc0.50 }

Captive Portal

rdr on igc0 inet proto tcp from any to ! <cpzoneid_2_cpips> port 80 tagged cpzoneid_2_rdr -> 192.168.10.254 port 8002
rdr on igc0.50 inet proto tcp from any to ! <cpzoneid_2_cpips> port 80 tagged cpzoneid_2_rdr -> 10.5.50.1 port 8002

Captive Portal

pass in quick on igc0 proto tcp from any to <cpzoneid_2_cpips> port 8002 ridentifier 13001 keep state(sloppy)
pass out quick on igc0 proto tcp from 192.168.10.254 port 8002 to any flags any ridentifier 13002 keep state(sloppy)
pass in quick from any to any tagged cpzoneid_2_passthru ridentifier 13003 keep state
block in quick on igc0 from any to ! <cpzoneid_2_cpips> ! tagged cpzoneid_2_auth ridentifier 13004
pass in quick on igc0.50 proto tcp from any to <cpzoneid_2_cpips> port 8002 ridentifier 13005 keep state(sloppy)
pass out quick on igc0.50 proto tcp from 10.5.50.1 port 8002 to any flags any ridentifier 13006 keep state(sloppy)
pass in quick from any to any tagged cpzoneid_2_passthru ridentifier 13007 keep state
block in quick on igc0.50 from any to ! <cpzoneid_2_cpips> ! tagged cpzoneid_2_auth ridentifier 13008

OpIT GmbH

I created a Bug Report

https://redmine.pfsense.org/issues/13391

Gertjan

@opit-gmbh

Recently, the 'ipfw' firewall, used for captive portal instances, was ditched and replaced by the 'pf' firewall.

'pf' is the one we use when we create our GUI firewall rules.

The conversion was a big task, and maybe ( ? ) the 'multiple interfaces' options was just omitted, or forgotten ( coders are still human ;) ).

OpIT GmbH

@gertjan
yeah it looks like the just have forgotten some things there but i also think that this should not be a big Problem to correct this.... :=)

Gertjan

@opit-gmbh

If you can edit a file :

Open /etc/inc/captiveportal.inc
Goto line 2576 ( ? )

You'll find

						$cpiplist = $cpip . ' ';

Change it to ( add a single point . ) :

						$cpiplist .= $cpip . ' ';

Now you will see in the firewall rules file :

....
# Captive Portal
table <cpzoneid_2_cpips> { 192.168.100.1 192.168.2.1  }
....

and these are the IP addresses of my two interfaces added to a captive portal zone.

I can't test drive this myself.
Can you test ?

OpIT GmbH

@gertjan

Tested it > and it seams to be working!

Many Thanks!!!

OpIT GmbH

I also found maybe another Problem. When you upload a Logo or a Background Logo, its created with 2 .. (Points) in the extension. So you have "captiveportal-logo..png or "captiveportal-background..png"

The Logos are displayed normally, so its just seams to be a cosmetic "Bug"

Gertjan

@opit-gmbh

Hummm.
The point you just added should be remove somewhere else ;)

OpIT GmbH

@gertjan

Not i add the Dot, the Netgate add it. I Upload a "logo.png" and the Netgate generates "captiveportal-logo..png"

Gertjan

@opit-gmbh

You didn't understood the suggestion.

Open /usr/local/www/services_captiveportal.php

Look for every function :

image_type_to_extension

And look closely to the example of the image_type_to_extension PHP function definition.

<?php
// Create image instance
$im = imagecreatetruecolor(100, 100);

// Save image
imagepng($im, './test' . image_type_to_extension(IMAGETYPE_PNG));
imagedestroy($im);
?>

The example :

Right after '/test there is no point included - so the point comes back with with the image_type_to_extension(IMAGETYPE_PNG) function call - so this function resturns
".png".

Now, back to our /usr/local/www/services_captiveportal.php, locate every line with image_type_to_extension and then look closely the line.
Example :

$logo_name = "captiveportal-logo." . image_type_to_extension(is_supported_image($_FILES['logo-img']['tmp_name']));

Do you see the point that you have to remove ?
It's right after captiveportal-logo

Redo the same thing for where the "captiveportal-background." is handled, and you'll be fine.

My suggestion was :you should remove some points '.' ^^

OpIT GmbH

@gertjan

ahhhh, now i know what you mean "The point you just added should be remove somewhere else" .... heheh :=)

THX!

Should all of this here be Mailed to Netgate directly, so that they can fix this stuff in the next Version or with a Patch? Our das Netgate read all the Forum Posts here?!

Gertjan

@opit-gmbh said in Problem with multiple Interfaces since Version 22.05:

Should all of this here be Mailed to Netgate directly

You opened a bug report, a regression actually, that points to this thread.
Some author will read the report, read the thread, and deal with it in no time.
Jimp already saw your report.
As I see it, 2.7.0 and 22.11 will contain the solution.

OpIT GmbH

@gertjan

i also added a comment about the "Dot" Problem in the Bug Report. So i think all should be fine for now.

THX Gertjan for your help!