Project

General

Profile

Actions

Bug #9977

closed

Enabling Captive Portal on 2.4.5 breaks network connectivity

Added by Jim Pingle almost 5 years ago. Updated almost 5 years ago.

Status:
Resolved
Priority:
Urgent
Assignee:
Category:
Captive Portal
Target version:
Start date:
12/17/2019
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.4.5
Affected Architecture:
All

Description

Enabling Captive Portal on 2.4.5 breaks connectivity even on interfaces which are not involved in Captive Portal. The same configuration on 2.4.4-p3 works without issue.

To reproduce, create a captive portal zone and enable it. No need for any special options (either click Local Database for auth, or choose no auth). As soon as the captive portal IPFW rules load, connectivity is lost.

To get back, from the console, kldunload ipfw.ko and then disable captive portal again. Or use viconfig to disable the portal and reboot.

I can reproduce this on multiple systems (amd64 and ARM) so it doesn't seem isolated to one single setup.

From a basic no-frills CP config:

IPFW Rules (basic config):

01000  0    0 skipto tablearg ip from any to any via table(cp_ifaces)
01100 83 6520 allow ip from any to any
02100  0    0 pipe tablearg MAC table(testzone_pipe_mac)
02101  0    0 allow pfsync from any to any
02102  0    0 allow carp from any to any
02103  0    0 allow layer2 mac-type 0x0806,0x8035
02104  0    0 allow layer2 mac-type 0x888e,0x88c7
02105  0    0 allow layer2 mac-type 0x8863,0x8864
02106  0    0 deny layer2 not mac-type 0x0800,0x86dd
02107  0    0 allow ip from any to table(testzone_host_ips) in
02108  0    0 allow ip from table(testzone_host_ips) to any out
02109  0    0 allow ip from any to 255.255.255.255 in
02110  0    0 allow ip from 255.255.255.255 to any out
02111  0    0 pipe tablearg ip from table(testzone_allowed_up) to any in
02112  0    0 pipe tablearg ip from any to table(testzone_allowed_down) in
02113  0    0 pipe tablearg ip from table(testzone_allowed_up) to any out
02114  0    0 pipe tablearg ip from any to table(testzone_allowed_down) out
02115  0    0 pipe tablearg ip from table(testzone_auth_up) to any layer2 in
02116  0    0 pipe tablearg ip from any to table(testzone_auth_down) layer2 out
02117  0    0 fwd 127.0.0.1,8002 tcp from any to any 80 in
02118  0    0 allow tcp from any to any out
02119  0    0 skipto 65534 ip from any to any
65534  0    0 deny ip from any to any
65535  0    0 allow ip from any to any

IPFW Table contents (basic config):

--- table(cp_ifaces), set(0) ---
cpsw1 2100 1 176 1576597816
--- table(testzone_auth_up), set(0) ---
--- table(testzone_host_ips), set(0) ---
10.22.0.1/32 0 0 0 0
--- table(testzone_pipe_mac), set(0) ---
--- table(testzone_auth_down), set(0) ---
--- table(testzone_allowed_up), set(0) ---
--- table(testzone_allowed_down), set(0) ---

From a host with a slightly more complex CP setup:

IPFW rules when CP is active:

01000  22 10336 skipto tablearg ip from any to any via table(cp_ifaces)
01100 650 46429 allow ip from any to any
02100   0     0 pipe tablearg MAC table(guestnetwork_pipe_mac)
02101   0     0 allow pfsync from any to any
02102   0     0 allow carp from any to any
02103   0     0 allow layer2 mac-type 0x0806,0x8035
02104   0     0 allow layer2 mac-type 0x888e,0x88c7
02105   0     0 allow layer2 mac-type 0x8863,0x8864
02106   0     0 deny layer2 not mac-type 0x0800,0x86dd
02107   0     0 allow ip from any to table(guestnetwork_host_ips) in
02108  22 10336 allow ip from table(guestnetwork_host_ips) to any out
02109   0     0 allow ip from any to 255.255.255.255 in
02110   0     0 allow ip from 255.255.255.255 to any out
02111   0     0 pipe tablearg ip from table(guestnetwork_allowed_up) to any in
02112   0     0 pipe tablearg ip from any to table(guestnetwork_allowed_down) in
02113   0     0 pipe tablearg ip from table(guestnetwork_allowed_up) to any out
02114   0     0 pipe tablearg ip from any to table(guestnetwork_allowed_down) out
02115   0     0 pipe tablearg ip from table(guestnetwork_auth_up) to any layer2 in
02116   0     0 pipe tablearg ip from any to table(guestnetwork_auth_down) layer2 out
02117   0     0 fwd 127.0.0.1,8003 tcp from any to any 443 in
02118   0     0 fwd 127.0.0.1,8002 tcp from any to any 80 in
02119   0     0 allow tcp from any to any out
02120   0     0 skipto 65534 ip from any to any
65534   0     0 deny ip from any to any
65535   0     0 allow ip from any to any

IPFW table contents:

--- table(cp_ifaces), set(0) ---
vmx2 2100 0 0 0
--- table(guestnetwork_auth_up), set(0) ---
--- table(guestnetwork_host_ips), set(0) ---
10.3.1.1/32 0 0 0 0
--- table(guestnetwork_pipe_mac), set(0) ---
 00:90:0b:7a:8a:66 any 2001 0 0 0
 any 00:90:0b:7a:8a:66 2000 0 0 0
--- table(guestnetwork_auth_down), set(0) ---
--- table(guestnetwork_allowed_up), set(0) ---
198.51.100.9/32 2002 0 0 0
--- table(guestnetwork_allowed_down), set(0) ---
198.51.100.9/32 2003 0 0 0

In either case, though the IPFW ruleset shows lots of hits on the allow any/any rule, traffic fails to pass. The host is actively sending out ICMP unreachable messages for its own addresses when it happens.

To compare, here is the ruleset from the second captive portal system from 2.4.4-p3:

01000   69  31388 skipto tablearg ip from any to any via table(cp_ifaces)
01100 4072 948086 allow ip from any to any
02100    0      0 pipe tablearg ip from any to any MAC table(guestnetwork_pipe_mac)
02101    0      0 allow pfsync from any to any
02102    0      0 allow carp from any to any
02103    0      0 allow ip from any to any layer2 mac-type 0x0806,0x8035
02104    0      0 allow ip from any to any layer2 mac-type 0x888e,0x88c7
02105    0      0 allow ip from any to any layer2 mac-type 0x8863,0x8864
02106    0      0 deny ip from any to any layer2 not mac-type 0x0800,0x86dd
02107    0      0 allow ip from any to table(guestnetwork_host_ips) in
02108   68  31352 allow ip from table(guestnetwork_host_ips) to any out
02109    0      0 allow ip from any to 255.255.255.255 in
02110    0      0 allow ip from 255.255.255.255 to any out
02111    0      0 pipe tablearg ip from table(guestnetwork_allowed_up) to any in
02112    0      0 pipe tablearg ip from any to table(guestnetwork_allowed_down) in
02113    0      0 pipe tablearg ip from table(guestnetwork_allowed_up) to any out
02114    0      0 pipe tablearg ip from any to table(guestnetwork_allowed_down) out
02115    0      0 pipe tablearg ip from table(guestnetwork_auth_up) to any layer2 in
02116    0      0 pipe tablearg ip from any to table(guestnetwork_auth_down) layer2 out
02117    0      0 fwd 127.0.0.1,8003 tcp from any to any 443 in
02118    0      0 fwd 127.0.0.1,8002 tcp from any to any 80 in
02119    0      0 allow tcp from any to any out
02120    1     36 skipto 65534 ip from any to any
65534    1     36 deny ip from any to any
65535    6   3037 allow ip from any to any

The table contents are identical.

Actions #1

Updated by Jim Pingle almost 5 years ago

  • Assignee set to Luiz Souza

Luiz is looking into this one

Actions #2

Updated by Luiz Souza almost 5 years ago

  • Status changed from Confirmed to Feedback
  • % Done changed from 0 to 100

Should be fixed in the next snapshot.

Actions #3

Updated by Jim Pingle almost 5 years ago

  • Status changed from Feedback to Resolved

Works well on CE 2.4.5.a.20200117.0757. Enabling Captive Portal does not affect traffic on interfaces not involved in Captive Portal. Captive Portal works as expected for clients on interfaces where it is enabled.

Thanks!

Actions

Also available in: Atom PDF