* Re: tuning iptables
@ 2002-12-08 12:55 Haines Brown
2002-12-08 18:12 ` Ray Olszewski
0 siblings, 1 reply; 5+ messages in thread
From: Haines Brown @ 2002-12-08 12:55 UTC (permalink / raw)
To: linux-newbie
The continuing saga of trying to get incoming accesss through my
iptables.
Before doing a flush of all INPUT rules, I ran #iptables -nvL and
ascertained that Lokkit had reinserted itself. I then did the flush to
remove any possbble iptables block for incoming:
# iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 150 packets, 10348 bytes)
pkts bytes target prot opt in out source destination
Chain RH-Lokkit-0-50-INPUT (0 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp -- * * 206.141.193.55 0.0.0.0/0
udp spt:53 dpts:1025:65535
0 0 ACCEPT udp -- * * 206.73.20.40 0.0.0.0/0
udp spt:53 dpts:1025:65535
0 0 ACCEPT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0
udp spts:67:68 dpts:67:68
0 0 ACCEPT udp -- eth1 * 0.0.0.0/0 0.0.0.0/0
udp spts:67:68 dpts:67:68
150 10348 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp flags:0x16/0x02 reject-with icmp-port-unreachable
0 0 REJECT udp -- * * 0.0.0.0/0 0.0.0.0/0
udp reject-with icmp-port-unreachable
Still have the odd eth1 (I'm only using the NIC chip on the
motherboard, and no NIC card). But otherwise I assume this is wide
open.
I then brought up ppp0 (ran adsl-start) and got a connection. I
rechecked iptables -nvL, and there was no change whatsoever. So I took
at look at what was logged when I made the connection and terminated it.
/var/log/messages:
Dec 7 17:12:54 hartford-hwp kernel: CSLIP: code copyright 1989
Regents of the University of California
Dec 7 17:12:54 hartford-hwp kernel: PPP generic driver version
2.4.2
Dec 7 17:12:55 hartford-hwp pppd[2097]: pppd 2.4.1 started by
root, uid 0
Dec 7 17:12:55 hartford-hwp pppd[2097]: Using interface ppp0
Dec 7 17:12:55 hartford-hwp pppd[2097]: Connect: ppp0 <-->
/dev/pts/1
Dec 7 17:12:55 hartford-hwp /etc/hotplug/net.agent: assuming ppp0
is already up
Dec 7 17:12:55 hartford-hwp pppoe[2098]: PPP session is 2237
Dec 7 17:12:56 hartford-hwp pppd[2097]: local IP address
64.252.170.51
Dec 7 17:12:56 hartford-hwp pppd[2097]: remote IP address
64.252.160.1
Dec 7 17:13:22 hartford-hwp adsl-stop: Killing pppd
Dec 7 17:13:22 hartford-hwp pppd[2097]: Terminating on signal 15.
Dec 7 17:13:22 hartford-hwp adsl-stop: Killing adsl-connect
Dec 7 17:13:22 hartford-hwp pppd[2097]: Connection terminated.
Dec 7 17:13:22 hartford-hwp pppd[2097]: Connect time 0.5 minutes.
Dec 7 17:13:22 hartford-hwp pppd[2097]: Sent 30 bytes, received
58 bytes.
Dec 7 17:13:22 hartford-hwp pppoe[2098]: read (asyncReadFromPPP):
Session 2237: Input/output error
Dec 7 17:13:22 hartford-hwp pppoe[2098]: Sent PADT
Dec 7 17:13:22 hartford-hwp pppd[2097]: Exit.
Dec 7 17:13:22 hartford-hwp /etc/hotplug/net.agent: NET unregister
event not supported
Am I correct to infer all this is normal?
My test of incoming access is a fetchmail mail retrieveal, so now I
focus on that.
First, fetchmail is able to get non-tcpip information from the mail
server:
# adsl-start
. Connected!
# fetchmail --check
21 messages for brownh@hartford-hwp.com at pop.registeredsite.com
(115279 octets).
Next, I wanted to log the fetchmail session. However, my attempt to
generate a log did not work for some reason I lacked time to figure
out ("tmp" directory is accessible).
$ adsl-start
. Connected!
$ fetchmail -v -v > /opt/tmp/-fetchmail.log.1
bash: /opt/tmp/-fetchmail.log.1: Permission denied
So instead I just logged the xterm:
$ fetchmail -v -v
fetchmail: 5.9.0 querying pop.registeredsite.com (protocol POP3) at
Sat 07 Dec 2002 05:41:57 PM EST
fetchmail: POP3< +OK InterMail POP3 proxy server ready.
fetchmail: POP3> USER brownh@hartford-hwp.com
fetchmail: POP3< +OK please send PASS command
fetchmail: POP3> PASS *
fetchmail: POP3< +OK brownh@hartford-hwp.com is welcome here
fetchmail: selecting or re-polling default folder
fetchmail: POP3> STAT
fetchmail: POP3< +OK 24 136888
fetchmail: POP3> LAST
fetchmail: POP3< +OK 0
24 messages for brownh@hartford-hwp.com at pop.registeredsite.com
(136888 octets).
fetchmail: POP3> LIST
fetchmail: POP3< +OK 24 messages
fetchmail: POP3< 1 3778
fetchmail: POP3< 2 3004
fetchmail: POP3< 3 1988
fetchmail: POP3< 4 3586
fetchmail: POP3< 5 3349
fetchmail: POP3< 6 3622
fetchmail: POP3< 7 23672
fetchmail: POP3< 8 3640
fetchmail: POP3< 9 3867
fetchmail: POP3< 10 3148
fetchmail: POP3< 11 3679
fetchmail: POP3< 12 3670
fetchmail: POP3< 13 2817
fetchmail: POP3< 14 3132
fetchmail: POP3< 15 2539
fetchmail: POP3< 16 2382
fetchmail: POP3< 17 2660
fetchmail: POP3< 18 31868
fetchmail: POP3< 19 2711
fetchmail: POP3< 20 3301
fetchmail: POP3< 21 2866
fetchmail: POP3< 22 5763
fetchmail: POP3< 23 3841
fetchmail: POP3< 24 12005
fetchmail: POP3< .
fetchmail: POP3> TOP 1 99999999
fetchmail: POP3< +OK 3778 octets
reading message 1 of 24 (3778 octets)
About to rewrite Return-Path:
<linux-usb-users-admin@lists.sourceforge.net>
Rewritten version is Return-Path:
<linux-usb-users-admin@lists.sourceforge.net>
About to rewrite From: Dan Hensley <dan.hensley@attbi.com>
Rewritten version is From: Dan Hensley <dan.hensley@attbi.com>
About to rewrite To: Brent R Brian <brent@bmgen.com>
Rewritten version is To: Brent R Brian <brent@bmgen.com>
About to rewrite Cc: USB Linux <linux-usb-users@lists.sourceforge.net>
Rewritten version is Cc: USB Linux
<linux-usb-users@lists.sourceforge.net>
About to rewrite Sender: linux-usb-users-admin@lists.sourceforge.net
Rewritten version is Sender:
linux-usb-users-admin@lists.sourceforge.net
Now, at this point, the process stopped dead. After that last
statement, just nothing until eventually I killed the process. Based
on comparison with my presently working system, this report so far
appears to be OK. What should come up next would be such lines as:
fetchmail: SMTP< 220 hartford-hwp.com ESMTP Sendmail 8.11.6/8.11.6;
Sun, 8 Dec 2002 07:40:26 -0500
fetchmail: SMTP> EHLO localhost
fetchmail: SMTP< 250-hartford-hwp.com Hello hartford-hwp.com
[127.0.0.1], pleased to meet you
fetchmail: SMTP< 250-ENHANCEDSTATUSCODES
...
Does this mean that SMTP is unable to set up its protocol for
tranferring tcp packegs back to my mahcine?
The messages log simply reports that the ppp0 interface has been
brought up successfully.
Now I go back to iptables -nvL to see what effect running fetchmail
has had on it:
========
# iptables -nvL
Chain INPUT (policy ACCEPT 271 packets, 143K bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 554 packets, 40441 bytes)
pkts bytes target prot opt in out source destination
Chain RH-Lokkit-0-50-INPUT (0 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp -- * * 206.141.193.55 0.0.0.0/0
udp spt:53 dpts:1025:65535
0 0 ACCEPT udp -- * * 206.73.20.40 0.0.0.0/0
udp spt:53 dpts:1025:65535
0 0 ACCEPT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0
udp spts:67:68 dpts:67:68
0 0 ACCEPT udp -- eth1 * 0.0.0.0/0 0.0.0.0/0
udp spts:67:68 dpts:67:68
150 10348 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp flags:0x16/0x02 reject-with icmp-port-unreachable
0 0 REJECT udp -- * * 0.0.0.0/0 0.0.0.0/0
udp reject-with icmp-port-unreachable
===========
I see that INPUT has accepted some packets, but don't know what to
make of this.
A ran /usr/sbin/lokkit and set for no firewall. Then run iptables -nvL
again and compare with previous. But that produced no change, nor did
runing fetchmail after setting Lokkit for no firewall.
Haines Brown
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: tuning iptables
2002-12-08 12:55 tuning iptables Haines Brown
@ 2002-12-08 18:12 ` Ray Olszewski
2002-12-08 21:31 ` Chuck Gelm
0 siblings, 1 reply; 5+ messages in thread
From: Ray Olszewski @ 2002-12-08 18:12 UTC (permalink / raw)
To: linux-newbie
Preliminary comment: whatever your problem is, it has nothing to do with
your firewall (at least with the modified, open version you are now testing
with). So I'm deleting that part of your message and focusing on the
fetchmail part.
At 07:55 AM 12/8/02 -0500, Haines Brown wrote:
[...]
>First, fetchmail is able to get non-tcpip information from the mail
>server:
>
> # adsl-start
> . Connected!
>
> # fetchmail --check
> 21 messages for brownh@hartford-hwp.com at pop.registeredsite.com
> (115279 octets).
Calling this stuff "non-tcpip" indicates some confusion. I'm not sure
myself whether fetchmail is using tcp ot udp to get this information, but
it is using one of them, probably tcp (and it is certainly using ip).
>Next, I wanted to log the fetchmail session. However, my attempt to
>generate a log did not work for some reason I lacked time to figure
>out ("tmp" directory is accessible).
> $ adsl-start
> . Connected!
> $ fetchmail -v -v > /opt/tmp/-fetchmail.log.1
> bash: /opt/tmp/-fetchmail.log.1: Permission denied
What userid are you? What is the output of
ls -l / | grep opt
ls -l /opt | grep tmp
ls -l /opt/tmp/-fetchmail.log.1
Without that info, no one can figure out the problem, no matter how much
time he or she has. "accessible" is not a well-defined term.
>So instead I just logged the xterm:
[...]
> About to rewrite Sender: linux-usb-users-admin@lists.sourceforge.net
> Rewritten version is Sender:
> linux-usb-users-admin@lists.sourceforge.net
>
>Now, at this point, the process stopped dead. After that last
>statement, just nothing until eventually I killed the process. Based
>on comparison with my presently working system, this report so far
>appears to be OK. What should come up next would be such lines as:
>
> fetchmail: SMTP< 220 hartford-hwp.com ESMTP Sendmail 8.11.6/8.11.6;
> Sun, 8 Dec 2002 07:40:26 -0500
> fetchmail: SMTP> EHLO localhost
> fetchmail: SMTP< 250-hartford-hwp.com Hello hartford-hwp.com
> [127.0.0.1], pleased to meet you
> fetchmail: SMTP< 250-ENHANCEDSTATUSCODES
> ...
>
>Does this mean that SMTP is unable to set up its protocol for
>tranferring tcp packegs back to my mahcine?
No. It means that fetchmail cannot open a connection to the smtp server on
your machine.
At this point, since the problem is with fetchmail and your smtp server,
not with your firewall, someone who uses fetchmail regularly should step in
here to give you focused advice.
My general advice is to stop looking at ipchains and focus on the local
configuration of fetchmail and whatever smtp server you have (sendmail,
exim, postfix, or something else ... evidently your old, working system
uses sendmail). The practical approach I'd advise is checking how your
working system runs sendmail ... first verify that something is listening
on port 25 (with "netstat -l"), then track down what that something is
(either sendmail itself or inetd on its behalf). Then set up your new
system so it works the same way as the old one did.
Just to be clear -- this problem has NOTHING WHATSOEVER to do with
ipchains, at least not when the INPUT chain has only an ACCEPT policy
running. The only way ipchains *could* affect this is if you had rules that
interfered with traffic on the "lo" interface.
[...]
--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski -- Han Solo
Palo Alto, California, USA ray@comarre.com
-------------------------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: tuning iptables
@ 2002-12-06 21:48 Haines Brown
2002-12-06 23:33 ` Ray Olszewski
0 siblings, 1 reply; 5+ messages in thread
From: Haines Brown @ 2002-12-06 21:48 UTC (permalink / raw)
To: linux-newbie; +Cc: ray
Well, I'm afraid I didn't get very far in straightening out my
iptables so that I could move tcpip packets.
I should mention that I'm running RedHat 8.0. I use pop3 to get email
and sendmail to send mail. I don't care to be pinged, and I'll do
without telnet. No one needs to access my standalone machine for FTP
etc.
1. First, I verify that INPUT chain's policy is set to ACCEPT:
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
150 10348 RH-Lokkit-0-50-INPUT all -- * * 0.0.0.0/0 0.0.0.0/0
This lokkit is a Firewall Configuration utility. It starts by saying
that "high security blocks all incoming accesses." Is that my
problem?
2. I flushed all rules for the INPUT chain:
# iptables -F INPUT
3. This had no feedback, and so I looked at my iptables:
# iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 150 packets, 10348 bytes)
pkts bytes target prot opt in out source destination
Chain RH-Lokkit-0-50-INPUT (0 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp -- * * 206.141.193.55 0.0.0.0/0
udp spt:53 dpts:1025:65535
0 0 ACCEPT udp -- * * 206.73.20.40 0.0.0.0/0
udp spt:53 dpts:1025:65535
0 0 ACCEPT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0
udp spts:67:68 dpts:67:68
0 0 ACCEPT udp -- eth1 * 0.0.0.0/0 0.0.0.0/0
udp spts:67:68 dpts:67:68
150 10348 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp flags:0x16/0x02 reject-with icmp-port-unreachable
0 0 REJECT udp -- * * 0.0.0.0/0 0.0.0.0/0
udp reject-with icmp-port-unreachable
Am I right to infer that since under the INPUT CHAIN, nothing is
listed, that the flush succeeded? I guess so, for Lokkit is gone.
4. Next, I connected with my DSL provider using rp-pppoe:
# adsl-start
. . . .Connect
5. To check the result, I ran ifconfig -a, and I see that eth0, lo, and
ppp0 are all up, and ppp0 has been assigned an address.
# ifconfig -a
ppp0 Link encap:Point-to-Point Protocol
inet addr:64.252.164.246 P-t-P:64.252.160.1 Mask:255.255.255.255
6. I try # fetchmail. No go. Same behavior as before. Fetchmail
accesses the mail server, reports the number of messages waiting,
but hangs when it comes to downloading the first.
7. I tried some pings. Same as before:
a. I ping my ppp0 address (64.252.164.246). Works fine.
b. Then my DNS: # ping 206.73.20.40. While no returns, the server
might block pings.
c. I ping hardware.redhat.com. Nothing comes back back.
d. I ping aol.com. Every five seconds a return. About 30 ms round
trip, which I guess is normal.
In sum, unless I somehow failed to flush rules for the INPUT chain,
while my iptables were messed up, that is not the basic problem.
I'm using the same box, and simply swapping hard disks, and so the
only hardware that changes is the hard disk. I have a high software
firewall, and have run Bastille so set up certain rules, but not
affecting iptables.
I also recall that my initial installation of RH8.0 resulted in a
broken rp-pppoe, which I replaced/upgraded with happier results. So I
wonder if something else might be broken. I'll try running
/usr/sbin/lokkit with either No Firewall or Medium security to see if
that helps. Medium security is what I have on my present machine, that
can receive tcp mail packets.
Haines Brown
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: tuning iptables
2002-12-06 21:48 Haines Brown
@ 2002-12-06 23:33 ` Ray Olszewski
0 siblings, 0 replies; 5+ messages in thread
From: Ray Olszewski @ 2002-12-06 23:33 UTC (permalink / raw)
To: linux-newbie
OK. Several things to consider here. Comments follow each of your steps below.
At 04:48 PM 12/6/02 -0500, Haines Brown wrote:
>Well, I'm afraid I didn't get very far in straightening out my
>iptables so that I could move tcpip packets.
>
>I should mention that I'm running RedHat 8.0. I use pop3 to get email
>and sendmail to send mail. I don't care to be pinged, and I'll do
>without telnet. No one needs to access my standalone machine for FTP
>etc.
>
>1. First, I verify that INPUT chain's policy is set to ACCEPT:
>
> Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
> pkts bytes target prot opt
> in out source destination
> 150 10348 RH-Lokkit-0-50-INPUT all -- * * 0.0.0.0/0 0.0.0.0/0
>
> This lokkit is a Firewall Configuration utility. It starts by saying
> that "high security blocks all incoming accesses." Is that my
> problem?
Maybe. That's what we're trying to test out. But the fetchmail tests are
not "incomming accesses"; they involve replies to outgoing connections.
Same for the ping tests.
>2. I flushed all rules for the INPUT chain:
>
> # iptables -F INPUT
Right.
>3. This had no feedback, and so I looked at my iptables:
>
> # iptables -nvL
> Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
> pkts bytes target prot opt in out source destination
>
> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
> pkts bytes target prot opt in out source destination
>
> Chain OUTPUT (policy ACCEPT 150 packets, 10348 bytes)
> pkts bytes target prot opt in out source destination
>
> Chain RH-Lokkit-0-50-INPUT (0 references)
> pkts bytes target prot opt in out source destination
> 0 0 ACCEPT udp -- * * 206.141.193.55 0.0.0.0/0
> udp spt:53 dpts:1025:65535
> 0 0 ACCEPT udp -- * * 206.73.20.40 0.0.0.0/0
> udp spt:53 dpts:1025:65535
> 0 0 ACCEPT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0
> udp spts:67:68 dpts:67:68
> 0 0 ACCEPT udp -- eth1 * 0.0.0.0/0 0.0.0.0/0
> udp spts:67:68 dpts:67:68
> 150 10348 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
> 0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0
> tcp flags:0x16/0x02 reject-with icmp-port-unreachable
> 0 0 REJECT udp -- * * 0.0.0.0/0 0.0.0.0/0
> udp reject-with icmp-port-unreachable
>
> Am I right to infer that since under the INPUT CHAIN, nothing is
> listed, that the flush succeeded? I guess so, for Lokkit is gone.
Yes.
>4. Next, I connected with my DSL provider using rp-pppoe:
>
> # adsl-start
> . . . .Connect
>
>5. To check the result, I ran ifconfig -a, and I see that eth0, lo, and
> ppp0 are all up, and ppp0 has been assigned an address.
>
> # ifconfig -a
> ppp0 Link encap:Point-to-Point Protocol
> inet addr:64.252.164.246 P-t-P:64.252.160.1 Mask:255.255.255.255
At this point, it would be wise to check "iptables -nvL" again. Just to see
if bringing ppp0 up caused execution of a script that changed your firewall
settings.
>6. I try # fetchmail. No go. Same behavior as before. Fetchmail
> accesses the mail server, reports the number of messages waiting,
> but hangs when it comes to downloading the first.
OK. This *may* still be a firewall problem (see item #5). But if it is not,
it may also be a fetchmail problem. Check your logs for any messages from
fetchmail. And describe "hangs" in more detail.
>7. I tried some pings. Same as before:
> a. I ping my ppp0 address (64.252.164.246). Works fine.
> b. Then my DNS: # ping 206.73.20.40. While no returns, the server
> might block pings.
> c. I ping hardware.redhat.com. Nothing comes back back.
> d. I ping aol.com. Every five seconds a return. About 30 ms round
> trip, which I guess is normal.
The problem with ping tests is that many servers are set not to respond to
pings. I get the same result from hardware.redhat.com that you do. (This is
why I always suggest you ping a known-good address, and I often even
suggest using mine, since I know it is set to answer pings.) But since the
other three work, I'd say you are OK with respect to ping.
>In sum, unless I somehow failed to flush rules for the INPUT chain,
>while my iptables were messed up, that is not the basic problem.
Agreed, subject to your doing the check of item #5. In fact, do this
*after* you have a fetchmail failure, since the report includes a listing
of how many packets each rule or policy processed.
>I'm using the same box, and simply swapping hard disks, and so the
>only hardware that changes is the hard disk. I have a high software
>firewall, and have run Bastille so set up certain rules, but not
>affecting iptables.
I don't know what this ("certain rules") means.
>I also recall that my initial installation of RH8.0 resulted in a
>broken rp-pppoe, which I replaced/upgraded with happier results. So I
>wonder if something else might be broken. I'll try running
>/usr/sbin/lokkit with either No Firewall or Medium security to see if
>that helps. Medium security is what I have on my present machine, that
>can receive tcp mail packets.
By all means try. But you can't set a firewall lower than "ACCEPT
everything", so (in a one-host setting, where NAT is not an issue) changing
the lokkit settings is unlikely to help (always assuming the test in #5
doesn't turn up something). I'd check to see how the two fetchmail setups
differ.
--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski -- Han Solo
Palo Alto, California, USA ray@comarre.com
-------------------------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2002-12-08 21:31 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-12-08 12:55 tuning iptables Haines Brown
2002-12-08 18:12 ` Ray Olszewski
2002-12-08 21:31 ` Chuck Gelm
-- strict thread matches above, loose matches on Subject: below --
2002-12-06 21:48 Haines Brown
2002-12-06 23:33 ` Ray Olszewski
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox