Date: Wed, 10 Dec 2008 11:20:11 -0800 From: Christopher Cowart <ccowart@rescomp.berkeley.edu> To: Olivier Nicole <on@cs.ait.ac.th> Cc: freebsd-questions@freebsd.org Subject: Re: Firewall with bridged interfaces and captive portal Message-ID: <20081210192011.GC3409@hal.rescomp.berkeley.edu> In-Reply-To: <200812040337.mB43bGHE015979@banyan.cs.ait.ac.th> References: <200812030508.mB358SUx095910@banyan.cs.ait.ac.th> <20081203222520.GA19693@hal.rescomp.berkeley.edu> <200812040337.mB43bGHE015979@banyan.cs.ait.ac.th>
next in thread | previous in thread | raw e-mail | index | archive | help
--dkEUBIird37B8yKS
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Olivier Nicole wrote:
>>> I need to implement a firewall with bridged interfaces that offers
>>> captive portal (authentication before opening the traffic).
>>=20
>> We are using a combination of squid+ipfw. Although we are NATing the
>> users, that really just introduces needless complexity that could be
>> avoided with a bridging solution.
>>=20
>> Our web-app/captive portal/authentication program is written in-house;
>> it's very tightly integrated with several existing pieces of
>> infrastructure. I don't know if there are any solutions that will work
>> out-of-the-box.
>>=20
>> I can get you more technical details if this is a direction you'd be
>> interested in moving.
>=20
> Long time ago I have been toying with ipf (for the genral firewall)
> and NoCat+ipfw for the captive portal.
>=20
> But that did not work too well, so any technical information will be
> appreciated :)
>=20
> My long term vision is a quite integrated thing, where users that read
> their email and authenticate to POP3/IMAP would be granted the access
> without the need to authenticate to the web portal.
Hi,
Sorry it's taken a while to get back to you on this.
You're going to want to get squid up and running as a transparent proxy.
You will probably want to write a redirect script [1]. Mine checks
against a small set of always-authorized URLs that squid is allowed to
proxy for; any other HTTP request will receive a redirect:
printf "302:%s%s\n" "${default_url}" "$suffix"
The URL points to the webserver running on the aux-router (as we call
it). The www user has passwordless sudo rules that allow the web code to
call scripts for adding and removing a client to and from ipfw tables [2].
You're also going to need to get ipfw to play with bridging. For this,
you'll need to `sysctl -w net.link.bridge.ipfw=3D1` [3].
The portion of your ruleset is going to look something like this:
TABLE_AUTH=3D'table(10)'
$cmd allow all from $TABLE_AUTH to any bridged
$cmd allow all from any to $TABLE_AUTH bridged
$cmd fwd 127.0.0.1,3128 tcp from $MY_SUBNET to any http bridged
$cmd deny all from any to any bridged
NB: you may need IPFIREWALL_FORWARD enabled to get full use of the fwd
action.
You'll also probably need to poke holes for or deal with DNS, any remote
webserver your authentication process may require access to, etc.
Also note, I haven't actually done this with bridging, so your mileage
my vary. I found 2 tools to be invaluable when working on this project:
1) tcpdump (use -i for interface, and watch the traffic in order to
profile exactly what you need to allow, fwd, etc.).
2) ipfw logging. I found that on any deny rule, especially when
troubleshooting, I'd do something like:
$cmd deny log logamount 0 all from any to any bridged
Or, just as useful, but you can stick anywhere in the middle without
affecting packet flow:
$cmd count log logamount 0 all from any to any bridged
NB: AFAIK, requires kernel option IPFIREWALL_VERBOSE
I might be able to give you some more pointers if you get stumped, but I
hope this helps you get well on your way.
[1] http://wiki.squid-cache.org/SquidFaq/SquidRedirectors
[2] ipfw(8) /LOOKUP TABLES
[3] ipfw(8) /PACKET FLOW
--=20
Chris Cowart
Network Technical Lead
Network & Infrastructure Services, RSSP-IT
UC Berkeley
--dkEUBIird37B8yKS
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)
iQIcBAEBAwAGBQJJQBZrAAoJEIGh6j3cHUNPmrkQAJqhs3wXTkWbQN0Bye4dufjN
ot50eNBrh7ycNAdy5Kgj1fm1iawt3jMPGAIKxYKMyLU/3P0VDG0lyhdMgiRiCNlP
K9XStHWC3ghZVyiiiUH7pd8A10wJkxkrNVLvL1iaggPnbCyoZzElk7cdMcC7wFJl
oQXNRefkspG0A3mi+vkCZfg5rkq+t01Ytd52NlyWCluhQsuC6uWkevK9eqDwTEtU
MRwIg9EKyDBXVoHizJmO80Wy1pgN6dP7Wph63pAVJoZQxeZ0w3jKccygdVc7IlfY
QAIeduLgtV0/mIT10E34r9d9vQCTUg/NQ6sLZlD5hZ+J25sTg6Hv74ZchJhfxG36
geuryxc7vmpVXr/foKsmb1Bek8oeEbSFp1WUkDhR9TSlR7KiUjtixVokwmbJ57EJ
qK8rQqZWBCIJWK+5EIE3vo3I3lAgEp/EzOTTurGP+9wATK1p2J8f1dSD3rcJ6EXY
Gi7fX+4byAsNjXXRlv1erdWgWvKpzoRzKbLqVnBtlqau+59GPn7wxPb1qWYrodek
dguA2clPGJZB3nSyUGE4ewRqL9KOAYEuk22J/B0gAY6Hm+/2KWGQJ1cG0MRgGiI3
cvx5W/yj9OafRb9i1bKAKT9cU4gAaG5Xba30kGbMfDtm0mLbMkwUFSn1yNoWcac1
gRZIy0pQmR1dfPYapB3Y
=ziR6
-----END PGP SIGNATURE-----
--dkEUBIird37B8yKS--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081210192011.GC3409>