RemoteApp fails due to "bogus" SSL Certificate after local network changes implemented

I recently had to replace my cable modem and firewall device and, as a result, changes were required to reestablish my local network connectivity.  With that behind me, RemoteApp applications which had been working correctly for months, are no longer working.  The .rdp file appears to start the process as always:RDP-credential-prompt.jpg
I have valid certificates, and even "re-keyed" them after my local network changes, for my Remote Gateway:Certificate---Valid-Remote-Gateway.jpg
and my Remote Host Session:Certificate---Valid-Host-Session.jpg
My problem is that after entering my credentials, the following Remote Gateway error is displayed:RDP-error-message.jpg
When I view the certificate, the following "bogus" certificate is displayed:Certificate---Bogus.jpgI have no idea why or where this certificate is even coming from.  As always, any help would be greatly appreciated!
Jim KlocksinOwner, Data ArchitectsAsked:
Who is Participating?
 
Jim KlocksinOwner, Data ArchitectsAuthor Commented:
I inadvertently discovered that this problem ONLY occurs when I'm attempting to connect via RDP from within my own network!  I was talking to a client on the phone, informed him of the problem, he tried to connect anyway and it worked fine!  Go figure...where I was convinced I had a problem, it turned out not to be a problem.  Thanks for your responses!
0
 
Cliff GaliherCommented:
USG is an alternate acronym used by several firewall/UTM for their unified security gateway products. Your replacement firewall is snagging port 443 instead of passing it on to your RDGateway. So look into your firewall configuration. Could be web server protection. Or could be remote management is enabled for public access and it uses 443. Those are common misconfigirarions I see.
0
 
tmoore1962Commented:
You will probably have to define rules in the new firewall to pass the port 443 to your RDP server depending on the firewall  you may also have to define the RDP access rule also.
0
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

 
Jim KlocksinOwner, Data ArchitectsAuthor Commented:
Right now, I don't have the new firewall yet (may be coming tomorrow...) and the only firewall I have on my server is the Windows Firewall where I have port 443 set up under my incoming connections.  Other than that, I have the XFINITY cable modem that they installed to get me back up on the Internet and the only options that I can see on that are to "block" ports 80 and 443 (which I obviously didn't check off) and, right now, I have the XFINITY cable modem router set to DISABLE FIREWALL.  I'm getting a Zoom cable modem router to replace the XFINITY, but that hasn't gotten here yet either.  The only conclusion I can come to is that, despite my settings, the XFINITY modem router is putting out that "bogus" certificate, but I don't see any way I can change that (I've already disabled it's firewall capabilities if I can believe what It's telling me!?).....Bottom line, I'm still getting the same error with the same USG certificate!
0
 
Cliff GaliherCommented:
That's a fair guess. I assume the cable modem is also handling NAT duties, and you usually need to add rules to properly NAT inbound traffic, nut just disable blocking them.
0
 
Jim KlocksinOwner, Data ArchitectsAuthor Commented:
Yes, you're right.  Since I prefer static IP addresses (small network), I had to change the default IP that came with the cable modem and the only real issue there was that I had been using 192.168.7.55 as my Gateway IP, XFINITY forced me to change that to 192.168.7.1 AND, in order to get my network connecting correctly, I had to turn off IPV6 on all of my computers.
0
 
Jim KlocksinOwner, Data ArchitectsAuthor Commented:
In this case, since, previously, I was always able to connect to my own network via RDP FROM my own network, I just assumed that I had a problem with this functionality.  Since I can't test this without contacting a client and have them test it, I was convinced that the problem would affect everyone, but, in the end, it turned out that I NEED to have an actual client test this before I make any assumptions!
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.