* problem reach the internal.
@ 2002-11-29 19:32 james.Q.L
2002-11-30 1:03 ` james.Q.L
0 siblings, 1 reply; 8+ messages in thread
From: james.Q.L @ 2002-11-29 19:32 UTC (permalink / raw)
To: netfilter
hi,
i have access to my firewall ip at port 8888 forward to port 80 at internal machine 192.168.0.3 .
but the connection always fail. can someone help me debug ? thanks.
[root@cozy166 public]#iptables -L --line-number -n
Chain INPUT (policy ACCEPT)
num target prot opt source destination
1 REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:6000 reject-with
tcp-reset
Chain FORWARD (policy DROP)
num target prot opt source destination
1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
2 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
3 ACCEPT tcp -- 0.0.0.0/0 192.168.0.3 tcp dpt:80
4 LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4
Chain OUTPUT (policy ACCEPT)
num target prot opt source destination
Chain drop-and-log-it (0 references)
num target prot opt source destination
1 DROP all -- 0.0.0.0/0 0.0.0.0/0
[root@cozy166 public]#iptables -L --line-number -n -t nat
Chain PREROUTING (policy ACCEPT)
num target prot opt source destination
1 DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8888 to:192.168.0.3:80
Chain POSTROUTING (policy ACCEPT)
num target prot opt source destination
1 SNAT tcp -- 192.168.0.0/24 192.168.0.3 tcp dpt:80 to:192.168.0.1
2 MASQUERADE all -- 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT)
num target prot opt source destination
the rules i added to try to make it work are :
iptables -t nat -A PREROUTING -p tcp -i eth1 --dport 8888 \
-j DNAT --to-destination 192.168.0.3:80
iptables -A FORWARD -p tcp --dport 80 -d 192.168.0.3 -j ACCEPT
iptables -t nat -A POSTROUTING -p tcp -s 192.168.0.0/24 -d 192.168.0.3 --dport 80 -j SNAT \
--to-source 192.168.0.1
=====
/James.Q.L
______________________________________________________________________
Post your free ad now! http://personals.yahoo.ca
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: problem reach the internal.
2002-11-29 19:32 problem reach the internal james.Q.L
@ 2002-11-30 1:03 ` james.Q.L
2002-11-30 1:35 ` Anders Fugmann
0 siblings, 1 reply; 8+ messages in thread
From: james.Q.L @ 2002-11-30 1:03 UTC (permalink / raw)
To: netfilter
sorry, i forgot mention that the request from outside my local network to the INET_IP:8888 is
fine. only the internal request to it fails.
i do not see what is wrong in the rules, anyone ?
--- "james.Q.L" <shijialeeee@yahoo.ca> wrote: > hi,
>
> i have access to my firewall ip at port 8888 forward to port 80 at internal machine 192.168.0.3
> .
> but the connection always fail. can someone help me debug ? thanks.
>
>
> [root@cozy166 public]#iptables -L --line-number -n
> Chain INPUT (policy ACCEPT)
> num target prot opt source destination
> 1 REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:6000 reject-with
> tcp-reset
>
> Chain FORWARD (policy DROP)
> num target prot opt source destination
> 1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
> 2 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
> 3 ACCEPT tcp -- 0.0.0.0/0 192.168.0.3 tcp dpt:80
> 4 LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4
>
> Chain OUTPUT (policy ACCEPT)
> num target prot opt source destination
>
> Chain drop-and-log-it (0 references)
> num target prot opt source destination
> 1 DROP all -- 0.0.0.0/0 0.0.0.0/0
>
> [root@cozy166 public]#iptables -L --line-number -n -t nat
> Chain PREROUTING (policy ACCEPT)
> num target prot opt source destination
> 1 DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8888 to:192.168.0.3:80
>
> Chain POSTROUTING (policy ACCEPT)
> num target prot opt source destination
> 1 SNAT tcp -- 192.168.0.0/24 192.168.0.3 tcp dpt:80 to:192.168.0.1
> 2 MASQUERADE all -- 0.0.0.0/0 0.0.0.0/0
>
> Chain OUTPUT (policy ACCEPT)
> num target prot opt source destination
>
> the rules i added to try to make it work are :
>
> iptables -t nat -A PREROUTING -p tcp -i eth1 --dport 8888 \
> -j DNAT --to-destination 192.168.0.3:80
> iptables -A FORWARD -p tcp --dport 80 -d 192.168.0.3 -j ACCEPT
> iptables -t nat -A POSTROUTING -p tcp -s 192.168.0.0/24 -d 192.168.0.3 --dport 80 -j SNAT \
> --to-source 192.168.0.1
=====
/James.Q.L
______________________________________________________________________
Post your free ad now! http://personals.yahoo.ca
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: problem reach the internal.
2002-11-30 1:03 ` james.Q.L
@ 2002-11-30 1:35 ` Anders Fugmann
2002-11-30 2:20 ` Joel Newkirk
0 siblings, 1 reply; 8+ messages in thread
From: Anders Fugmann @ 2002-11-30 1:35 UTC (permalink / raw)
To: james.Q.L; +Cc: netfilter
james.Q.L wrote:
> sorry, i forgot mention that the request from outside my local network to the INET_IP:8888 is
> fine. only the internal request to it fails.
>
> i do not see what is wrong in the rules, anyone ?
It cannot be done, as the webserver will try to give an answer to the
query directly, and not back through your router, and thus the client
will not accept the reply.
For a more complete explanation, search the email archives. This
question has been asked and answered numerous times.
Regards
Anders Fugmann
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: problem reach the internal.
2002-11-30 1:35 ` Anders Fugmann
@ 2002-11-30 2:20 ` Joel Newkirk
2002-11-30 8:34 ` james.Q.L
2002-11-30 11:44 ` Anders Fugmann
0 siblings, 2 replies; 8+ messages in thread
From: Joel Newkirk @ 2002-11-30 2:20 UTC (permalink / raw)
To: Anders Fugmann, james.Q.L; +Cc: netfilter
On Friday 29 November 2002 08:35 pm, Anders Fugmann wrote:
> james.Q.L wrote:
> > sorry, i forgot mention that the request from outside my local network to
> > the INET_IP:8888 is fine. only the internal request to it fails.
> >
> > i do not see what is wrong in the rules, anyone ?
>
> It cannot be done, as the webserver will try to give an answer to the
> query directly, and not back through your router, and thus the client
> will not accept the reply.
>
> For a more complete explanation, search the email archives. This
> question has been asked and answered numerous times.
That's what his SNAT rule should handle: (snippet from original message)
> the rules i added to try to make it work are :
>
> iptables -t nat -A PREROUTING -p tcp -i eth1 --dport 8888 \
> -j DNAT --to-destination 192.168.0.3:80
> iptables -A FORWARD -p tcp --dport 80 -d 192.168.0.3 -j ACCEPT
> iptables -t nat -A POSTROUTING -p tcp -s 192.168.0.0/24 -d 192.168.0.3 \
> --dport 80 -j SNAT --to-source 192.168.0.1
port 80 requests heading out to the server (192.168.0.3) from anywhere on the
lan (already DNATted in prerouting) are SNATted to appear to come from the
firewall/router (192.168.0.1) so that they return through it properly. Yes,
this has been answered before, and is covered in the DNAT section of Oscar's
tutorial, but the rules he has here appear to be correct. (well, along with
the FORWARD EST/REL rule I didn't include in this snippet)
James - I'd recommend that you try:
iptables -z
to clear counters, then try accessing the server from the LAN, then
iptables -L -v -n
to list your ruleset along with the packet/byte counts which matched. This
will often show where unexpected things are happening. IE, if the counts in
the FORWARD rules accepting ESTABLISHED/RELATED and packets destined for the
server are both zero, then the problem is at PREROUTING. If the FORWARD
count for server-bound shows your request, but your POSTROUTING SNAT is zero,
or if those both show counts but nothing coming back from the server
(EST/REL) those can narrow things down. (of course if the DNAT rule in
PREROUTING counts 0 that pretty much nails the problem down... :^) Extreme
Logging can help as well, where you insert a LOG rule as the first rule in
each chain, try to connect, then check the logs. This can generate a LOT of
logging if there is other activity through the firewall, though. If you do
this, you should log nat PRE and POST, FORWARD, and INPUT. The first three
are where it should be, the fourth is where it shouldn't but might, if the
DNAT isn't matching.
I'd also suggest you reconsider FORWARD rule #2, which accepts EVERYTHING, and
limit your MASQUERADE to traffic outbound to the internet, simply with
-o $eth0 or whatever interface connects to the world.
j
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: problem reach the internal.
2002-11-30 2:20 ` Joel Newkirk
@ 2002-11-30 8:34 ` james.Q.L
2002-11-30 15:27 ` Joel Newkirk
2002-11-30 11:44 ` Anders Fugmann
1 sibling, 1 reply; 8+ messages in thread
From: james.Q.L @ 2002-11-30 8:34 UTC (permalink / raw)
To: netfilter, Anders Fugmann; +Cc: netfilter
the iptables counter is very neat to debug problem. i never thought of that.
found a problem that in the following ruleset i shouldn't have '-i eth1'. it blocks the internal
DNAT.
> > iptables -t nat -A PREROUTING -p tcp -i eth1 --dport 8888 \
> > -j DNAT --to-destination 192.168.0.3:80
i also change the order of the rule in FORWARD chain in Filter table.
the rule for filter table is:
[root@cozy166 Qiang]#iptables -L -n --line-numbers
Chain FORWARD (policy DROP)
num target prot opt source destination
1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
2 ACCEPT tcp -- 0.0.0.0/0 192.168.0.3 tcp dpt:80
3 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
4 LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4
the line num 3 and num 2 are swapped.
i tried reset the counter of ruleset and make connection test to it. i found something that i
don't understand. when i am testing from an internal machine to INET_IP:8888 the ruleset for
filter table is (counter has reset to zero)
[root@cozy166 Qiang]#iptables -L -v -n --line-numbers
Chain FORWARD (policy DROP 5 packets, 224 bytes)
num pkts bytes target prot opt in out source destination
1 11806 15M ACCEPT all -- eth1 eth0 0.0.0.0/0 0.0.0.0/0 state
RELATED,ESTABLISHED
2 3 144 ACCEPT tcp -- * * 0.0.0.0/0 192.168.0.3 tcp
dpt:80
3 8000 341K ACCEPT all -- eth0 eth1 0.0.0.0/0 0.0.0.0/0
4 5 224 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG
flags 0 level 4
Chain OUTPUT (policy ACCEPT 13143 packets, 996K bytes)
num pkts bytes target prot opt in out source destination
Chain drop-and-log-it (0 references)
num pkts bytes target prot opt in out source destination
1 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
####
noticed that the Forward chain has (policy DROP 5 packets, 224 bytes) and the line num 2 has 3
counter and 144bytes hits. it's gotta be a problem here.
one thing i am unsure is if the counter and packet get hit means the packet get passed or
attempted to pass? taking a look at the line num 2 ruleset, it shouldn't block proper packet tho.
2 ACCEPT tcp -- 0.0.0.0/0 192.168.0.3 tcp dpt:80
another thing i'm unsure is the POSTROUTING and PREROUTING both have two hits and packet records.
so this seems to say the packet got back from the webserver. but if the FORWARD chain drops the
packet there, the POSTROUTING shouldn't have anything..
[root@cozy166 Qiang]#iptables -L -v -n -t nat --line-numbers
Chain PREROUTING (policy ACCEPT 146 packets, 10341 bytes)
num pkts bytes target prot opt in out source destination
1 4 192 DNAT tcp -- * * 0.0.0.0/0 65.48.28.33 tcp
dpt:8888 to:192.168.0.3:80
Chain POSTROUTING (policy ACCEPT 1 packets, 249 bytes)
num pkts bytes target prot opt in out source destination
1 4 192 SNAT tcp -- * * 192.168.0.0/24 192.168.0.3 tcp
dpt:80 to:192.168.0.1
2 51 2866 MASQUERADE all -- * eth1 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 79573 packets, 5705K bytes)
num pkts bytes target prot opt in out source destination
James.Q.L
=====
/James.Q.L
______________________________________________________________________
Post your free ad now! http://personals.yahoo.ca
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: problem reach the internal.
2002-11-30 2:20 ` Joel Newkirk
2002-11-30 8:34 ` james.Q.L
@ 2002-11-30 11:44 ` Anders Fugmann
1 sibling, 0 replies; 8+ messages in thread
From: Anders Fugmann @ 2002-11-30 11:44 UTC (permalink / raw)
To: netfilter; +Cc: james.Q.L, netfilter
Joel Newkirk wrote:
> On Friday 29 November 2002 08:35 pm, Anders Fugmann wrote:
>>It cannot be done, as the webserver will try to give an answer to the
>>query directly, and not back through your router, and thus the client
>>will not accept the reply.
>>
>>For a more complete explanation, search the email archives. This
>>question has been asked and answered numerous times.
>
>
> That's what his SNAT rule should handle: (snippet from original message)
Thanks for the correction. I see that it can be done, allthough I guess
that some serious network degradation will result, especially on a half
duplex network.
Regards
Anders Fugmann
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: problem reach the internal.
2002-11-30 8:34 ` james.Q.L
@ 2002-11-30 15:27 ` Joel Newkirk
2002-12-01 22:35 ` james.Q.L
0 siblings, 1 reply; 8+ messages in thread
From: Joel Newkirk @ 2002-11-30 15:27 UTC (permalink / raw)
To: james.Q.L; +Cc: netfilter
On Saturday 30 November 2002 03:34 am, james.Q.L wrote:
> the iptables counter is very neat to debug problem. i never thought of
> that.
>
> found a problem that in the following ruleset i shouldn't have '-i eth1'.
> it blocks the internal DNAT.
>
> > > iptables -t nat -A PREROUTING -p tcp -i eth1 --dport 8888 \
> > > -j DNAT --to-destination 192.168.0.3:80
>
> i also change the order of the rule in FORWARD chain in Filter table.
>
> the rule for filter table is:
> [root@cozy166 Qiang]#iptables -L -n --line-numbers
>
> Chain FORWARD (policy DROP)
> num target prot opt source destination
> 1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state
> RELATED,ESTABLISHED 2 ACCEPT tcp -- 0.0.0.0/0
> 192.168.0.3 tcp dpt:80 3 ACCEPT all -- 0.0.0.0/0
> 0.0.0.0/0
> 4 LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG flags
> 0 level 4
>
> the line num 3 and num 2 are swapped.
>
> i tried reset the counter of ruleset and make connection test to it. i
> found something that i don't understand. when i am testing from an internal
> machine to INET_IP:8888 the ruleset for filter table is (counter has reset
> to zero)
>
> [root@cozy166 Qiang]#iptables -L -v -n --line-numbers
>
> Chain FORWARD (policy DROP 5 packets, 224 bytes)
> num pkts bytes target prot opt in out source destination
> 1 11806 15M ACCEPT all -- eth1 eth0 0.0.0.0/0
> 0.0.0.0/0 state RELATED,ESTABLISHED
> 2 3 144 ACCEPT tcp -- * * 0.0.0.0/0
> 192.168.0.3 tcp dpt:80
> 3 8000 341K ACCEPT all -- eth0 eth1 0.0.0.0/0
> 0.0.0.0/0
> 4 5 224 LOG all -- * * 0.0.0.0/0
> 0.0.0.0/0 LOG flags 0 level 4
>
> Chain OUTPUT (policy ACCEPT 13143 packets, 996K bytes)
> num pkts bytes target prot opt in out source
> destination
>
> Chain drop-and-log-it (0 references)
> num pkts bytes target prot opt in out source
> destination
> 1 0 0 DROP all -- * * 0.0.0.0/0
> 0.0.0.0/0
>
> ####
> noticed that the Forward chain has (policy DROP 5 packets, 224 bytes) and
> the line num 2 has 3 counter and 144bytes hits. it's gotta be a problem
> here.
Well, what were those 5 packets? They were logged by line 4. You can add
--log-prefix "IPT:forward drop:" to the rule, and then use:
tail -n 100 /var/log/messages | grep IPT:for
later to list them. (or any other useful prefix for the log lines)
> one thing i am unsure is if the counter and packet get hit means the packet
> get passed or attempted to pass? taking a look at the line num 2 ruleset,
> it shouldn't block proper packet tho.
> 2 ACCEPT tcp -- 0.0.0.0/0 192.168.0.3 tcp dpt:80
The counter in the first listing indicates that three packets matched this
rule, and were accepted.
> another thing i'm unsure is the POSTROUTING and PREROUTING both have two
> hits and packet records. so this seems to say the packet got back from the
> webserver. but if the FORWARD chain drops the packet there, the POSTROUTING
> shouldn't have anything..
>
> [root@cozy166 Qiang]#iptables -L -v -n -t nat --line-numbers
> Chain PREROUTING (policy ACCEPT 146 packets, 10341 bytes)
> num pkts bytes target prot opt in out source
> destination
> 1 4 192 DNAT tcp -- * * 0.0.0.0/0
> 65.48.28.33 tcp dpt:8888 to:192.168.0.3:80
>
> Chain POSTROUTING (policy ACCEPT 1 packets, 249 bytes)
> num pkts bytes target prot opt in out source
> destination
> 1 4 192 SNAT tcp -- * * 192.168.0.0/24
> 192.168.0.3 tcp dpt:80 to:192.168.0.1
This tells us that 4 packets, total 192 bytes, matched this rule in
POSTROUTING. 4 packets from somewhere on the LAN, going to the server. The
rule above this shows 4 packets, total 192 bytes, matching the rule in
PREROUTING that performs the DNAT.
Unfortunately this doesn't tell us anything about return packets. The only
places those would be matched (at least with the listed rules) are in the PRE
and POST policies, and in the ESTABLISHED rule in FORWARD. However,
PREROUTING policy accepted 146 packets, POSTROUTING policy only 1, and the
listed rules match 4 and 4, so the remaining 145 packets are unaccounted for
in the data here.
> 2 51 2866 MASQUERADE all -- * eth1 0.0.0.0/0
> 0.0.0.0/0
>
> Chain OUTPUT (policy ACCEPT 79573 packets, 5705K bytes)
> num pkts bytes target prot opt in out source
> destination
j
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: problem reach the internal.
2002-11-30 15:27 ` Joel Newkirk
@ 2002-12-01 22:35 ` james.Q.L
0 siblings, 0 replies; 8+ messages in thread
From: james.Q.L @ 2002-12-01 22:35 UTC (permalink / raw)
To: netfilter; +Cc: netfilter
> > [root@cozy166 Qiang]#iptables -L -n --line-numbers
> >
> > Chain FORWARD (policy DROP)
> > num target prot opt source destination
> > 1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state
> > RELATED,ESTABLISHED 2 ACCEPT tcp -- 0.0.0.0/0
> > 192.168.0.3 tcp dpt:80 3 ACCEPT all -- 0.0.0.0/0
> > 0.0.0.0/0
> > 4 LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG flags
> > 0 level 4
> >
> > the line num 3 and num 2 are swapped.
> >
> > i tried reset the counter of ruleset and make connection test to it. i
> > found something that i don't understand. when i am testing from an internal
> > machine to INET_IP:8888 the ruleset for filter table is (counter has reset
> > to zero)
> >
> > [root@cozy166 Qiang]#iptables -L -v -n --line-numbers
> >
> > Chain FORWARD (policy DROP 5 packets, 224 bytes)
> > num pkts bytes target prot opt in out source destination
> > 1 11806 15M ACCEPT all -- eth1 eth0 0.0.0.0/0
> > 0.0.0.0/0 state RELATED,ESTABLISHED
> > 2 3 144 ACCEPT tcp -- * * 0.0.0.0/0
> > 192.168.0.3 tcp dpt:80
> > 3 8000 341K ACCEPT all -- eth0 eth1 0.0.0.0/0
> > 0.0.0.0/0
> > 4 5 224 LOG all -- * * 0.0.0.0/0
> > 0.0.0.0/0 LOG flags 0 level 4
> >
> > Chain OUTPUT (policy ACCEPT 13143 packets, 996K bytes)
> > num pkts bytes target prot opt in out source
> > destination
> >
> > Chain drop-and-log-it (0 references)
> > num pkts bytes target prot opt in out source
> > destination
> > 1 0 0 DROP all -- * * 0.0.0.0/0
> > 0.0.0.0/0
> >
> > ####
> > noticed that the Forward chain has (policy DROP 5 packets, 224 bytes) and
> > the line num 2 has 3 counter and 144bytes hits. it's gotta be a problem
> > here.
haven't nailed the problem yet.. can i ask further help please ?
#eth0 is internal IF, eth1 external IF.
#dmesg | tail
FWD drop IN=eth0 OUT=eth0 SRC=192.168.0.3 DST=192.168.0.12 LEN=64 TOS=0x00 PREC=0x00 TTL=127
ID=22869 DF PROTO=TCP SPT=80 DPT=1026 WINDOW=17520 RES=0x00 ACK SYN URGP=0
so it's the FWD chain problem?
# request INET_IP:8888 from internal machine 192.168.0.12. only one type of msg greped out.
#grep 192.168.0.12 /proc/net/ip_conntrack
tcp 6 59 SYN_RECV src=192.168.0.12 dst=65.48.28.33 sport=1109 dport=8888 src=192.168.0.3
dst=192.168.0.1 sport=80 dport=1109 use=1
this seeems to be SYN/ACK in return. but no established further on..
here is more verbose iptables dump..
from iptables -L -v -n
Chain FORWARD (policy DROP 130 packets, 7822 bytes)
pkts bytes target prot opt in out source destination
1292K 1462M ACCEPT all -- eth1 eth0 0.0.0.0/0 0.0.0.0/0 state
RELATED,ESTABLISHED
55 3204 ACCEPT tcp -- * * 0.0.0.0/0 192.168.0.3 tcp dpt:80
18402 1286K ACCEPT all -- eth0 eth1 0.0.0.0/0 0.0.0.0/0
53 3296 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0
level 4 prefix `FWD DROP '
from iptables -L -v -n -t nat
Chain PREROUTING (policy ACCEPT 51091 packets, 3818K bytes)
pkts bytes target prot opt in out source destination
7 396 DNAT tcp -- * * 0.0.0.0/0 65.48.28.33 tcp
dpt:8888 to:192.168.0.3:80
Chain POSTROUTING (policy ACCEPT 276 packets, 46588 bytes)
pkts bytes target prot opt in out source destination
10 576 SNAT tcp -- * * 192.168.0.0/24 192.168.0.3 tcp dpt:80
to:192.168.0.1
5715 315K MASQUERADE all -- * eth1 0.0.0.0/0 0.0.0.0/0
many thanks,
=====
/James.Q.L
______________________________________________________________________
Post your free ad now! http://personals.yahoo.ca
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2002-12-01 22:35 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-11-29 19:32 problem reach the internal james.Q.L
2002-11-30 1:03 ` james.Q.L
2002-11-30 1:35 ` Anders Fugmann
2002-11-30 2:20 ` Joel Newkirk
2002-11-30 8:34 ` james.Q.L
2002-11-30 15:27 ` Joel Newkirk
2002-12-01 22:35 ` james.Q.L
2002-11-30 11:44 ` Anders Fugmann
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.