spurious DMZ

Confused by portions of the config file (see below). I set up this Pix, and serviced it yesterday,

but dont have full responsibility for it.

I see that an object group has a network object refering to non existant DMZ addresses:

network-object 192.168.2.10 255.255.255.255

used again in a static:

static (inside,dmz) 192.168.2.10 XXXXXXX1 netmask 255.255.255.255 0 0

I was told this allowed for communication between servers in the inside and the DMZ.

I half expected to find multiple IP's on the servers in both the 192.168.0 and 192.168.2

but didn't. (Walter , what do you think ?)

: Saved

: Written by enable_15 at 15:21:06.511 UTC Mon Jan 30 2006

PIX Version 6.3(1)

interface ethernet0 auto

interface ethernet1 auto

interface ethernet2 auto

nameif ethernet0 outside security0

nameif ethernet1 inside security100

nameif ethernet2 dmz security50

enable password Rxxxxxxxxxxxx encrypted

passwd xxxxxxxxxx encrypted

hostname atcentralfw

domain-name atcentral

fixup protocol ftp 21

fixup protocol h323 h225 1720

fixup protocol h323 ras 1718-1719

fixup protocol http 80

fixup protocol ils 389

fixup protocol rsh 514

fixup protocol rtsp 554

fixup protocol sip 5060

fixup protocol sip udp 5060

fixup protocol skinny 2000

fixup protocol smtp 25

fixup protocol sqlnet 1521

names

name 192.168.0.101 XXXXXXX1

name 192.168.0.102 XXXXXXX2

name 192.168.0.112 XXXXXXXf2

name 192.168.0.111 XXXXXXXf1

name 192.168.2.121 XXXXXXXweb

name 192.168.0.103 XXXXXXX3

name 192.168.0.104 XXXXXXX4

object-group service XXXXXXX tcp

port-object range 6990 6992

object-group network XXXXXXXServers

network-object XXXXXXX1 255.255.255.255

network-object XXXXXXX2 255.255.255.255

network-object XXXXXXX3 255.255.255.255

network-object XXXXXXX4 255.255.255.255

object-group network XXXXXXXServers_ref

network-object 192.168.2.10 255.255.255.255

network-object 192.168.2.11 255.255.255.255

network-object 192.168.2.12 255.255.255.255

network-object 192.168.2.13 255.255.255.255

object-group service PCAnywhere tcp-udp

description PCAnywhere Standard Ports

port-object range 5631 5632

object-group service PCAnyWeb tcp-udp

description PCAnywhere and Web Services

port-object range 5631 5632

port-object range 80 80

access-list inside_outbound_nat0_acl permit ip any 192.168.0.192

255.255.255.192

access-list outside_access_in permit tcp any interface outside object-group PCAnyWeb

access-list outside_access_in permit icmp any any echo

access-list outside_access_in permit icmp any any echo-reply

access-list outside_access_in permit tcp any host 192.168.0.42 range 10000

10005

access-list outside_access_in permit tcp any host 192.168.0.122

access-list outside_access_in permit udp any host 192.168.0.122

access-list outside_access_in permit tcp any interface outside range 3060

3064

access-list outside_access_in permit udp any interface outside range 3060

3064

access-list dmz_access_in permit tcp host XXXXXXXweb object-group XXXXXXXServers_ref object-group XXXXXXX

pager lines 24

logging timestamp

logging monitor debugging

logging trap debugging

logging host inside 192.168.0.244

mtu outside 1500

mtu inside 1500

mtu dmz 1500

ip address outside XXX.XXX.XX.1XX 255.255.255.252

ip address inside 192.168.0.2 255.255.255.0

ip address dmz 192.168.2.1 255.255.255.0

ip verify reverse-path interface outside

ip audit name checkit attack action alarm reset

ip audit interface outside checkit

ip audit info action alarm

ip audit attack action alarm

ip local pool XXXdsupport 192.168.0.200-192.168.0.230

pdm location 192.168.0.31 255.255.255.255 inside

pdm location XXXXXXXf1 255.255.255.255 inside

pdm location 192.168.2.33 255.255.255.255 inside

pdm location XXXXXXXweb 255.255.255.255 dmz

pdm location XXXXXXX1 255.255.255.255 inside

pdm location XXXXXXX2 255.255.255.255 inside

pdm location XXXXXXXf2 255.255.255.255 inside

pdm location 0.0.0.0 255.255.255.255 inside

pdm location 192.168.2.10 255.255.255.255 dmz

pdm location 192.168.2.11 255.255.255.255 dmz

pdm group XXXXXXXServers inside

pdm group XXXXXXXServers_ref dmz reference XXXXXXXServers

pdm history enable

arp timeout 14400

global (outside) 1 interface

global (dmz) 1 interface

nat (inside) 0 access-list inside_outbound_nat0_acl

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

static (dmz,outside) tcp interface www XXXXXXXweb www netmask

255.255.255.255 0 0

static (dmz,outside) tcp interface pcanywhere-data XXXXXXXweb pcanywhere-data netmask 255.255.255.255 0 0

static (dmz,outside) tcp interface 5632 XXXXXXXweb 5632 netmask

255.255.255.255 0 0

static (inside,outside) tcp interface 10000 192.168.0.42 10000 netmask

255.255.255.255 0 0

static (inside,outside) tcp interface 10001 192.168.0.42 10001 netmask

255.255.255.255 0 0

static (inside,outside) tcp interface 10002 192.168.0.42 10002 netmask

255.255.255.255 0 0

static (inside,outside) tcp interface 10003 192.168.0.42 10003 netmask

