My IT service provider is a Kaseya user. They want to deploy KNM into our network and asked me to allow a bidirectional rule on the firewall for TCP 4242. This rule is in play and they asked me for the public IP for our MPLS network firewall. I sent them this IP and they say they cannot telnet to that IP on port 4242.
4242 as I understand is open bidirectionally to their KServer only. I can telnet out to their KServer on 4242 but they tell me they cannot telnet inbound to our FW public IP on 4242.
Surely they should not point \ scan the public facing IP of the FW as essentially no networks exist in that range...the public facing IP of the MPLS firewall is a public IP that the FW NATs traffic through to our internal private ranges of which there are many in the 10.200.x.x range.
What should they point their KNM monitor at?
Is it not a better idea to deploy an agent inside the MPLS to scan the internal ranges and report the discovery data back to their cloud based KServer?
Thanks in advance...
They must be using the older version of KNM (stand alone). You only need TCP Port 4242 outbound from whatever server that you are allowing them to install their "Gateway" on. They are incorrect if they are telling you that you need 4242 open inbound on your firewall.
The Gateway reports OUTBOUND to their server so as long as you are opening TCP 4242 outbound to their external IP then it should be working.
Ross, our MPLS firewall is a Fortinet device and is managed by our ISP. Our MPLS stretches a huge geographic area across Southern Africa. At this early stage we want to monitor bandwidth usage as well as all of our MPLS routers and thus site locations uptime \ downtime.
Tim, I suspect you are right about KNM (stand alone) I've seen that somewhere? As I mentioned I can now successfully telnet outbond to the server IP they provided...but I am unaware they have deployed anything internally other than Kaseya agents on our Servers...that system works a treat...
I need to ask them about this 'gateway server' because pointing their server from the outside of our network at our firewall seems pointless to me? It makes more sense as you describe to have an internal gateway server scaning, monitoring and reporting outbound to the Kaseya platform exactly as the agent software does on the server infrastructure...!?
Currently this is what we see...
1. (it is either a misconfiguration on their gateway.cfg file or the firewall outbound) Ask them to regenerate the CFG file for the gateway, copy it to the server, and restart the KNM service along with validating on the firewall that TCP4242 is open the same as the agents on TCP5721.
2. They could update their Kaseya server to move to the KNMi (Integrated) version and thus use the same port as the agents use for their communication :)