[stunnel-users] More questions on RDP and port forwarding

Wed Nov 28 04:42:47 CET 2007

Well, I fixed my problem with the Juniper firewall but have yet to get the
Watchguard SOHO 6tc working (mainly because it is in Phoenix and I'm not).
Anyway, I thought I would let the list know what I did.

I reset the Netscreen to factory defaults before I started.  I then created
a custom service called VNC-Secure, TCP, source ports 1-65535, destination
ports 45900-45908. 
(My first post was about RDP but because I don't have RDP running at home, I
used VNC instead).

I then assigned that custom service as a VIP service to my UNTRUST interface
with a target of 192.168.10.52 (my Linux stunnel server).

Finally, I created a policy from UNTRUST to TRUST with a source address of
ANY, destination address of the VIP service on the UNTRUST interface, log,
and PERMIT.

On the Linux box, I configured stunnel to accept inbound connections on
45900 and to connect to 192.168.10.105:5900 (my Mac OS X running Vine - OSX
VNC).  I used the same certs as before.

On the Windows client, I configured stunnel to accept inbound connections on
5901 and to connect to my firewall's OUTSIDE (UNTRUST) IP address:45900.
Again, I used the same certs as before.

When I fired up VNC Viewer and connected to localhost:5901, I could see in
the stunnel log that I was attempting to connect but the connection failed.
I then reviewed the firewall's logs and it showed port forwarding to .52
(the Linux stunnel server).  I then checked the stunnel server logs and
didn't see anything.  I noticed that debugging was not on, so I turned it on
and configured where the log file should go.  Restart the stunnel service
and now everything works.

I completely started over on my Netscreen configuration but my first few
attempts at connecting through it using port-forwarding were unsuccessful.
I changed from using a Windows stunnel server to a Linux one, and I
installed stunnel on kubuntu using the package manager (remember to enable
stunnel in /etc/default/stunnel4 or it won't work).  I also used VNC instead
of RDP.  So, what was the magic fix?  I have no idea.  However, I tend to
believe using Linux without its inclusion into Microsoft AD might be the
biggest contributor to getting this working.  Rebuilding the Netscreen might
have helped too.

Richard