Project

General

Profile

Actions

Regression #13391

closed

Multiple Captive Portal interfaces do not properly form the list of portal IP addresses

Added by OpIT GmbH about 2 years ago. Updated almost 2 years ago.

Status:
Resolved
Priority:
Normal
Category:
Captive Portal
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
23.01
Release Notes:
Default
Affected Version:
Affected Architecture:

Description

When you select multiple Interfaces in a Captive Portal Zone, its just creating Rules for one Interface and that cause that just one Interface will work with Captive Portal...

You can see this by viewing the /tmp/rules.debug File (# Captive Portal)
There should be multiple "cpzoneid_" and "pass on" and "anchor" rule entries for each interface. But it just create them for one Interface and not for all selected!

If you create multiple Zones, its creating that rules just fine and everything works as it should...

Netgate Forum Thread: https://forum.netgate.com/topic/173842/problem-with-multiple-interfaces-since-version-22-05

Actions #2

Updated by Jim Pingle about 2 years ago

  • Tracker changed from Bug to Regression
  • Subject changed from Problem with multiple Interfaces since Version 22.05 to Multiple Captive Portal interfaces do not properly form the list of portal IP addresses
  • Target version set to 2.7.0
  • Plus Target Version changed from 22.05 to 22.11
Actions #3

Updated by Jim Pingle almost 2 years ago

  • Plus Target Version changed from 22.11 to 23.01
Actions #4

Updated by Reid Linnemann almost 2 years ago

I don't currently see this behavior in devel, unless I understand the problem incorrectly, but I do see a problem with the cpzone cpips alias omitting all but one interface IP. When I create a zone and assign two interfaces to it, I see this:

table <cpzoneid_2_cpips> { 192.168.61.1  }
ether pass on { vtnet0.60 vtnet0.61  } tag "cpzoneid_2_rdr" 
ether anchor "cpzoneid_2_auth/*" on { vtnet0.60 vtnet0.61  }
ether anchor "cpzoneid_2_passthrumac/*" on { vtnet0.60 vtnet0.61  }
ether anchor "cpzoneid_2_allowedhosts/*" on { vtnet0.60 vtnet0.61  }
rdr on vtnet0.60 inet proto tcp from any to ! <cpzoneid_2_cpips> port 80 tagged cpzoneid_2_rdr -> 192.168.60.1 port 8002
rdr on vtnet0.61 inet proto tcp from any to ! <cpzoneid_2_cpips> port 80 tagged cpzoneid_2_rdr -> 192.168.61.1 port 8002
pass in quick on vtnet0.60 proto tcp from any to <cpzoneid_2_cpips> port 8002 ridentifier 13001 keep state(sloppy)
block in quick on vtnet0.60 from any to ! <cpzoneid_2_cpips> ! tagged cpzoneid_2_auth ridentifier 13003
pass in quick on vtnet0.61 proto tcp from any to <cpzoneid_2_cpips> port 8002 ridentifier 13004 keep state(sloppy)
block in quick on vtnet0.61 from any to ! <cpzoneid_2_cpips> ! tagged cpzoneid_2_auth ridentifier 13006

As you can see, the ether, pass, block, and rdr rules were all appropriately created with both vtnet0.60 (lan1) and vtnet0.61 (lan2) interfaces, however the cpzonid_2_cpips alias only has vtnet0.61's (lan2) address 192.168.61.1.

Actions #5

Updated by Reid Linnemann almost 2 years ago

Reading over the forum post again, I think I am actually seeing what you are describing - that the ips for the interfaces are not all being concatenated, not that the interfaces are missing rules, in which case I have a fix that makes the addresses concatenate correctly. As pointed out in the forum, $cpiplist was being reassigned every iteration over the interface list. I've made a slightly more thorough change that collects the IPs and VIPs into a list rather than directly concatenating the string, then joins it with spaces when it's concatenated to the rule output.

I have a change in CE right now that I'll be merging to Plus momentarily, and it should show up in the next build.

Actions #6

Updated by Reid Linnemann almost 2 years ago

  • Status changed from New to Feedback
  • Assignee set to Reid Linnemann
  • Start date set to 12/22/2022
  • % Done changed from 0 to 100
Actions #7

Updated by Jim Pingle almost 2 years ago

  • Status changed from Feedback to Resolved
  • Start date deleted (12/22/2022)

This appears to be OK now:

table <cpzoneid_2_cpips> { 10.23.0.1 10.23.2.1}

: pfctl -T show -t cpzoneid_2_cpips
   10.23.0.1
   10.23.2.1
Actions

Also available in: Atom PDF