pix 501 6.3 default route on a stub network on the outside interface

pix 501 6.3 default route on a stub network on the outside interface

NewsGroups | Search | Tools
 comp.dcom.sys.cisco  Post an article  get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content  add this group's latest topics to your Google content  YahooMyWeb Yahoo!  Google Google  Windows Live Favorites Windows Live  del.icio.us del.icio.us  digg digg  Add to Netscape Netscape
Subject Author Date
pix 501 6.3 default route on a stub network on the outside interface noname 12-16-2004
Posted by noname on December 16, 2004, 7:43 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
Hi all,

I'm getting confused with this default route thing.

Consider the simplest case, a pix with an inside and outside interface.

According to pix docs, there must be a default route on the outside
interface:

route outside 0.0.0.0 0.0.0.0 <next-hop-ip>

But what if there is no 'next-hop' on the outside network? Say it's just
a stub network or even a single computer?

My first thought is, in the case of spurious packets on the outside
(single host) network, you want them to just die. That'd be cool, except
you have to have that default route thing.

So next maybe just tell the pix to route spurious
packets coming into the outside interface right back out the outside
interface.

So, if you -must- have a default route
statement, it would be:

route outside 0.0.0.0 0.0.0.0 <outside-single-host-ip>

or maybe to just make the packets die, route them to a bogus outside ip:

route outside 0.0.0.0 0.0.0.0 <bogus-outside-ip>

but there's gotta be something wrong with that? Or is there already a
'right' solution that I can't discover?

Thanks in advance!


Network Magic 20% Off NMEASY coupon code spring banner 468x60
Posted by Walter Roberson on December 17, 2004, 4:59 am
If you were  Registered and logged in, you could reply and use other advanced thread options
:I'm getting confused with this default route thing.

:Consider the simplest case, a pix with an inside and outside interface.

:According to pix docs, there must be a default route on the outside
:interface:

:route outside 0.0.0.0 0.0.0.0 <next-hop-ip>

That's wrong, in at least two different ways:

1) You can use the word 'interface' instead of giving an IP. The
packets will be thrown onto the ethernet and either something
will take care of them or nothing will and they will be ignored.

2) You don't need a default route. You only need routes to
IP addresses that you need to be able to reach. If you are
running a private network, that might be (say) just your
intranet and DNS servers. And even if you are connected to
the Internet, you might have set your ACLs so that people
can only access a limited number of sites (e.g., your
remote corprate finance system), in which case you only need
routes that help to get to those sites.

Most people will have a default route because most people
will have their PIX connected to the Internet somehow, and
most PIXes will be configured to allow connections to a large
number of different locations (e.g., all mail servers on port 25
anywhere in the world.) If your next hop has the information
about how to get to everywhere you need to be able to reach,
it is easier to use a default route than to list all the
locations exhaustively.


:But what if there is no 'next-hop' on the outside network? Say it's just
:a stub network or even a single computer?

See above.


:My first thought is, in the case of spurious packets on the outside
:(single host) network, you want them to just die. That'd be cool, except
:you have to have that default route thing.

Spurious packets originating outside or originating inside?


:So next maybe just tell the pix to route spurious
:packets coming into the outside interface right back out the outside
:interface.

You can't do that. The PIX will never route packets back out
the same interface they came in. If you try to do that, it will
drop the packets.

--
Aleph sub {Aleph sub null} little, Aleph sub {Aleph sub one} little,
Aleph sub {Aleph sub two} little infinities...


Posted by mcaissie on December 17, 2004, 4:21 pm
If you were  Registered and logged in, you could reply and use other advanced thread options

>
> 2) You don't need a default route.

FYI

I was doing VPN tests one day and i had a simple environment
with 2 PIX connected on the outside through a crossover cable .
Tunnel was coming up ( sh isakmp = QM-IDLE) but no traffic
was going through. I was getting a " no route to [destination address]"
message.

Comparing my config with a valid one i could not find where the bug was .
Finally i realised that the only difference was that i didn't have a
default route,
wich i shouldn't need since both peer are on the same subnet.

So i add a route outside 0 0 statement with a bogus address as the gateway
and suddenly the traffic began to flow.

It's like if a route statement was needed to activate the routing on the
PIX.

This was with 6.3(3)





Posted by PES on December 17, 2004, 8:50 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
mcaissie wrote:
>>2) You don't need a default route.
>
>
> FYI
>
> I was doing VPN tests one day and i had a simple environment
> with 2 PIX connected on the outside through a crossover cable .
> Tunnel was coming up ( sh isakmp = QM-IDLE) but no traffic
> was going through. I was getting a " no route to [destination address]"
> message.
>
> Comparing my config with a valid one i could not find where the bug was .
> Finally i realised that the only difference was that i didn't have a
> default route,
> wich i shouldn't need since both peer are on the same subnet.
>
> So i add a route outside 0 0 statement with a bogus address as the gateway
> and suddenly the traffic began to flow.
>
> It's like if a route statement was needed to activate the routing on the
> PIX.
>
> This was with 6.3(3)
>
>
>

I'm not doubting your statement, and if it is true, it is a bug.
However just to confirm, did you have route outside that matched the ip
addresses on the other end of the tunnel on each pix?

--
-------------------------
Paul Stewart
Lexnet Inc.
Email address is in ROT13


Posted by mcaissie on December 20, 2004, 7:08 pm
If you were  Registered and logged in, you could reply and use other advanced thread options

> mcaissie wrote:
> >>2) You don't need a default route.
> >
> >
> > FYI
> >
> > I was doing VPN tests one day and i had a simple environment
> > with 2 PIX connected on the outside through a crossover cable .
> > Tunnel was coming up ( sh isakmp = QM-IDLE) but no traffic
> > was going through. I was getting a " no route to [destination
address]"
> > message.
> >
> > Comparing my config with a valid one i could not find where the bug was
.
> > Finally i realised that the only difference was that i didn't have a
> > default route,
> > wich i shouldn't need since both peer are on the same subnet.
> >
> > So i add a route outside 0 0 statement with a bogus address as the
gateway
> > and suddenly the traffic began to flow.
> >
> > It's like if a route statement was needed to activate the routing on the
> > PIX.
> >
> > This was with 6.3(3)
> >
> >
> >
>
> I'm not doubting your statement, and if it is true, it is a bug.
> However just to confirm, did you have route outside that matched the ip
> addresses on the other end of the tunnel on each pix?

No , i had no route oustside statement at all.

I had 192.168.0.0 /24 on one inside network and 192.168.1.0 /24 on the
other.

Both outside were at 1.1.1.1 and 1.1.1.2

when i added route outside 0.0.0.0 1.1.1.3 on both side
it then worked , even though there was nothing at 1.1.1.3.

So i guess the PIX checks the routing tables before checking the crypto-maps
and if there is no route for the destination it will stop there and give
the "no route" error , even though when the route is there it may not be
used, like in my case.

When 192.168.1.1 call 192.168.0.1 and that the traffic is triggered by the
crypto-map , i would think that the only route needed is for the outside to
reach the other peer . But if both peers are on the same subnet no route
should be needed.

I'll double check this when i get a chance.




Similar ThreadsPosted
Need to route SMTP traffic through static interface (not default route) March 27, 2007, 5:19 pm
OSPF Stub area question re: Default Routes June 17, 2005, 5:36 pm
Default route using interface not next-hop on LAN March 2, 2005, 6:39 am
Can't set default route to outside interface May 29, 2008, 10:12 pm
learning destination MAC if default route uses interface and not next-hop IP September 20, 2005, 8:19 am
What is the default precedence: local-route, static-route, OSPF-route? August 4, 2008, 3:00 am
PIX 506E Routing from Inside Interface network To outside interface network August 4, 2005, 3:48 pm
RIP + Default Route October 21, 2005, 1:58 am
Default Route November 4, 2005, 7:05 pm
Default Route(s) August 14, 2006, 11:58 am

other useful resources:
The Federal Communications Commission (FCC)
Telecommunications Industry Association
Electronic and Software Security Products and Services
International Telecommunication Union

Custom CGI Perl and PHP programming by 1-Script.com

Contact Us | Privacy Policy
The site map in XML format XML site map