iptables dropping legitimate packets?
jan at geezjan.org
Sun Feb 27 03:54:56 UTC 2005
Robert Spangler wrote:
> -----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
> 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.
>> :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
>> -A RH-Firewall-1-INPUT -j LOG -d 192.168.0.5 --log-prefix "iptables: "
>> -A RH-Firewall-1-INPUT -j DROP
> 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.
> Smile... it increases your face value!
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
> -----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.
More information about the users