Captive portal issue, Apple devices pass thru without authentication

never-enuff

I have several captive portals running and I have been told by a few people that although they are working great and stopping most computers with a login screen, alot of ipad's and even some ipod's can pass right thru without ever needing to login to the CP. I have tried to reproduce this and have a couple of times, so my next question is, what could be causing this and what logs could I provide that will provide a clue to why Apple products do not get a login screen but everyone else does.

Thank you

Dickie

wallabybob

@never-enuff:

I have several captive portals running and I have been told by a few people that although they are working great and stopping most computers with a login screen, alot of ipad's and even some ipod's can pass right thru without ever needing to login to the CP.

PERHAPS these devices are piggybacking off a previous login from the same AP or a previous login from another device which has the same MAC address (shouldn't happen BUT …)

I suggest you track down a device displaying this behaviour, determine its MAC address and attempt an access through the captive portal and see if the same MAC address is associated with a logged in user.

onlineph

This happened to me already. Not only apple products seemingly by-pass the log-in portal but they are simply piggy backing the active user's MAC address. I myself have replicated this event and I was able to by-pass my own CP. However, once the voucher expires the true user together with the piggy back rider will both lose connection.

I wonder, is it true that the BackTrack 5 can be able to hack CP?

cmb

You don't need Backtrack to "hack" a CP like that. If you don't have protections inside the network to ensure people aren't just seeing and swiping someone else's MAC and IP, you can reconfigure networking on most any kind of device to do so. By the time it reaches the firewall it's impossible to detect that, your switches and/or APs have to take care of that scenario.

The original poster's scenario sounds like what would happen when an AP is source NATing or MAC translating, that's the usual cause when we run into this kind of issue with support customers. Those devices are piggy backing off someone else's connection for that reason.

onlineph

I don't know if this is possible. I was wondering if someone in the pfsense expert core group could create a package that would could translate or camouflage the user's mac address into something like pfmac and then the unique pfmac would serve as the real mac user where pfsense acknowledges. The user's original MAC is translated in PFMAC everytime it authenticate or re-authenticate. In this way, even if the piggyback riders had the user's original MAC address, it can no longer be valid since it was already used and have been translated into pfmac.

So that user > authenticated via CP > MAC is transalated into PFMAC (once only) > PFsense would only acknowledge the PFMAC

So that when piggybacking using user's MAC > become invalid since a user's MAC can only be translated once.

It's just y wild imagination though… ;)

Gertjan

As cmb said above, most of that support should be handled in the AP.
He said it all by mentioning "By the time it reaches the firewall it's impossible to …."

But, the solution exists already for years - I'm using it for years. A message - way back - on this forum explain how it works. (I'll post a link if I can find that post).

The solution could be called: "use ebtables".
Today, another company made the solution VERY visible to you: Windows 6 and up. When you choose a PUBLIC network, it will disable all contact to local 'LAN' devices EXCEPT for the gateway (the portal interface, in this case). No more sharing - only contact to the 'internet' is possible.

But, clever guys could eve-drops the info on the LAN.
So, the AP, all AP, should be made 'more clever'.

What it should do:
Every Wifi/Portal connection can only be routed to the MAC interface of the portal interface of pfSEnse.
On every AP on my Poratl network, I have this

ebtables -L
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 4, policy: ACCEPT
-s 0:0:0:0:0:0/0:0:0:0:0:0 -d Broadcast -j ACCEPT
-s 0:0:0:0:0:0/0:0:0:0:0:0 -d 0:f:b5:fe:4e:e7 -j ACCEPT
-s 0:f:b5:fe:4e:e7 -d 0:0:0:0:0:0/0:0:0:0:0:0 -j ACCEPT
-j DROP

"0:f:b5:fe:4e:e7" is the MAC of my pfSEnse Portal interface (192.168.2.1).

These rules enforce the fact that NO-ONE can communicate with NO-ONE on the portal network, except for the gateway (the portal of pfSEnse).

Btw: most AP have this option in their admin interface. It's often being called 'AP Isolation'.
But if you have more then one AP, all linked together with a switch - you need ebtables (which is not iptables). APs with DD-WRT have it. Any good AP should have it.

This setup means that portal users should only connected to these AP's - no dumm switches should be used to wire-connect users to the Portal interface.
Normally, this is the typical setup for most Portal solutions. people aren't walking in with their desktop on their backs anyway.

PS: needles to say that I never saw iStuff using the connection of another iStuff ….. and my portal is being used: http://www.test-domaine.fr/munin/dyndns.org/brithotelfumel.dyndns.org/portaluser.html

onlineph

Thanks a lot for that info.

m4st3rc1p0

i have the same issue is there a fix for this.

Gertjan

There is no: "push a button and the problem is gone".

Read message 2,3 and especially 3 (cmb) and even mine: This is NOT a pfSense problem.
As said: if packet come into the Portal interface with the same MAC adress, same source IP then pfSEnse can't tell any difference.
Try for yourself: if your portal interface is a wire only solution - so hook all guest up with cables on a switch behind the OPT1-portal interface (so NO Wifi Acces points) then this problem will stop.
Draw your conclusions.

