Project

General

Profile

Actions
Copy link

Bug #4903

closed

Captive Portal ipfw rules are not correctly including interface CARP VIPs

Added by Jim Pingle over 9 years ago. Updated over 9 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Captive Portal
Target version:
2.2.5
Start date:
07/29/2015
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.2.x
Affected Architecture:
All

Description

With Captive Portal on an interface with a CARP VIP, 2.1.x properly included the CARP VIP in the ipfw rules:

65310  206529   22569562 allow ip from any to { 255.255.255.255 or 192.168.1.1 or 192.168.1.3 } in

The same configuration on 2.2.4 yields:

65310   569   82492 allow ip from any to { 255.255.255.255 or 192.168.1.3 or 192.168.1.3 } in

Notice the interface IP address is repeated in the 2.2.x version and the CARP VIP is missing.

Actions
Copy link
 #1

Updated by Jim Pingle over 9 years ago

There is similar code in filter.inc and captiveportal.inc for these rules. The code in filter.inc generates rules for pf, captiveportal.inc for ipfw. The code is nearly identical except for a few different intermediate steps specific to the respective filters.

https://github.com/pfsense/pfsense/blob/RELENG_2_2/etc/inc/filter.inc#L2947
https://github.com/pfsense/pfsense/blob/RELENG_2_2/etc/inc/captiveportal.inc#L492

Sometimes the code in filter.inc manages to collect the interface IP addresses, IP Alias VIPs and CARP VIPs, but other times it fails the same way as the code in captiveportal.inc

For example:

: grep 800 /tmp/rules.debug
pass in  quick on { em1 } proto tcp from any to { 192.168.71.2 192.168.71.1 1.2.3.4 } port { 8003 8002 } tracker 1000000551 keep state(sloppy)

(some time later after a few filter reloads):
: grep 800 /tmp/rules.debug
pass in  quick on { em1 em1 } proto tcp from any to { 192.168.71.2 192.168.71.2 } port { 8003 8002 } tracker 1000000551 keep state(sloppy)

There is apparently a much deeper issue here than anticipated.

Actions
Copy link
 #2

Updated by Jim Pingle over 9 years ago

  • Status changed from Confirmed to Feedback
  • % Done changed from 0 to 100
Actions
Copy link
 #3

Updated by Jim Pingle over 9 years ago

Actions
Copy link
 #4

Updated by Sander Peterse over 9 years ago

Jim P wrote:

Applied in changeset 6538d22fcb8068b276585b6cc2b4f7b9b0c58829.

This resolved the issue for me, tested on PFSense 2.2.4 x64. Thanks!

Actions
Copy link
 #5

Updated by Sander Peterse over 9 years ago

A note on my previous comment:

First this fix didn't work, these rules were missing (in 'ipfw -x 2 show'):

allow ip from any to { 255.255.255.255 or 192.168.X.253 or 192.168.X.1 } in
allow ip from { 255.255.255.255 or 192.168.X.253 or 192.168.X.1 } to any out
allow icmp from { 255.255.255.255 or 192.168.X.253 or 192.168.X.1 } to any out icmptypes 0
allow icmp from any to { 255.255.255.255 or 192.168.X.253 or 192.168.X.1 } in icmptypes 8

Missing these rules means that everything is allowed through the captive portal. I had to disable the captive portal, click save, enable it again and hit save once more.

Actions
Copy link
 #6

Updated by Jim Pingle over 9 years ago

  • Status changed from Feedback to Resolved

Yes, after applying the patch the ipfw/CP rules will need a kick (or, ideally, a reboot) -- that won't be an issue for those who get the fix as part of a firmware upgrade since it would reboot after the upgrade anyhow.

Thanks for confirming the fix!

Actions
Copy link

Also available in: Atom PDF