|
Horms wrote:
On Mon, Aug 25, 2003 at 10:39:30AM -0400, Marc Tardif wrote:
Horms wrote:
Hi,
I take it that this tcpdump was taken on the internal interface
of the linux director (gateway). If so it looks like the packet
from the real server (external box) is being correctly sent to
the real server (internal box) and that the real server is in
turn replying correctly, It also seems that the Linux Director is
seeing the return packet, though without examining the MAC address
it is hard to confirm that it has been sent to the Linux Director.
I would suspect that the problem is that that the Linux Director
is not demasquerading and forwarding the return packets. Can you
confirm that the routing on the Linux Director is correct,
that probablyu means 10.9.201/24 being routed to the internal
interface and 0/0 or at least 192.168.0/24 being routed to the
external interface.
Here's a tcpdump on the external interface of the Linux Director:
10:07:51.140679 192.168.0.68.1084 > 192.168.0.2.http: S
352642595:352642595(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
10:07:54.066679 192.168.0.68.1084 > 192.168.0.2.http: S
352642595:352642595(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
That means the external box keeps trying to establish an http connection
but is never receiving a response. Therefore, you are right that the
Linux Director is not forwarding the return packets. You've asked me to
confirm the routing information but I'm not sure what to show you other
than the ipchains configuration in my original message. Just in case
it's relevant, here's my routing table on the Linux Director:
# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags Iface
10.9.201.0 0.0.0.0 255.255.255.0 U eth0
192.168.0.0 0.0.0.0 255.255.255.0 U eth1
127.0.0.0 0.0.0.0 255.0.0.0 U lo
0.0.0.0 10.9.201.7 0.0.0.0 UG eth0
That looks about right to me. Do you have any iptables
rules other than the masq rule that you mentioned in a previous email?
If so perphaps they are causing a problem. In any case, try clearing
all of the iptables rules and setting the default policies to
ACCEPT, perhaps that will help, though I doubt it.
The only other thing that springs to mind is to try a different
kernel. Sometimes strange versions do strange things.
I have no other iptables rules. Also, as suggested by someone else, I
also tried removing all rules and that didn't work either.
What's odd is that I was then constantly trying to telnet from my
external box to my gateway (Linux Director) on port 80. At first, it was
constantly getting a "Failed to connect" error message. Then, I ran
tcpdump on the internal interface and telnet suddenly was going through.
I didn't do anything other than run tcpdump and it magically started
working. I hate when things like this happen which I can't explain more
intelligently, but my load balancing now works.
--
Marc Tardif
Sitepak
(514) 866-8883
|
