Improve company productivity with a Business Account.Sign Up

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 295
  • Last Modified:

Pix and Apache Web Server

What has to be opened up on a PIX 506e to allow name based virtual hosts to pass through the pix to the webserver.  I know it has something to do with dns.  Is it just opening up the dns port inbound?
  • 6
  • 3
  • 3
  • +2
2 Solutions
You shouldn't have to do anything other than open up port 80. As long as external DNS resolves all host names to the same public IP address that the PIX has natted to the Web server.
If it doesn't work, try disabling fixup http
  no fixup protocol http
Thermo1Author Commented:
The server works fine when I put it directly on the internet, something about the PIX blocks it.  Ill have to set the pix up again and try that no fixup.  I got so frustrated with it I just left the webserver directly on the internet.
Take a break and then have a look at the configuration again. If still no joy post the configuration here so that we can take a look at it.

The IT Degree for Career Advancement

Earn your B.S. in Network Operations and Security and become a network and IT security expert. This WGU degree program curriculum was designed with tech-savvy, self-motivated students in mind – allowing you to use your technical expertise, to address real-world business problems.

Thermo1Author Commented:
I put the old configuration back in, put in the no fixup 80.  Still no luck.  Even with changing the service group to letting all tcp ports, still doesnt work.  See config below.  Thanks

PIX Version 6.3(4)
interface ethernet0 auto
interface ethernet1 auto
nameif ethernet0 outside security0
nameif ethernet1 inside security100
clock timezone EST -5
clock summer-time EDT recurring
fixup protocol dns maximum-length 512
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
no fixup protocol http 80
fixup protocol pptp 1723
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
name WebServerInside
name WebServerOutside
object-group service webservices tcp
  port-object eq www
  port-object eq ftp-data
  port-object eq https
  port-object eq ftp
  port-object eq hostname
access-list 100 permit icmp any any
access-list 100 permit icmp any any echo-reply
access-list 100 permit icmp any any time-exceeded
access-list 100 permit icmp any any unreachable
access-list 100 permit tcp any host WebServerOutside object-group webservices
pager lines 24
mtu outside 1500
mtu inside 1500
ip address outside
ip address inside
ip verify reverse-path interface outside
ip audit name DropAndKill attack action drop reset
ip audit name DropInfo info action drop reset
ip audit interface outside DropInfo
ip audit interface outside DropAndKill
ip audit info action alarm
ip audit attack action alarm
pdm location inside
pdm logging informational 100
pdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 1 0 0
static (inside,outside) WebServerOutside WebServerInside netmask 0 0
access-group 100 in interface outside
route outside 1
timeout xlate 0:05: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
http server enable
http inside
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
tftp-server inside \pixbackup
floodguard enable
isakmp enable outside
isakmp nat-traversal 20
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption des
isakmp policy 20 hash md5
isakmp policy 20 group 2
isakmp policy 20 lifetime 86400
telnet inside
telnet timeout 5
ssh timeout 5
management-access inside
console timeout 0
dhcpd lease 3600
dhcpd ping_timeout 750
terminal width 80
: end
There's nothing at all wrong with your PIX configuration, and nothing that I'm aware of that could possibly be causing this issue. Unfortunately I don't know how the Apache server is looking at the GET requests and the user headers. The PIX does not rewrite anything at all, it just passes packets that are allowed.

One last ditch effort. Try adding "dns" keyword to the xlate

no static (inside,outside) WebServerOutside WebServerInside netmask 0 0
clear xlate
static (inside,outside) WebServerOutside WebServerInside dns netmask 0 0
Thermo1Author Commented:
how do you post one of those cross reference links over to the apache forum to see if those guys have any answers?
Just copy the URL from this page and post a new *pointer* question in the Apache forum, then paste this link into the comment box..
I can do it for you if you'd like..
Thermo1Author Commented:
I think I got it.
What error do you get?  What does the Apache logs show?

