Bug #16264
open
Ethernet rules generated by Captive portal can block ARP
100%
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
Updated by Danilo Zrenjanin 5 months ago
In ticket 24032478035, disabling XML-RPC for Captive Portal helped stop the issue from occurring. The symptoms were very similar.
Updated by Christopher Causer 5 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.
Updated by Lev Prokofev 4 months ago
- File clipboard-202507031604-v3sfd.png clipboard-202507031604-v3sfd.png added
- File clipboard-202507031604-svctj.png clipboard-202507031604-svctj.png added
- File clipboard-202507031605-zvwil.png clipboard-202507031605-zvwil.png added
- File clipboard-202507031606-apesg.png clipboard-202507031606-apesg.png added
Updated by Marcos M about 1 month 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.
Updated by James Turner 14 days 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.
Updated by Marcos M 8 days ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Applied in changeset pfsense:604a7b0d4d31e332d6fd4111b22ee29416e0700d.