«

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

In article <HQ8Ab.874$ t>,
J Bard <> wrote:
IX 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
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
revent 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.

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?

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" <> wrote in message
news:bqr8fc$s3o$...
> In article <HQ8Ab.874$ t>,
> J Bard <> wrote:
> IX 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
> 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
> revent 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.