Hy Guys,
i have a server 2016 remotedesktopserverfarm with 2 RemoteDesktopServers and one Windows-RemoteDesktopBroker, which redirects the user to the correct RemoteDesktopServer.
When i create SSL VPN bookmarks (RDP - Port 3389) to both terminalserver directly, it works - but it's a 50:50 chance to get the server where the user is loaded. When I create a bookmark to the broker, it don't work -> Connection refused.
Any idea?
Thanks!
Manuel Wagner
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
kubimike, I found after some more testing that what I said earlier wasn't working with a strong success rate so I did some more digging and found a route that's getting me closer to the end goal.
I stumbled across this video (https://www.youtube.com/watch?v=nMcwdOyXO5U) where they used the Fortigate's LB functionality to establish connection to the RDS environment. I set it up and modified as needed to use the SSL VPN portal and it's half way to working. I can successfully connect to the RDS environment however I do find that I have to hit the Reconnect button up to 3 times to get connected (I have 4x RDSH servers)
I'm going to look into seeing what I can do about eliminating the Reconnect issue but I do feel I am getting close.
Do you have a 100e ?
I am running the 500e with firmware 6.0.7 currently. My RDS farm is currently a 2012R2 based farm. It uses the RD Connection Broker for handling connections.
I am also building a new 2019 farm at the moment so I am going to see if there is a way eliminate the reconnect prompts that are occurring with the current 2012R2 farm and the Fortigate.
So I wanted to report back that while I have made some progress I am still struggling to get this configured to work.
I was able to establish a connection using RDP however it would require clicking Reconnect serveral times until you arrived at the correct server in your RDS farm. This isn't viable given it's a bad experience.
Trying to pass credentials to the RDWeb login page is also proving interesting but I've hit a roadblock. It seems that when trying to pass credentials to the webpage, it's modifying the javascript which results in failure.
For example this is a snippet of code from renderscripts.js found on the RDWeb server
function onClickSecurity() { var bPrivateMode = document.getElementById("rdoPrvt").checked; var objPassword = document.getElementById("UserPass"); var objDomainUserName = document.getElementById("DomainUserName"); if (GetActiveXSSOMode()) { document.getElementById("trPrvtWrn").style.display = bPrivateMode ? "" : "none"; } if ( bPrivateMode ) { document.FrmLogin["flags"].value |= 4; if ( objPassword && objDomainUserName ) { objPassword.setAttribute("autocomplete", "on"); objDomainUserName.setAttribute("autocomplete", "on"); } } else { document.FrmLogin["flags"].value &= ~4; if ( objPassword && objDomainUserName ) {
objPassword.setAttribute("autocomplete", "on"); objDomainUserName.setAttribute("autocomplete", "on");
} } }
When accessing the same page however through the SSL Web portal with SSO enabled, the code is being modified in a number of places to add a fgt_sslvpn value into the script:
function onClickSecurity() { var bPrivateMode = document.getElementById("rdoPrvt").checked; var objPassword = document.getElementById("UserPass"); var objDomainUserName = document.getElementById("DomainUserName"); if (GetActiveXSSOMode()) { document.getElementById("trPrvtWrn").style.display = bPrivateMode ? "" : "none"; } if ( bPrivateMode ) { document.FrmLogin["flags"].value |= 4; if ( objPassword && objDomainUserName ) { fgt_sslvpn.set_attr(objPassword,"autocomplete", "on"); fgt_sslvpn.set_attr(objDomainUserName,"autocomplete", "on"); } } else { document.FrmLogin["flags"].value &= ~4; if ( objPassword && objDomainUserName ) { fgt_sslvpn.set_attr(objPassword,"autocomplete", "off"); fgt_sslvpn.set_attr(objDomainUserName,"autocomplete", "off"); } } } So the struggle for me here is two fold. One is I don't know where I find the script that is modifying the information and two I'm not much of a coder so figuring something like this out will take some time.
I have the Hotfix for 100e, I don't have it for 500e :(
Hi all,
We have the same problem there: 4 servers farm, 2 HA connection Broker.
Tried a lot of things:
- Upgraded to 6.0.7 and then to 6.0.10
- Set the load-balancing-info to the same string than internal one (tsv://MS Terminal Services Plugin.1.COLLECTIONNAME)
- Tried with rdweb
- Tried with webclient
- Tried to create as many DNS records as RDSH servers (with the same name)
The only connection I can get is a direct connection to one of our broker...
Does anybody have some updates ? or mybe a Hotfix ?
Thanks
Hello ! I noticed the same problem using Fortigate VM01V.
I tried all release from 6.0.9 to 6.4.1 but we are unable to correctly bookmark a RDS farm with a broker.
My workaround is to use a HAproxy in front of RDS then create the RDP bookmark to HAproxy only.
Below the configuration of HA proxy to perform the correct load balancing between the RDS.
frontend Proxy3389
mode tcp
bind haproxy.dev.local:3389 name rdp
timeout client 1h
log global
option tcplog
tcp-request inspect-delay 2s
tcp-request content accept if RDP_COOKIE
default_backend IPETS
backend IPETS
mode tcp
balance leastconn
persist rdp-cookie
timeout server 1h
timeout connect 4s
log global
option tcp-check
tcp-check connect port 3389 ssl
default-server inter 3s rise 2 fall 3
server RDS1 rds1.dev.local:3389 weight 10 check
server RDS2 rds2.dev.local:3389 weight 10 check
All seems working for me with this solution
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1663 | |
1077 | |
752 | |
446 | |
220 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.