-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday 24 February 2005 11:30, Jan Morales wrote:
Because of this network architecture, the PC under RHEL3 recorded no dropped packets, presumably because the network firewall was doing its job. However, now that the PC is running FC3 I am seeing dropped packets logged. The packets, however, are not inbound sessions. They appear to be packets inbound that are part of outbound sessions, e.g. POP and web sessions initiated by the PC. The logged packets also don't appear to be dropped from every single session, just from some, in a pattern I haven't figured out yet. Here is a sample of the logged packets:
If I had to make a guess at what was going on here, without seeing a log file from the RHEL3 machine, I would say it's a timing issue. I do agree with you that it's all from an established connection and not a new one.
What it looks like to me is that for some reason these packets when they arrive are not being seen as part of an established/related connection. But without more detail it would really be hard to tell you exactly what is happening.
Let me ask you this: what are you running for a firewall/NAT box?
Is there some reason why iptables is dropping, or at least logging, these legitimate packets? Is there a difference between iptables in RHEL3 and FC3 that accounts for this? My /etc/sysconfig/iptables follows:
I really cannot say without more information and iptables is not only logging these packets but dropping them as well with the last rule.
# Firewall configuration written by redhat-config-securitylevel # Manual customization of this file is not recommended. *filter
:INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT -A FORWARD -j RH-Firewall-1-INPUT -A RH-Firewall-1-INPUT -i lo -j ACCEPT -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT -A RH-Firewall-1-INPUT -j LOG -d 192.168.0.5 --log-prefix "iptables: " -A RH-Firewall-1-INPUT -j DROP COMMIT
I don't understand why RH doesn't move the ESTABLISHED,RELATED rule to the top of the chain. If a connection is established or related then there is no reason to drop down through all the rules again just to get to that one.
Here is something that you could try.
1. Start ethereal and get a packet capture. Let it run for a while.
2. Start a console and run 'tail -f /var/log/messages'
3. Run a web browser and fetch some mail.
4. Watch 'tail' until you see a few dropped packets being logged.
5. Stop ethereal and compare what you captured to what is being logged in the message file.
With this you should be able to see the complete transaction and figure out what is being dropped when.
Regards Robert
Smile... it increases your face value! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFCI9jC0xJrO8dQYHgRArm7AJ94Ckj/45SKvTjhDDzPutU2ldGWhwCgnfJu 6co+kBgdi8ajDbkRPzfoY0E= =3Drk -----END PGP SIGNATURE-----
Well, at the very least I feel like I got a sanity check; that my /etc/sysconfig/iptables is not likely the problem.
When I first moved to FC3 I was running a Netgear RT311 as my firewall/NAT box. I recently replaced it with a Linksys BEFSX41 firewall router. The iptables behavior appears unaffected by this switch. RHEL3 was definitely not showing this behavior.
I'll give ethereal a try in the next day or two.
Thanks! Jan
