Re: Translating IP tables

[Ray Olszewski <ray@comarre.com>]

At 11:48 AM 2/1/2005 -0500, Eve Atley wrote:


>I'm wanting to set up to allow port 23 to be accepted via the internet in my
>Linux box running RedHat Linux Enterprise Workstation. I did some research
>and have an output pasted below; am I truly allowing input/output from the
>internet?
>
>What I truly am attempting to do is telnet to port 5201 in order to allow
>for VNC, but it appears I can not telnet on port 23 either (telnetting to
>the machine on port 5201 should bring back an rfb: prompt, but connection is
>refused on both 5201 and 23); so, my first guess is that I need to allow
>port 23. Can someone assist me in cleaning up?

I won't belabor this point, but I do feel an obligation to mention, at 
least in passing, that accepting telnet (port 23) input on a server 
connected to the Internet is a major security risk. I assume you are a 
grownup and cam make your own decisions about balancing risks and benefits, 
but my conscience won't let me troubleshoot telnet problems without at 
least mentioning their riskiness.

In any case, getting port 5201 working DOES NOT require you first to get 
port 23 working. Although you can use the telnet *client* to test other 
ports, as you seem to be doing here, that sort of test works just fine 
without a functioning telnet *server* on the target host.

Below, I comment on your firewall rulesets in specific and identify the 
likely problem ... but not the solution, because I do not know how RH 
generates its rulesets. If you were able to modify the INPUT chain, though, 
I guess you do, so you can use that knowledge to modify the 
RH-Firewall-1-INPUT so it ACCEPTs port 5201.

>Thanks,
>Eve
>
>
>Chain INPUT (policy ACCEPT)
>target     prot opt source               destination
>RH-Firewall-1-INPUT  all  --  anywhere             anywhere
>ACCEPT     tcp  --  anywhere             anywhere           tcp dpt:telnet

Because the first rule directs all traffic to the RH-Firewall-1-INPUT 
chain, subsequent rules have no effect. So the second, ACCEPT rule is 
irrelevant.

>Chain FORWARD (policy ACCEPT)
>target     prot opt source               destination
>RH-Firewall-1-INPUT  all  --  anywhere             anywhere
>
>Chain OUTPUT (policy ACCEPT)
>target     prot opt source               destination
>
>Chain RH-Firewall-1-INPUT (2 references)
>target     prot opt source               destination
>ACCEPT     all  --  anywhere             anywhere
>ACCEPT     icmp --  anywhere             anywhere           icmp any
>ACCEPT     ipv6-crypt--  anywhere             anywhere
>ACCEPT     ipv6-auth--  anywhere             anywhere
>ACCEPT     all  --  anywhere             anywhere           state
>RELATED,ESTABLISHED
>ACCEPT     tcp  --  anywhere             anywhere           state NEW tcp
>dpt:smtp
>ACCEPT     tcp  --  anywhere             anywhere           state NEW tcp
>dpt:http
>ACCEPT     tcp  --  anywhere             anywhere           state NEW tcp
>dpt:ftp
>ACCEPT     tcp  --  anywhere             anywhere           state NEW tcp
>dpt:ssh
>ACCEPT     tcp  --  anywhere             anywhere           state NEW tcp
>dpt:7886
>ACCEPT     tcp  --  anywhere             anywhere           state NEW tcp
>dpt:webcache
>ACCEPT     tcp  --  anywhere             anywhere           state NEW tcp
>dpt:cvspserver
>REJECT     all  --  anywhere             anywhere           reject-with
>icmp-host-prohibited

This chain is, probably,  the source of your problem. (In saying this, I am 
making a guess about its first entry; see next paragraph.) It needs ACCEPT 
rules for ports 5201 and (if you *really* want telnet itself) 23. And, for 
that matter, for ANY service that you wish to run on this host. (They need 
to have the same form as the rules currently present for smtp, heep, and so 
forth.) Without such rules, the traffic drops down to the last rule in this 
chain, which causes it to be REJECTed.

An aside: when listing rulesets, it is better to use the -nvL flags. The 
listings you provided here are incomplete ... probably not in ways that 
matter to your actual problem, but in ways that do often matter to ruleset 
troubleshooting ... for example, the first rule in the chain is 
incomprehensible as written in this output (it must have some flags set 
that are not listed in this format, or it would simply ACCEPT all traffic).

If my guess about this first rule is mistaken, then your iptables rules are 
NOT the source of the problem, and you need to tell us more about the VNC 
server installation itself. You are correct that it should reply to a 
telnet connection with a prompt that begins with "RFB" (on my VNC host, it 
is "RFB 003.003"). Make sure that the vncserver is actually listening on 
port 5201 ("netstat -ln" is one way).




-- 
Internal Virus Database is out-of-date.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.7.4 - Release Date: 1/25/2005


-
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