So, please, take 5 minutes - do the test I proposed, and see what happens. Post back with the results.

Btw: this is not a 'iPod-Pad-Phone-Mac-Apple' problem.

m4st3rc1p0

here's what, i setup a new pfsense and configure it to serve my LAN and VLAN's desktop. Captive portal i serving well all workstations however smartphones were able to browse the internet without authenticating to the portal and how did that happen ?

wallabybob

@m4st3rc1p0:

however smartphones were able to browse the internet without authenticating to the portal and how did that happen ?

You have provided nowhere near enough configuration information for me to say definitely. Perhaps captive portal is not enabled on the pfSense interface upstream of the smartphones. Perhaps the smartphones are downstream of some device that has authenticated with the captive portal and they are "piggybacking" on that device's access. Perhaps they are going through some proxy. Perhaps …

I suggest you provide a network network diagram showing at least a few of the smartphones exhibiting the behaviour, the upstream pfSense box and relevant interfaces, any intermediate devices and the IP address and subnet mask of all the interfaces on the diagram.

m4st3rc1p0

hi, here's your request attaching my network diagram.

@wallabybob:

@m4st3rc1p0:

however smartphones were able to browse the internet without authenticating to the portal and how did that happen ?

You have provided nowhere near enough configuration information for me to say definitely. Perhaps captive portal is not enabled on the pfSense interface upstream of the smartphones. Perhaps the smartphones are downstream of some device that has authenticated with the captive portal and they are "piggybacking" on that device's access. Perhaps they are going through some proxy. Perhaps …

I suggest you provide a network network diagram showing at least a few of the smartphones exhibiting the behaviour, the upstream pfSense box and relevant interfaces, any intermediate devices and the IP address and subnet mask of all the interfaces on the diagram.

![NETWORK DIAGRAM.jpg](/public/imported_attachments/1/NETWORK DIAGRAM.jpg)
![NETWORK DIAGRAM.jpg_thumb](/public/imported_attachments/1/NETWORK DIAGRAM.jpg_thumb)

wallabybob

I presume the smartphones access the Internet through one of the APs on your diagram.

I suspect that the APs are doing NAT for the smart phones which would mean that pfSense would not be able to distinguish between two different smartphones using the same AP, hence a smart phone could "piggy back" on the authentication of another smart phone on the AP. You probably need to operate the APs as bridges rather than NAT routers. I am not familiar wit the APs you are using. Do they have multiple "LAN" ports and a "WAN" port?

m4st3rc1p0

All AP's does not have authentication they are open as authentication are being processed on Captive Portal using mac pass through. All AP's is under VLAN and PFSense is also servicing DHCP for that VLAN. My question in this is that Smarthphones connecting via AP's does not have any records on Captive Portral but they were able to by pass it ?

As I said earlier this is a new setup PFsense 2.0.1 and Portal is serving workstation well that means authentication page are being seen on all workstation except to all smartphones.

I forgot to mention all AP's are just running as bridge, and all IP being thrown are from PFSense DHCP Server (VLAN)

TIA

@wallabybob:

I presume the smartphones access the Internet through one of the APs on your diagram.

I suspect that the APs are doing NAT for the smart phones which would mean that pfSense would not be able to distinguish between two different smartphones using the same AP, hence a smart phone could "piggy back" on the authentication of another smart phone on the AP. You probably need to operate the APs as bridges rather than NAT routers. I am not familiar wit the APs you are using. Do they have multiple "LAN" ports and a "WAN" port?

Gertjan

Is it possible that the SmartPhone have any notion about the 1.1.1.1/24 network ?
I mean, if they get hold on and 1.1.1.1/24 the would not even see/hear/feal your pfSense installation.

But, why only smartphones act like this is strange. They have no such thing as a special power to avoid portal pages. I'm pretty sure you won't find ANY communication on the pfSEnse box. Just try this : pull out the 1.1.1.1/.24 cable on your pfsense box and see if the smartphohes are still connected.
If they do: and as said in another thread (http://forum.pfsense.org/index.php/topic,61954.0.html), remove SQUID & SNORT and see what happens.

m4st3rc1p0

i think i found the problem, after carefully checking the routes, the policy i have on firewalls and how the device passes over pfsense. Ok i will list it in details:

PFSEnSE is implementing a fail-over rule (I grouped the two ISP so it will served my failover)
ON firewall policy i define objects that will be under my failover setup
both LAN and VLAN contains both policy for failover
PFSense Captive Portal INterface is LAN and VLAN.

What I did is remove the failover policy (gateway) on the objects and put an any-any policy for testing purposes, and restarted Captive portal. After restarting the services of Portal I did run a test on Smartphones and BOOOOMMM there goes the login screen of portal.

I enable again the policy and there it goes the phone can by pass the portal and workstation cannot ! . This is really weird can someone enlighten me on this.

TIA

Gertjan

Good thing to here !

Btw: did your never thought about making your network more - simple -.