Thanks for the reply Jason.

Actually, the routing was completely correct.  I spent 5 hours on the phone 
with TAC yesterday and they confirmed that it was a bug with the double 
NAT.  For some reason, IOS NAT, when presented with already NATed traffic, 
won't properly send the traffic to a default route.  Strangely enough, I 
was able to test another double-NAT situation, this time with two PIX 
boxes, and I had no issues at all.  As a workaround, I had to put policy 
routing in place with a bunch of statements for the servers that needed to 
"ACK" traffic from the old network.

Thanks again,
Craig

At 03:24 AM 5/25/2001 -0400, you wrote:
>What if you move the default route to toward the PIX?  I bet it works then.
>How is the router to know where to forward the packets just because there is
>a NAT in place?  The NAT happens as the packets go from one interace to the
>other, but that is still depending on routing taking place for it to know
>where to send it.  Why not just set up a static route toward the PIX for the
>old network?
>
>--
>Jason Roysdon, CCNP+Security/CCDP, MCSE, CNA, Network+, A+
>List email: [EMAIL PROTECTED]
>Homepage: http://jason.artoo.net/
>
>
>
>""Craig Columbus""  wrote in message
>[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > I'm about to open a case with Cisco regarding this issue, but I'm curious
> > if anyone out there has run into something similar:
> >
> > Background:
> > A company is migrating networks.  For various reasons, the following
> > network is in place.
> > Cisco 1720: has a fast ethernet connecting to the PIX, an ethernet
> > connecting to the old network, and a Serial connecting to the Internet.
> > Ethernet0 Interface has address 1.1.1.3/24, routing all "old-network"
> > traffic to 1.1.1.1.  This is also a NAT Outside interface.
> > Fast Ethernet0 has address 2.2.2.1/26, routing all inbound "new network"
> > traffic to 2.2.2.2 (PIX Outside Interface).  This is a NAT Inside
>interface.
> > Serial 0 is the default-route for all destinations not found in the route
> > table.
> >
> > Problem:
> > When traffic is sent to a 1.1.1.x address, it gets translated properly
>into
> > a 2.2.2.x address and routed to the PIX.  The PIX translates the 2.2.2.x
> > address to a (static) 10.x.x.x address.  The traffic reaches the
> > destination machine inside the network.  The machine then tries to
respond
> > to the original source.  The PIX recognizes and properly translates the
> > traffic.  The Cisco 1720 does not translate any traffic where the
> > destination can only be reached by using the default route.  If there is
a
> > specific route for the destination in the 1720 routing table, the 1720
> > correctly translates and passes the traffic.  If I originate traffic that
> > must use the default route from the 1720, the 1720 routes it correctly.
> > Now, I'm aware that the NAT will not work is there isn't a route to the
> > destination in the routing table, or if there are access lists blocking a
> > port.  There are no access-lists in use anywhere in this scenario, other
> > than the one associated with NAT and the default route works correctly
>when
> > NAT isn't involved.
> > Curiously, and this may or may not be important, I notice that I get a
> > response to a 1.1.1.x address, but the router is only translating one
> > way.  It appears, oddly enough, that the router is generating the ICMP
>echo
> > response for the (virtual) 1.1.1.x address.
> > Is there an issue with double-NAT of which I'm not aware?
> >
> > Thoughts?
> >
> > Craig
> > FAQ, list archives, and subscription info:
>http://www.groupstudy.com/list/cisco.html
> > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>FAQ, list archives, and subscription info: 
>http://www.groupstudy.com/list/cisco.html
>Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=5896&t=5752
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to