Bug #4141
closedcaptive-portal on opt1 interface affects traffic going through other interfaces
0%
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..
Updated by Ermal Luçi almost 10 years ago
Can you show me an ipfw zone list when this happens?
Updated by Pi Ba almost 10 years ago
Seems then that interface is wrongly added to the ipfw context.
ipfw zone list Currently defined contextes and their members: 2: em2,em0,
Updated by Pi Ba almost 10 years ago
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..
Updated by Pi Ba almost 10 years ago
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'..
Updated by Chris Buechler almost 10 years ago
- Status changed from New to Closed
Thanks for diagnosis PiBa. #4148 has root cause
Updated by Ermal Luçi almost 10 years ago
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.