255.255.255.255 0 0

static (inside,outside) tcp interface 3060 192.168.0.122 3060 netmask

255.255.255.255 0 0

static (inside,outside) tcp interface 3061 192.168.0.122 3061 netmask

255.255.255.255 0 0

static (inside,outside) tcp interface 3062 192.168.0.122 3062 netmask

255.255.255.255 0 0

static (inside,outside) tcp interface 3063 192.168.0.122 3063 netmask

255.255.255.255 0 0

static (inside,outside) tcp interface 3064 192.168.0.122 3064 netmask

255.255.255.255 0 0

static (inside,outside) udp interface 3061 192.168.0.122 3061 netmask

255.255.255.255 0 0

static (inside,outside) udp interface 3060 192.168.0.122 3060 netmask

255.255.255.255 0 0

static (inside,outside) udp interface 3062 192.168.0.122 3062 netmask

255.255.255.255 0 0

static (inside,outside) udp interface 3063 192.168.0.122 3063 netmask

255.255.255.255 0 0

static (inside,outside) udp interface 3064 192.168.0.122 3064 netmask

255.255.255.255 0 0

static (inside,dmz) 192.168.2.10 XXXXXXX1 netmask 255.255.255.255 0 0

static (inside,dmz) 192.168.2.11 XXXXXXX2 netmask 255.255.255.255 0 0

static (dmz,inside) 192.168.0.121 XXXXXXXweb netmask 255.255.255.255 0 0

static (inside,dmz) 192.168.2.12 XXXXXXX3 netmask 255.255.255.255 0 0

static (inside,dmz) 192.168.2.13 XXXXXXX4 netmask 255.255.255.255 0 0

access-group outside_access_in in interface outside

access-group dmz_access_in in interface dmz

route outside 0.0.0.0 0.0.0.0 155.212.99.141 1

timeout xlate 3:00:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225

1:00:00

timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00

timeout uauth 0:05:00 absolute

aaa-server TACACS+ protocol tacacs+

aaa-server RADIUS protocol radius

aaa-server LOCAL protocol local

http server enable

http 192.168.0.31 255.255.255.255 inside

http XXXXXXXf1 255.255.255.255 inside

no snmp-server location

no snmp-server contact

snmp-server community public

no snmp-server enable traps

floodguard enable

sysopt connection permit-pptp

telnet 0.0.0.0 0.0.0.0 inside

telnet timeout 33

ssh 0.0.0.0 0.0.0.0 outside

ssh timeout 20

console timeout 0

vpdn group PPTP-VPDN-GROUP accept dialin pptp

vpdn group PPTP-VPDN-GROUP ppp authentication chap

vpdn group PPTP-VPDN-GROUP client configuration address local xxxxxsupport

vpdn group PPTP-VPDN-GROUP client configuration dns xxx.xx.xx.2 xxx.xx.xx.15

vpdn group PPTP-VPDN-GROUP pptp echo 60

vpdn group PPTP-VPDN-GROUP client authentication local

vpdn username xxxxtech password xxxxxxx

vpdn enable outside

username dealer password XXXXXXXXXX encrypted privilege 2

terminal width 80

Cryptochecksum:XXXXXXXXXX

: end

In article , Barrett Bonden wrote: :Confused by portions of the config file (see below). I set up this Pix, and :serviced it yesterday, :but dont have full responsibility for it.

:I see that an object group has a network object refering to non existant DMZ :addresses:

:network-object 192.168.2.10 255.255.255.255 :used again in a static:

:static (inside,dmz) 192.168.2.10 XXXXXXX1 netmask 255.255.255.255 0 0

:I was told this allowed for communication between servers in the inside and :the DMZ.

That part's okay. When a host in the dmz addresses a packet to

192.168.2.10 then the PIX will proxy-arp the IP, accept the packet, and translate the destination to XXXXXXX1. Conversely, if XXXXXXX1 sends to the dmz, the dmz destination will see the source as 192.168.2.10.

I have not yet found a situation in which such a configuration has meaningful advantages over, e.g.,

static (inside,dmz) XXXXXXXX1 XXXXXXXX1 netmask 255.255.255.255 0 0

or the nat 0 access-list equivilent. I suppose there -is- the point that this configuration does not require that the DMZ hosts have any routing entries other than to their local subnet... and if there is no default route for them then there is a much lowered risk that the dmz hosts will accidently leak a packet outward.

There is a completely different section of your configuration which is broken:

Well, there is the point that you are using a PIX version with known security holes. You really should get the free security upgrades to 6.3(4).

That's not going to work. Your vpdn pool ip addresses are in the same subnet that belongs to the inside interface. When an inside host attempts to reply to an IP in the PPTP allocation range, the PIX is going to see that the IP coming in to the inside interface belongs to the inside interface subnet, and the PIX will drop the packet because PIX 6.x is designed to never route a packet in a [logical] interface and back out the same [logical] interface.

You need to change your XXXdsupport pool to reflect IPs in an unused range, such as 192.168.3.200-192.168.3.230 and then change your inside_outbound_nat0_acl so that the appropriate subnet appears in the destination field. When you have that set up, then as far as the inside hosts (and the PIX) are concerned, the

192.168.3.x destinations are "outside" [because of the default route] so the PIX will process NAT for them as appropriate for inside->outside transactions [which will be no NAT because of your nat 0 access-list], and the PIX will then match the translated IPs against the VPN tunnels it knows about and do the appropriate encapsulation and send to the appropriate public IP corresponding to that tunnel's public endpoint.