We use the switches in a client's executive office suite buildings. We needed a way to provide internet access on a per suite basis, and we needed to provide public addresses on an as-needed basis (if they had a mail server, for example). We had a previous solution in place, but it was about 8-9 years old, and required manual intervention when tenants move from suite to suite (which happens a lot in these buildings).
So our new (15 month old at this point) setup has 3 vlans on the switches:
"private unauthenticated", "private authenticated", and "public
authenticated". ("private" and "public" refer to the address spaces in use on
the vlans). As part of that setup, we use mac-based authentication on the HP
switches. So, a client (aka tenant) can be plugged into any port on the
switch, and the FreeRADIUS package from pfSense can provide authentication and
VLAN assignments to the switch, and the switch will use the RADIUS information
to put them on the correct VLAN automatically. For any client that does not
authenticate, the switch throws them on the "private unauthenticated" vlan,
and then the client cannot get on the internet without authenticating with the
pfsense captive portal (the custom captive portal page pretty much says "hey,
you aren't getting on the internet unless you pay the land lord more $$. If
you want access, call up xxx and give them this mac address:
xx:xx:xx:xx:xx:xx"). If their mac address is present in FreeRADIUS, then they
get put on whatever vlan is assigned them from the vlan box. The "private
authenticated" vlan is a private address space vlan that is NATted to the
internet, and the "public authenticated" vlan is directly on the internet. In
order to keep clients from seeing each other on the "private authenticated"
vlan (basically this vlan is for tenants that have a single pc with no
router), we add the following to each client entry in the "Additional RADIUS
Options" box:
HP-Nas-Filter-Rule = "permit in ip from any to 172.20.1.1", HP-Nas-Filter-Rule
+= "deny in ip from any to 172.20.1.0/24", HP-Nas-Filter-Rule += "permit in ip
from any to 0.0.0.0/0"
This permits the clients to talk to the gateway and the rest of the internet,
but not to any other machine on the same subnet.
I don't know how much of this applies to your setup, but to sum up this
solution, unauthenticated clients get put on a vlan that can't get on the
internet (they can, but are "stopped" by a custom captive portal page from
pfSense that tells them what to do), and authenticated clients get put on
vlans that can freely access the internet. In your case, you might just need
to use FreeRADIUS along with some switch ACLs (in the "Additional RADIUS
Options" box) to allow/limit/prevent internet access.
Hopefully that made some sense. It's a bit tough to describe without seeing
it! :)
Dimitri Rodis
Integrita Systems LLC
http://www.integritasystems.com
-----Original Message-----
From: Tim Dressel [mailto:[email protected]]
Sent: Friday, May 08, 2009 9:07 PM
To: [email protected]
Subject: Re: [pfSense Support] Captive Portal Question
Hi folks,
Just an update. I built a new machine from the ground up today. Took a
backup from the old machine, and just copied and pasted the 300+
mac-bypass entries into the new config file. Everything is working
well, and as expected.
I'm interested though Dimitri on the switch issue. I'm connected
entirely to new managed HP 2848's and 2510G-48's and I have great LAN
performance. Are you doing something directly with your switches as
far as authentication goes, or did you just include the switches for
completeness?
Finally, I'd appreciate any feedback out there on installs with counts
on mac bypass entries topping a 1000 count. I am considering tying
together several of my networks and would like to know what the upper
end on the captive portal looks like.
Thanks!
On Fri, May 8, 2009 at 1:33 AM, Dimitri Rodis
<[email protected]> wrote:
> We have a pfSense setup with the FreeRADIUS package that authenticates folks
> that plug in to HP 3500yl and 2626 switches-- the set up is for a few
> executive office suite buildings that are linked together by fiber and all
> share a single 10Mb symmetric connection to the internet. 0 problems for
> about
> 15 months now--still running on 1.2-release. If you have some good managed
> switches, that's the way to do it IMHO.
>
> Dimitri Rodis
> Integrita Systems LLC
> http://www.integritasystems.com
>
> -----Original Message-----
> From: RB [mailto:[email protected]]
> Sent: Thursday, May 07, 2009 3:16 PM
> To: [email protected]
> Subject: Re: [pfSense Support] Captive Portal Question
>
> On Thu, May 7, 2009 at 15:55, Tim Dressel <[email protected]> wrote:
>> 1. What is the limitation on the number of mac-bypass entries? And is
>> what I am seeing expected with 300 entries?
>
> I'm sure someone will chime in with the precise ipfw limitation, but
> this is mostly going to be dependent on your system's performance
> specs - memory & CPU.
>
>> 2. If I should not be doing this with 300 clients, is anyone using
>> another FOSS product to do MAC authenticated control outbound from
>> their firewall?
>
> Possibly, but [as I hope you know] MAC filtering only keeps honest
> people honest, it is in no way any form of authentication. At that
> number of unique users, you may be better served by setting up an
> actual RADIUS server to do proper authentication and AAA instead of
> manually maintaining tables.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
> Commercial support available - https://portal.pfsense.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
Commercial support available - https://portal.pfsense.org
smime.p7s
Description: S/MIME cryptographic signature
