Bridging vlans w/firewall and selective HTTP redirect?
dima
_pppp at mail.ru
Wed Sep 29 04:50:53 PDT 2004
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,
More information about the freebsd-net
mailing list