Regression #13391
closed
Multiple Captive Portal interfaces do not properly form the list of portal IP addresses
100%
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
Updated by OpIT GmbH over 2 years ago
User gertjan found the Problem. See this Post: https://forum.netgate.com/topic/173842/problem-with-multiple-interfaces-since-version-22-05/9?_=1659518983176
Updated by Jim Pingle over 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
Updated by Jim Pingle about 2 years ago
- Plus Target Version changed from 22.11 to 23.01
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.
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.
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
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