If you do not choose OK, then the changes you just made, will not take effect. After doing this, you must move your mouse pointer to the OK box and click your Left mouse button. The circle should be dark now(if it s already dark, then your desktop is already configured for remote connectivity). You should now be in the Remote tab menu, and it should look like the picture below: You need to move your mouse pointer down to the Remote Desktop section of this menu, and then hit your left mouse button in the circle next to Allow connections from computers running any version of Remote Desktop (less secure). After doing so, click the Left mouse button again. this is more clean and easier to read and investigate.2 You now need to move your mouse pointer over to Remote Settings. Why a client / independent share only for testing? You avoid the overload of entries in the logfiles from all those other people accessing the system. W10 client that has a share - proof it does not work - then check logfiles there after enabling them.
Use simpler services to investigate like a file-server or even a file-share on a client-system in the network - e.g. pointing more in direction of an authentication issue at a certain point in time.Įnable advanced security audit-logs (GPO / advanced section) on your servers and e.g. just RDS - I assume it is more wide-spread.
I still tend to think in direction KERBEROS - this is something you could investigate on the client eventlogs - but it should as well show up in any WireShark within the tunnel - what is one of the more complicated ones to capture depending if your VPN network adapter exists or is dynamically created, but that's a whole other story.ĭid you check and see if File-Servers are available right away - just to see if the issue is more wide-spread over the board or more narrow to e.g. Hmm, then it might be something that is more specific to the firewall model and VPN client - cause I never had issues like you describe them (let's say - I do not remember such issues - might have had em). I understand you used WireShark, and you say you weren't redirected - now - did the first attempt to the broken get through or did he deny you?īut for now I would get the broken and DNS out of the equation, test it with a simple W10 or W7 client as target and fiddle around with some settings on them, instead of influencing a multi-user RDS system.Īnother thing solution would be to remove VPN from your equation by setting up an RDS GateWay instead that would allow the users to connect without VPN - but this now depends on some policies and procedures you might have in place in regards to the system security and possible access. check if you have network drives available the before you have issues.Having that said, if you have Security Audit rules set up sufficient enough, there should be some log entries that would point you to that - or any other possible root cause. Well - did you try to bypass network level authentication? Greg might be right and you don't have a valid Kerberos ticket from the DC at this point in time. If you need any further information please let me know and I will provided whatever is needed. Has anyone run into anything similar to this or have any ideas as to where to go from here? If the client isn't even sending packets to the term server, what is happening? Is the redirection just never reaching the client, does the client ignore it? I am at a loss here. If I click on the remote app again it connects successfully and I can see the transition in the packet capture from the connection broker over to the terminal server that was assigned. Again, I see the traffic to the connection broker, but nothing to any of the terminal servers. I then proceeded to fire up wireshark on the VM and capture all traffic while attempting to use remoteapp. I see the RDP traffic going to the connection broker, but nothing going to any of the actual terminal servers. During all of this I have a debug flow and packet capture occuring on the Fortigate firewall that handles the VPN connection. I check the event logs for TS and RemoteApp/Desktop on the connection broker and it states that the user (me) was successfully redirected to "one of four TS in the farm". If I immediately click on the app again, I successfully receive the remoteapp session very quickly. I go to the remote web access page and click on any of the programs and it will fail essentially saying that the computer isn't turned out or that it is being blocked by a firewall.
DOES FORTIGATE WORK WITH WINDOWS REMOTE DESKTOP CLIENT WINDOWS 10
To attempt to recreate the issues they experienced, I created a windows 10 pro vm, installed forticlient and connected to the VPN. Hello, I have a client that is utilizing RemoteApp for their employees to access numerous applications.
0 kommentar(er)
