Re: Firewall with bridged interfaces and captive portal
Olivier Nicole wrote:
I need to implement a firewall with bridged interfaces that offers
captive portal (authentication before opening the traffic).
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.
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.
I can get you more technical details if this is a direction you'd be
interested in moving.
Long time ago I have been toying with ipf (for the genral firewall)
and NoCat+ipfw for the captive portal.
But that did not work too well, so any technical information will be
appreciated :)
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=1` [3].
The portion of your ruleset is going to look something like this:
TABLE_AUTH='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
--
Chris Cowart
Network Technical Lead
Network Infrastructure Services, RSSP-IT
UC Berkeley
pgpPfbyITHbVi.pgp
Description: PGP signature
Re: Firewall with bridged interfaces and captive portal
Olivier Nicole wrote: I need to implement a firewall with bridged interfaces that offers captive portal (authentication before opening the traffic). [...] Is there any solution that exists? I looked at pfSense, but captive portal does not work on bridged interfaces; it's one or the other. Any other suggestion? Hello, 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. 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. I can get you more technical details if this is a direction you'd be interested in moving. -- Chris Cowart Network Technical Lead Network Infrastructure Services, RSSP-IT UC Berkeley pgpLZMO2kRw0d.pgp Description: PGP signature
Re: Firewall with bridged interfaces and captive portal
Hi Chris, I need to implement a firewall with bridged interfaces that offers captive portal (authentication before opening the traffic). 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. 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. I can get you more technical details if this is a direction you'd be interested in moving. Long time ago I have been toying with ipf (for the genral firewall) and NoCat+ipfw for the captive portal. But that did not work too well, so any technical information will be appreciated :) 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. Best regards, Olivier ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Firewall with bridged interfaces and captive portal
Olivier Nicole wrote: Hi Chris, I need to implement a firewall with bridged interfaces that offers captive portal (authentication before opening the traffic). 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. 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. I can get you more technical details if this is a direction you'd be interested in moving. Long time ago I have been toying with ipf (for the genral firewall) and NoCat+ipfw for the captive portal. But that did not work too well, so any technical information will be appreciated :) 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. For squid have a look at the option auth_param You are able to use your own authorisation app/script that can check all kinds of places to see if that IP is allowed access. For example I have a client that has samba on his transparent proxy. Each user has a drive letter mapped to that share. The script defined by auth_param just greps the ip from 'smbstatus -p' and uses the username with that IP to tell squid what user it is for the logs. There would be nothing to stop the script to check ipfw, to see if there is rules for that ip to allow access and then if there isn't, add them. To remove the ipfw rules you could have a cron script that checks the last packet time (using -t or -T) and if its over a certain time then remove it (preferably with the checking of where you got the initial check to see if the user is valid or not). HTH cya Andrew Best regards, Olivier ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
