Bug #2780
closedCP: passthough has no effect
Added by Daniel Berteaud almost 12 years ago. Updated over 11 years ago.
0%
Description
I've just updated to Jan 25 snapshot (amd64) and passthrough (MAC or IP address) doesn't work anymore. It seems to have no effect at all, I always have to log into the captive portal
Updated by Chris Buechler almost 12 years ago
- Target version set to 2.1
- Affected Version set to 2.1
Updated by Ermal Luçi almost 12 years ago
Can you show
ipfw -x $cpzone show ipfw -x $cpzone table all list
Updated by Daniel Berteaud almost 12 years ago
Here's the result (wifi is the name of my CP zone)
[2.1-BETA1][root@pfsense.domain.local]/root(1): ipfw -x wifi show
65291 0 0 allow pfsync from any to any
65292 0 0 allow carp from any to any
65301 14 626 allow ip from any to any layer2 mac-type 0x0806,0x8035
65302 0 0 allow ip from any to any layer2 mac-type 0x888e,0x88c7
65303 0 0 allow ip from any to any layer2 mac-type 0x8863,0x8864
65307 0 0 deny ip from any to any layer2 not mac-type 0x0800,0x86dd
65310 3 237 allow ip from any to { 255.255.255.255 or 192.168.17.1 } in
65311 3 346 allow ip from { 255.255.255.255 or 192.168.17.1 } to any out
65312 0 0 allow icmp from { 255.255.255.255 or 192.168.17.1 } to any out icmptypes 0
65313 0 0 allow icmp from any to { 255.255.255.255 or 192.168.17.1 } in icmptypes 8
65314 0 0 pipe tablearg ip from table(3) to any in
65315 0 0 pipe tablearg ip from any to table(4) out
65316 0 0 pipe tablearg ip from table(1) to any in
65317 0 0 pipe tablearg ip from any to table(2) out
65532 0 0 fwd 127.0.0.1,8000 tcp from any to any dst-port 80 in
65533 0 0 allow tcp from any to any out
65534 21 2357 deny ip from any to any
65535 5 364 allow ip from any to any
[2.1-BETA1][root@pfsense.domain.local]/root(2): ipfw -x wifi table all list
[2.1-BETA1][root@pfsense.domain.local]/root(3):
In the CP settings, I've added b8:c6:8e:f3:a1:43 in Mac-Passthrough and 192.168.19.253 in Allowed IP Addresses.
If I log into the CP with the device which has MAC address b8:c6:8e:f3:a1:43 (because I'm redirected to the login page), here's the result of ipfw -x wifi table list all:
[2.1-BETA1][root@pfsense.domain.local]/root(5): ipfw x wifi table all list
---table(1)--
192.168.17.11/32 mac b8:c6:8e:f3:a1:43 2046 126 16228
---table(2)---
192.168.17.11/32 mac b8:c6:8e:f3:a1:43 2047 172 200094
[2.1-BETA1][root@pfsense.domain.local]/root(6):
Allowed IP Addresses are essentials for me (it allows my own computers to bypass the CP with a VPN connection). For now, I had to revert to Nov 25 snapshot (which is the last I've tried where everything in the Captive Portal works on amd64). Just as a side note (maybe this should go in another bug), in the Allowed IP addresses settings, the Direction drop-down list (both, from or to) doesn't appear anymore.
Regards, Daniel
Updated by Cyrill B almost 12 years ago
Ermal LUÇI:
It seems that when configuring pipes the context argument is not correctly handled.
ipfw -x guest pipe 2006 config bw 0Kbit/s queue 100 buckets 16
ipfw: setsockopt(IP_DUMMYNET_CONFIGURE): Invalid argument
Updated by Cyrill B almost 12 years ago
The direction support has been removed in commit [1] but the "Allowed Hostnames" configuration still shows the form fields.
[1] https://github.com/bsdperimeter/pfsense/commit/aea564088a335bef9c9d6fb55409dd0ad65b3049
Updated by Ermal Luçi almost 12 years ago
- Status changed from New to Feedback
FIx has been included and should behave better in the later coming snapshots.
Updated by Daniel Berteaud almost 12 years ago
I've just tested snapshot Jan 27. MAC passthrough seems to be working fine, but Allowed IP addresses are not. Here's the output of the two ipfw commands:
[2.1-BETA1][root@pfsense.domain.local]/root(1): ipfw \-x wifi show
00032 0 0 pipe 2080 ip from any to any MAC b8:c6:8e:f3:a1:43 any
00033 0 0 pipe 2081 ip from any to any MAC any b8:c6:8e:f3:a1:43
65291 0 0 allow pfsync from any to any
65292 0 0 allow carp from any to any
65301 5 212 allow ip from any to any layer2 mac-type 0x0806,0x8035
65302 0 0 allow ip from any to any layer2 mac-type 0x888e,0x88c7
65303 0 0 allow ip from any to any layer2 mac-type 0x8863,0x8864
65307 0 0 deny ip from any to any layer2 not mac-type 0x0800,0x86dd
65310 5 372 allow ip from any to { 255.255.255.255 or 192.168.17.1 } in
65311 5 494 allow ip from { 255.255.255.255 or 192.168.17.1 } to any out
65312 0 0 allow icmp from { 255.255.255.255 or 192.168.17.1 } to any out icmptypes 0
65313 0 0 allow icmp from any to { 255.255.255.255 or 192.168.17.1 } in icmptypes 8
65314 0 0 pipe tablearg ip from table(3) to any in
65315 0 0 pipe tablearg ip from any to table(4) out
65316 0 0 pipe tablearg ip from table(1) to any in
65317 0 0 pipe tablearg ip from any to table(2) out
65532 0 0 fwd 127.0.0.1,8000 tcp from any to any dst-port 80 in
65533 37 15216 allow tcp from any to any out
65534 124 20138 deny ip from any to any
65535 20 18424 allow ip from any to any
[2.1-BETA1][root@pfsense.domain.local]/root(2): ipfw \-x wifi table all list
---table(3)---
192.168.19.253/32 2082 0 0
---table(4)---
192.168.19.253/32 2083 0 0
[2.1-BETA1][root@pfsense.domain.local]/root(3):
I don't quite understand what's wrong, looks like the tables have the correct entries (I've allowed IP 192.168.19.253), but I still cannot connect to it until I log into the CP (which is what I want to avoid)
Updated by Ermal Luçi almost 12 years ago
Can you check the following sysctl values
net.link.ether.ipfw net.inet.ip.fw.one_pass
they should be 1 on both.
Also the output of
sysctl -a | grep pfil
Updated by Fredrik Reuterswärd almost 12 years ago
I have the same problem using build Jan 28 08:16:34 EST 2013
Both net.link.ether.ipfw and net.inet.ip.fw.one_pass are set to 1
sysctl -a | grep pfil
net.inet.ip.pfil.inbound: pf, ipfw*
net.inet.ip.pfil.outbound: pf, ipfw*
net.link.bridge.pfil_local_phys: 0
net.link.bridge.pfil_member: 1
net.link.bridge.pfil_bridge: 0
net.link.bridge.pfil_onlyip: 0
net.inet6.ip6.pfil.inbound: pf, ipfw*
net.inet6.ip6.pfil.outbound: pf, ipfw*
Updated by Daniel Berteaud almost 12 years ago
Sorry for the delay, here's the result:
[2.1-BETA1][root@pfsense.domain.local]/root(1): sysctl -a | grep net.link.ether.ipfw
net.link.ether.ipfw: 1
[2.1-BETA1][root@pfsense.domain.local]/root(3): sysctl -a | grep net.inet.ip.fw.one_pass
net.inet.ip.fw.one_pass: 1
[2.1-BETA1][root@pfsense.domain.local]/root(4): sysctl -a | grep pfil
net.inet.ip.pfil.inbound: pf, ipfw*
net.inet.ip.pfil.outbound: pf, ipfw*
net.link.bridge.pfil_local_phys: 0
net.link.bridge.pfil_member: 1
net.link.bridge.pfil_bridge: 0
net.link.bridge.pfil_onlyip: 0
net.inet6.ip6.pfil.inbound: pf, ipfw*
net.inet6.ip6.pfil.outbound: pf, ipfw*
[2.1-BETA1][root@pfsense.domain.local]/root(5):
Updated by Renato Botelho almost 12 years ago
- Status changed from Feedback to New
Updated by Phil Lavin over 11 years ago
Also replicated here. Happy to provide debug info if it's required.
Phil
Updated by Renato Botelho over 11 years ago
Since when to/from/both direction options were removed on aea564088a it started to consider Allowed IPs just as From. We still need to discuss if this function should or not be restored, I'll keep the ticket as New for now.
I've committed 5b0e0182c7 a bandaid to fix it for now.
Updated by Daniel Berteaud over 11 years ago
Just updated to snapshot Wed Feb 27 and I confirme that the problem is fixed now, both MAC passthrough and Allowed IP are working.
Updated by Renato Botelho over 11 years ago
- Status changed from Feedback to Resolved