Note: This is an existing thread in google groups, and I just copied and pasted the text. I really need some help with figuring this out, thanks.
-------------------------------
I have a customer, they just got an Eschelon T1 in addition to their
existing wireless broadband from Sprint. I have been searching through
groups trying to find a definitive answer, but can't...I need to how
routing can be implimented using NAT over just the broadband.
They have a block of 8 from Eschelon, and the pix already nat/pat
internal net, but they want their traffic outbound (just from hosts;
all server traffic will go over the T1) to go over the wireless.
Obviously it doesn't need to be nat'd again over the T1, but how can I
get it out the broadband link? I'm pretty sure I need to nat because Sprint
won't take the Eschelon block over their network, and I'm just not
familiar enough with route-map statements to configure them myself.
Can I use a nat statement for just the interface of the PIX (which is
the pat int of the internal hosts) over the fa0/0 of the router?
Reply
-bump-
Here is what someone has helped me with...
Thanks for the response. I will try this soon, but what I don't
understand is how either the pix or the router will know how to split
traffic out either end. The route statements don't look at source,
only destination, right? So the default route on the router is set for
Sprint, wouldn't all unknown traffic get pushed out that anyway,
regardless of the policy on the pix...? Again, I'm not too keen on,
nor a big fan of, the pix, so bear with me.
Also to clarify, they don't have a separate block from Sprint. Prior
to this install, it was a little Linksys router that was auto-assigned
an IP, and it was in a /24 block. I don't think that is correct, but
regardless they don't have a dedicated block to play with. They may
have one or two on the same subnet, but I need to double-check. So can
the policy still use an IP that isn't a "leased block" so to speak?
-----Original Message-----
On the 501, have two distinct nat (inside) policy numbers, one of
which matches the servers (-all- of their traffic is to go over the T1,
right?), and the other policy number for the other hosts.
Then have two distinct global (outside) statements, one for each
policy. On the global policy for the servers, have the outside IP be
one appropriate for the Eschelon. On the global policy for the other
hosts, have the outside IP be one appropriate for sprint wireless.
Then at the 1841 level, do *not* NAT the IPs. Do, however, add one or
more ip route statements to point both those IP ranges towards the
outside interface IP of the PIX.
As long as the packet gets to the outside of the PIX (because of the
'ip route') then the PIX will not care that the packet is or is not
part of the outside IP range: the PIX will look through its tables and
see that it has a translation for that IP and will put the packet
through as appropriate.
To emphasize and clarify: you may have an indefinite number of public
IP ranges being global'd (or static'd) to the outside of the PIX, and
as long as you route the packets to the PIX outside IP, the PIX will
handle them fine even though they are not in the interface subnet. The
PIX is happy to allow packets *through* that are not in the interface
subnet. The interface subnet is only important for when the PIX needs
to ARP the outside route destination, or when the PIX needs to *itself*
create traffic (e.g., you ping'd from a CLI, or you configured the PIX
to send RST packets), or the PIX needs to accept traffic itself (e.g.,
you ping the PIX -itself-, or you terminate a VPN tunnel at the PIX
interface.) But for traffic flowing through, the PIX doesn't care what
the IP range is as long as it has a translation.
