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

Discussion in 'Cisco' started by noname, Dec 17, 2004.

  1. noname

    noname Guest

    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!
     
    noname, Dec 17, 2004
    #1
    1. Advertisements

  2. :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.
     
    Walter Roberson, Dec 17, 2004
    #2
    1. Advertisements

  3. noname

    mcaissie Guest

    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)
     
    mcaissie, Dec 17, 2004
    #3
  4. noname

    PES Guest

    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?
     
    PES, Dec 18, 2004
    #4
  5. noname

    mcaissie Guest

    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.
     
    mcaissie, Dec 21, 2004
    #5
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.