Problem with conntrackd: TCP RST sent on NAT connections
For the record (users googling for problems).
Signature · 1 line
"Los honestos son inadaptados sociales" -- Les Luthiers
Am Friday 20 February 2009 17:49:23 schrieben Sie:
Quoted 54 lines
Quoted 16 lines · Michael Schwartzkopff
Hi,
I have a strange problem here. I set up a testbed like in the on on the website, except that I have NAT im my scenario.
When I test a SSH connection everything goes fine.
When I download a file via HTTP the first failover works, but the failback breaks the connection and the download stops. Tracing the connection show that during the failback the HTTP Server sends a package to the virtual NAT address of my firewall and the firewall send a TCP RST back and thus stops the connection.
Of course I tried first to sync the connection table and after that set up my virtual addresses, but it seems that it does not help.
Quoted 6 lines
A similar problem was described from Abhijit Menon-Sen on Oct, 30th 2007 on the nf-failover mailing list. But I did not find any solution there.
My system:
debian lenny.
Kernel 2.6.26-1-686I remember that this kernel version has some problems if your setup has any helper, if so, I suggest you to upgrade to latest linux kernel.
Quoted 1 line
conntrackd version 0.9.6-4
This is rather old conntrack-tools version. Could you try latest conntrack-tools version from www.netfilter.org?
Using the latest
primary-backup.shscript from git.netfilter.org instead of the old ones that you are using would be also a good idea:http://git.netfilter.org/cgi-bin/gitweb.cgi?p=conntrack-tools.git;a=tree;f=
doc/sync;h=d0e3afe1bca3a581d246fa0b07b67bb8175295f6;hb=HEADQuoted 5 lines
Mode: FTFW, heartbeat as HA solution.
My firewall does allow everything. The only rule is the NAT rule that translats all packets comming from internal to the virtual external address.
Your firewall has to drop invalid packets at least, see the example rule-set in the website. The firewall sends a TCP RST to the client if it didn't find the NAT information, this happens when the conntrack entry does not exist.
Quoted 1 line
Any idea what could be wrong? How could I trace the problem further?
After the first failover, check the primary's internal cache and backup's external cache with the commands:
Quoted 7 lines
show internal cache (do this in the primary):
# conntrackd -ishow external cache (do this in the backup):
# conntrackd -eThey should show the same entries.
Hi,
I did an update to:
kernel 2.6.28-1
libnfnetlink 0.0.40
libnetfilter_conntrack-0.0.99
and
conntrack-tools-0.9.11
No it seems to work everything. Thanks for your help.
Waiting to see these packages in the "usual" distributions ...
Signature · 18 lines
Dr. Michael Schwartzkopff MultiNET Services GmbH Addresse: Bretonischer Ring 7; 85630 Grasbrunn; Germany Tel: +49 - 89 - 45 69 11 0 Fax: +49 - 89 - 45 69 11 21 mob: +49 - 174 - 343 28 75 mail: [email protected] web: www.multinet.de Sitz der Gesellschaft: 85630 Grasbrunn Registergericht: Amtsgericht München HRB 114375 Geschäftsführer: Günter Jurgeneit, Hubert Martens --- PGP Fingerprint: F919 3919 FF12 ED5A 2801 DEA6 AA77 57A4 EDD8 979B Skype: misch42