I set up an SSL-VPN with a Web-only portal; I want users to be able to connect to internal servers using RDP. I created a bookmark for an internal terminal server.
The portal itself works fine. When I click on the bookmark, I get the usual Java security warnings, then RDP launches and reports "Configuring remote session" to 127.0.0.1:49152. RDP stays at that message and never connects. Eventually, the portal times out and logs out.
I've set up such an SSL-VPN before and got it to work with no problems, but can't figure out what I'm missing this time.
FortiOS 5.0 on a FGT 60D.
For my testing, the client is Windows 8.1 64 bit with Java 8 Update 45 and Java 7 update 75 both installed. Both the 32-bit and 64-bit versions of Java are installed. I am using IE 11.
Solved! Go to Solution.
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.
Would it be accurate to say you're using RDP-Native? If so, what is the impact of changing the bookmark to use Java-based RDP?
Regards, Chris McMullan Fortinet Ottawa
Would it be accurate to say you're using RDP-Native? If so, what is the impact of changing the bookmark to use Java-based RDP?
Regards, Chris McMullan Fortinet Ottawa
Christopher McMullan_FTNT wrote:Would it be accurate to say you're using RDP-Native? If so, what is the impact of changing the bookmark to use Java-based RDP?
Yes, your assumption is correct, I used RDP Native. When I use the Java-based RDP, I get an error message "Connection exception. SSL Negotiation failed. please check your Fortigate configuration". The computer I am trying to connect to uses the standard SSL self-signed certificate. I don't think the RDP Native implementation even gets to the point where it would check certificates; it seems to not even connect to port 3389 at all.
This is going to sound odd, but could you check to verify whether the destination address object in any ssl.<vdom> to internal policy is correctly defined for the resource you're trying to access?
I found one case where it was simply an ACL issue: the policy didn't allow the destination specified in the bookmark. This would apply equally to Java-based and native SSLVPN RDP connections.
Regards, Chris McMullan Fortinet Ottawa
Christopher McMullan_FTNT wrote:This is going to sound odd, but could you check to verify whether the destination address object in any ssl.<vdom> to internal policy is correctly defined for the resource you're trying to access?
I found one case where it was simply an ACL issue: the policy didn't allow the destination specified in the bookmark. This would apply equally to Java-based and native SSLVPN RDP connections.
Not odd at all. And in fact, I had completely forgotten the police from the ssl.root interface to internal. Unfortunately, that's not the only problem; even after adding it, the problem still persists.
Christopher McMullan_FTNT wrote:This is going to sound odd, but could you check to verify whether the destination address object in any ssl.<vdom> to internal policy is correctly defined for the resource you're trying to access?
I found one case where it was simply an ACL issue: the policy didn't allow the destination specified in the bookmark. This would apply equally to Java-based and native SSLVPN RDP connections.
I found the problem. The ssl.<vdom> to internal policy actually isn't needed at all; it is only required for tunnel mode. I got it to work without this policy.
The real problem turned out with my sslvpn policy; I had specified the wrong destination interface (I had it as wan1 to ssl.root instead of wan1 to internal).
Thanks for your help! You pointed me in the right direction.
No problem! Glad it's working.
Regards, Chris McMullan Fortinet Ottawa
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 |
---|---|
1666 | |
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.