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