Thread Info
  • State Verified Answer
  • +2 person also asked this people also asked this
  • Locked Locked
  • Replies 29 replies
  • Subscribers 6 subscribers
  • Views 117676 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Publishing Microsoft Remote Desktops Server Gateway with Sophos UTM

ckruesi
Hello. 

We had an old ISA Server from Microsoft to publish our Remotedesktopserver(-gateway) and replaced it now with a Sophos UTM 320 (FW 9.106-17). I’m not really a firewall professional, so I thought maybe there is someone in this forum who can take a look at my configuration and give me some advice if I did something wrong. I did the same before with my configuration of the Webserver in the DMZ and our Exchangeserver. I’m glad that a professional looked over it (https://community.sophos.com/products/unified-threat-management/astaroorg/f/57/t/50158 and https://community.sophos.com/products/unified-threat-management/astaroorg/f/57/t/50159). 
Hope that someone can have a look at this one too (this is the last service I migrated from the old ISA box, so the last post with this question). Thanks in advance.

It looks like you can’t use WAF for publishing a Remotedesktopservergateway. There are two feature request that I found: Web Application Security: Remote Desktop Support and Web Application Firewall: Remote Desktop Gateway support

I found also a post in the german forum (https://community.sophos.com/products/unified-threat-management/astaroorg/f/68/t/59919) and two in the English (https://community.sophos.com/products/unified-threat-management/astaroorg/f/80/t/65149 and https://community.sophos.com/products/unified-threat-management/astaroorg/f/54/t/39975). In the first one the Astaro Beta Bot says that “The Mantis ID #25441 is now under investigation”. 

So maybe in the future there is also the possibility to use the UTM as reverse proxy for the RD Gateway like it is working for Exchange now. 
In the meantime I tried to configure it with a DNAT rule. 

NAT
I created a DNAT rule with these settings: For traffic from: Any, Using Service: HTTPS, Going to: external Network Address, Change the destination to: Remotedesktopservergatewayserver. 

Firewall
The firewall rule I added myself. Any -- > HTTPS -- > Remotedesktopservergateway. 

IPS
Since the Server is in the local networks of the Intrusion Prevention the traffic should be secured by the Intrusion Prevention of the UTM. 

I hope, I didn’t made something wrong and we’re safe. But I would feel more comfortable if someone of you could confirm this. Thanks.


This thread was automatically locked due to age.
  • 0
    In order to keep my RDP secure as best I can, I have only published it to the HTML5 Portal.  This requires only authenticated users that can access the UTM first be the only ones with access to RDP.  The second layer would be authentication to the RDP server itself, with access there.  I don't use AD or SSO, as mine is for home use, but prevents the port from being opened, and I keep my security intact without someone nosing around on 3389.

    Internally, of course I can reach my RDP server via my local machine.  Externally however, better have access to UTM first as a user.  [;)]

    OPNSense 64-bit | Intel Xeon 4-core v3 1225 3.20Ghz
    16GB Memory | 500GB SSD HDD | ATT Fiber 1GB
    (Former Sophos UTM Veteran, Former XG Rookie)

  • 0 in reply to Amodin
    In order to keep my RDP secure as best I can, I have only published it to the HTML5 Portal.  This requires only authenticated users that can access the UTM first be the only ones with access to RDP.  The second layer would be authentication to the RDP server itself, with access there.


    How about stability, do you suffer instability with RDP over HTML5? For a while back I tried to put a TS machine in HTML5 portal and was able to connect, but the connection wasn't stable and I had to reconnect over and over again. For this reason I have turned to first making a VPN-connection and then being able to reach TS-machine and this has since been very stable.

    Managing several Sophos firewalls both at work and at some home locations, dedicated to continuously improve IT-security and feeling well helping others with their IT-security challenges.

  • 0 in reply to apijnappels
    [...] but the connection wasn't stable and I had to reconnect over and over again.


    Try to change Pattern and Update check/download from 15 Minutes to 4 hours. This has worked for my Clients and my Home-UTM.
  • 0 in reply to apijnappels
    How about stability, do you suffer instability with RDP over HTML5? For a while back I tried to put a TS machine in HTML5 portal and was able to connect, but the connection wasn't stable and I had to reconnect over and over again. For this reason I have turned to first making a VPN-connection and then being able to reach TS-machine and this has since been very stable.


    Nothing I have seen yet, unless the browser from other locations is outdated, then there seems to be issues.  Other than that, no.  It works well for what I need.  I am not on it for hours, as anything like that I would either be at the server or RDP internally. 

    The response has been pretty good though with HTML5 access.  You will suffer speed though the more users access the portal.  Again for me, not an issue.  There are maybe two or three that access it and we are not all on it at the same time.

    I also have availability as well using the VPN client if I need it.  I haven't used it much though.

    OPNSense 64-bit | Intel Xeon 4-core v3 1225 3.20Ghz
    16GB Memory | 500GB SSD HDD | ATT Fiber 1GB
    (Former Sophos UTM Veteran, Former XG Rookie)

  • 0
    Thanks Solae and Amodin (and sorry for hijacking this thread). Anyway another safe possibility (next to HTML5 would be to hide RDP-servers behind a VPN).

    Managing several Sophos firewalls both at work and at some home locations, dedicated to continuously improve IT-security and feeling well helping others with their IT-security challenges.

  • 0 in reply to apijnappels
    Any updates on getting this functionality (RDP gateway publishing through Sophos) working properly? Any further configuration or log information that can be provided?

    It feels like functionality that should be 'working' given the use is documented, but as it doesn't is 'broken'. As users, how do we get this resolved?

    Thanks!
  • +2 in reply to tsull360

    Hey guys.

    I know this is kinda old, but it's actually working with 9.404 (or 9.405).

    Pretty much follow https://sophserv.sophos.com/repo_kb/120454/file/Configuring%20UTM%20firewall%20for%20Remote%20Desktop.pdf.

    I did some modifications to suit my needs and to get it working with RD Client for Android and IOS.

    Basically at URL hardening in Firewall Profile, I added:

    /rpc
    /prcWithCert
    /rdweb
    /RDWeb
    /RDweb
    /rpc/rpcproxy.dll?localhost:3388

    Those different RDWeb stuff are for allowing users to not worry so much about typing the URL exactly as /RDWeb. That last line, however, was necessary for RD Client on IOS to work. I know it should be covered by /rpc, but for some reason it is not. It only worked after I added the whole thing. For windows clients, however, that was not needed.

    Again, in Exceptions, I added a few things to make life easier:

    /rpc/*
    /rpcWithCert/*
    /RDWeb/*
    /RDweb/*
    /rdweb/*

    What happens here is that first the RD Client will try to reach RD Gateway using the /remoteDesktopGateway/ path. If allowed access, using that path will activate RDG_IN_DATA and RDG_OUT_DATA protocol, that won't work with WAF and Outlook Anywhere, because it's a different protocol than RPC over HTTPS. Since in the recommended configuration /remoteDesktopGateway/ is not allowed by URL Hardening, the client will fallback to RPC over HTTPS (hence rpcproxy.dll) and it will just work.

    At least, it's working very well for me, and for some time now. The RD Client for IOS was the only piece of the puzzle missing, for two reasons: the previous versions added :443 at the end of the URL, which cause URL Hardening to block access, after all, it did not match the exceptions. This was fixed on the latest client build. Even after that, for some reason, requests coming from RD Client for IOS was still blocked by URL Hardening. I figured out last night that adding that last line at URL Hardening in Firewall Profile made everything work. Go figure.

    So give it a try and let me know how it works.

    Regards - Giovani

     
  • 0 in reply to giomoda

    Thank you this has help me as well, I already added /rpc/* /RPCWithcert/* but still I could not access my RD gateway from IOS and mac, untill I did add the /rpc/rpcproxy.dll?localhost:3388 to firewall profile and now my users can access the servers from Iphone and mac.

    Thanks you

  • 0 in reply to giomoda

    I can confirm the above works. RD Web access as well as full RDP access to 2012R2 works well.

Unfiltered HTML