Project

General

Profile

Actions
Copy link

Bug #16264

closed

Captive Portal Ethernet rules can block ARP

Added by Lev Prokofev 6 months ago. Updated 8 days ago.

Status:
Resolved
Priority:
Normal
Assignee:
Marcos M
Category:
Captive Portal
Target version:
2.9.0
Start date:
Due date:
% Done:

100%

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

Description

The setup is on an HA pair, Captive portal configured on LAN interface (ix0)

            <if>ix0</if>
            <spoofmac></spoofmac>
            <enable></enable>
            <ipaddr>192.168.7.4</ipaddr>
            <subnet>29</subnet>

Ethernet ruleset:

# pfctl -s ether
ether pass on ix0 l3 all tag cpzoneid_2_rdr
ether anchor "cpzoneid_2_auth/*" on ix0 l3 all
ether anchor "cpzoneid_2_passthrumac/*" on ix0 l3 all
ether anchor "cpzoneid_2_allowedhosts/*" on ix0 l3 all
After the random time, the primary node stops passing the ARPs on IX0 for all hosts

It starts to work if the subnet is tagged by "cpzoneid_2_auth"

 echo 'ether pass in quick proto 0x0806 l3 from 192.168.7.0/29 tag cpzoneid_2_auth' | pfctl -a 'cpzoneid_2_auth/192.168.7.0_29' -f -

The issue never occurs on the secondary node.

Ticket for reference #23118866478 (additionally probably related tkt #24032478035)

Files

Download all files
clipboard-202507031604-v3sfd.png (928 KB) clipboard-202507031604-v3sfd.png Lev Prokofev, 07/03/2025 01:04 PM
clipboard-202507031604-svctj.png (479 KB) clipboard-202507031604-svctj.png Lev Prokofev, 07/03/2025 01:04 PM
clipboard-202507031605-zvwil.png (517 KB) clipboard-202507031605-zvwil.png Lev Prokofev, 07/03/2025 01:05 PM
clipboard-202507031606-apesg.png (382 KB) clipboard-202507031606-apesg.png Lev Prokofev, 07/03/2025 01:06 PM
Actions
Copy link
 #1

Updated by Danilo Zrenjanin 6 months ago

In ticket 24032478035, disabling XML-RPC for Captive Portal helped stop the issue from occurring. The symptoms were very similar.

Actions
Copy link
 #2

Updated by Christopher Causer 6 months ago

Danilo Zrenjanin wrote in #note-1:

In ticket 24032478035, disabling XML-RPC for Captive Portal helped stop the issue from occurring. The symptoms were very similar.

For our setup, we disabled XML-RPC for Captive Portal (both forwards and backwards) and this issue persisted.

Actions
Copy link
 #5

Updated by Marcos M 2 months ago

See if the following patch helps - it can be applied using the System Patches package.

diff --git a/src/etc/inc/captiveportal.inc b/src/etc/inc/captiveportal.inc
index 78f907f39a..0298c46245 100644
--- a/src/etc/inc/captiveportal.inc
+++ b/src/etc/inc/captiveportal.inc
@@ -2671,6 +2671,9 @@ function filter_captiveportal_ether() {
         $interfaces = captiveportal_zone_interfaces($cpcfg);

         if (!empty($interfaces)) {
+            /* prevent ARP from being sent to dummynet */
+            $rules .= "ether pass in quick on { {$interfaces} } proto 0x0806 tag \"{$rdrtag}\"\n";
+            $rules .= "ether pass out quick on { {$interfaces} } proto 0x0806\n";
             /* set 'rdr' tag for further captive portal web portal redirection */
             $rules .= "ether pass on { {$interfaces} } tag \"{$rdrtag}\"\n";
             /* anchor to set the PASS tag for authenticated clients */
@@ -2847,7 +2850,7 @@ function captiveportal_ether_configure_entry($hostent, $anchor, $user_auth = fal
     }

     $rules = "ether pass in quick {$macfrom} {$l3from} tag {$tag} dnpipe {$pipeup}\n";
-    $rules .= "ether pass out quick {$macto} {$l3to} tag {$tag} dnpipe {$pipedown}\n";
+    $rules .= "ether pass out quick {$macto} {$l3to} dnpipe {$pipedown}\n";

     captiveportal_load_pfctl("{$cpzoneprefix}_{$anchor}", $host, $rules);
 }

Make sure to reload the filter after applying the patch.

Actions
Copy link
 #6

Updated by James Turner about 2 months ago

We've upgraded to 25.07.1 and applied the patch. Without the patch it only managed a few hours before losing ARP, but it's now managed almost two days and is still up. So that's looking fairly promising.

Actions
Copy link
 #7

Updated by Marcos M about 2 months ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100
Actions
Copy link
 #8

Updated by Marcos M about 2 months ago

  • Subject changed from In some circumstances, ethernet rules generated by the Captive portal block the ARP to Ethernet rules generated by Captive portal can block ARP
Actions
Copy link
 #9

Updated by Marcos M about 2 months ago

  • Assignee set to Marcos M
  • Target version set to 2.9.0
Actions
Copy link
 #10

Updated by Marcos M about 2 months ago

  • Project changed from pfSense Plus to pfSense
  • Category changed from Captive Portal to Captive Portal
  • Affected Plus Version deleted (24.11)
  • Plus Target Version set to 25.11
Actions
Copy link
 #11

Updated by Jim Pingle about 1 month ago

  • Subject changed from Ethernet rules generated by Captive portal can block ARP to Captive Portal Ethernet rules can block ARP
Actions
Copy link
 #12

Updated by Kris Phillips 8 days ago

  • Status changed from Feedback to In Progress

Customer reports that this issue is still the same, but now the "Incomplete" MAC addresses are no longer present in the MAC table.

Some devices are able to connect at the same time others are not.

They are running 25.07.1 with all patches applied.

Actions
Copy link
 #13

Updated by Marcos M 8 days ago

  • Status changed from In Progress to Resolved

That confirms this specific issue with ARP is resolved. It sounds like something else is happening there (e.g. #16540). I suggest removing any added patches and testing on 25.11 instead (which includes the fix for #16540).

Actions
Copy link

Also available in: Atom PDF