On the other side of the US I have a Fiber connection connected to a MikroTik as router/firewall, feeding a Linux PC and a NAS. My normal workflow is the MikroTik has a Wireguard server and I VPN in and then administer everything (incl. updating and reconfiguring the MikroTik) via the local LAN.
But the Fiber in that area goes down somewhat often, and while all that above is on a UPS, the power sometimes goes down in the Summertime due to thunderstorms. I bought the Comet 5G so that if the Fiber goes down or the power is off or if I end up bootlooping the PC or misconfiguring the MikroTik I can still get into the PC and shut down/reconfigure/etc. the setup.
The thing is, I have 5 more static (global) IPs available on that Fiber setup, and I’d prefer to connect the Comet directly to the Internet using one of the static IPs so that even if the MikroTik is down I can get into the PC then get it going again- but of course that can be problematic.
I just saw there were some CVEs on the Comet series, and the only one that I consider an issue (no limit on repeated login attempts) has already been fixed in the FW release I’m on (v1.9.1).
What’s the underlying security protocol(s) on the Comet and GLKVM? Are they considered secure enough to leave the device exposed to the general Internet? I have a strong password and 2FA turned on, too. I figure that since it’s got a 5G radio built in for failover (which can get incoming connections too, depending on the provider and plan) that implies there’s some sort of built-in firewalling and/or highly-secure security (my MikroTik has a Wireguard server connected directly to the internet, for example, and I sleep well at night knowing that is proven secure).
$ sudo nmap -A 192.168.126.49
Starting Nmap 7.98 ( https://nmap.org ) at 2026-06-28 13:18 -0700
Nmap scan report for 192.168.126.49
Host is up (0.0040s latency).
Not shown: 997 closed tcp ports (reset)
PORT STATE SERVICE VERSION
22/tcp open ssh Dropbear sshd 2025.89 (protocol 2.0)
80/tcp open http nginx 1.26.2
|\_http-title: Did not follow redirect to https://192.168.126.49/
|\_http-server-header: nginx/1.26.2
443/tcp open ssl/http nginx 1.26.2
|\_http-server-header: nginx/1.26.2
|\_http-title: GLKVM
|\_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: commonName=localhost/organizationName=GLKVM/countryName=US
| Not valid before: 1970-01-01T00:00:12
|\_Not valid after: 1979-12-30T00:00:12
MAC Address: 94:83:C4:XX:YY:ZZ (GL Technologies (Hong Kong) Limited)
Device type: general purpose|router
Running: Linux 4.X|5.X, MikroTik RouterOS 7.X
OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 cpe:/o:mikrotik:routeros:7 cpe:/o:linux:linux_kernel:5.6.3
OS details: Linux 4.15 - 5.19, OpenWrt 21.02 (Linux 5.4), MikroTik RouterOS 7.2 - 7.5 (Linux 5.6.3)
Network Distance: 1 hop
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
TRACEROUTE
HOP RTT ADDRESS
1 3.99 ms 192.168.126.49
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 16.06 seconds
... and for more information on the potential attack surface, the Comet would be attached to a headless Linux box that would have only a text window VT for logins (and a session with auto-logout). While it would be technically possible if breached to brute-force that login given enough time, eventually I'd get repeated-login E-mails sent to me and could shut the Comet down.
But I'm really looking forward to hearing GLi's input on this.
I can access my Comet at home that's connected via a router (and I don't have UPnP enabled on my MikroTiks) from anywhere from a web page (via glkvm.com) ; maybe one of those three protocols is baked into the glkvm.com protocols?
Well, the good thing is they won't have access to my local network via the Comet should it be breached, as it'll be on the "Public" side (same as the MikroTik) of the internet and will have no connection to my local network (via IP)
Eh, I develop Linux kernels that get put in embedded devices for a living, some of which are directly connected to the Internet ... that's not really that big a deal.
There's been a number of AI-discovered fixes that have been patched in recent weeks (i.e., the AF_ALG exploit that gets you root), but the good thing is most of them require some sort of shell access (i.e., the only thing you can do otherwise is DoS). That being said, I trust someone at GLi is looking for Vulns and applying patches (which won't update the kernel version).
It's about to be Monday morning in Shenzhen (et al.); waiting with bated breath for the GLi guys to chime in ....
This is excellent news! But just so I'm clear- you're saying that the product was designed with the probability that it may be connected to the general internet (if not entirely encouraged)?
I’ve just double-checked, and the documentation indeed lacks detailed information regarding the modem's firewall; the setup is quite simple—you just need to add specific IP ranges or individual IPs to the whitelist. There are no specific settings required for the Ethernet connection, as your KVM device receives a LAN IP from the router rather than a public IP, so this issue does not arise.
... as your KVM device receives a LAN IP from the router rather than a public IP, so this issue does not arise.
But you understand that I actually DO want to put the Comet 5G on the unfiltered Internet, as I want to be able to access my devices should a bad router reconfiguration (my MikroTik isn't like some consumer TP-Link or the like, it's more like a Cisco Enterprise device and a bad entry can make the LAN unreachable/unusable).
... which leads me to my original question- what security protocols do the Comets use, and what kind of exposure am I doing by putting it directly on the Internet?
We've established that I can get to the Comet 5G from the Web interface even when it's NATed under a router, and yesterday I popped a SIM into the Comet5G, disconnected it from the LAN and was able to see it as well via the Web interface.
So depending on what the Comet5G uses to determine failover (i.e, "lack of link" vs. "unable to ping known IPs" (and I suspect the latter)) then I should be able to connect the Comet 5G to the LAN side of my MikroTik, and should the Fiber or the MikroTik go down (and lose connectivity) then the Comet 5G will hopefully use the SIM connection to allow the device to be reached, so I should be covered in any case.
i'll be deploying the Comet 5G in the next month to the remote site; of course as this kind of thing goes, once I put it out there the Fiber will never go down again (I bought a generator for my place at home after a number of half-day power outages and it hasn't happened since )
If it doesnt then its a moot point to be worrying about the firewall on the 5g side.
This isn't my real concern at all, though. To recap, I want to connect the Ethernet on the Comet 5G to the output of the Fiber ONT and give it one of my remaining (and routable) static IP addresses on the actual internet. It's the firewall and/or the security protocols on the Ethernet port I'm really wondering about, as despite my realization above about having it on the LAN the most-failsafe method is having a Public IP on the Ethernet side- and that's what I'd like an answer from GL-i about.
(The current SIM in there is most definitely CG-NAT, FWIW)
I wouldn't really recommend doing this; if your device obtains a public IP address via Ethernet, it will be exposed to the risk of automated scanning and probing. Since the device uses HTTPS/TLS for web management and WebRTC for audio, video, and control streams, these ports are easily detected by automated scanning scripts. Of course, you can protect the device against brute-force attacks by setting a strong password and enabling 2FA. However, I must point out that if the device harbors any undiscovered security vulnerabilities, deploying it on the public internet poses a significant risk. If you do have a genuine need for this setup, you should configure the firewall via iptables in the device's backend to mitigate these risks.
If you do have a genuine need for this setup, you should configure the firewall via iptables in the device's backend to mitigate these risks
OK, understood ... what IP ranges (and ports) will glkvm.com be using? That's how I'll be accessing the Comet when I'm away from it. Or does glkvm.com simply bridge access, and the incoming IP is the IP of the browser I'm using to get in?
Your "not recommended" hasn't fallen on deaf ears, BTW; if direct connection wasn't an expected use-case during design and implementation then I'll defer setting the Comet up that way.
(I bought a generator for my place at home after a number of half-day power outages and it hasn't happened since 
)