On Saturday 26 February 2005 22:54, Jan Morales wrote: >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 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. Its not. >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 hate to pan a reputable makers product, but I've now had 3 copies of that BEFSX41 router installed here, and they were all broken. I was never able to get a udp packet based protocol to work at all, and even icmp was broken by the 1.50.18 firmware. (ping for instance would work only if the firmware version was backed down to 1.50.9 from 1.50.18) and traceroute was dead until I specified it to use the icmp protocol with the cli -I option. With firmware 1.50.9 in it, I could go get my email, at a working speed of about 1200 baud (I'm on adsl 768/128) but I couldn't even connect with the verizon mail server with 1.50.18 firmware in it. FWIW, I am, and have been using for 2 years, a BEFSR41 which has worked flawlessly, set for gateway mode. But I wanted VPN for a business venture and SNMP for mrtg's reports, which the BEFSR41 doesn't do. >I'll give ethereal a try in the next day or two. > >Thanks! >Jan -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.34% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
