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

HTML5 VPN with RDP via connection broker

Hey,

 

we would like to use HTML5 VPN to access our Terminalserver Farm.

 

The Destination points to the RDP connection broker - once a user is authenticated

the connection is redirected to one of our terminalserver - at the same time the HTML connection dies.

 

Is the use of a RDP connection broker supported?

 

Thanks

Philipp



This thread was automatically locked due to age.
Parents
  • Hi Philip,

    Have you ever found a solution for this?
    We are currently struggling with the same requirements...


    Thanks,
    Chris.

  • Hi, Christian, and welcome to the UTM Community!

    Why not simply use a DNAT for this and let Citrix do the authentication?  Otherwise, the most efficient, secure and free solution with the UTM is L2TP/IPsec with certificate authentication.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • I assume that the key issue here is the need to put two-factor authentication on every form of remote access, to make PCI DSS happy.

    I think the only form of 2FA for Microsoft Terminal Server is a Smart Card.   I have not investigated the technology at all, but this would require that the user have a smart card reader on his remote access device.

    SSL VPN requires prior software installation on the remote access device.

    I am less savvy about L2TP, but I think it also requires technical client configuration prior to use.

    In some remote access scenarios, the remote employee wants to use a device at a location where he is a guest, such as a physician in a hospital or a consultant at his client's site.  In other cases, the remote user may be unwilling to accept a solution that requires complex setup.

    HTML5 VPN with RDP and OTP is attractive because it solves the problem and does not require any client pre-configuration.   But as you say, your experience is that it does not scale well. 

    I think you will need a different 2FA product.

    I don't like 2FA solutions that accept your password first, and then initiate a secondary channel for confirmation, because it releases information about password correctness to a password guesser.   However,, it permits the implementation to provide multiple options for the second factor, which is why DUO, Microsoft Live, and others use this approach.  UTM wiht OTP reveals nothing when an incorrect password is attempted, but it has only one option for the 2nd factor.

  • Hi Douglas,
    Hi BAlfson,

    Thank you very much for your help.
    Douglas hit the nail on the head.
    We want to use 2FA and DNAT is not an option for us.

    I think we will configure a straight RDP-connection to a single RDSH without having the comfort/redundancy of a Terminalserverfarm.

    Again,
    thank you very much for your help!

    Chris.

Reply
  • Hi Douglas,
    Hi BAlfson,

    Thank you very much for your help.
    Douglas hit the nail on the head.
    We want to use 2FA and DNAT is not an option for us.

    I think we will configure a straight RDP-connection to a single RDSH without having the comfort/redundancy of a Terminalserverfarm.

    Again,
    thank you very much for your help!

    Chris.

Children
No Data