I would suggest that you install a packet tracing program on the Apache Server ( is good and free) and run a trace.

As long as the http request gets to the apache sever without being modifed there should be no issue.
Add the following line to Your pix config (http is not allowed by firewall at all)

config t
access-list 100 permit tcp any host ip.of.Your.server eq www
#then save config with
write mem


--> access-list 100 permit tcp any host WebServerOutside object-group webservices


--> object-group service webservices tcp
-->   port-object eq www
-->   port-object eq ftp-data
-->   port-object eq https
-->   port-object eq ftp
-->   port-object eq hostname

cover that?
Thermo1Author Commented:
I got the traces, but I dont really understand them.  Is there anyway to post them to be looked at.  I opened them in notepad, and they get kinda scrambled.  Anyway to export the trace as text?
Thermo1Author Commented:
One thing i did notice.... from the apache access log.

On the firewall: - - [13/Nov/2006:16:54:58 -0500] "GET / HTTP/1.1" 304 - - - [13/Nov/2006:16:54:58 -0500] "GET /apache_pb.gif HTTP/1.1" 304 - - - [13/Nov/2006:16:54:58 -0500] "GET /favicon.ico HTTP/1.1" 404 - - - [13/Nov/2006:16:54:58 -0500] "GET / HTTP/1.1" 304 - - - [13/Nov/2006:16:54:58 -0500] "GET /apache_pb.gif HTTP/1.1" 304 - - - [13/Nov/2006:16:54:58 -0500] "GET /favicon.ico HTTP/1.1" 404 -

Off the firewall: - - [13/Nov/2006:16:56:23 -0500] "GET / HTTP/1.1" 200 328 - - [13/Nov/2006:16:56:23 -0500] "GET /imgs/Cam01.jpg HTTP/1.1" 304 - - - [13/Nov/2006:16:56:23 -0500] "GET /imgs/Cam03.jpg HTTP/1.1" 304 - - - [13/Nov/2006:16:56:23 -0500] "GET /imgs/Cam02.jpg HTTP/1.1" 304 - - - [13/Nov/2006:16:56:23 -0500] "GET /imgs/Cam04.jpg HTTP/1.1" 304 - - - [13/Nov/2006:16:56:23 -0500] "GET /favicon.ico HTTP/1.1" 404 -

The first get http header has some different numbers after it.  Does that mean anything?
All of these are the "responses" to the GETs.

--> - - [13/Nov/2006:16:54:58 -0500] "GET / HTTP/1.1" 304 -

A non-specific GET using HTTP 1.1 was done.  This causes the Web sever to either serve up a document that matches the default document name (normally index.html), show a directory listing (if enabled and there is no "default document found), or say directory listing/browsing is denied (if directory listing is disabled and there is no default document).

The "304" is the HTTP return code that the Apache returned.  In this it case Apache is saying the document has not changed and so use the "cached" version.  Which is weird, as I did not think you could return a 304 for a "/" request.  That it had be be a request for a specific file name (like/imgs/Cam01.jpg).  

If the browser has a cached copy of the file, when it issues the GET it will include an HTTP header with the datetime stamp of the file in cached.  If the file has not changed the sever will return "304", it is has changed it will return a "200" and the file.

On the second instance:

--> - - [13/Nov/2006:16:56:23 -0500] "GET / HTTP/1.1" 200 328

The same get was issued, but this time Apache returned "200", which means the get was succesfull, here is the document and oh by the way it is 328 bytes long.

I don't see how using a PIX firewall would cause this.  Unless when using the PIX it is re-routing request through some type of inbound (reverse) proxy sever.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

What Kind of Coding Program is Right for You?

There are many ways to learn to code these days. From coding bootcamps like Flatiron School to online courses to totally free beginner resources. The best way to learn to code depends on many factors, but the most important one is you. See what course is best for you.

  • 6
  • 3
  • 3
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now