Are your VSA and your Manage server on the same network?
From the perspective of the Manage server, what does the hostname that you are using in the "Management IT Solution" setup table in Manage for the VSA server? (In the "Override Webservice location box").
In my case at least I'm not using the same hostname as what we "normally" use to access the VSA in this box. I'm also *not* using https. Assuming they are on the same network I would try changing it to http rather than http, and try plugging in the internal IP rather than a hostname. I'm thinking two things here.
My thoughts here are two-fold.
1.) Like I say on ours I don't have it using https, and it works.
2.) If you are using the same hostname as your "normal" access to the VSA, and it resolves to the public IP, then the access rules only allowing access from your internal IP of your manage server may actually be blocking you.
We are on the same internal network. I have it setup with the external domain name, which resolves internally due to the DNS Zone we have.
I've tried disabling HTTPS, having the URL be HTTPS / HTTP with the host name, with the IP address to the same result. On a PC that isn't allowed to access it, I do get an Access Denied instead of the "oops" page so I know at least the restrictions are working properly.
I've had ConnectWise on the system multiple times and they are scratching their heads at it as well. I sort of dislike that you can't browse to the URL any longer as it creates an issue with testing to verify the website is actually working.
Thanks for the assistance, I'll see what ConnectWise comes back with.
The fact that your log shows it getting redirected to the error page pretty well indicates it's still getting *some* kind of error in their code the same as it does when you try to browse to it in a browser.
Out of curiosity... Where is your key.json file... In c:\program files\Connectwise, or in c:\program files\Connectwise\KaseyaCWWebService?
Also if you are "ok" with SQL. Take a quick look at the CW manage database. In the cwwebapp_<yourcompanyname> database, in the Mgmt_It_Setup table, there will be a record that you should relatively easily be able to identify as the one for your Kaseya server. One of the columns will be a column named Kaseya_Key. Check that value against the "Key" value in the key.json file on the VSA server. They *should* match. You can't really do much to verify the RSA keys at this point, but that's the only other thing I can think of off the top of my head.
Also one other thing you can do to try and help debug it yourself.... In IIS on the VSA server, Browse specifically to the KaseyaCWWebService Application directory in the listing. Click on it and then in the "Features" pane double click on .Net Error Pages in the top section.
Then Click Edit Feature Settings in the action pane (or right click and select Edit Feature settings if the action pane is turned off for some reason.)
This will bring up the Edit Error Pages Settings. From there you can change the mode to "Off", and check the checkbox for "Allow Nested Errors". Then try browsing to the page in your browser. Now you'll see the *actual* underlying ASP.net errors rather than being redirected to the generic page.
Make sure to set that back to "On" once you are done with your testing. Generally speaking when you try from a browser, you'll end up seeing something about "unauthorized" due to the fact that you aren't sending the correct auth info from the keys. There's another way you can simulate that info as well, but we'll save that for another discussion (maybe offline).
The key.json is the "C:\Program Files\ConnectWise" directory
This key matches the "Kaseya Key" present inside of the SQL Table matches to the key.json in the above directory
When making the changes requested inside of IIS and then loading the page, I get 'Bad Request', this is using the following URL:
If instead I use this URL:
It results in the following, with a longer stack trace.
Server Error in '/KaseyaCwWebservice' Application.
Attempted to perform an unauthorized operation.
I think as it shows unauthorized, it is loading correctly, but somehow ConnectWise is not able to pull the information or passing the key.
Hmmm with that I wonder what happens if you put http://<ip of vsa>:18081/... .In the CW setup table...
Otherwise, there isn't much else I can think of to help at this point.
Unfortunately we get similar:
System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond
It looks as though the direct IP or CNAME is working fine, but it's just unable to determine the version of the Kaseya Server. I've just updated this morning to the .20 patch release with a sliver of hope that it would make a different but still the same.
I do appreciate all the help. It was much more thorough than what CW has assisted with thus far.
As an update, I finally got a response from ConnectWise and was able to resolve the issue. Inside of the web.config, the physical path had to be altered. I had previously done this (numerous times actually) along with their Support, but leaving off the 'KaseyaCwWebService' in the path allowed it to finally detect and work properly:
Incorrect: <add key="KaseyaWebPagesPath" value="C:\Program Files\ConnectWise\KaseyaCwWebService" />
Correct: <add key="KaseyaWebPagesPath" value="C:\Program Files\ConnectWise\" />
Now to fix the flood of new assets.
'K. That actually makes sense. At the end of the day, it's using that key to tell it where to find the json key file with the private key.... For reference I also found a fully unsupported way to do a better test using Postman, but it involves running wireshark on the CW Manage server, looking for the traffic going to your VSA from it on the HTTP port, and then running the test to grab the authentication headers :).