From: Herman <Herman@AerospaceSoftware.com>
To: tsh@mrc-lmb.cam.ac.uk
Cc: netfilter@lists.netfilter.org
Subject: Re: Bridge question
Date: Fri, 17 Oct 2003 07:49:50 -0600 [thread overview]
Message-ID: <200310170749.50608.Herman@AerospaceSoftware.com> (raw)
In-Reply-To: <200310170839.h9H8dY8206228@alf1.lmb.internal>
Hmmm, could you clue me up a little more?
Our problem is this:
- Hotel with 300 rooms.
- VLANs on 3COM switches to isolate the guests and consolidate the feed, back
to the server.
- Kernel 2.2 server system - does not understand VLAN packets and rejects
them.
As a stop-gap, until the server is updated to kernel 2.4, we want to filter
the VLAN Q-tags using a kernel 2.4 bridge. We have this working, but the
bridge works like a hub and connects everything to everything, so then the
VLAN 'security' is lost, putting us back to square one.
We therefore need to add filtering capability to the bridge to keep the guests
separated. Preferably, this should be done at the ethernet level, but since
this is a stopgap solution, we could use netfilter to block certain packets
to prevent guests from browsing each other.
Now, the part from your comment that I don't understand is 'proxy ARP'.
Could you clue me up?
We're using netfilter as a filtering bridge + NAT + local router between
us and the the local university router (via which we are attached to
*its* LAN) using proxy arp and iptables. It's been running happily for
about 1.5 years (touch wood) supporting about 1200 hosts behind it.
What I have been thinking, in order to avoid having to apply patches to the
kernel to get bridge+iptables to work, is to simply use more ethernet ports
and loop two of them with a cross-over cable. Then run a bridge between eth0
and eth1, loop eth1 to eth3 and run iptables between eth2 and eth3. Kludgy
but doable. Finally, use iptables as an Ingress filter to the Bridge to
block the MS Windows Network Neighborhood feature, making the usual kind of
guest unable to browse other guests.
The 3COM switches will then be connected to the iptables side of the thing and
the server to the bridge side. Technically, the VLAN security will still be
lost, but the addition of iptables will allow us to limit the damage and have
improved isolation between guests.
Comments?
Cheers,
--
Herman Oosthuysen
B.Eng(E), MIEEE
Aerospace Software Ltd.
Ph: 1.403.241-8773, Cell: 1.403.852-5545, Fx: 1.403.241-8841
Herman@AerospaceSoftware.com, http://www.AerospaceSoftware.com
next prev parent reply other threads:[~2003-10-17 13:49 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-16 22:02 Isolate a legacy machine Ringer, Torleiv
2003-10-17 3:15 ` Bridge question Herman
2003-10-17 3:46 ` Mark E. Donaldson
2003-10-17 8:39 ` tsh
2003-10-17 13:49 ` Herman [this message]
2003-10-17 13:37 ` Jeremy Jones
2003-10-17 13:52 ` Herman
2003-10-17 3:52 ` Isolate a legacy machine Bill Chappell
2003-10-17 4:37 ` Joel Newkirk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200310170749.50608.Herman@AerospaceSoftware.com \
--to=herman@aerospacesoftware.com \
--cc=netfilter@lists.netfilter.org \
--cc=tsh@mrc-lmb.cam.ac.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox