[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: outbound addresses and PF



I have already read the damn manual:

This technique allows a *single* IP address on the translating host to
support network traffic for a larger range of machines on an "inside"
network

I know how NAT works and I understand the concept, and I am using it
now.  The functionality I was commenting on is this:

On your *ONE* external NIC you have lets say 10 IP's (say you are on a
T1).  You can do this in unix if I am not mistaken... bind several IP's
to 1 adapter.  In PIX, outbound connections are round-robin'ed on the
external IP's that you have setup.  STILL NAT'd mind you, but spread
across several IP's.  That is what I am commenting on.  It is useful in
our PIX environment, I thought it might be useful in OpenBSD
environments as well.  Because as far as I have been able to read, PF
only supports NAT'ing to 1 IP.  If this is wrong then I need to be
pointed to the URL.  And if you believe that 1500 people's worth of
traffic, nearly saturating 3 T1s can be NAT'd out 1 IP address then
fine, I retract my request for comment on the additional functionality. 
It was my thinking that maybe Cisco had an interesting functionality...



On Fri, 2002-12-13 at 18:55, Michael Shalayeff wrote:
> Making, drinking tea and reading an opus magnum from Geoff Sweet:
> > I tried digging through the archives and google on this one and found a
> > few things that were close, but I thought I would ask in misc anyway. 
> > Has the idea of adding functionality to PF ever been considered, where
> > PF could round robin multiple IP's outbound from a firewall?  I notice
> > that with devices such as PIX you can have a pool of IP addresses that
> > it uses for outbound connections.  I personally would find that sort of
> > functionality very useful, sort of a load balancing scheme.  And believe
> > me if my programming skills were up to par, I would attack it myself,
> > until then I just buy alot of CD's.   :-) 
> 
> general rule is to read the damn manual before inventing new
> functionality, then you would know how to use nat that
> implements the proposed by your feature.
> 
> cu