I have a small remote network using a RB960PGS as core router. There are several wireless clients and a bunch of IP cameras and remote solar system monitors on its LAN side.
Recently, one of the TYCON TPDIN remote voltmeters (original version) I use to monitor legacy solar systems that don’t have their own remote monitoring became inaccessible.
Using the various tools in the 960, I found that the static IP for the TPDIN has lost the first digit of the first octet of it’s IP address. Instead of 192.168.0.243, it is now 92.168.0.243.
My question is: is there any way to access this “new” address remotely since it falls outside of the 192.168.0.x range I am using? It doesn’t ping.
If I reboot the router and then check the log, I can see the router find the incorrect address during the reboot. It also shows up in Tools>>IP scan.
The network is 400 miles away and whatever I try must NOT break things with the 960.
I have a Raspberry Pi inside the network with VNC access for working on this.
Add a “secondary” IP address on that LAN interface / Bridge ?
To my knowledge you can have multiple IP’s
So put 92.168.0.254/24 as an additional IP on the Mikrotik/Bridge side ?
I had given some thought to something like this but need to be sure that whatever I do I doesn’t kill the rest of the network in the process. So, here I am asking for advice.
Following advice by @jvanhambelgium should not break anything …
Unless some addresses from the “fake” subnet are vital to operation of your remote site (e.g. your “home” IP address falls into that range and you’re trying to do the remote management from home) in which case things will fail (connections will get routed to LAN instead of WAN).
Okay, it’s gratifying to have this level of expertise.
I believe you are proposing that I add another entry to my IP>>Address category which currently looks like this (minus the #2 entry for the WAN side for security):
+++++++++++++++++++++++++++++++++++++
[admin@MikroTik] /ip address> print detail
Flags: X - disabled, I - invalid, D - dynamic
0 ;;; defconf
address=192.168.0.1/24 network=192.168.0.0 interface=ether2
actual-interface=bridge1
Should be OK to my knowledge. That additional IP would go under the same as the existing 192.168.0.1 interface indeed.
I’ve just tried it on my RB3011-LAN on the LAN/Bridge side, I’ve added an IP to my brdige.
[jvanham@GATEWAY] /ip/address> print detail
Flags: X - disabled, I - invalid, D - dynamic
0 address=172.29.45.254/24 network=172.29.45.0 interface=Bridge actual-interface=Bridge
5 address=72.29.45.254/24 network=72.29.45.0 interface=Bridge actual-interface=Bridge
The question then is : what are you going to do next…
You might have to make sure the prefix 92.168.0.x/24 get into your global routing ? Because you want to establish connection to this device to adapt is config ?
Can you do this through “telnet” or “ssh” so from the Mikrotik or do you need specific client-software to do this?
I have a spare TPDIN I had brought back from the remote site to upgrade firmware here with me, so to try things locally, I set it to 92.168.0.243, then added the above to the mAP I am using here. And was successfully able to access the TPDIN.
After proving that it didn’t take out anything (especially WAN access to the router), I plugged that rule into the remote 960. Was then able to reconfigure the remote TPDIN.
Now, I need to figure out what happened as this is not the first time. The very same thing occurred in August to a solar charge controller - the 192.168.0.x entries for IP, Gateway, and DNS 1 and 2 were all truncated to 92.168.0.x. I fixed that by connecting to the CC locally with a USB to RS-232 cable which does not care about IP’s.
Having this happen multiple times is weird. I will readily admit I didn’t have password protection on the TPDIN and didn’t disallow network setting changes on the charge controller. I have done that now.
The changes that were made are so consistent they almost seem automated…if someone found their way in to those devices and wanted to mess with me, I would have thought they would do something more drastic. Just changing the IP would have been enough. Why change the Gateway and DNS address as well?
One thing in common between the two devices - they are all running very basic Web servers to display settings and use SoC devices like the Microchip PIC18F97J60:
Edit: After posting this, I saw that problem was solved in the mean time… so you can ignore this.
If you are worried about breaking stuff on the RB960PGS and you have a Raspberry Pi in the LAN with the TYCON TPDIN, I would focus on the Raspberry Pi.
The spec sheets for the TYCON TPDIN only talk about Web and SNMP, no ssh or even telnet, adding a secondary address to the RB960PGS is going to be of limited value. Is this the device you are talking about? Edit: The first time I tried to download the userguide I got a dns failure, but after I downloaded the spec sheet, and after I posted this the first time, I was able to download the user guide and it does claim to support telnet.
If the Raspberry Pi has a static ip address, adding a secondary address should be straight forward. On the other hand, it the Raspberry Pi is getting its ip address via dhcp, then it will be more invoved. A quick google search for add secondary ip address linux on interface with dhcp client found this serverfault post Set up two IPs (one using DHCP and other static) over the same Interface
I am not sure how you determined the TYCON TPDIN had ip address 92.168.0.243. Dropping a leading decimal digit for the dotted decimal ip representation doesn’t have a nice binary explanation, i.e. it wasn’t a bit flip. How is the TYCON TPDIN obtaining its address? Is it a dhcp client, or is it statically set? If it is a dhcp client, and the lease time is relatively short, then can you verify that the dhcp server is giving it the correct ip address?
Do you know what the mac address of the TYCON TPDIN is?
Yep, it’s fixed, but I wouldn’t mind chasing some reasons WHY it happened if it’s OK with you.
The IP, Gateway, and DNS 1 and 2 addresses were all set manually in the Network page of the TPDIN Web interface years ago and haven’t been touched since then.
The link you found for it is the current Rev. 3 version - I have several of the “legacy” versions:
I determined the “changed” address by using WebFig and Tools>>IP Scan and looking in the system log after a reboot of the 960. Since this happened once before, I kinda knew what I might be looking for which helped.
I have had problems in the past due to incorrectly coded telemetry Web pages that didn’t deal properly with signed/unsigned ints before - similar to your “bit-flip” issue. But it doesn’t seem to apply here. Dropping the leading digit after all this time on two disparate devices is very strange.
Excellent info on adding a secondary IP to the rPI. Similar to multihoming, which I haven’t used for years. I’ll keep this info handy. It is useful beyond words to have a device like the Pi within the remote LAN that I can VNC into to fix stuff. “Just like being there”, as they say.
Hopefully you are not port forwarding to devices in the “inside” that are not security hardened. I would not consider many “SCADA” devices to be security hard in general. That’s why they are often on a highly protected dedicated network with a gatekeeper (firewall/gateway) to prevent unauthorized access.
Are you using vpn (or even something like zerotier on the Raspberry Pi) to provide remote access? Here’s an example on Tom Lawrence’s youtube channel where he is using a “portable raspberry pi 4” that he can use with a client for remote access to their network (for security scans). He’s using Kali, but you can load Zerotier on Raspberry Pi OS (aka Raspbian) as well. If you do a google search for raspberry pi zerotier you will find many tutorials. How To Access a Raspberry Pi Running Kali Linux Anywhere with ZeroTier
I am guilty of a few remaining port forwards that are leftovers from when i set things up in 2008 and was using consumer satellite Internet (Starband) as a backhaul. It was so slow that PF’s were the only mechanism that allowed remote access that didn’t time out.
Things are different now and with some computing power on the inside that can be used as a gateway, I have eliminated most of them. I will be inspired now to get rid of all PF’s.
I hadn’t heard of ZeroTier. I am currently using RealVNC to get inside to do network chores as it seems to be pretty secure. I’ll start research ZT. Do you have an opinion on one vs. the other?
ZT is pretty neat. Look at it like “a / your own switch in the cloud” . No “centralised” thing (eg. star-topology where you create VPN’s or full-mesh thing)
You can run your own ZT “node” on your (VM) infra if desired
Basically you “plug” (virtually) all your ZT-endpoints on “your own cloud switch” wherever they are in the world. Like this you could create some sort of '(management) LAN" for you to access globally.
All communications are encrypted off course.
Then make some IP-plan to go along with it and you are set with you own “network”
I wouldn’t use any VNC or RDP directly exposed to the internet myself. Perhaps RealVNC is safe, I just don’t know, as I always use a VPN or zerotier for remote access. Primarily I use RDP over VPN to do work related stuff from home.
The “problem” with zerotier is it is easy for someone to create unauthorized remote access with it, since it is the thing that “opens” the connection to the outside. If you watched the Tom Lawrence video, you can see that he didn’t open up the firewall or forward any ports to allow remote access. Same problem with any of the remote access tools like teamviewer, or many IoT devices that “phone home”. The point is, like discovery protocols, they can be very useful to a network admin, but equally useful to a malware infected pc. Standard stateful firewall rules blocking new connections from the outside do not protect against rogue devices establishing connections to outside and then allowing remote access back in. That’s the primary reason for putting IoT devices on their own vlan, at least it helps contain any remote access into the “inner walls”.
Convenience and security have different goals, and they usually don’t mix well. And remember that software vendors sell based on user convenience and features, and security is usually an after thought, and is seen as an annoyance by many users. If you enforce MFA you will know that users don’t consider it a userful feature, they just see it as something that wastes their time. Same with choosing good passwords, and not reusing them at multiple sites. And retrofitting security after the design is complete usually takes the back seat until it is too late.
How would that be easy ? I have a ZT network created, I need to manually ALLOW you to join that network through the admin-interface on my.zerotier.com
Sure if you create a “public” network all you need is the network-ID to join and you are connected.
I’ll need to read up some on the things you are bringing up. Especially my use of VNC.
While I completely understand that it is not a panacea, I have things that I need to administer inside the network all using non-standard ports, which helps some with the script kiddies. This includes RealVNC Server and all 'Tik equipment.
I think I can eliminate all PF’s, but I haven’t yet figured a way for this one:
I have several IP cameras that serve up still images on demand simultaneously to a single Web page. The cgi-bin command used to get the image from the cam is restricted to the user “viewer” that has no privileges except to view. This all works fine, except that anyone can find the IP addresses of the cameras with a few clicks in their browser.
I have found several examples of using VPN’s to access one camera at a time, but none (so far, still looking) for simultaneous multiple cams.
Well … are these camera’s located on different sites ? Or multiple camera’s on 1 location ? Or a combination ?
Do you have a consistent IP-numbering scheme or have you “overlap” complicating things when deploying VPN ?
Apart from that I don’t see the problem, you could have a VPN from X locations connecting to 1 Mikrotik centrally and from there you can access everything.
Much more detail is needed to assist you on such topology/design.
Probably still leaving out something you need to know. I claim no expertise here. My only experience with VPN’s was setting up a server on the remote 'Tik for admin purposes.
So these camera’s effectively serve screenshot by making a request to the camera itself OR do these device perform some FTP “upload” every X time for a still picture?
Can you talk about the “entrypoint” in terms of Internet. You speak about an “external website” (do you host that yourself, is this “Internet” available on that same location)
An RPi could easily be used as a VPN-gateway indeed.
These integration can become quite complex and without visual representation its always a bit guessing.
For security I would make sure that if this webserver is compromised that there is no entrypoint further into the infrastructure. That could be accomplished by pushing screenshot/stills OUT onto some share space where the webserver can pick them up, without the possibility to enter in the opposite direction. (“diode” , sort of 1-way)
If you’re going to run rPi in the cam LAN, then you can run a decent reverse proxy on it as well (e.g. haproxy) … which will hide individual web cams behind distinct path parts of URL …