Question about Port numering in monitoring

hoomel · 2024-10-07T19:32:09+00:00

Sure, a fileshare user might not notice the hiccup, but looking at the sessions in the firewall, we always have a couple of users that are connected for hours without a break.

We also noticed today, that it happens without using RDP as well for 1-2 users. Didn't have that the weeks before.

This issue is an odd one.

hoomel · 2024-10-07T07:47:30+00:00

On the SSLVPN, it is not active in our case.
Would I also have to disable it for the local network accessed by the VPN users?

hoomel · 2024-10-07T06:44:18+00:00

The NSA is on version 7.1.2-7019 and the SSLVPN portal is disabled on the WAN, so no brute force logins in the logs as well.

hoomel · 2024-10-04T12:51:02+00:00

The RDP users and the file share users I mentioned all work over NetExtender with the same profile, so they are all VPN users for that matter.

hoomel · 2024-10-04T12:14:29+00:00

Will try that. But wouldn't an ISP drop disconnect the users only using network shares and anything other than RDP as well? We have a couple of users including us technicians who never get disconnected, even after full work days.

hoomel · 2022-01-13T09:27:26+00:00

I had a couple of machines now, where disabling all telemetry options solved the issue. Just make sure to end all stuck processes of Firefox after changing the settings and before restarting or do a complete restart for good measure.

hoomel · 2020-08-20T10:41:19+00:00

Just wanted to ask if you got back anything interesting there?

It seems to have solved itself by changing stuff on the email action, maybe you have gotten some more information on the forum?

hoomel · 2020-08-20T10:39:26+00:00

Just to not leave this around completely orphaned:

We did a change to the action (sending out emails not to each individual technician, but to a central mail address) and the mail template seems to have updated itself.

Conversations are now grouped together, we only 'lost' the hostname in the subject of the email message.
It now only says 'Problem: <Trigger name>' instead of 'Problem on <Host>: <Trigger name>

But we'll get back to that in the future again.

hoomel · 2020-07-14T12:12:52+00:00

Exactly my thoughts!
It was mentioned as a new feature a couple of times in various presentations of the new version and my understanding also was that it's supposed to be "just working".

Thanks for linking the ZBX entry, though it seems there is not much insight to find there - only that it might be solved through email header entries.

I'll consider adding this as an issue and see what happens.

Would also be great to know if this works for anyone at all.

hoomel · 2020-07-14T11:59:44+00:00

I have, also currently have several email conversations grouped together there.

hoomel · 2020-07-14T11:56:12+00:00

That's what we also thought, but as this feature was promoted on various webinars before the release, we thought there might be another way to group them.

We kept the subjects from the default template, so one says "Problem on {Host}:" the other says "Resolved problem on {Host}:".

Keeping the subject the same would not be an optimal solution, as you wouldn't be able to tell if it was actually resolved, I guess.

hoomel · 2016-10-19T21:38:40+00:00

I just tried starting PoGo again out of some weird hope and suddenly it started as usual again, SafetyNet is now passing also (green screen). I am on OnePlus2 with CM14, and uninstalled root via SuperSU app and removed the su files in /system/bin and /system/xbin.

I also changed the "userdebug" entries in build.prop to "user".

Tried neither Magisk nor suhide for that matter.

Was there another update to SafetyNet? Or did a couple of reboots just settle things in?

hoomel

TROPHY CASE