From mboxrd@z Thu Jan 1 00:00:00 1970 From: Doug Watson Subject: RE: intermittent and unreliable behaviour with iptables scripts Date: Wed, 13 Nov 2002 09:34:08 -0500 Sender: netfilter-admin@lists.netfilter.org Message-ID: <91F7518FF779D41181A700010266356D015555DE@mail.springbound.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28B21.B9E83620" 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_01C28B21.B9E83620 Content-Type: text/plain; charset="iso-8859-1" Thank you for your prompt response. 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. 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) 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? Thank you, Doug Watson -----Original Message----- From: alex [mailto:alex@bennee.com] Sent: Monday, November 11, 2002 6:19 PM To: Doug Watson Cc: 'netfilter@lists.netfilter.org' Subject: Re: intermittent and unreliable behaviour with iptables scripts On Mon, 2002-11-11 at 17:25, Doug Watson wrote: > However, I along with my test group of 5 "lucky" users began to see > some > intermittent and unreliable behavior when accessing the internet > through > this new firewall most notably when browsing the web. > > When browsing the web, web pages that normally would load very quickly > seem > to hang for an inconsistent amount of time, anywhere between 1 second > to 30 seconds or more > before they would even begin to load or would at times never load at > all as > if the connection to the web was lost. This sound familiar to my own woes with port forwarded connections. I suspect a bug in ip_conntrack that somehow causes FORWARDED packets to end up in the output chains. I've been trying to find out exactly when this occurs and why (and certainly why my older script worked without problems). You could try a using a variation of this script to monitor your connections "live" and see which rule starts dropping when you experience your problems. Try using it with something like watch: iptables -Z -t nat iptables -Z watch -n 5 -d ./dumpview #!/bin/bash # # dumpview - try and see where the packets get dropped. # echo "DNAT Stuff" iptables -nvL -t nat echo "Dropped packets of normal chains" iptables -nvL | egrep "Chain|DROP" echo "Connections" cat /proc/net/ip_conntrack | wc -l echo "Web Connections" cat /proc/net/ip_conntrack | grep "port=80" -- alex My own hacking haven ------_=_NextPart_001_01C28B21.B9E83620 Content-Type: text/html; charset="iso-8859-1" RE: intermittent and unreliable behaviour with iptables scripts

Thank you for your prompt response.

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.

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)

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?

Thank you,
Doug Watson

-----Original Message-----
From: alex [mailto:alex@bennee.com]
Sent: Monday, November 11, 2002 6:19 PM
To: Doug Watson
Cc: 'netfilter@lists.netfilter.org'
Subject: Re: intermittent and unreliable behaviour with iptables scripts


On Mon, 2002-11-11 at 17:25, Doug Watson wrote:
>  However, I along with my test group of 5 "lucky" users began to see
> some
> intermittent and unreliable behavior when accessing the internet
> through
> this new firewall most notably when browsing the web.
>
> When browsing the web, web pages that normally would load very quickly
> seem
> to hang for an inconsistent amount of time, anywhere between 1 second
> to 30 seconds or more
> before they would even begin to load or would at times never load at
> all as
> if the connection to the web was lost.

This sound familiar to my own woes with port forwarded connections. I
suspect a bug in ip_conntrack that somehow causes FORWARDED packets to
end up in the output chains. I've been trying to find out exactly when
this occurs and why (and certainly why my older script worked without
problems).

You could try a using a variation of this script to monitor your
connections "live" and see which rule starts dropping when you
experience your problems. Try using it with something like watch:

    iptables -Z -t nat
    iptables -Z
    watch -n 5 -d ./dumpview

#!/bin/bash
#
# dumpview - try and see where the packets get dropped.
#
echo "DNAT Stuff"
iptables -nvL -t nat
echo "Dropped packets of normal chains"
iptables -nvL | egrep "Chain|DROP"
echo "Connections"
cat /proc/net/ip_conntrack | wc -l
echo "Web Connections"
cat /proc/net/ip_conntrack | grep "port=80"

