Apache not responding to web requests after ISP change

[FIX5150]

First, let me start by stating that I am by no means an apache or
linux expert.

I was contracted to move a school from one ISP to another. There T1
service provider was discontinuing service, so they went with Optimum
Business with a single static IP.

Their firewall is a Netscreen 25, with outside, inside and DMZ
networks.

>From the outside SMTP (25) and SSH (22) work to the linux box no

problem, as well as seeing inbound HTTP (80) packets via TCPDUMP. The
box just doesnt send an ACK to any port 80 packets it encounters from
the outside (untrusted) interface.

Requests from the internal (trusted) network are responded to with no
issue.

There have not been ANY changes to the linux box. The only thing that
has changed is the external IP address. The approriate DNS changes
have also been made, and mail is also flowing through this box with no
problems. It is relaying for the internal MS Exchange server.

On the firewall a VIP is setup, redirecting port 80, 25 and 22 to this
servers IP of 192.168.1.3. Everything works excepts 80, and whats
killing me is that I can see the packets pass through the firewall,
AND see them on the box itself via TCP DUMP, AND SERVICES ARE
WORKING!.

My question is; could there be something specific to APACHE that may
be causing this?

Thanks!

[massimo]

Is apache listening on a different port than 80? Is there anything in the apache logs (error, access) what would give us some more information? What does the apache configuration for this specific host look like (virtual host?)?
_________________
Hello 911? How are you?

[Hu]

Please post the output of netstat -atn ; iptables-save -c ; emerge -pv apache; ip addr; ip route; sysctl -a | grep rp_filter from 192.168.1.3, the tcpdump output that indicates that it is working, and a description of the behavior seen by a client trying to access the site from the external interface. Specifically, I want to know whether the request hangs or immediately fails.

Also, are there any other hops between the NAT device and the Apache? I doubt anything in the Apache configuration could be causing this, since Apache cannot suppress sending a SYN|ACK back to the client. Apache can only choose to refuse service after the OS has already sent the SYN|ACK. Since you see no SYN|ACK, the problem lies elsewhere.