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 over 9 years ago
Can you show me an ipfw zone list when this happens?
Updated by Pi Ba over 9 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 over 9 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 over 9 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 over 9 years ago
- Status changed from New to Closed
Thanks for diagnosis PiBa. #4148 has root cause
Updated by Ermal Luçi over 9 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.