LinuxInfo wrote:

*Hi all!

I have a SuSE 9.2 as firewall with SuSE Firewall2. Im trying to redirect java_tight vnc (port 5801 on the firewall) to a tight vnc server behind my firewall (port 5801 for http server) and port 5901 on the vnc server.

Why are you trying to redirect 5801 to 5901? Ports 580x are for use by the vnc mini-httpd while ports 590x are for use by vnc clients (including the java client, once it is downloaded). Maybe my appreciation of what this says is different from what you actually mean. The documentation TightVNC has on their website is very very sparse (read: almost useless), but they do refer you to the RealVNC website (these are the guys who invented the protocol), where the documentation is a little more helpful. The first thing you should probably do is make sure your vnc is working properly, without adding any firewall issues: can you connect to the vnc server, using both a browser and the vnc viewer, from your firewall machine? But I think configuring a VNC is probably not your real problem. It is certain that you -must- forward ports 5801 and 5901 if you want to use a web browser to connect to the vnc server. All 5801 is going to be used for is to download the vnc java client, after which all the network traffic will be on port 5901 (see http://www.realvnc.com/javavncviewer.html). If you are only going to use the separate vnc viewer client, then all you should need to forward is 5901.

... add a new redirect on the firewall, 5901 to the internal machine i can get everything to work once. But if i disconnect and try to connect again it fails. But if i remove port 5901 on the firewall again so that i can load the applet and then add the 5901 rediect again it works...

It is my understanding that the vnc server will disconnect as soon as the client disconnects. However, iptables will view this as an ESTABLISHED connection, and maybe iptables will keep it alive in case any additional traffic arrives. The timeout for this is, I believe, going to be determined by the value in /proc/sys/net/ipv4/tcp_fin_timeout which defaults to 60 seconds. Perhaps also relevant are the values in /proc/sys/net/ipv4/tcp_keepalive_* (but I think these values are only for keeping alive an idle connection). These are all documented in /usr/src/linux/Documentation/networking/ip-sysctl.txt and there is additional information in /usr/src/linux/Documentation/filesystems/proc.txt. According to this second file, the tcp_fin_timeout value violates the TCP specification, but it is necessary, so the file says, to prevent DoS attacks (I think only the SYN-flood type, and I also think it won't help at all if the attacker is just sending out SYN packets and no FIN packets; however, my default SuSE 9.0 configuration did survive a limited DDoS SYN attack from about 12 or 15 distinct IPs, from some disgruntled IRC users I threw out of my channel -- and my ISP would not have known what was happening except everything slowed down, if I hadn't phoned them to tell them about it :-) ). Maybe running your vnc server from inetd will be a solution to your problem. See the xnvc(1) manpage, or http://www.realvnc.com/v4/man/Xvnc.html if you don't have the vnc manpages. BTW, are you aware that there is now a vnc server module for XFree86? I think as of version 4.0, but certainly for 4.2. See http://xf4vnc.sourceforge.net/. I don't know if it works also in X.org. There is also a VNC multicast server, http://www.informatik.uni-trier.de/~ziewer/MulticastVNC/ Also, here is a rather nice article I found on VNCs: http://cyberelk.net/tim/articles/VNC/, and there is a tutorial on tunnelling VNC through SSH at http://pigtail.net/LRP/vnc/ (I didn't actually visit the multicast and SSH tunnelling sites, so I don't know if they are still active.)