Oh, just had a thought which solved odd bugs in the past with routers:
Have you disabled 'ip route-cache' on the interfaces? At this point you
could probably care less, but I'd be curious to hear if it was a switching
problem.
--
Jason Roysdon, CCNP+Security/CCDP, MCSE, CNA, Network+, A+
List email: [EMAIL PROTECTED]
Homepage: http://jason.artoo.net/
""Jason Roysdon"" wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> 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]
> 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=5941&t=5752
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
