I have a PIX (Version 6.3) 515E configured with an inside and outside
interfaces. I want to transition the existing T1 connection to a new
T1 connection. In doing so, I'd like to have the existing static NAT
definitions to work across both connections until the DNS is
transferred over and then the original T1 connection is
de-commissioned. So say I had:

outside: 11.11.11.128/25
outside2: 22.22.22.96/27
inside: 10.0.0.0/24

Essentially what I would like to do is:

global (outside) 10 interface
global (outside2) 20 interface

nat (inside) 10 0.0.0.0 0.0.0.0 0 0

static (inside,outside) 11.11.11.130 10.0.0.10 netmask 255.255.255.255
static (inside,outside2) 22.22.22.110 10.0.0.10 netmask 255.255.255.255

The PIX translates connections into 11.11.11.130 properly. It receives
ping requests on 22.22.22.110, but no responses. I believe this is
because of the default NAT route is back through outside. I could of
course change the default NAT route to outside2, but then it should
break the existing static NATs. How do I go about implementing this as
I believe it is possible?

In article <1147736347.046102.63470@v46g2000cwv.googlegroups. com>,
Lone <junkmail@nexxis.net> wrote:
That's fine provided that there is an unambiguous way to determine
which traffic should head to outside and which should head to
outside2. As long as the range of source IPs that can read one of the
two interfaces is fixed, you can use static "ip route" statements.
The step above that would to allow dynamic routing configuration
via OSPF, but unless you already have OSPF set up, that's probably
not the best way to proceed.

What you cannot do is have two default routes and expect that
because a packet came in via one interface, that the PIX will
"somehow" remember the interface and reply back through that interface.
The PIX cannot do that. The PIX figures out which interface to
go to via the routing tables -- packet by packet.



There is no such thing as a "NAT route". If you are thinking of

global (outside) 10 interface
global (outside2) 20 interface
nat (inside) 10 0.0.0.0 0.0.0.0

then you need to know that the "0.0.0.0 0.0.0.0" of the nat statement
is NOT a route: it is a source IP selector on outgoing traffic. For
example, you could have

nat (inside) 10 10.0.0.5 255.255.255.255
nat (inside) 20 10.0.0.16 255.255.255.240
nat (inside) 30 0.0.0.0 0.0.0.0

and that would mean to apply global policy 10 to packets sourced from
host 10.0.0.5, global policy 20 for packets sourced from 10.0.0.16-.31
and global policy 30 for all other inside source packets.
But those aren't routes: they do not control which interface the
traffic heads towards. Routes are handled via "ip route" or
rip or ospf. Having different policies for the same inside interface
allows you to select which IP address different hosts will
present themselves as when going out through the -same- interface.

If arbitrary packets might enter through either interface, then
you cannot do what you want through anything like the technique
you are working with.... but under some conditions, you can
do it via "reverse nat". I've written the constraints and
configuration instructions in a few earlier postings in this newsgroup.