Duncan Hill wrote:
> 
How about this:

You set up a box on your "Outside" network that does NAT/PAT for
the duplicated IP space!
Lets see if the ascii survives communicator:

you have a setup like this, right?:

+----------+
| Internet |
+----------+
        |
     +---------------+
     | border router |
     +---------------+
        |
+-------------+
|   PIX       |  <--NAT'ing bogus internal addresses
+-------------+
          |
      +--------------+
      | bogus ip net |  <-using addresses registered
      +--------------+     to other.com.


What about doing it like this?
+----------+
| Internet |
+----------+
        |
     +---------------+
     | border router |
     +---------------+
        |
     +---------------+
     |linux/bsd/cisco| <--NAT's other.com addrs, pass-thru else.
     +---------------+
        |
        |
+-------------+
|   PIX       |  <--NAT'ing bogus internal addresses
+-------------+
          |
      +--------------+
      | bogus ip net |
      +--------------+


See? your PIX converts internal addresses to a valid
one, so the DMZ will never see your internal addresses.
You set up the linux box ipchains acl's to forward
everything except the "disputed" ip range, which it
NATs to some valid address.

This lets your servers correctly respond to requests
from other.com, but still doesn't let your bogus machines
connect as clients to other.com's servers.

Does that fix your problems?

> On Fri, 2 Jun 2000, Alan Mead wrote:
> 
> > >external host with the same IP as a server on the inside requests
> > >something from the inside host, it gets through fine, and receives an
> > >answer fine due to the way the PIX does the translation.
> >
> > When you say "determine internal and external traffic by the address" you
> > lose me.  It's entirely possible that a local host and a remote host are
> > both using the same IP, right?  So for those few remote hosts that share
> 
> Yes, that is possible.  However, the requests are being made to my
> external address, not my internal one.  So, theoretically (highly!), I
> should be able to tell that the request was for my external.  However,
> I'm not familiar enough with the translation rules of the firewall.
> 
> --
> 
> Duncan Hill                     Sapere aude
> My mind not only wanders, it sometimes leaves completely.
> 
> --
> To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
> as the Subject.

-- 
-------------------------------------
Sam Bayne - System Administrator
North Seattle Community College
[EMAIL PROTECTED]     (206)527-3762
=====================================


-- 
To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
as the Subject.

Reply via email to