--
alex <alex@bennee.com>
My own hacking haven

------_=_NextPart_001_01C28B21.B9E83620-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Raymond Leach Subject: RE: intermittent and unreliable behaviour with iptables scripts Date: 13 Nov 2002 17:16:06 +0200 Sender: netfilter-admin@lists.netfilter.org Message-ID: <1037200566.4557.37.camel@rayw.knowledgefactory.co.za> References: <91F7518FF779D41181A700010266356D015555DE@mail.springbound.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-63yppBsOBVW84NNl3UKm" Return-path: In-Reply-To: <91F7518FF779D41181A700010266356D015555DE@mail.springbound.com> Errors-To: netfilter-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: To: "'netfilter@lists.netfilter.org'" --=-63yppBsOBVW84NNl3UKm Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2002-11-13 at 16:34, Doug Watson wrote: > Thank you for your prompt response. >=20 > If there really is a bug in ip_conntrack > that makes me unfortunately skiddish about=20 > continuing on with netfilter/iptables as a=20 > viable solution for my company. Yet it seems=20 > like many people have implemented this and have > not seen these types of problems. >=20 hmm... me neither > 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) >=20 It means that the default policy for the OUTPUT chain is to accept packets and that there have been 4 packets totalling 284 bytes tested against this chain. > Is that the total number of packets to traverse the OUTPUT=20 > chain or it he number of packets ACCEPTED by the policy for the=20 > OUTPUT chain? Or something else? >=20 As above ... > Thank you, > Doug Watson >=20 > -----Original Message----- > From: alex [mailto:alex@bennee.com] > Sent: Monday, November 11, 2002 6:19 PM > To: Doug Watson > Cc: 'netfilter@lists.netfilter.org' > Subject: Re: intermittent and unreliable behaviour with iptables > scripts >=20 >=20 > On Mon, 2002-11-11 at 17:25, Doug Watson wrote: > > However, I along with my test group of 5 "lucky" users began to see > > some > > intermittent and unreliable behavior when accessing the internet > > through > > this new firewall most notably when browsing the web.=20 > >=20 > > When browsing the web, web pages that normally would load very > quickly > > seem=20 > > to hang for an inconsistent amount of time, anywhere between 1 > second > > to 30 seconds or more > > before they would even begin to load or would at times never load at > > all as > > if the connection to the web was lost. >=20 > This sound familiar to my own woes with port forwarded connections. I > suspect a bug in ip_conntrack that somehow causes FORWARDED packets to > end up in the output chains. I've been trying to find out exactly when > this occurs and why (and certainly why my older script worked without > problems). >=20 > You could try a using a variation of this script to monitor your > connections "live" and see which rule starts dropping when you > experience your problems. Try using it with something like watch: >=20 > iptables -Z -t nat > iptables -Z > watch -n 5 -d ./dumpview >=20 > #!/bin/bash > # > # dumpview - try and see where the packets get dropped. > # > echo "DNAT Stuff" > iptables -nvL -t nat > echo "Dropped packets of normal chains" > iptables -nvL | egrep "Chain|DROP" > echo "Connections" > cat /proc/net/ip_conntrack | wc -l > echo "Web Connections" > cat /proc/net/ip_conntrack | grep "port=3D80"=20 >=20 > --=20 > alex > My own hacking haven --=20 --=-63yppBsOBVW84NNl3UKm Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA90my1h1fuR/Bv+ygRApxvAJ0SHyn0077JAS9nL/fCGmNwItZSmQCgqk+x NMSayBa1/s0xniNLrWsuLTA= =drqi -----END PGP SIGNATURE----- --=-63yppBsOBVW84NNl3UKm-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dax Kelson Subject: RE: intermittent and unreliable behaviour with iptables scripts Date: 13 Nov 2002 11:13:54 -0700 Sender: netfilter-admin@lists.netfilter.org Message-ID: <1037211234.2257.14.camel@mentor> References: <91F7518FF779D41181A700010266356D015555DE@mail.springbound.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <91F7518FF779D41181A700010266356D015555DE@mail.springbound.com> Errors-To: netfilter-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Content-Type: text/plain; charset="us-ascii" To: Doug Watson Cc: 'alex' , "'netfilter@lists.netfilter.org'" On Wed, 2002-11-13 at 07:34, Doug Watson wrote: > Thank you for your prompt response. > > 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. > > 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) > > 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? > > Thank you, > Doug Watson I don't think there is a bug, but rather improper rules. This is a common mistake that beginners and experts make on firewalls. What you describe: "When browsing the web, web pages that normally would load very quickly seem to hang for an inconsistent amount of time, anywhere between 1 second to 30 seconds or more before they would even begin to load or would at times never load at all as if the connection to the web was lost." This is the CLASSIC (bizarre, yes) symptom of IP fragmentation not working properly. When I first say these symptoms in 1996, it stumped me for awhile. Why would IP fragmentation not be working properly? The answer is that you are not letting ICMP Type 3, Code 4 (ala fragmentation-needed) packets through. I don't know what your specific rules are, but generally the solution is to have the following rule as the first rule in either INPUT, OUTPUT, or FORWARD (or all three, which one depends on the overall design of your ruleset). iptables -A INPUT/OUTPUT/FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT The 'RELATED' will catch those ICMP Typ3, Code 4 packets. Dax Kelson Guru Labs From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joel Newkirk Subject: Re: intermittent and unreliable behaviour with iptables scripts Date: Wed, 13 Nov 2002 15:21:21 -0500 Sender: netfilter-admin@lists.netfilter.org Message-ID: <200211131521.21313.netfilter@newkirk.us> References: <91F7518FF779D41181A700010266356D015555DE@mail.springbound.com> <1037200566.4557.37.camel@rayw.knowledgefactory.co.za> Reply-To: netfilter@newkirk.us Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1037200566.4557.37.camel@rayw.knowledgefactory.co.za> Errors-To: netfilter-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Content-Type: text/plain; charset="us-ascii" To: "'netfilter@lists.netfilter.org'" On Wednesday 13 November 2002 10:16 am, Raymond Leach wrote: > On Wed, 2002-11-13 at 16:34, Doug Watson wrote: > > what does the (policy ACCEPT 4 packets, 284 bytes) mean? > > Chain OUTPUT (policy ACCEPT 4 packets, 284 bytes) > > It means that the default policy for the OUTPUT chain is to accept > packets and that there have been 4 packets totalling 284 bytes tested > against this chain. Actually, this tells us that 4 packets totalling 284 bytes made it throug= h the=20 output chain rules and were ACCEPTED by policy rather than a rule. If an= =20 earlier rule in the chain led to an ACCEPT or a DROP or RETURN then it wi= ll=20 NOT be counted here, but only in the rule(s) it matched. > > 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? > > As above ... j From mboxrd@z Thu Jan 1 00:00:00 1970 From: alex Subject: RE: intermittent and unreliable behaviour with iptables scripts Date: 13 Nov 2002 22:47:37 +0000 Sender: netfilter-admin@lists.netfilter.org Message-ID: <1037227657.8028.36.camel@trent.nin> References: <91F7518FF779D41181A700010266356D015555DE@mail.springbound.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <91F7518FF779D41181A700010266356D015555DE@mail.springbound.com> Errors-To: netfilter-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Content-Type: text/plain; charset="us-ascii" To: Doug Watson Cc: netfilter@lists.netfilter.org 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/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Luis Fernando Barrera" Subject: ICMP question Date: Thu, 14 Nov 2002 12:28:29 -0600 Sender: netfilter-admin@lists.netfilter.org Message-ID: References: <1037211234.2257.14.camel@mentor> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1037211234.2257.14.camel@mentor> Errors-To: netfilter-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Content-Type: text/plain; charset="us-ascii" To: netfilter@lists.netfilter.org Hi all, I have a RedHat 7.3 box which I use as a dual homed firewall. One of the rules is that I allow all the ICMP traffic from one PC in the protected LAN to the Internet. Here it is one set of rules iptables -A FORWARD -p ICMP -s 192.168.1.37 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A FORWARD -p ICMP -d 192.168.1.37 -m state --state ESTABLISHED -j ACCEPT I've been experiencing the problem that with this set of rules, suddenly, the PC in the LAN cannot "ping" any hosts in the Internet. To solve the problem I delete all my user's chains and flush them, and I worked again. I already asked if there is a buffer or counter that gets filled, and someone told me to watch the number of connections being tracked. I did that and it seems that the number of connections being tracked is very low (about 160). Since the problem was a "mistery", I changed the rules to this: iptables -A FORWARD -p ICMP -s 192.168.1.37 -j ACCEPT iptables -A FORWARD -p ICMP -d 192.168.1.37 -j ACCEPT These are the same rules, except that don't track the state of the connections... Could someone tell me what is the risk asociated to NOT to track the connections? One more question... Is it true that when you specify the ICMP protocol, iptables only applies the rule to the type 0? thanks in advance Luis Fernando Barrera luba@assist.com.gt From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joel Newkirk Subject: Re: ICMP question Date: Thu, 14 Nov 2002 20:59:43 -0500 Sender: netfilter-admin@lists.netfilter.org Message-ID: <200211142059.43778.netfilter@newkirk.us> References: Reply-To: netfilter@newkirk.us Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Errors-To: netfilter-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Content-Type: text/plain; charset="us-ascii" To: Luis Fernando Barrera , netfilter@lists.netfilter.org On Thursday 14 November 2002 01:28 pm, Luis Fernando Barrera wrote: > iptables -A FORWARD -p ICMP -s 192.168.1.37 -m state --state > NEW,ESTABLISHED -j ACCEPT > iptables -A FORWARD -p ICMP -d 192.168.1.37 -m state --state ESTABLISHE= D -j > ACCEPT > > I've been experiencing the problem that with this set of rules, suddenl= y, > the PC in the LAN cannot "ping" any hosts in the Internet. To solve the > problem > iptables -A FORWARD -p ICMP -s 192.168.1.37 -j ACCEPT > iptables -A FORWARD -p ICMP -d 192.168.1.37 -j ACCEPT > > These are the same rules, except that don't track the state of the > connections... > > Could someone tell me what is the risk asociated to NOT to track the > connections? For the first rule just use the second version (without state match), but= for=20 the second rule you want state as it will prevent any ICMP connections=20 originating anywhere else from being forwarded to that IP, assuming other= =20 rules and policy don't ACCEPT it. (and assuming you don't want that...) = The=20 new pair would then allow any ICMP through that came FROM 192.168.1.37, a= nd=20 prevent any ICMP from going TO 192.168.1.37 UNLESS it is part of an=20 established connection, IE a response to a ping that was ACCEPTed by the=20 first rule. Using the state matches can help you tighten things up considerably, and = also=20 considerably reduce the number of rules you need to explicitly define. Y= ou=20 can allow a local machine out only to port 80 and 53, nothing back to it = at=20 all, then accept ESTABLISHED/RELATED both ways and everything will work,=20 because the responses back to the local machine, and even ICMP messages=20 related to the connection, are matched based on state. > One more question... Is it true that when you specify the ICMP protocol= , > iptables only > applies the rule to the type 0? Nope, unless it's a bug in a version other than 1.2.5, I just tested. (P= ing=20 my ISP's DNS, nothing, added ICMP rule with no type specified, 18.2ms) > thanks in advance > > Luis Fernando Barrera > luba@assist.com.gt j From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Darrell F. Dieringer" Subject: RE: ICMP question Date: Thu, 14 Nov 2002 15:47:18 -0600 Sender: netfilter-admin@lists.netfilter.org Message-ID: References: Reply-To: Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Errors-To: netfilter-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Content-Type: text/plain; charset="us-ascii" To: netfilter@lists.netfilter.org Anyone please feel free to correct me if I'm wrong, but I think your original rules would work fine if your "ESTABLISHED" rule was changed to "ESTABLISHED,RELATED". Perhaps the "NEW,ESTABLISHED" rule should also say "NEW,ESTABLISHED,RELATED" as well. If your internal machine issues an "echo request", the "echo reply" will be a "RELATED" packet. (I'd use icmp type numbers, but I don't know them off the top of my head.) Darrell Dieringer - Madison, WI > -----Original Message----- > From: netfilter-admin@lists.netfilter.org > [mailto:netfilter-admin@lists.netfilter.org]On Behalf Of > Luis Fernando > Barrera > Sent: Thursday, November 14, 2002 12:28 PM > To: netfilter@lists.netfilter.org > Subject: ICMP question > > > Hi all, > > I have a RedHat 7.3 box which I use as a dual homed firewall. > > One of the rules is that I allow all the ICMP traffic from one > PC in the protected LAN to the Internet. > > Here it is one set of rules > > iptables -A FORWARD -p ICMP -s 192.168.1.37 -m state --state > NEW,ESTABLISHED -j ACCEPT > iptables -A FORWARD -p ICMP -d 192.168.1.37 -m state > --state ESTABLISHED -j > ACCEPT > > I've been experiencing the problem that with this set of > rules, suddenly, > the PC in the LAN cannot "ping" any hosts in the Internet. > To solve the > problem > I delete all my user's chains and flush them, and I worked again. > I already asked if there is a buffer or counter that gets > filled, and > someone > told me to watch the number of connections being tracked. I > did that and it > seems > that the number of connections being tracked is very low > (about 160). > > Since the problem was a "mistery", I changed the rules to this: > > iptables -A FORWARD -p ICMP -s 192.168.1.37 -j ACCEPT > iptables -A FORWARD -p ICMP -d 192.168.1.37 -j ACCEPT > > These are the same rules, except that don't track the state of the > connections... > > Could someone tell me what is the risk asociated to NOT to track the > connections? > > One more question... Is it true that when you specify the > ICMP protocol, > iptables only > applies the rule to the type 0? > > thanks in advance > > Luis Fernando Barrera > luba@assist.com.gt > > > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Drage Subject: Re: ICMP question Date: Sun, 24 Nov 2002 16:34:38 +0000 Sender: netfilter-admin@lists.netfilter.org Message-ID: <20021124163438.A14289@funkyjesus.org> References: Reply-To: Netfilter Mailing List Mime-Version: 1.0 Return-path: Content-Disposition: inline In-Reply-To: ; from homes@darrelldieringer.com on Thu, Nov 14, 2002 at 03:47:18PM -0600 Errors-To: netfilter-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: netfilter@lists.netfilter.org On Thu, Nov 14, 2002 at 03:47:18PM -0600, Darrell F. Dieringer wrote: > > Anyone please feel free to correct me if I'm wrong, but I think your > original rules would work fine if your "ESTABLISHED" rule was changed > to "ESTABLISHED,RELATED". Perhaps the "NEW,ESTABLISHED" rule should > also say "NEW,ESTABLISHED,RELATED" as well. > > If your internal machine issues an "echo request", the "echo reply" > will be a "RELATED" packet. (I'd use icmp type numbers, but I don't > know them off the top of my head.) /usr/include/netinet/ip_icmp.h Is always handy for this kind of thing ( 8 and 0 respectively ). -- FunkyJesus System Administration Team