[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now


PIX DMZ to DMZ routing problem

Posted on 2006-05-22
Medium Priority
Last Modified: 2013-11-16
Hi, I have a routing/connection problem that I can’t figure out.  We have redundant Cisco PIX’s in our production environment.  I just added a 4 port NIC to both PIX’s so we could add a second DMZ.  The new DMZ and the current DMZ need to communicate.  This is temporary so until we decommission the servers in the current DMZ.  Over the weekend I installed the NIC’s and created a new DMZ.  For some reason only a few of the servers in the current DMZ can ping the servers in the new DMZ.  The new DMZ has a lower security level then the new DMZ.  (Current DMZ is called DMZ, new DMZ is called DMZ1)

nameif ethernet2 dmz security50
nameif ethernet3 dmz1 security40

I checked the default gateway on all the servers in the current DMZ.  It is the same for each server.  There are 8 servers in the current DMZ and 3 of them can ping servers in the new DMZ.  The others can’t.  I have a default route in the PIX for outside traffic but I don’t have any other routes.  Do I need to add one?  I checked Cisco’s site and I didn’t see any examples of routes in a PIX for DMZ access.  Below is the config from the PIX.  I removed all IP information and also removed the access-list and static entries.  I did leave the ICMP access-list entries.  Servers/users on our corporate network (inside interface) can access all the servers in both DMZ’s.  The communication problem is from DMZ to DMZ1

There isn’t a router in either DMZ.  The servers use the PIX interface for their gateway.  Does anyone know why only certain servers in the current DMZ can access the new DMZ?  This makes no sense to me.  I went over the IP configuration on the current DMZ servers a dozen times and it is the same for each machine.  I'm baffled.

Any assistance/advice would be greatly appreciated.

: Saved
: Written by enable_15 at 11:20:59.442 UTC Sun May 21 2006
PIX Version 6.3(4)
interface ethernet0 100full
interface ethernet1 100full
interface ethernet2 100full
interface ethernet3 100full
interface ethernet4 auto shutdown
interface ethernet5 auto shutdown
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 dmz security50
nameif ethernet3 dmz1 security40
nameif ethernet4 intf4 security8
nameif ethernet5 intf5 security10
enable password xxxxxxxxxxxxxxxxxxxxx
passwd xxxxxxxxxxxxxxxxxx
hostname xxxxxxxxxxxxx
domain-name xxxxxxxxxxxxxxxxxxx
fixup protocol dns maximum-length 512
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
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
fixup protocol tftp 69
no names
access-list outside_in permit icmp any any echo
access-list outside_in permit xxxxxxxxxxxxxxxxx
access-list outside_in permit xxxxxxxxxxxxxxxxx
access-list dmz_out permit icmp any any
access-list dmz_out permit xxxxxxxxxxxxxxxxxxxx
access-list dmz_out permit xxxxxxxxxxxxxxxxxxxx
access-list dmz_out permit tcp any any             <== added this for testing
access-list dmz1_out permit icmp any any
access-list dmz1_out permit xxxxxxxxxxxxxxxxxxx
access-list dmz1_out permit xxxxxxxxxxxxxxxxxxx
pager lines 24
logging on
logging timestamp
logging buffered debugging
logging trap debugging
logging facility 22
logging queue 1024
mtu outside 1500
mtu inside 1500
mtu dmz 1500
mtu dmz1 1500
mtu intf4 1500
mtu intf5 1500
ip address outside x.x.x.x x.x.x.x
ip address inside x.x.x.x x.x.x.x
ip address dmz x.x.x.x x.x.x.x
ip address dmz1 x.x.x.x x.x.x.x
no ip address intf4
no ip address intf5
ip audit info action alarm
ip audit attack action alarm
failover timeout 0:00:00
failover poll 15
failover ip address outside x.x.x.x
failover ip address inside x.x.x.x
failover ip address dmz x.x.x.x
failover ip address dmz1 x.x.x.x
no failover ip address intf4
no failover ip address intf5
pdm history enable
arp timeout 14400
global (outside) 1 x.x.x.x-x.x.x.x netmask
global (outside) 1 x.x.x.x netmask
global (dmz) 1 x.x.x.x-x.x.x.x netmask
global (dmz) 1 x.x.x.x netmask
global (dmz1) 1 x.x.x.x-x.x.x.x netmask
global (dmz1) 1 x.x.x.x netmask
nat (inside) 1 0 0
nat (dmz) 1 x.x.x.x 0 0
nat (dmz1) 1 x.x.x.x 0 0
static (dmz,outside) x.x.x.x x.x.x.x netmask 0 0
static (dmz1,outside) x.x.x.x x.x.x.x netmask 0 0
static (inside,dmz) x.x.x.x x.x.x.x netmask 0 0
static (inside,dmz1) x.x.x.x x.x.x.x netmask 0 0
static (dmz,dmz1) x.x.x.x x.x.x.x netmask 0 0
access-group outside_in in interface outside
access-group inside_out in interface inside
access-group dmz_out in interface dmz
access-group dmz1_out in interface dmz1
route outside x.x.x.x 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 TACACS+ max-failed-attempts 3
aaa-server TACACS+ deadtime 10
aaa-server RADIUS protocol radius
aaa-server RADIUS max-failed-attempts 3
aaa-server RADIUS deadtime 10
aaa-server LOCAL protocol local
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
telnet timeout 5
ssh inside
ssh timeout 10
console timeout 0
terminal width 80
Question by:steno1122
  • 3

Accepted Solution

stressedout2004 earned 1400 total points
ID: 16735283
Ok, the configuration look fine. But if you only need DMZ to DMZ1 communication and not the other way around, I would remove this line:

no static (dmz,dmz1) x.x.x.x x.x.x.x netmask 0 0
clear xlate

Now as far as routing, if the inside host can communicate with servers on the DMZ1 through the PIX, then that means routing is working fine.

I would turn on logging on the PIX to see what's going on. Access the PIX via CLI and do the following:

If via console:

logging console 7
debug icmp trace
logging on

If via telnet/ssh

logging monitor 7
debug icmp trace
logging on
term mon

Then from a server behind the DMZ, ping a host on the DMZ1 that you can reach and verify that you see the echo request and reply on the PIX. Once you verify that you can see the logs on the PIX, ping a server on the DMZ1 that you can't reach and watch the logs. You should see the translation being created on the logs as well as icmp going through the PIX. I would save the CLI session as it might be difficult to look at the log on real time depending on how busy the PIX.


Author Comment

ID: 16735534
Hi stressedout2004

Thanks for the reply!  I didn't clear the xlate when I installed the NIC and configured the DMZ.  The xlate timeout is set for 3 hours.  Its been 2 days since I made the configuration changes.  Do you think that clearing the xlate will still help?  I'll have to wait till off-hours to do it since the PIX is very busy.

The PIX is in a remote location so I'll have to wait to enable debug icmp.  I'd rather not do it via ssh.

Expert Comment

ID: 16735925
Well, normally it is recommended to do a clear xlate everytime you modify or add static, nat or access-rule entries so the PIX update its connection and translation table entries. But at this point, I don't believe it matters because the inside network can reach the new DMZ so that means that the translation entry has been updated. The only reason I ask you to do the clear xlate is because I have asked you to removed that extra static translation. You can give it a try though since it doesn't hurt before doing the debugs as suggested to see if it makes a difference. If not then proceed with the debugs.

Expert Comment

ID: 16736119
This is a little off topic but I would suggest you get rid or lower the following logging:

logging buffered debugging
logging trap debugging

Running logging on the highest level (lvl 7) which is debugging is not recommended in a production environment unless you have it on for troubleshooting purpose. It uses cpu and memory and therefore affects the PIX performance.  I would suggest you lower it to  error(lvl 3) or warning (lvl4).

logging trap error ---> enable this command only if you have a host on the network running syslog
logging buffered  error

Featured Post

Hire Technology Freelancers with Gigs

Work with freelancers specializing in everything from database administration to programming, who have proven themselves as experts in their field. Hire the best, collaborate easily, pay securely, and get projects done right.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Concerto Cloud Services, a provider of fully managed private, public and hybrid cloud solutions, announced today it was named to the 20 Coolest Cloud Infrastructure Vendors Of The 2017 Cloud  (http://www.concertocloud.com/about/in-the-news/2017/02/0…
When speed and performance are vital to revenue, companies must have complete confidence in their cloud environment.
As a trusted technology advisor to your customers you are likely getting the daily question of, ‘should I put this in the cloud?’ As customer demands for cloud services increases, companies will see a shift from traditional buying patterns to new…
Both in life and business – not all partnerships are created equal. Spend 30 short minutes with us to learn:   • Key questions to ask when considering a partnership to accelerate your business into the cloud • Pitfalls and mistakes other partners…
Suggested Courses
Course of the Month18 days, 16 hours left to enroll

834 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question