l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2011 Feb 21 16:41

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Apache: 2, Me: 0.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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  --            <my IP address>     tcp spts:1024:65535 dpt:80 flags:0x17/0x02
ACCEPT     all  --             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.
vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Sunset Systems
Who graciously hosts our website & mailing lists!