Project

General

Profile

Actions

Bug #2780

closed

CP: passthough has no effect

Added by Daniel Berteaud almost 9 years ago. Updated over 8 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Captive Portal
Target version:
Start date:
01/26/2013
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.1
Affected Architecture:

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

Actions #1

Updated by Chris Buechler almost 9 years ago

  • Target version set to 2.1
  • Affected Version set to 2.1
Actions #2

Updated by Ermal Luçi almost 9 years ago

Can you show

ipfw -x $cpzone show
ipfw -x $cpzone table all list

Actions #3

Updated by Daniel Berteaud almost 9 years ago

Here's the result (wifi is the name of my CP zone)

[2.1-BETA1][]/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(2): ipfw -x wifi table all list
[2.1-BETA1][]/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(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(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

Actions #4

Updated by Cyrill B almost 9 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
Actions #5

Updated by Cyrill B almost 9 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

Actions #6

Updated by Ermal Luçi almost 9 years ago

  • Status changed from New to Feedback

FIx has been included and should behave better in the later coming snapshots.

Actions #7

Updated by Daniel Berteaud almost 9 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(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(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(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)

Actions #8

Updated by Ermal Luçi almost 9 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

Actions #9

Updated by Fredrik Reuterswärd almost 9 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*

Actions #10

Updated by Daniel Berteaud almost 9 years ago

Sorry for the delay, here's the result:

[2.1-BETA1][]/root(1): sysctl -a | grep net.link.ether.ipfw
net.link.ether.ipfw: 1
[2.1-BETA1][]/root(3): sysctl -a | grep net.inet.ip.fw.one_pass
net.inet.ip.fw.one_pass: 1
[2.1-BETA1][]/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(5):

Actions #11

Updated by Renato Botelho almost 9 years ago

  • Status changed from Feedback to New
Actions #12

Updated by Phil Lavin almost 9 years ago

Also replicated here. Happy to provide debug info if it's required.

Phil

Actions #13

Updated by Renato Botelho almost 9 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.

Actions #14

Updated by Daniel Berteaud almost 9 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.

Actions #15

Updated by Ermal Luçi almost 9 years ago

  • Status changed from New to Feedback
Actions #16

Updated by Renato Botelho over 8 years ago

  • Status changed from Feedback to Resolved
Actions

Also available in: Atom PDF