PIX 515 Preliminary setup "script"; feedback welcome !

Discussion in 'Cisco' started by J Bard, Dec 5, 2003.

  1. J Bard

    J Bard Guest

    LAN consists of 15 computers running into a hub, hence to the PIX; from the
    pix to a Netgear router , then to
    the ISP. PIX model is 515e with 2 ports. I hope to use a virtual port for
    the DMZ. The install happens shortly ...

    1) is the logical vlan set up OK ?
    2) what's my inside route to if we've no switch or router ? just the network
    of 192.168.1.0 ?
    3) is the aaa authentication set up OK for a local database of users ?
    4) what else is screwed up ? Any feedback welcome !

    passwd dante
    configure terminal
    hostname styx
    enable password beatrice

    telnet 0 0 inside

    http server enabled
    http client 192.168.0.1 (laptop's ip)

    interface ethernet1 auto

    interface ethernet1 vlan2 logical (is that enought for the creation of
    a logical "port" ?)


    logging buffered debugging

    nameif e0 outside sec0
    nameif e1 inside sec100
    nameif vlan2 DMZ sec 50

    ip address outside 129.42.17.99 255.255.255.0
    ip address inside 192.168.1.1 255.255.255.0
    ip address DMZ 192.168.2.1 255.255.255.0

    route outside 0000 0000 129.42.17.99
    route inside (??? we have no inside router, just a hub with no IP #
    .. What do we do here ?)

    global (outside) 1 interface
    nat (inside) 1 00
    nat (DMZ) 1 0 0




    static (DMZ,outside) tcp 129.42.17.99 80 192.168.1.5 www netmask
    255.255.255.255 0 0


    static (inside,DMZ) 192.168.2.5 192.168.2.5 (don't translate ! is this
    OK ? (from R.Deal page 180))



    access-list NO_NAT permit ip 192.168.1.0 255.255.255.0 195.168.2.5
    nat (inside) 0 access-list NO_NAT (again from R.Deal's "Cisco PIX
    Firewall" p 180 )

    access-list DMZ permit ip host 192.168.2.5 192.168.1.0 255.255.255.0

    access-list DMZ deny ip any 192.168.1.0 255.255.255.0 (again, adapted from
    R Deal p 183, but doesn't this

    prevent work getting done inside the LAN ?)

    access-list DMZ permit ip 192.168.2.5 192.168.2.5 255.255.255.0 any

    access-group DMZ in interface dmz



    access-list INTERNAL permit tcp any host 192.168.2.5 eq 80

    access-list INTERNAL deny ip any 192.168.2.0 255.255.255.0

    access-list INTERNAL permit ip 192.168.1.0 255.255.255.0 any

    access-group INTERNAL in interface inside


    access-list EXTERNAL permit tcp any 129.42.17.99 eq 80 (our outside
    ip, and where the web server must seem to be , no?)
    access-list EXTERNAL deny ip any any

    access-group EXTERNAL in interface outside


    aaa authentication include http DMZ 0 0 0 0 LOCAL (is this all ??
    Seems so from the cisco site, but ...)
    aaa authentication secure-http-client
     
    J Bard, Dec 5, 2003
    #1
    1. Advertising

  2. In article <HQ8Ab.874$>,
    J Bard <> wrote:
    :pIX model is 515e with 2 ports. I hope to use a virtual port for
    :the DMZ.
    The install happens shortly ...

    :1) is the logical vlan set up OK ?
    :2) what's my inside route to if we've no switch or router ? just the network
    :eek:f 192.168.1.0 ?
    :3) is the aaa authentication set up OK for a local database of users ?
    :4) what else is screwed up ? Any feedback welcome !

    :interface ethernet1 vlan2 logical (is that enought for the creation of
    :a logical "port" ?)

    Yes.

    :ip address outside 129.42.17.99 255.255.255.0
    :ip address inside 192.168.1.1 255.255.255.0
    :ip address DMZ 192.168.2.1 255.255.255.0

    :route outside 0000 0000 129.42.17.99

    0000 is rather unusual. In theory you could use
    route outside 0 0 129.42.17.99
    but the PIX is going to conver that to
    route outside 0.0.0.0 0.0.0.0 129.42.17.99
    anyhow.

    You don't want to name the outside IP there, you want to name the
    next-hop router in the 129.42.17/24 subnet. Or if you just want
    to throw the packets on the wire and hope for the best, use
    the word 'interface' instead of the interface IP address:

    route outside 0.0.0.0 0.0.0.0 interface

    Do not leave it as the explicit outside IP: that probably will not work.


    :route inside (??? we have no inside router, just a hub with no IP #
    :. What do we do here ?)

    You don't need a 'route inside' statement in your situation. The
    'ip address' commands will insert entries into the route table for you.


    :global (outside) 1 interface
    :nat (inside) 1 00

    nat (inside) 1 0 0

    :nat (DMZ) 1 0 0

    :static (DMZ,outside) tcp 129.42.17.99 80 192.168.1.5 www netmask 255.255.255.255 0 0

    Might as well use 'www' instead of '80' there.

    You probably have that second address wrong: you probably mean
    192.168.2.5 seeing as 192.168.1.5 would be on your inside interface,
    not your DMZ interface.

    129.42.17.99 is your interface IP. You should not use your interface IP
    in a 'static' statement: you should use the word 'interface' instead:

    static (DMZ, outside) tcp interface www 192.168.1.5 www netmask 255.255.255.255 0 0

    :static (inside,DMZ) 192.168.2.5 192.168.2.5 (don't translate ! is this
    :OK ? (from R.Deal page 180))

    No, you probably don't want this statement at all. The inside interface
    will be able to use the DMZ destination of 192.168.2.5 without
    any static statement. You use static statements when you need to be
    able to have a lower security interface start new connections to a
    higher security interface.


    :access-list NO_NAT permit ip 192.168.1.0 255.255.255.0 195.168.2.5
    :nat (inside) 0 access-list NO_NAT (again from R.Deal's "Cisco PIX
    :Firewall" p 180 )

    You probably mean 192.168.2.5 instead of 195.168.2.5, and you probably
    want a 'host' in there:

    access-list NO_NAT permit ip 192.168.1.0 255.255.255.0 host 192.168.2.5

    Really, though, the only reason you would need this nat 0 access-list
    is if it is important that your dmz WWW server be able to
    distinguish between inside hosts (e.g., if you want to log inside
    access by IP.) And using this nat 0 access-list has the side effect
    of allowing new connections from the dmz to the inside (provided
    the dmz access list permits them) without using a 'static' statement.

    If that is your intent, though, you would probably be better off with
    static (inside, dmz) 192.168.1.0 192.168.1.0 netmask 255.255.255.0
    as people know what static means, but not so many know about that
    side effect of nat 0 access-list.


    :access-list DMZ permit ip host 192.168.2.5 192.168.1.0 255.255.255.0

    There is no good reason for this statement. If you want your
    DMZ host to be able to access everything in your inside network, then just
    put your WWW server on your inside network. Your dmz should only
    be permitted to access the minimal inside resources that you can get
    away with (e.g., perhaps a DNS server, but even that should be on the dmz.)


    :access-list DMZ deny ip any 192.168.1.0 255.255.255.0 (again, adapted from
    :R Deal p 183, but doesn't this
    :prevent work getting done inside the LAN ?)

    That statement prevents dmz hosts other than 192.168.2.5 from starting
    new connections to the inside. It has no effect on the inside starting
    new connections to anything.


    :access-list DMZ permit ip 192.168.2.5 192.168.2.5 255.255.255.0 any

    perhaps you mean access-list DMZ permit ip host 192.168.2.5 any

    :access-group DMZ in interface dmz

    :access-list INTERNAL permit tcp any host 192.168.2.5 eq 80
    :access-list INTERNAL deny ip any 192.168.2.0 255.255.255.0
    :access-list INTERNAL permit ip 192.168.1.0 255.255.255.0 any
    :access-group INTERNAL in interface inside

    :access-list EXTERNAL permit tcp any 129.42.17.99 eq 80 (our outside
    :ip, and where the web server must seem to be , no?)
    :access-list EXTERNAL deny ip any any
    :access-group EXTERNAL in interface outside

    The deny is the default for falling off the end of any list, but it
    doesn't hurt to include it.

    You should not include an interface IP address in an access-list: the
    PIX does unexpected things when you do. Use the word 'interface' instead.
    Or, rather, seeing as you are using VLANs, you are using 6.3, so use
    interface followed by the interface name:

    access-list EXTERNAL permit tcp any interface outside eq www


    : aaa authentication include http DMZ 0 0 0 0 LOCAL (is this all ??
    :Seems so from the cisco site, but ...)
    : aaa authentication secure-http-client

    You will need:

    aaa-server LOCAL protocol local

    and you will need 'username' commands if you want to use LOCAL or else
    the PIX is going to grumble at you.
    --
    Come to think of it, there are already a million monkeys on a million
    typewriters, and Usenet is NOTHING like Shakespeare. -- Blair Houghton.
     
    Walter Roberson, Dec 6, 2003
    #2
    1. Advertising

  3. J Bard

    Rik Bain Guest

    On Fri, 05 Dec 2003 18:39:08 -0600, Walter Roberson wrote:


    >
    > You don't want to name the outside IP there, you want to name the
    > next-hop router in the 129.42.17/24 subnet. Or if you just want to throw
    > the packets on the wire and hope for the best, use the word 'interface'
    > instead of the interface IP address:
    >
    > route outside 0.0.0.0 0.0.0.0 interface
    >


    Pix command reference states that you can specify the ip address of the
    interface and it will arp for the destination address. I have seen this
    work fine in practice (until someone buys a security book and disables
    proxy-arp on the neighboring router...).

    Is "interface" even a valid option for gateway_ip?
     
    Rik Bain, Dec 6, 2003
    #3
  4. J Bard

    J Bard Guest

    Mr. Roberson:

    Many thanks; you're very kind and of great help. It's reasuring knowing
    one is not totally off on a wrong track.

    Art Heyman


    "Walter Roberson" <-cnrc.gc.ca> wrote in message
    news:bqr8fc$s3o$...
    > In article <HQ8Ab.874$>,
    > J Bard <> wrote:
    > :pIX model is 515e with 2 ports. I hope to use a virtual port for
    > :the DMZ.
    > The install happens shortly ...
    >
    > :1) is the logical vlan set up OK ?
    > :2) what's my inside route to if we've no switch or router ? just the

    network
    > :eek:f 192.168.1.0 ?
    > :3) is the aaa authentication set up OK for a local database of users ?
    > :4) what else is screwed up ? Any feedback welcome !
    >
    > :interface ethernet1 vlan2 logical (is that enought for the creation

    of
    > :a logical "port" ?)
    >
    > Yes.
    >
    > :ip address outside 129.42.17.99 255.255.255.0
    > :ip address inside 192.168.1.1 255.255.255.0
    > :ip address DMZ 192.168.2.1 255.255.255.0
    >
    > :route outside 0000 0000 129.42.17.99
    >
    > 0000 is rather unusual. In theory you could use
    > route outside 0 0 129.42.17.99
    > but the PIX is going to conver that to
    > route outside 0.0.0.0 0.0.0.0 129.42.17.99
    > anyhow.
    >
    > You don't want to name the outside IP there, you want to name the
    > next-hop router in the 129.42.17/24 subnet. Or if you just want
    > to throw the packets on the wire and hope for the best, use
    > the word 'interface' instead of the interface IP address:
    >
    > route outside 0.0.0.0 0.0.0.0 interface
    >
    > Do not leave it as the explicit outside IP: that probably will not work.
    >
    >
    > :route inside (??? we have no inside router, just a hub with no

    IP #
    > :. What do we do here ?)
    >
    > You don't need a 'route inside' statement in your situation. The
    > 'ip address' commands will insert entries into the route table for you.
    >
    >
    > :global (outside) 1 interface
    > :nat (inside) 1 00
    >
    > nat (inside) 1 0 0
    >
    > :nat (DMZ) 1 0 0
    >
    > :static (DMZ,outside) tcp 129.42.17.99 80 192.168.1.5 www netmask

    255.255.255.255 0 0
    >
    > Might as well use 'www' instead of '80' there.
    >
    > You probably have that second address wrong: you probably mean
    > 192.168.2.5 seeing as 192.168.1.5 would be on your inside interface,
    > not your DMZ interface.
    >
    > 129.42.17.99 is your interface IP. You should not use your interface IP
    > in a 'static' statement: you should use the word 'interface' instead:
    >
    > static (DMZ, outside) tcp interface www 192.168.1.5 www netmask

    255.255.255.255 0 0
    >
    > :static (inside,DMZ) 192.168.2.5 192.168.2.5 (don't translate ! is

    this
    > :OK ? (from R.Deal page 180))
    >
    > No, you probably don't want this statement at all. The inside interface
    > will be able to use the DMZ destination of 192.168.2.5 without
    > any static statement. You use static statements when you need to be
    > able to have a lower security interface start new connections to a
    > higher security interface.
    >
    >
    > :access-list NO_NAT permit ip 192.168.1.0 255.255.255.0 195.168.2.5
    > :nat (inside) 0 access-list NO_NAT (again from R.Deal's "Cisco PIX
    > :Firewall" p 180 )
    >
    > You probably mean 192.168.2.5 instead of 195.168.2.5, and you probably
    > want a 'host' in there:
    >
    > access-list NO_NAT permit ip 192.168.1.0 255.255.255.0 host 192.168.2.5
    >
    > Really, though, the only reason you would need this nat 0 access-list
    > is if it is important that your dmz WWW server be able to
    > distinguish between inside hosts (e.g., if you want to log inside
    > access by IP.) And using this nat 0 access-list has the side effect
    > of allowing new connections from the dmz to the inside (provided
    > the dmz access list permits them) without using a 'static' statement.
    >
    > If that is your intent, though, you would probably be better off with
    > static (inside, dmz) 192.168.1.0 192.168.1.0 netmask 255.255.255.0
    > as people know what static means, but not so many know about that
    > side effect of nat 0 access-list.
    >
    >
    > :access-list DMZ permit ip host 192.168.2.5 192.168.1.0 255.255.255.0
    >
    > There is no good reason for this statement. If you want your
    > DMZ host to be able to access everything in your inside network, then just
    > put your WWW server on your inside network. Your dmz should only
    > be permitted to access the minimal inside resources that you can get
    > away with (e.g., perhaps a DNS server, but even that should be on the

    dmz.)
    >
    >
    > :access-list DMZ deny ip any 192.168.1.0 255.255.255.0 (again, adapted

    from
    > :R Deal p 183, but doesn't this
    > :prevent work getting done inside the LAN ?)
    >
    > That statement prevents dmz hosts other than 192.168.2.5 from starting
    > new connections to the inside. It has no effect on the inside starting
    > new connections to anything.
    >
    >
    > :access-list DMZ permit ip 192.168.2.5 192.168.2.5 255.255.255.0 any
    >
    > perhaps you mean access-list DMZ permit ip host 192.168.2.5 any
    >
    > :access-group DMZ in interface dmz
    >
    > :access-list INTERNAL permit tcp any host 192.168.2.5 eq 80
    > :access-list INTERNAL deny ip any 192.168.2.0 255.255.255.0
    > :access-list INTERNAL permit ip 192.168.1.0 255.255.255.0 any
    > :access-group INTERNAL in interface inside
    >
    > :access-list EXTERNAL permit tcp any 129.42.17.99 eq 80 (our outside
    > :ip, and where the web server must seem to be , no?)
    > :access-list EXTERNAL deny ip any any
    > :access-group EXTERNAL in interface outside
    >
    > The deny is the default for falling off the end of any list, but it
    > doesn't hurt to include it.
    >
    > You should not include an interface IP address in an access-list: the
    > PIX does unexpected things when you do. Use the word 'interface' instead.
    > Or, rather, seeing as you are using VLANs, you are using 6.3, so use
    > interface followed by the interface name:
    >
    > access-list EXTERNAL permit tcp any interface outside eq www
    >
    >
    > : aaa authentication include http DMZ 0 0 0 0 LOCAL (is this all

    ??
    > :Seems so from the cisco site, but ...)
    > : aaa authentication secure-http-client
    >
    > You will need:
    >
    > aaa-server LOCAL protocol local
    >
    > and you will need 'username' commands if you want to use LOCAL or else
    > the PIX is going to grumble at you.
    > --
    > Come to think of it, there are already a million monkeys on a million
    > typewriters, and Usenet is NOTHING like Shakespeare. -- Blair

    Houghton.
     
    J Bard, Dec 7, 2003
    #4
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Scott Townsend
    Replies:
    8
    Views:
    709
    Roman Nakhmanson
    Feb 22, 2006
  2. fruitbat

    Some Digital Rebel & EF-S 18-55mm preliminary comments

    fruitbat, Sep 24, 2003, in forum: Digital Photography
    Replies:
    4
    Views:
    361
    fruitbat
    Sep 25, 2003
  3. Doug MacLean
    Replies:
    0
    Views:
    433
    Doug MacLean
    Jul 29, 2003
  4. deryck  lant

    Nikon D2X Test Report: Preliminary Image Analysis

    deryck lant, Mar 14, 2005, in forum: Digital Photography
    Replies:
    1
    Views:
    286
    Brian C. Baird
    Mar 14, 2005
  5. Matt Adamson

    Feedback from feedback on MCP questions

    Matt Adamson, Apr 27, 2009, in forum: Microsoft Certification
    Replies:
    0
    Views:
    1,621
    Matt Adamson
    Apr 27, 2009
Loading...

Share This Page