spurious DMZ

Jan 31, 2006 1 Replies
B

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


Vote
Twitter Facebook LinkedIn
W

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.
Vote
Twitter Facebook LinkedIn

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required