--- Jim Carter <jimc@xxxxxxxxxxxxx> schrieb: > Hmmm, good point. However, I think a packet is considered to be part of an > established connection because it has particular header bits set, not > because of IP address matching in the conntrack tables. Someone who's more > familiar with the sources, could you please confirm or correct this > statement? As far as i (thought to) know, a session has to go through the SYN_SENT and SYN_RCVD states before reaching the ESTABLISHED state. the firewall box has to see the TCP SYN, SYN/ACK, ACK packets of a new session before the session is added to the connection table as an established session. if the firewall later sees packets belonging to one of the established sessions in it's connection table, it forwards them if the rulebase is configured so. packets of an established session which can't be matched against a session in the connection table - according to the source and destination sockets - are dropped. > Oh, I didn't understand the configuration. Hmmm again. I would really > expect the http and ssh connections to behave the same. Yep, thats the point. but they don't. > What are the > differences between the connections? Are the services on different > operating systems (Linux / Windows), so the TCP stack behaves differently? The clients are win 2k and Linux, the servers are running Linux (SuSE 8.2, Knoppix) and solaris 8. > Maybe you could put the server-side DMZ's switch into promiscuous mode (so > you can snoop on all packets) and run tcpdump / ethereal / snort. If any > machine is somehow using the IP address of the individual firewall box as > its gateway, its connections won't survive the failover, while if the > shared address is being used, as it should be, it should work. The same > principle applies on the client side too. We were running sniffers on the win 2k client (winpcap/ethereal) and on the servers (tcpdump) as well. on the client and the servers, the gateways were set correctly to the failover addresses of the firewall boxes. i'm aware that we didn't sniff the complete traffic on the switched network segments, but since we didn't see any packets belonging to a new session setup after failover (we would have seen them in the dumps), imho there is no need to dig into the stack implementations at this stage. for me it looks really as if netfilter is not working as it should in this case. __________________________________________________________________ Gesendet von Yahoo! Mail - http://mail.yahoo.de Logos und Klingeltöne fürs Handy bei http://sms.yahoo.de