Thread Info
  • State Verified Answer
  • +2 person also asked this people also asked this
  • Locked Locked
  • Replies 29 replies
  • Subscribers 6 subscribers
  • Views 118364 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.
Parents
  • 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

     
Reply
  • +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

     
Children
Unfiltered HTML