Hello! We're running into another potential interaction, this time between tproxy and IPVS http://www.linuxvirtualserver.org on Linux 2.4.27. What we see with TPPROXY 2.0, and going at least as far back as 1.9.6, is that incoming connections that go through IPVS for load balancing are properly mapped to a real server, but when the reply packets come back from the real server, they aren't recognized. Conntrack considers the connection [UNREPLIED] even though tcpdump shows that the reply packets are arriving with the expected source and destination address/ports. It seems like the reply packets are being dropped. The only evidence suggesting that TPROXY is involved at this point is the observation that the problem doesn't appear when we use TPROXY 1.2. One other data point is that, when we use TPROXY 2.0, the problem appears even when the module is not loaded, so it seems to be a side effect of patches to other modules. I realize this is vague, and we're trying to track it down, but I thought I would post and just see if anyone else has observed similar behavior, or if there are any ideas for locating the source of the problem. Thanks! Tim _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com
Hi, 2004-10-14, cs keltezéssel 12:04-kor Tim Burress ezt írta:
The only evidence suggesting that TPROXY is involved at this point is the observation that the problem doesn't appear when we use TPROXY 1.2. One other data point is that, when we use TPROXY 2.0, the problem appears even when the module is not loaded, so it seems to be a side effect of patches to other modules.
I realize this is vague, and we're trying to track it down, but I thought I would post and just see if anyone else has observed similar behavior, or if there are any ideas for locating the source of the problem.
Do you use the TCP window tracking patch from the TProxy tarball? Although I don't use LVS myself, I've found this: http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.filter_rules.html -- Regards, Krisztian KOVACS
Hello! Yes, we have these patches installed: 00-tcp_window_tracking.diff 01-nat_reservations.diff 02-nat_reservations_tproxy_exports.diff 03-tproxy.diff plus Julian's ipvs_nfct patch (the one you mention in the link) to provide the interface between IPVS and conntrack. I also should have said that we are only using LVS-NAT in the IPVS setup. Thanks for your note and the link. We'll keep digging ;-) Tim --- KOVACS Krisztian <hidden@balabit.hu> wrote:
Hi,
2004-10-14, cs keltez�ssel 12:04-kor Tim Burress ezt �rta:
The only evidence suggesting that TPROXY is involved at this point is the observation that the problem doesn't appear when we use TPROXY 1.2. One other data point is that, when we use TPROXY 2.0, the problem appears even when the module is not loaded, so it seems to be a side effect of patches to other modules.
I realize this is vague, and we're trying to track it down, but I thought I would post and just see if anyone else has observed similar behavior, or if there are any ideas for locating the source of the problem.
Do you use the TCP window tracking patch from the TProxy tarball? Although I don't use LVS myself, I've found this:
http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.filter_rules.html
-- Regards, Krisztian KOVACS
_______________________________________________ tproxy mailing list tproxy@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/tproxy
_______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com
Hi, 2004-10-15, p keltezéssel 04:20-kor Tim Burress ezt írta:
plus Julian's ipvs_nfct patch (the one you mention in the link) to provide the interface between IPVS and conntrack. I also should have said that we are only using LVS-NAT in the IPVS setup.
Hmm, strange... Can you try _without_ window tracking? -- Regards, Krisztian KOVACS
Hi Krisztian! Your suggestion to remove window tracking was a good one, and finally led us to the real root of the problem, which turned out to be an uninitialized stack variable in the ipvs_nfct code. We just sent Julian a patch, so I guess that will be updated at some point. What made the problem appear related to TPROXY turned out to be differences in interaction between different versions of the TPROXY patches and some of the other patches we use. Netfilter is getting to be kind of a jungle in that way... Anyway, sorry to have troubled you, and thanks very much for your help and patience! Tim _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com
participants (2)
-
KOVACS Krisztian
-
Tim Burress