Is there an easy way (via Terminal?) to test the connection to a UMS server? I’m trying to figure out why I can reach the UMS server from a new device via the servers themselves, but not the VIP.
They are a few ways:
1. ums_available
2. probeport igelrmserver 30001 and 8443
3. nc same syntax like on probeport
Damn, probeport is successful, which makes no sense. When I go to UMS Registration, I can’t authenticate using the VIP.
If I use the individual UMS servers, it’s fine
Any ideas on that one? If I scan for the device in UMS, I do find it.
Deleted
@member you find this also in the system tab 😇
Yeah, that’s the exact tool I’m trying to use
Oh, then they changed it completely on newer firmwares… I never retried it since months, thanks! @member forget my py file. Wasn’t expecting that it is the same tool.
I’m going to see if there’s a log of the connection attempt somewhere on the device
Failed to receive data from UMS server, Failed to get command data from server, and Local command show_message failed with return value=-1
you could check the catalina Logs %ProgramDir%IGELRemoteManagerrmguiserverlogs
are they Firewall or Antivirus inbetween?
So with VIP you mean a LB-IP?
Our VIP is actually setup in our NetScaler
And behind are two IPs for two UMS server?
yep
@member did you followed a specific Howto like this one? igelcommunity.slack.com/archives/C8FC01UNM/p1525703526000735
Yep, that’s the one. Was just about to post the link
FWIW, this only seems to be an issue, at least initially, with registering devices using the VIP. I can connect to the UMS console using the VIP just fine.
Does the NS show something when you let run the cat log?
Not sure what you mean?
Would port 30005 also be used here? If I probeport that, it does fail.
The cat aaaa.debug – but that’s more regarding Auth.
What came to my mind is that I once had an error because the firewall did open the SSL cert to inspect and because of that registering failed. Implementing an exception made it work.
Would that help?
30005 is from UMS to the endpoints.
I’m not a NetScaler guy, unfortunately. If I have him cat aaaa.debug, you’re saying he could possibly see an issue in there from these connection attempts?
Yeah, that’s why I asked for FW or AV: kb.igel.com/endpointmgmt-6.02/en/device-registration-behind-sonicwall-firewall-fails-22462176.html
Or AV, which might make a SSL Certificate Check
On the UMS servers, we’re running McAfee.
All of the necessary firewall ports should be open, though
But if any system will check our cert- registration will fail because UMS will recognize that.
I’m relaying this to my NS guy right now
The aaaa.debug didn’t show anything while attempting to connect to the VIP
If I run netstat on the UMS server this device is hitting, I do show a SYN_RECEIVED. It basically ends there, though.
My NS guy was running a trace on the device, and all traffic appeared to be going through. So it sounds like the issue is from the UMS server this hits back to the client somehow. He says the NS config is exactly the way it is in that guide, so the client IP should be used
And what about a cert inspection?
What‘s about the catalina logs posted before?
Where would the cert inspection be done? I’m going to check the catalina log right now
The last entry for the catalina log is from an hour ago: 2020-02-17T09:58:12,003 ERROR [https-jsse-nio-8443-exec-5] Http11NioProtocol: Error reading request, ignored
I’ve tried connecting since then
If I run ProcMon on the UMS server while connecting via the VIP, all I see for this device is a TCP Disconnect. If I use the UMS server, I see TCP Accept, followed by Sends and Receives.
Can‘t help that much tbh. Would recommend to open a ticket. I don‘t have the environment to reproduce it.
From the customer I had with that problems it was on the firewall – actually it was a SonicWall as described in the KB article.
We run Checkpoint, and I’ve verified that we don’t do anything mentioned within that KB. I swear I was able to connect to the individual UMS yesterday, but today I can’t connect to either of the UMS servers or the VIP. Do ports change if you’re in the HA Load Balancing config? I’m trying to connect via 30001 in the UMS Registration tool, but failing. I swear I’ve read that 30002 is used when you are in a LB pair.
Incidentally, in the UMS console when logged in with an AD account, I don’t have the option of scanning for devices. I only see that option if I’m logged in with the local account used to create the DB. I have no idea if this is related to 6.04.100, though.
In the log, when connecting to the UMS servers directly, I see: _igelrm_agent[10156]: ** ERROR: igel_ssl_check_certificate: Certificate doesn’t verify: reason = 18: error: 00000012:lib(0):func(0):reason(18)_ and it fails immediately.
Don’t see that when I attempt to connect to the VIP, and it takes a few minutes to fail.
So there are different ports when using HA kb.igel.com/endpointmgmt-6.04/en/ums-communication-ports-26035034.html
If the UMS Server and Load Balancer are installed on the same servers, does that actually change anything from the client perspective? I’m trying to connect to 30001 in UMS Registration, which appears to be correct according to the document.
Continue reading and comment on the thread ‘Is there an easy way (via Terminal?) to test the connection to a IGEL UMS server? ‘. Not a member? Join Here!
Learn more, search the IGEL Knowledge Base
Ask a question or comment on the above message thread?
Join or log in to the IGEL Community to ask us anything and meet other IGEL customers, partners, and EUC enthusiasts.Submit a question, or Join Today!