PIX IOS 7.0 www STATIC Problem

This is driving me crazy guys....help much needed. Below is the config of our PIX, everything works except the WWW passthrough from 217.34.1xx.xxx to in the DMZ. The static works, because when I enable ICMP in from outside, and out from the dmz I can ping the box on the 217.34.1xx.xxx address. It is just www that wont work.

Please tell me what I'm doing wrong - I have done a million of these before but this is just killing me, as I say, the PPTP and GRE works e.t.c. e.t.c.

Another bit of info is that if I log on to the box, I can get internet access (no DNS, but straight IP) and the source address is 217.34.1xx.xxX so the static is definately working.


PIX Version 7.0(1)
interface Ethernet0
 nameif outside
 security-level 0
 ip address 217.34.1xx.xxP
interface Ethernet1
 nameif inside
 security-level 100
 ip address
interface Ethernet2
 nameif dmz
 security-level 4
 ip address
enable password *** encrypted
passwd *** encrypted
hostname ***
ftp mode passive
access-list 101 extended permit ip any any
access-list 101 extended permit tcp any any
access-list 101 extended permit udp any any
access-list 101 extended permit icmp any any
access-list 101 extended permit tcp host any
access-list 101 extended permit udp host any
access-list 110 extended permit tcp any host 217.34.1xx.xxY eq smtp
access-list 110 extended permit tcp any host 217.34.1xx.xxY eq pptp
access-list 110 extended permit gre any host 217.34.1xx.xxY
access-list 110 extended permit tcp host a.a.a.a host 217.34.1xx.xxA eq 1567
access-list 110 extended permit tcp host a.a.a.a host 217.34.1xx.xxA eq citr
access-list 110 extended permit tcp host B.B.B.B host 217.34.1xx.xxA eq 156
access-list 110 extended permit tcp host B.B.B.B host 217.34.1xx.xxA eq cit
access-list 110 extended permit tcp any host 217.34.1xx.xxX eq www
access-list 110 extended permit tcp any host 217.34.1xx.xxX eq https
access-list 120 extended permit tcp host any eq https
access-list 120 extended permit tcp host host eq sqlnet
access-list 120 extended permit tcp host any eq www
access-list 120 extended permit tcp host any eq www
no pager
logging asdm informational
mtu outside 1500
mtu inside 1500
mtu dmz 1500
monitor-interface inside
asdm image flash:/asdm
no asdm history enable
arp timeout 14400
global (outside) 1 217.34.1xx.xxC netmask
global (dmz) 1 netmask
nat (inside) 1
static (inside,dmz) netmask
static (inside,outside) 217.34.1xx.xxY netmask
static (inside,outside) 217.34.1xx.xxA netmask
static (dmz,outside) 217.34.1xx.xxX netmask
access-group 110 in interface outside
access-group 101 in interface inside
access-group 120 in interface dmz
route outside 217.34.1xx.xxZ 1
route inside 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00
timeout mgcp-pat 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption des
isakmp policy 10 hash sha
isakmp policy 10 group 2
isakmp policy 10 lifetime 86400
telnet inside
telnet timeout 5
ssh timeout 5
console timeout 0
class-map inspection_default
 match default-inspection-traffic
policy-map global_policy
 class inspection_default
  inspect dns maximum-length 512
  inspect ftp
  inspect h323 h225
  inspect h323 ras
  inspect http
  inspect rsh
  inspect rtsp
  inspect sip
  inspect skinny
  inspect esmtp
  inspect sqlnet
  inspect pptp
service-policy global_policy global
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Sounds like your web server is having DNS issues. And when clients are connecting to it, it is unable to do reverse DNS lookup on their IP and so it drops the WWW connection. Fix the DNS issue and that will probably fix your problem. I don't think it has anything to do with the PIX.
prodriveitAuthor Commented:
Hmmm....I wish.

We have an almost identical setup in another site which works ok without any DNS configured on the web server and so to test your theory I have put Network Monitor on the web server in the DMZ and monitored the traffic whilst sending HTTP requests to it using the external IP. Nothing came up.

We sent the same requests using the internal IP address from an internal client, we got access to the site and the packets were displayed in netmon.....

so it's definately something to do with the PIX - any other ideas?

How can I debug the pix remotely? Anyone?


Try to test modularly if you can. I would start by removing the access lists (or permit everything).
Fundamentals of JavaScript

Learn the fundamentals of the popular programming language JavaScript so that you can explore the realm of web development.

You say PPTP works but that's to a different server. You say ICMP works but I'd like to make sure you're actually pinging that server. Can you sniff the server while pinging from the outside?
prodriveitAuthor Commented:

Added the following commands

access-list 120 permit icmp host any
access-list 110 permit icmp any host 217.34.1xx.xxX

and ran the sniff - icmp echo and reply packets captured successfully.

Also then tried to open everything on the pix by adding the following

access-list 110 permit tcp any host 217.34.xx.xxX
access-list 110 permit ip any host 217.34.1xx.xxX
access-list 120 permit tcp host any
access-list 120 permit ip host any

Still no joy - I'm glad I'm not going mad!

Any other throughts?

That is indeed weird. You could try turning off the global service-policy.
But one thing I would definitely do is turn on capture on the PIX itself.
access-list capture permit ip host 217.34.xx.xxX any
access-list capture permit ip any host 217.34.xx.xxX
access-list capture permit ip host any
access-list capture permit ip any host
capture capture-out access-list capture interface outside
capture capture-dmz access-list capture interface dmz
show capture capture-out
show capture capture-dmz

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
prodriveitAuthor Commented:
Ok - this is even more wierd.

When I ping the xx.xxX address I see the packets...as below....in both the outside and dmz captures.

  25: 03:32:57.750022 194.73.yyy.yyy > 217.34.xxx.xxX: icmp: echo request
  26: 03:32:57.750724 217.34.xxx.xxX> 194.73.yyy.yyy: icmp: echo reply

However when doing a web request, I see nothing - in my browser I am putting http://217.34.1xx.xxX - there are no proxy settings in the browser.
prodriveitAuthor Commented:
Interestingly I also see https packets on 443.
prodriveitAuthor Commented:
We have sorted it - thank you for your help, the Internet router is a BT provided Xyxel SDSL router and as such comes preconfigured with a load of IP filters - one of which filters porrt 80 for any source and destination addresses - nice of them to let us know!


Do you have a router outside that PIX? Can you see if there are any ACLs on there that might blocking it? Can you set up debugs to see if the web packets are hitting that router at least and whether or not the router is forwarding it towards the PIX?
Oops, I guess I wrote that 4 minutes too late. Glad you found the problem.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.