In article <2DYdd.5164$ et>,
Scooby <> wrote:
|> "ae" <> wrote in message
|> news:B7Vdd.8590$ m...
|> > Obviously, Companies A & B have identical IP address space.
|> > The requirements are these:
|> > 1. Traffic between Host A & B must be in VPN tunnel.
|> > 2. Host A can use Router A's overloaded external address. This way Host B
|> > sees Host A as having an address of 100.1.1.1 (Router A's address).
|This can become a difficult solution on the pix
The PIX handles the situation relatively cleanly.
The old solution on the PIX was to use the 'alias' command.
The 'alias' command had two different meanings, though, and
has been functionally replaced by new options on static and nat
commands, allowing a finer control.
The new solution on the PIX would be to use "reverse nat" (also called
"bidirectional nat"). On A, one would configure something like,
static (outside, inside) 192.168.2.0 192.168.1.0 netmask 255.255.255.0 dns
Then, to send to B's 192.168.1.N, the user would addres the packet
to 192.168.2.N. As the packet was preparing to cross the outside
interface, the destination IP would be mapped to the corresponding
192.168.1.N IP before being sent over the tunnel to B. The host on
B replies, the response comes through the tunnel, and A then
maps the source address of the reply packet from 192.168.1.N to the
corresponding 192.168.2.N IP before passing the packet on to the
original inside computer. This completes the circuit.
The 'dns' option on the end specifies that if A requests DNS
resolution from a host beyond the outside interface (could be
somewhere on the internet, could be somewhere on B's site),
then if the DNS response contains any IPs in the 192.168.1.N range,
then the PIX will alter the response to be 192.168.2.N instead.
Thus, if there is a DNS server at B that returns 192.168.1
IP addresses for B's hosts, the response will be altered so that
the host at A is handed the right IP to use to get to the resource
on B. If A has a DNS server for its own internal resources
and that DNS server is in the 'inside' or is on any DMZ interface,
and A isn't trying to resolve it's own IP addreses from something
beyond the 'outside' interface, then the 192.168.1.* IP returned
internally or from a DMZ will -not- be changed, and so will
refer to A's resource with that IP.
However, if the DNS servers for A and B are -both- behind
the outside interface relative to A, then you must *not* use the
'dns' option, or else the PIX will know whether any
particular 192.168.1.* address was at A or B, and the PIX will just
go ahead and translate them all as if they were at B. If you are
trying to use overlapping IP ranges with DNS servers that return
the internal 192.168.1.* IP addresses, then you can't do it with
straight-forward DNS configuration and the 'dns' option if the
DNS servers are both outside of 'A' and outside of 'B' as well.
[If the DNS server for A is on the internet and the DNS server
for B is inside B, then you should do the reverse-NAT trick at B instead
of at A.]
If the DNS servers for A and B are both outside relative to A and B
then do not use the 'dns' option: instead, use DNS servers that can
do "split views" (such as bind9), and have it return different
answers depending on whether it sees that A or B are asking the
question.
(IOS runs into the same issues about placement of DNS servers.)
So... on PIX you can often get the desired behaviour by simply
adding a single 'static' to one of the two ends. That's a lot easier
than creating pools and loopback interfaces and whatever else.
--
Caution: A subset of the statements in this message may be
tautologically true.
|
Similar Threads
