|
|
|
|
|
|
| Author |
Message |
Tilman Bohn *nix forums beginner
Joined: 14 Mar 2005
Posts: 5
|
Posted: Mon Mar 14, 2005 5:08 am Post subject:
Re: Non-trivial dual bridge + pf
|
|
|
Sorry to follow up on my own post, just a quick clarification:
In message <slrnd3a9pq.q8b.myfirstname@urizen.tilmanbohn.com>,
Tilman Bohn wrote on Mon, 14 Mar 2005 06:55:06 +0100:
[...]
| Quote: | Q1. Will it be possible to prevent intranet segment 2 from being routed
while routing and NATing segment 1? In my previous bridging
experience it didn't look like OpenBSD had a clear concept of which
interface belonging to a bridge individual hosts were attached to.
|
This should have read `didn't look like _pf_ had a clear concept of
which interface...' The bridging code itself obviously knows where each
host lives, otherwise it wouldn't work. ;-)
--
Cheers, Tilman
`Boy, life takes a long time to live...' -- Steven Wright |
|
| Back to top |
|
 |
Tilman Bohn *nix forums beginner
Joined: 14 Mar 2005
Posts: 5
|
Posted: Mon Mar 14, 2005 4:55 am Post subject:
Non-trivial dual bridge + pf
|
|
|
Hi all,
I'm in the process of switching a client's Linux based firewall to
OpenBSD, and for what I need it to do it seems two bridges would be a
good fit (I'm running a similar but simpler, single bridge setup on
another client's site with good results). However, I'd like to run this
by a few more eyes to see if there's anything especially insane about
it.
Ok, the basic topology would look like this:
------------
|Router ISP|
------------
|
em0
------------
[Intranet]--em2| GW |em3-- [Intranet]
[segment 1] ------------ [segment 2]
em1
|
[DMZ]
br0 = em0+em1, DMZ: allocated IPs
br1 = em2+em3, Intranet: RFC 1918 IPs
where I'd have two `crossed' bridges plus routing between _some_ of the
attached segments of the bridged subnets. The way I see it I'd need one
IF in each bridge to have its own IP for reasons stated below.
Now what I want to achieve by this is the following:
1. Get some separation between the two intranet segments, but allow
specific SMB traffic between them -- headaches with cross-subnet SMB
are the main rationale for bridging these two, and hosts in segment
2 should really not sit in the same physical network as the other
intranet machines. (I might transition the SMB stuff to some other,
saner protocol later, but not at this time.)
2. Get to use the whole subnet allocated to my client from the ISP
instead of having to split it up (as is done now). Hosts in the DMZ
are offering external services, but IPs are getting close to running
out.
3. Do NAT for intranet segment 1 -- and only segment 1! -- on em0, which
is why I think I'll need to configure em0 and em2 with their own IP
from the respective subnets: em2 for clients to set their default
route to (since em0 and em2 are _routed_, not bridged), em0 for
NATing their addresses to.
4. Route Intranet segment 1 both to the internet via em0 (NATed, as I
mentioned) and to the DMZ via em1, but whether or not they're NATed
when speaking to the DMZ doesn't matter much.
5. Don't route Intranet segment 2 _anywhere_. It should only be able to
talk SMB to segment 1.
The points I'm least sure if they will be possible or if they could
present problems in this setup are:
Q1. Will it be possible to prevent intranet segment 2 from being routed
while routing and NATing segment 1? In my previous bridging
experience it didn't look like OpenBSD had a clear concept of which
interface belonging to a bridge individual hosts were attached to.
I saw a recent thread here about `bridge issues with pf rules on
OpenBSD/Sparc' <JMF-44A797.22053822022005@comcast.dca.giganews.com>
that conformed my suspicions that this might turn out to be a
problem, but there didn't seem to be a resolution in that thread.
Any ideas?
Q2. Will I kill performance because all IFs will run PROMISC? I have
absolutely no performance problems with other bridged setups, but
here I'm a bit concerned about the traffic between the two intranet
segments affecting service for DMZ hosts to the outside. I don't
really _expect_ there to be a problem in this regard though.
Q3. The basic setup seems fairly straightforward to me, but are there
any other pitfalls in it I just haven't considered? Should I be
aware of some additional limitations that make this plan infeasible
or at least tricky? Or is it in fact less straightforward than I
think it is, and others would consider it looney? ;-)
I feel like I'm forgetting some other question I had, but the post is
long enough as it is, and I'd be most appreciative of any thoughts
others might have on this planned layout.
--
Cheers, Tilman
`Boy, life takes a long time to live...' -- Steven Wright |
|
| Back to top |
|
 |
Google
|
|
| Back to top |
|
 |
|
|
The time now is Thu Jan 08, 2009 5:09 pm | All times are GMT
|
|
Final Fantasy | Tour Management Software | Bankruptcy | Loans | Soul Calibur III Mp3
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|