>Does your pix have a default route?
>Does your pix forward packets between subnets?
>Logically, then, the pix routes. Call it what you will, when forwarding
>between disparate networks, you route. I suppose cisco misunderstands the
>term "route" too.
Also confusing the terminology may be that the PIX product was a
Cisco acquisition. Although the original manufacturer escapes me,
the pre-Cisco PIX had an excellent reputation. I remember, however,
that when one read the first Cisco-revised manual, the PIX couldn't
POSSIBLY have worked as they described it.
Something that may help understand it, though -- think of the PIX not
as a conventional router, but as a multiple-interface server that
appears as a host on multiple subnets. It needs a default gateway on
each of those subnets.
I agree that no classical description is "clean," but this is the
nature of midboxes.
>
>http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_v42/pix42cfg/pix42apa.htm#xtocid88422
>
>Here's from Cisco:
>
>route Command
>
>The following are the extensions to the route command:
>
> The routing table has been improved to let you specify the IP address
>of a PIX Firewall interface in the route command. If the route
> command statement uses the IP address from one of the PIX Firewall
>unit's interfaces as the gateway IP address, PIX Firewall will
> ARP for the destination IP address in the packet instead of ARPing
>for the gateway IP address.
>
> PIX Firewall also does not accept duplicate routes with different
>metrics for the same gateway.
>
> In version 5.1(1), the CONNECT route entry is supported. (This
>identifier appears when you use the show route command.) The
> CONNECT identifier is assigned to an interface's local network and
>the interface IP address, which is in the IP local subnet. PIX
> Firewall will use ARP for the destination address. The CONNECT
>identifier cannot be removed, but changes when you change the
> IP address on the interface.
>
> You can now enter duplicate route command statements with different
>gateways and metrics.
>
> You can now enter static route command statements with virtual
>subnets; for example:
>
>route outside 10.2.2.8 255.255.255.248 192.168.1.3
>route outside 10.2.2.8 255.255.255.255 192.168.1.1
>
>--- Jason <[EMAIL PROTECTED]> wrote:
>> As someone said yesterday: The PIX will not route, period. It will NAT
>> (including NAT 0), but it will not route packets between different
>> networks.
>> If you need routing off any interface on a PIX, you need a router there.
>>
>> --
>> Jason Roysdon, CCNP+Security/CCDP, MCSE, CNA, Network+, A+
>> List email: [EMAIL PROTECTED]
>> Homepage: http://jason.artoo.net/
>> Cisco resources: http://r2cisco.artoo.net/
>>
>>
>> "anthony kim" <[EMAIL PROTECTED]> wrote in message
>> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>> > A device can best be described by its chief function. You can use a
>> > PIX as a router, just allow everything through. In fact you can use a
>> > router as a firewall, be selective with access lists. Terminology is
>> > flexible as long as you're pragmatic about function.
>> >
>> >
>> > On Fri, Feb 16, 2001 at 10:52:06AM -0800, Dan West wrote:
>> > >PIX - sounds like a router to me - packet forwarding
>> > >based on layer 3 addressing. It has extra security
>> > >features and all of a sudden it's a
>> > >firewall...marketing fluff? or accurate description???
>> > >who will uncover this mystery???? ;>
>> > >
>> > >--- mtieast <[EMAIL PROTECTED]> wrote:
>> > >> I think this comes from the fact that cisco
>> > >> instructors in class say that
>> > >> the Pix is not a router. I have heard this as well
>> > >> when I had the class.
>> > >>
>> > >> I know the Pix is not a router, but does it route?
>> > >> Well, if making decisions
>> > >> about where to send traffic based on layer 3 info is
>> > >> routing then I would
>> > >> argue it does route. It does not forward traffic
>> > >> based on layer 2 info so
>> > >> ......
> > > >>
>> > >> It routes traffic to the appropriate interface. Can
>> > >> someone else shed some
>> > >> light as to why this is said. If it doesn't route
>> > >> the traffic it recieves
>> > >> what does it do?
>> > >>
>> > >>
>> > >>
>> > >> -----Original Message-----
>> > >> From: haroldnjoe <[EMAIL PROTECTED]>
>> > >> Newsgroups: groupstudy.cisco
>> > >> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
>> > >> Date: Friday, February 16, 2001 12:41 PM
>> > >> Subject: Firewalls and VPNs
>> > >>
>> > >>
>> > >> >I've read here a couple of times that PIX's don't
>> > >> route. Period. In light
>> > >> of
>> > >> >this I'm left a little confused as to a proposed
>> > >> network map I was given
>> > >> >recently.
>> > >> >
>> > >> >The core layer router is a 3640 linking all of our
>> > >> branch offices together.
>> > >> >From the 3640, there is an ethernet connection to a
>> > >> PIX 515R. From the
>> > >> PIX,
>> > >> >there is another ethernet connection to a 1750
>> > >> router. The 1750 connects
>> > >> via
>> > >> >T1 to our ISP. There is yet another ethernet
>> > >> connection from the PIX to
>> > >> the
>> > >> >isolation lan, on which resides an internet
>> > >> mail/web server and a VPN 3000
>> > >> >concentrator.
>> > >> >
>> > >> >If PIX's don't route, what subnet is the isolation
>> > >> lan going to sit on? As
>> > >> >I understand it, the PIX will be providing NAT
>> > >> functionality for the 3640
>> > >> >and everything behind it. So I would assume that
>> > >> the T1 and ethernet
>> > >> >interfaces on the 1750, the outside interfaces on
>> > >> the PIX, and everything
>> > >> in
>> > >> >the isolation lan including the VPN concentrator
>> > >> will have to have public
>> > >> IP
>> > >> >addresses which will be given to us by our ISP.
>> > >> The way the map is layed
>> > >> >out, it looks to me like the isolation lan would
>> > >> have to be on its own
>> > >> >subnet.
>> > >> >
>> > >> >What am I missing? If the PIX doesn't route, do
>> > >> it's ethernet interfaces
>> > >> >reside on the same subnet as the isolation lan? If
>> > >> so, then the ethernet
>> > >> >interface on the 1750 must also be on that subnet,
>> > >> right?
>> > >> >
>> > >> >This is the proposed network map that Cisco's
>> > >> presale engineers gave me.
>> > >> >I'm sure it's a solid design, but I'm still trying
>> > >> to work out the details
>> > >> >so that I understand what I'm implementing (always
>> > >> a good thing, I think).
>> > >> >
>> > >> >Thanks for your time,
>> > >> >
> > > >> >[EMAIL PROTECTED]
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]