Re: unexpected behaviour...?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 --- 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


[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux