[vox-tech] Apache: 2, Me: 0.

[Shwaine]

On Tue, 15 Feb 2011, Troy Arnold wrote:
> On Tue, Feb 15, 2011 at 03:27:01PM -0500, Peter Salzman wrote:
>>
>> But as to why the 3-way handshake isn't being fully established ...
>> that would suck because I have *no* idea how to diagnose that sort of
>> thing...
>
> Hey, Pete-
>
> netcat is the perfect tool for determining if the 3 way handshake is
> successful.
>
> On satan:
> stop apache
> # nc -l -p 80
>
> from elsewhere:
> nc dirac.org 80
>
>
> if it works you'll be able to type stuff on either side and see it echoed
> on the other (after hitting return)
>
> At least at the end of this you'll know if your apache config is to blame.
>

Sorry for the late reply, I've been swamped with program reviews, 
candidate interviews, paper writing and teaching all week.... (the things 
we do for academia, heh)

To follow-up on the TCP 3-way handshake issue, in particular, the ACK 
packet is not getting through. If you look at the original tcpdump log, 
the SYN from the outside world gets in, the SYN/ACK from satan gets out, 
but the final ACK from the outside world never arrives.

I sincerely doubt this is an Apache issue. It looks more like an iptables 
issue to me. Try what Troy recommends to confirm that netcat also gets 
blocked (which I suspect it will) just to be sure it isn't Apache. If you 
cannot get through with netcat, the next thing to do is check iptables 
with the following command:

iptables -L -n

Forward the output from that command to the list and we can see if its 
your iptable rules that are preventing the connection from establishing. 
In particular, I would bet you don't have an "allow RELATED,ESTABLISHED" 
rule in place. You probably only have an "allow SYN to port 80" in place. 
Without the corresponding related/established rule, your TCP 3-way 
handshake would get cut off on sending the final ACK, just as was seen in 
your tcpdump output.

For example, for my webserver, you would see the following in the iptables 
INPUT chain with the above iptables command:

Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     tcp  --  0.0.0.0/0            <my IP address>     tcp spts:1024:65535 dpt:80 flags:0x17/0x02
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED

If you are missing that second line while having the "flags" on the first 
line (allow SYN flag only) and your default policy on INPUT is to DROP, 
then you've found your culprit.