Carter, Thanks. With the exception of the client's loopback address in the hosts file, I have a very similar configuration. I have created an inbound rule (Custom service with an inbound rule declaration but no outbound rule) that looks just like my inbound RDP rules - I even reviewed the configuration file and the stunnel rule had the same commands as the RDP rule. However, RDP works through the firewall but stunnel does not. My Windows firewall has an exception for stunnel with a scope of "Internet" and the stunnel server works from within the corporate network. Meaning, I think, that the Windows firewall is not denying the connection (at least from within the same subnet).
I am not a Windows AD guy, but is there a way to prevent network connections without using the Windows firewall? I mean, can a GPO be created that prevents connections from IP addresses not on the same subnet but that does not use the OS's firewall? If so, this could be the issue because from what I can see, neither the Watchguard nor the Windows firewalls are blocking the connection; yet I still cannot connect.
Richard
Carter Browne wrote: I use stunnel to protect RDP for a couple of sites using a mix of Watchguard Edge and V series firewalls. For computer ABC that I want to connect to, I create an entry in the hosts file: 127.0.0.n ABCs (where n is greater than 1)
On the client side I have an entry:
[ABC-RDP] accept = ADCs:12345 connect = ABC:54321 client = yes
On the server sid I have an entry:
[RDP-IN] accept = 54321 connect = 3389 client = no
Port 54321 is enabled in both the Watchguard and the Windows firewalls.
Using the 127.n.n.n ports are not processed by the firewalls. You can use 127.0.0.1 for everything, but I needed to connect to more that one host and wanted a standard setup. I have had a number of users confused by this setup whereby the program references a local port to connect to a remote computer. For stunnel, it is the connect string that determines the destination, so any local port works fine for the accept string.
Carter
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
-
Richard Woodman -
richard.woodman＠cox.net