no body wrote:

> > A trivial example of what I am looking for is to allow local machines to
> > access an external DNS server without having to know its public IP address
> > or DNS name. All the local machines need to do is to place in their
> > configuration files the virtual local IP address that is NAT translated
> > to some external DNS.
> >
> > Then when the remote DNS fails - functionality can be restored by creating
> > another reverse=nat mapping to a functional DNS elsewhere. I then do not
> > have to reconfigure the local machines for DNS access.
>
> iptables that comes with the 2.4 kernel can do that. We have a Linux
> Security Server set up (from www.ComputerSecurityResearch.com, if that
> matters) that does the DNAT just as your example needs. All the internal
> boxes have their DNS pointing to the security server, and it in turn it
> DNATs the DNS requests out to the current DNS server. If that DNS server
> starts acting buggy we just make one change on the security server and all
> the clients benefit from the change. Sounds like just what you need.
>
> Now here's one hitch I can see, and I see the way around it. Let's say you
> have networks A and B, each with more than one machine, and each with only
> one public IP (or IP that will be used to link them together). So computer
> A.1 wants to connect to B.1, the security server for A correctly changes the
> destination IP to B's public IP. B's security server gets this packet and
> doesn't know which internal computer to send it to.
>
> The way around it is what we've done with this security server. A's and B's
> security servers create an IPSEC tunnel between them and have route entries
> that say "anything for B's net - route to B's IPSEC IP" and likewise for A.
> Works like a charm because their isn't any DNAT involved. You wouldn't need
> the tunnel, we just needed the data to be secure between the networks.
>
> In the case where you have A, B, and C *and* two networks (say B and C) have
> the same private address range, you have the combination of the two examples
> above put together. A's network thinks B's and C's networks are actually
> different, and a DNAT translation happens on B's and C's security servers.
> What you end up with is a "global address map" that says network A has this
> "public" range (not true public, but only used once within all your
> networks), B has this "public" range, etc... Then anything destined for A
> will be addressed to that "public" range, and A's security server is
> expected to do the DNAT to the real internal IP address.
>
> It's complicated, but it works. And none of our local nets had to get
> renumbered.
>
> One thing that stinks is the one-to-one NAT. Each box has one line DNAT,
> and one line SNAT per internal IP. The nice thing here is the only NAT is
> happening on the security server responsible for those IPs. This lets us
> add more IPs to a network without having to go change all the security
> servers, we just change the one that manages that network. And the load of
> doing the NAT is on the local security server, so if we have a new local
> network with thousands of IPs, we get a more powerful (as in CPU/mem)
> security server just for that network, we don't have to upgrade the whole
> infrastructure to support the increase in NATs of more IPs. That security
> server is the only one that realizes the load of those additional IPs and
> their resultant NATs.

Another project I am working with is a backend secure or top-secret
capable network that will handle traffic to 15,000 - 35,000 separately
administered private networks. I am finding it extremely difficult to acquire
public registered IP addresses in North America for each security server
to NAT address its resources. Many of the 15,000 - 35,000 networks
will have conflicting private addresses. This secure private backbone
will not be connected to the Internet.

I am toying with the idea of using a registered address space
allocated to some other continental IP registry for use in this
virtual link-layer backbone. With appropriate NAT policy, the local
network attached devices, except for the security access servers,
will have no knowledge of the link-layer backbone transport network.
All services advertized by NAT to the link-layer backbone will
be reverse-NAT advertized into each local network as a virtualized
local IP address.

I cannot use the "link-layer" address block reserved by IANA
because the special use is for development of zeroconf IPv4
devices. The operation of these devices on the "link-layer"
address block makes the address space unusable for the secure
backbone service.

IPsec-ESP has problems if the tunnel endpoints are address-translated.

With the "link-layer" transport in question, and that security devices
have both forward NAT and reverse NAT to protect and isolate
the addressing zones, IPsec operations fail.

Local Network A

Host A [192.168.1.1] --> transport Host-A [14.1.1.1]
Virtual Host A' [192.168.1.2] <-- transport Host-B [14.2.2.2]

Local Network B

Host B [192.168.1.1] --> transport Host-B [14.2.2.2]
Virtual Host B' [192.158.1.2] <-- transport Host-A [14.1.1.1]

Without encryption, Host-A can communicate with Host-B by addressing
Virtual Host A'

Without encryption, Host-B can communicate with Host-A by addressing
Virtual Host B'

Attempts to link Network A and Network B with IPsec, and other IP tunnel
protocols fails because of the network address translation issues.
Tunnel technology currently requires Network A and Network B tunnel
endpoints to be in separate IP address zones (not sharing the same subnet
or IP addresses).

What will work for security is the use of SSL or TLS at the application
interface to a communications path suchas TCP or IP-Stream. But there are
currently few programs that are SSL/TLS compliant. I know of NO IP Tunnel
protocols that are compatible with the endpoints being address translated.

- Steve Hathaway