Re: iptables dropping legitimate packets?

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

 



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


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux