Project

General

Profile

Actions
Copy link

Bug #4141

closed
PB

captive-portal on opt1 interface affects traffic going through other interfaces

Bug #4141: captive-portal on opt1 interface affects traffic going through other interfaces

Added by Pi Ba over 11 years ago. Updated over 11 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Captive Portal
Target version:
2.2
Start date:
12/23/2014
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.2
Affected Architecture:
amd64

Description

captive-portal on opt1 interface affects traffic going through other interfaces.

ive got a pfSense box with 3 interfaces (that i think are relevant) wan,lan,opt1 all have static ip's.
When i enable a captive-portal zone on the opt1 interface. I loose the ability to ping the lan-ip and lan-carpip from a machine that is connected to the wan interface. Ping's to the wan-ip and opt1-ip keep working though..

If i run "ipfw -x 2 delete 65534" to remove the "deny ip from any to any" rule from ipfw all the pings immediately start working again..

EL Updated by Ermal Luçi over 11 years ago Actions
Copy link
 #1

Can you show me an ipfw zone list when this happens?

PB Updated by Pi Ba over 11 years ago Actions
Copy link
 #2

Seems then that interface is wrongly added to the ipfw context.

ipfw zone list
Currently defined contextes and their members:
2: em2,em0,

PB Updated by Pi Ba over 11 years ago Actions
Copy link
 #3

Ok found the cause of the issue.
I have a ipv6 carp-ip "abcd::1234/64" defined on my wan interface. (its a test box.. so thats why the wierd ip..)

When link_ip_to_carp_interface is called, it checks if the interface ip is in the same subnet, and generates a wrong IPv4 subnet..

gen_subnet(10.10.10.10, 24) : 10.10.10.0
gen_subnet(abcd::1234, 64) : 0.0.0.0

Though this might be the wrong approach all together, as carp-ip does not need to be 'inside' a subnet of a interface..

PB Updated by Pi Ba over 11 years ago Actions
Copy link
 #4

When gen_subnet is fixed (for example by pulling [https://github.com/pfsense/pfsense/pull/958] ), ip_in_subnet(11.22.33.5,abcd::/64) is a next issue as it returns 'true'..

CB Updated by Chris Buechler over 11 years ago Actions
Copy link
 #5

  • Status changed from New to Closed

Thanks for diagnosis PiBa. #4148 has root cause

EL Updated by Ermal Luçi over 11 years ago Actions
Copy link
 #6

This will really be fixed when the carp interface link is made a strong one rather than the weak one that is today.
I am looking for a fix for now.

Actions
Copy link

Also available in: Atom