Very, very odd, but I can believe it. I've run into a ton of odd bugs like
this and usually spent a number of hours with TAC before getting to an
engineer who knew about it.
Thanks for the heads up. I almost suggested a route-map in the first place,
but I wasn't entirely sure of what you mean with the routing situation.
We used to get this sort of thing with the old PIX 4.x software (it allowed
for two default routes, one on the inside interface, and one on the
outside). If we didn't explicitly specify the internal networks it wouldn't
always work even though we had a default route on the inside. Somewhat
different scenario than yours, but still, one of those odd bugs. The funny
thing is that it would work for a number of networks, but not some.
Of course with the PIX OS 5.x software you couldn't set duplicate routes on
two interfaces, so it forced use to fix it properly (when we found all the
networks that didn't have an explicit route set couldn't get to the
internet). At that point we just set up routes for 192.168/16, 172.16/12,
and 10/8 on the inside (since they shouldn't be on the outside of the PIX,
and all we use is private addressing on the inside).
--
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]...
> Truthfully, after spending 5 hours with a cell phone to my head I couldn't
> be bothered asking how a router would be aware of a double NAT.
> The problem only occurred when an ACK was returning with a destination
that
> had to be reached by the default route. The correct sequence of NAT
> requires the NAT process to check for a route to the destination before
> performing the translation. If there's a destination in the route table,
> translation is supposed to occur. Once examined, it was clear that a
> packet entering the network was Natted once on the 1720 and again on the
> PIX, finally reaching the destination machine. When the destination
> machine responded with an ACK, the PIX was translating correctly, but the
> 1720 was only translating if there was a specific entry in the route table
> for the destination network. If the destination required the packet to
> take the default route, no translation would occur and the packet was
> dropped. The workaround required policy routing that looks at the source
> of the ACK and then sets the "ip next-hop" manually if the packet matches
> the rules.
>
> Craig
>
> At 07:44 AM 5/25/2001 -0700, you wrote:
> >I agree with the other guy. How would any router "know" that a packet had
> >already been natted?
> >
> >Does Cisco NAT set on of the IP or TCP obscure bits? What did Cisco say?
> >
> >Chuck
> >
> >-----Original Message-----
> >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of
> >Craig Columbus
> >Sent: Friday, May 25, 2001 5:03 AM
> >To: [EMAIL PROTECTED]
> >Subject: Re: Double-Nat troubles [7:5752]
> >
> >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]
> >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=5937&t=5752
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
