Hey Tyler:
Nobody else seems to have replied, so I guess I will :)
Well, these days I'm doing this with iptables, but back with ipchains and
ipmasqadm, your rule looks correct to me.
If nmap is telling you it's filtered, then it's not getting any response
back. Most of the ports it defines as closed are because it (nmap) gets
RST packets back in response to its SYN packets it sends (I'm assuming
you're just using nmap without any commandline options, the default
behavior attempts a 3-way handshake). When it comes back as "open," your
nmap host is getting back a SYN/ACK. When it says "filtered," it's
getting back nothing at all, not even a RST. That's why ftp'ing to
another port without a listening daemon, gives you back an instant
refusal, because the remote computer sent you back a RST right away,
indicating no listening service there. When you're trying to connect to
the right port, you get back no RST, you get back nothing, so you have to
wait for your box to try four times (4 SYN packets) before it "times out."
So, I'm not able to tell you why it's breaking :) But, maybe you could
provide a little more information about the "sometimes" part of when it
comes back "open" and when it comes back "filtered." Are there reboots
between, restarting daemons, running some kind of firewalling script,
bringing interfaces up/down, etc?
Are you certain that their is no ipchain rule that prevents the packet
from being forwarded? A default policy of DENY for the input or forward
chains? What does `cat /proc/sys/net/ipv4/ip_forward` give you? You'll
need it to be '1' and not '0' for forwarding to work. Any leftover rules
in ipmasqadm (I believe it's `ipmasqadm portfw -l -n` or just flush them
with `ipmasqadm portfw -f` before you enter your forwarding rule)?
My first thoughts anyway :) Hope it helps some. Send back more details
if you want to. Running a sniffer (tcpdump would be fine for this, but
nmap sends a lot of packets, so you'll want to write them to a file and
use 'less' or something to find the packets you're interested in) might
help you find out how far along the connection is getting. You'd want to
run it on both sides of the forwarding box. You might not need it though,
I'm guessing it must have to do with that ip_forward thing in /proc, or an
errant ipchains rule or something.
Good luck ;)
Wes
On Tue, 1 Jan 2002, Tyler Hall wrote:
> Happy New Years;
>
> I'm having some issues with port forwarding. I'm using this command;
>
>
> [root@router tyler]# ipmasqadm portfw -a -P tcp -L 206.100.120.175 80
> -R 192.168.0.15 80
>
> and sometimes, I can do a nmap (from another box) and it will show
> port 80 as open;
>
> 80/tcp open http
>
> But other times, when I do it again, it will show it as
>
> 80/tcp filtered http
>
> If its filtered, I won't be able to connect to it. It does the same
> thing with the ftp port, so I'm confused. If it's filtered, it will
> just sit there;
>
> [root@router tyler]# ipmasqadm portfw -a -P tcp -L 206.100.120.175
> 1500 -R 192.168.0.3 21 [thall@wampa thall]$ ftp 206.100.120.175 1500
> After Control-C'ing it; I try another port;
>
> [thall@wampa thall]$ ftp 206.100.120.175 1358
> ftp: connect: Connection refused
> ftp> quit
>
> and it refuses it right away. So its trying to make a connection, but
> just sits there. Anyone else have a idea?
>
> Tyler
>
(text/plain)