Showing results for 
Search instead for 
Did you mean: 

DMZ Access

I have a strange issue with access to the web server in my DMZ. It has a web portal running on it. When users try to log in first thing in the morning it fails the first time but works the 2nd time. It is then fine for the rest of the day. We have put the server on the LAN to test if this happens there but it doesnt. Only when the server is in the DMZ. Here is my config. Can anyone help shed any light on the matter. Thanx.

Also when I look at my syslog server I dont see any errors and when it doesnt work I can ping the server in the DMZ without any issue.

PIX Version 6.2(2)

nameif ethernet0 outside security0

nameif ethernet1 inside security100

nameif ethernet2 dmz security50

enable password XXXXXXXXX encrypted

passwd XXXXXXXXXX encrypted

hostname pix

fixup protocol ftp 21

fixup protocol http 80

fixup protocol h323 h225 1720

fixup protocol h323 ras 1718-1719

fixup protocol ils 389

fixup protocol rsh 514

fixup protocol rtsp 554

fixup protocol smtp 25

fixup protocol sqlnet 1521

fixup protocol sip 5060

fixup protocol skinny 2000


access-list inside_access_in permit tcp any any eq www

access-list inside_access_in permit tcp any any eq ftp

access-list inside_access_in permit tcp any any eq ftp-data

access-list inside_access_in permit tcp any any eq telnet

access-list inside_access_in permit tcp any any eq smtp

access-list inside_access_in permit esp any any

access-list inside_access_in permit ip any any

access-list inside_access_in permit udp any any

access-list nonat permit ip

access-list splitACL permit ip

access-list mail_in permit tcp any host XXXXXXXX eq smtp

access-list mail_in permit tcp any host XXXXXXXX eq www

access-list mail_in permit tcp any host XXXXXXXX eq https

pager lines 24

logging on

logging timestamp

logging trap notifications

logging host inside

interface ethernet0 10baset

interface ethernet1 10full

interface ethernet2 auto

mtu outside 1500

mtu inside 1500

mtu dmz 1500

ip address outside XXXXXXXXX

ip address inside

ip address dmz

ip audit info action alarm

ip audit attack action alarm

ip local pool vpndhcp

pdm location inside

pdm location inside

pdm location inside

pdm location inside

pdm location dmz

pdm location inside

pdm logging notifications 100

pdm history enable

arp timeout 14400

global (outside) 1 interface

nat (inside) 0 access-list nonat

nat (inside) 1 0 0

static (inside,outside) tcp xxxxxxxxx smtp smtp netmask 0 0

static (inside,dmz) netmask 0 0

static (dmz,outside) xxxxxxxxx netmask 0 0

access-group mail_in in interface outside

access-group inside_access_in in interface inside

route outside xxxxxxxxxxx 1

timeout xlate 0:05:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h323 0:05:00 si

p 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 inside

no snmp-server location

no snmp-server contact

snmp-server community public

no snmp-server enable traps

floodguard enable

sysopt connection permit-ipsec

no sysopt route dnat

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac

crypto dynamic-map outside_dyn_map 20 set transform-set ESP-3DES-SHA

crypto map outside_map 20 ipsec-isakmp dynamic outside_dyn_map

crypto map outside_map interface outside

isakmp enable outside

isakmp policy 20 authentication pre-share

isakmp policy 20 encryption 3des

isakmp policy 20 hash sha

isakmp policy 20 group 2

isakmp policy 20 lifetime 86400

vpngroup vpn address-pool vpndhcp

vpngroup vpn dns-server

vpngroup vpn default-domain xxxxxxxxxxxxx

vpngroup vpn split-tunnel splitACL

vpngroup vpn idle-time 1800

vpngroup vpn password xxxxxxxxx

telnet inside

telnet timeout 5

ssh timeout 5

terminal width 80


: end





Hi Dave,

I think its a problem with the arp cache aging out, try increasing the arp timeout value.


timeout uauth 0:05:00 absolute --> you may need to increase with bigger value for absolute.


i think above is your problem, you may refer to this page



This timeout will come into play a role when you have AAA configured on the PIX fo r the pass-thru traffic not for the web server authenticated traffic. So, changing this timeout will not have any effect as there is no AAA configured on the PIX. Dave, if you can captured the syslog (setting logging level to debugging) for a session when it fails), we can shed some lights as to whats going on. Your config looks good to me. How is the traffic load on the PIX?





Did you ever get this issue resolved? I am having a similar issue with some web portals also.