Bridging vlans w/firewall and selective HTTP redirect?

[dima]

Would you bother reading cisco tech documentation regarding 802.1x?
http://cisco.com/en/US/products/hw/switches/ps628/products_configuration_guide_chapter09186a008022995b.html
It states you can configure guest vlan for non-authentified users; you
can also temporarily disable infected users' accounts.
So, I guess you should only configure your networking hardware & radius
server properly. Also make a common remedy web/ftp server in the guest
vlan (which would contain both 802.1x software and
anti-compromise/infection information).

PS: A PC wouldn't ever give you the traffic/packet rates equal to the
hardware ones; especially at the layer 2. Just use the things in the
tasks they were designed for.

> I'm interested in placing an FBSD box (prefer 4.x since it's production, 
> though I've also used 5.2) inline on a link with 802.1Q-tagged vlans with 
> firewalling and selective HTTP redirects.  Bridging a couple of ethernets 
> isn't a problem, and it appears I can enable ipf or ipfw (but not pf; too 
> bad, ALTQ and pfsync would be nice).  What does not appear viable is the 
> interception and transparent redirect of HTTP traffic in this bridged 
> environment.  Anyone know of a good way to do this?
> 
> The purpose of the above is to support a wireless network where users may be 
> associated with various vlans, some of which will require selective traffic 
> filtering and transparent http redirects.  For example, there might be an 
> SSID for a "readme" vlan network where people could log in to a web page and 
> download an 802.1X supplicant.  The supplicant would be preconfigured to join 
> another SSID, e.g. "campus wireless", which would allow authenticated users 
> full Internet access.  If a particular user is known to have a 
> compromised/infected system, they'd be mapped to a quanantine vlan, which 
> ideally would block most traffic and redirect them to a web page with 
> additional information and remediation tools.  Similar techniques would be 
> used to support an https login process that would selectively open the 
> firewall for authenticated users.  I'm sure someone reading this is 
> wondering, "why not do the web redirects on a routed interface instead of 
> with an inline bridge, since redirects at an L3 interface work?"  The answer 
> is scalability and roaming:  I'd like routing to be done at a couple of 
> upstream Cisco boxes, with two or more FBSD boxes inline on the downstream 
> vlans supporting wireless and (ultimately) some wired ports.  I'll do it 
> routed if I must, but it would be great if I could redirect locally at the 
> bridge.
> 
> I'm looking at Linux/OpenBSD/NetBSD, too, though I've always preferred FBSD 
> (still have my 1.x CDs) and have happily used it for DNS, web, ftp, etc. 
> servers for years.
> 
> Any suggestions/comments/questions welcome.
> 
> Cheers,