From mboxrd@z Thu Jan 1 00:00:00 1970 From: Doug Watson Subject: RE: intermittent and unreliable behaviour with iptables scripts Date: Fri, 15 Nov 2002 10:14:14 -0500 Sender: netfilter-admin@lists.netfilter.org Message-ID: <91F7518FF779D41181A700010266356D015555ED@mail.springbound.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28CB9.A8B11090" Return-path: Errors-To: netfilter-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: To: 'alex' Cc: netfilter@lists.netfilter.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C28CB9.A8B11090 Content-Type: text/plain; charset="iso-8859-1" Thanks for the response. What you mentioned in your first paragraph was and may still be part of my problem. Per the suggestion of another list user I am on the trail of RELATED packets that may be getting DROPped. I think that I have adjusted my rules in the INPUT, OUTPUT and FORWARD chains properly to allow for this. But the latest development in the enigma that surrounds my firewall is this. For one, I did not know where packets were being logged when the --log-level option was set to DEBUG. Can anyone clarify this for me? More importantly I simply removed the --log-level option from my logging rule in the FORWARD chain prior to a drop by the FORWARD chains policy (DROP) so that they would be logged to /var/log/messages where I could find them. What I have seen both disturbs and confuses me terribly. I am seeing packets that have a source address from my LAN that are destined to an external network that are hitting the firewall on its WAN interface (eth2) rather than its LAN interface (eth0) and being DROPped by the FORWARD chain's policy. I would think that these packets should be incoming on the firewall's LAN interface. This seems to coincide with the intermittent and unreliable performance that I have been seeing. For example yesterday I was at the console of the firewall and using tail -f /var/log/messages to see what was being logged and tcpdump I started seeing these packets being logged when someone was attempting to browse the internet and could not. Eventually without explanation that person was able to get through to some web pages and when this happened I stopped seeing these packets being logged and dropped. My set up is a tad screwy in that I am trying to test this along side my current production firewall and I only have 1 source of bandwidth which comes and goes through a Cisco 2621 router. I have the ethernet from the Cisco plugged into a 3Com 3300 switch. I also have the current firewalls external interface plugged into this switch along with some of our servers. I also have the LAN and WAN interfaces of the firewall in question plugged into this switch. The switch is unlinked via fiber to the rest of the network. In the end I would have the ethernet from the Cisco plugged directly into the WAN interface of the new (questionable) firewall. That being said has anyone seen the situation described above before? Do you think that my switch or atleast a port on the switch could be to blame for these packets arriving on the wrong interface if that is what truly is happening. Thank you, Doug Watson Director of Information Systems 1stBooks Library http://www.1stbooks.com dwatson@1stbooks.com 1 800 839 8640 Toll Free 1 812 339 6554 Fax -----Original Message----- From: alex [mailto:alex@bennee.com] Sent: Wednesday, November 13, 2002 5:48 PM To: Doug Watson Cc: netfilter@lists.netfilter.org Subject: RE: intermittent and unreliable behaviour with iptables scripts On Wed, 2002-11-13 at 14:34, Doug Watson wrote: > If there really is a bug in ip_conntrack > that makes me unfortunately skiddish about > continuing on with netfilter/iptables as a > viable solution for my company. Yet it seems > like many people have implemented this and have > not seen these types of problems. Agreed. I finally solved my problem which was due to me not allowing ICMP packets to sent out the OUTPUT chain for established connections that where being forwarded. My bad, *not* a conntrack problem, it just seemed that way at the time. > I have run the script that you sent me several times. > Attached is a sample output from it. I don't believe that > I am seeing anything too strange, but I do have 1 question. > in the following line which you will see in the attached file > what does the (policy ACCEPT 4 packets, 284 bytes) mean? > Chain OUTPUT (policy ACCEPT 4 packets, 284 bytes) Your attachment seems to of been filtered out. The policy lines mean that no rules in the chain matched and therefor the default policy took effect. It is usually recommended to have a default DROP policy if your being paranoid and explicitly allow the connections you want to come through. However as I learnt the hard way you have to make sure the related traffic is also allowed through. The ICMP packet that bit me was due to fragmentation being required but not possible on the gateway, probably a symptom of the fact my two interfaces (ppp and eth) had different MTU's. > Is that the total number of packets to traverse the OUTPUT > chain or it he number of packets ACCEPTED by the policy for the > OUTPUT chain? Or something else? Just the packets that defaulted to the policy, the other counts will be against each rule itself. -- Alex http://www.bennee.com/~alex/ ------_=_NextPart_001_01C28CB9.A8B11090 Content-Type: text/html; charset="iso-8859-1" RE: intermittent and unreliable behaviour with iptables scripts

Thanks for the response. What you mentioned in your first
paragraph was and may still be part of my problem.

Per the suggestion of another list user I am on the trail
of RELATED packets that may be getting DROPped. I think that
I have adjusted my rules in the INPUT, OUTPUT and FORWARD
chains properly to allow for this.

But the latest development in the enigma that surrounds my firewall is this.
For one, I did not know where packets were being logged when the --log-level option
was set to DEBUG. Can anyone clarify this for me?
 
More importantly I simply removed the --log-level option from my logging
rule in the FORWARD chain prior to a drop by the FORWARD chains policy (DROP)
so that they would be logged to /var/log/messages where I could find them.
What I have seen both disturbs and confuses me terribly.
I am seeing packets that have a source address from my LAN that are destined
to an external network that are hitting the firewall on its WAN interface (eth2) rather
than its LAN interface (eth0) and being DROPped by the FORWARD chain's policy.
I would think that these packets should be incoming on the firewall's LAN interface.
This seems to coincide with the intermittent and unreliable performance that I have
been seeing.
For example yesterday I was at the console of the firewall and using
tail -f /var/log/messages to see what was being logged and tcpdump I started seeing
these packets being logged when someone was attempting to browse the internet and could not.
Eventually without explanation that person was able to get through to some web pages and when
this happened I stopped seeing these packets being logged and dropped.

My set up is a tad screwy in that I am trying to test this along side my current production firewall and
I only have 1 source of bandwidth which comes and goes through a Cisco 2621 router. I have the ethernet
from the Cisco plugged into a 3Com 3300 switch. I also have the current firewalls external interface
plugged into this switch along with some of our servers. I also have the LAN and WAN interfaces of the
firewall in question plugged into this switch. The switch is unlinked via fiber to the rest of the
network. In the end I would have the ethernet from the Cisco plugged directly into the WAN interface
of the new (questionable) firewall.

That being said has anyone seen the situation described above before? Do you think that my switch or atleast a
port on the switch could be to blame for these packets arriving on the wrong interface if
that is what truly is happening.

Thank you,
Doug Watson
Director of Information Systems
1stBooks Library
http://www.1stbooks.com
dwatson@1stbooks.com
1 800 839 8640 Toll Free
1 812 339 6554 Fax


-----Original Message-----
From: alex [mailto:alex@bennee.com]
Sent: Wednesday, November 13, 2002 5:48 PM
To: Doug Watson
Cc: netfilter@lists.netfilter.org
Subject: RE: intermittent and unreliable behaviour with iptables scripts


On Wed, 2002-11-13 at 14:34, Doug Watson wrote:
> If there really is a bug in ip_conntrack
> that makes me unfortunately skiddish about
> continuing on with netfilter/iptables as a
> viable solution for my company. Yet it seems
> like many people have implemented this and have
> not seen these types of problems.

Agreed. I finally solved my problem which was due to me not allowing
ICMP packets to sent out the OUTPUT chain for established connections
that where being forwarded. My bad, *not* a conntrack problem, it just
seemed that way at the time.

> I have run the script that you sent me several times.
> Attached is a sample output from it. I don't believe that
> I am seeing anything too strange, but I do have 1 question.
> in the following line which you will see in the attached file
> what does the (policy ACCEPT 4 packets, 284 bytes) mean?
> Chain OUTPUT (policy ACCEPT 4 packets, 284 bytes)

Your attachment seems to of been filtered out. The policy lines mean
that no rules in the chain matched and therefor the default policy took
effect. It is usually recommended to have a default DROP policy if your
being paranoid and explicitly allow the connections you want to come
through. However as I learnt the hard way you have to make sure the
related traffic is also allowed through. The ICMP packet that bit me was
due to fragmentation being required but not possible on the gateway,
probably a symptom of the fact my two interfaces (ppp and eth) had
different MTU's.

> Is that the total number of packets to traverse the OUTPUT
> chain or it he number of packets ACCEPTED by the policy for the
> OUTPUT chain? Or something else?

Just the packets that defaulted to the policy, the other counts will be
against each rule itself.

--
Alex
http://www.bennee.com/~alex/

------_=_NextPart_001_01C28CB9.A8B11090--