If one pass captive portal and the other is pass (no need auth) ??

jet0202ttt

thank your replay ….
| wan
|
pfsense
| lan
|
| wan
wireless ap
|
| lan (enable dhcp)
client1 client2
I think the key point is wreless ap wan gateway is point to pfsense lan,
clinet1 and client2 have the same ip (wireless wan ) when they
connect to pfsense captive portal, so if one have pass through authenticated
the other is pass without authentication

so why can i do, to make every client connet to pfsense have themself ip address
, use NAT or another ??????

buraglio

It sounds like you're using another router with wireless built into it for your wireless access, which also means you're likely also doing dual PAT. I always recommend against any kind of dual PAT/NAT because it adds levels of unnecessary complexity, but if you're willing to support it, have at it.
Personally, I'd switch to a real access point that just bridges wireless traffic. You could probably do some 1:1 NAT trickery on the wireless router and maybe make it work but thats not really a best practice solution or something I want to get into on so you're on your own with that one.

I'd recommend something like this:

nb

jet0202ttt

thank you any way :

| wan (to internet)
pfsense
| lan (enable captive portal)
|
| wan
wireless ap

client1 client2

client1 and client2 all is wireless client

joe_adk

I have a similar problem with guests adding their own wireless routers, and leaving it unsecured. This bypasses captive portal for 2-n users, as long as the guest logs in the first time. Anyone know how to stop that?

buraglio

That is a tough one especially if they do NAT. Low timeout values on the login page and a lot of user education is the real way to handle it. A lot of stumbling for the locations of rogue access points, etc. It's a pain.
I had to deal with it a little and basically went around shutting down ports on the switches (after using flow data / arp to determine best guess which port(s) they are coming from). It's a bit of a "sledgehammer to kill a fly" way of doing it but it works. No one plugs that crap in anymore or else they get shut down till I feel like turning them back on.

tomdchi

What I am attempting to do and I think it should work in your case also is this. Don't have a login page on the captive portal. Authenticate via mac address only. The captive portal can have sign up info and you can set the ip's to your website for ordering in the allow ip's section.

One other thing to try is to map the known mac addresses to a static ip's for your dhcp server. Then set a allias for the dhcp addresse range. use the alias in the traffic shapper with the penalize function and throttle the bandwidth way down. This one would be the easiest to try and while it would not stop the problem the connection they get while using a wireless router will be crap.

buraglio

This would work, in a way, but most of the wireless broadband routers will clone MACs (if they are worth a darn) and the bandwidth may not (read: won't be) be the issue. The amount of flows generated, in my experience, is almost always more of an issue. Too many flows can crumble a lower end router/firewall/etc.

eri--

There is a software called p0f which claims to identify NAT and other things.
Part of it is implemented in pf for OS detection but not for the NAT part and i do not know how successful it is at finding such things.
AFAIK the technique it uses to find NATed traffic is reliable especially when the NATed environment is from inexperienced users.

joe_adk

Thanks, everyone, for replying. p0f http://lcamtuf.coredump.cx/p0f.shtml sounds like what I would want (and what I was hoping was available). I currently use the buraglio method, but it is time consuming.

eri--

Do a feature request for this and comment if you are willing to test and support this in any way so i doesn't get forgotten.

buraglio

I've used p0f for some other stuff (baselining active OSs on the networ, etc) but it does seem like a good package to have in pfsense. I've had mixed results using it to "discover" NAT, it may have improved since I last used it. I ran it off of an optical tap and a copper SPAN, it may work better inline (although I don't see why it would really make a difference). I've been wrong before.

I'd be willing to test this and help in making it a package as time permits.

nb

eri--

I replied at this other post.
http://forum.pfsense.org/index.php/topic,10392.0.html

Please, keep this under the same thread so it can be tracked easily.