Re: Bridging vlans w/firewall and selective HTTP redirect?

From: dima (_pppp_at_mail.ru)
Date: 09/29/04

  • Next message: dima: "Re: IPFW and 5.2.1" 
    To: Kevin Schmidt <kps@ucsb.edu>
Date: Wed, 29 Sep 2004 15:50:48 +0400

    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,

    _______________________________________________
    freebsd-net@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-net
    To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"

  • Next message: dima: "Re: IPFW and 5.2.1"