How to establish remote access to onboard systems

At times, it becomes necessary to request shore-side support when troubleshooting onboard systems. Such requests can be initiated through various means, including phone calls, emails, WhatsApp texts, TeamViewer, or other applicable channels.

Today, I aim to look at the installation process of a router intended to function as a link between one of the onboard systems, specifically the exhaust gas treatment system manufactured by Xeamos, and the shore-side support.

The role of this router entails establishing connectivity between the PLC of the exhaust gas treatment system and a cloud-based platform. This setup facilitates technician access to the onboard PLC via the cloud, consequently enabling remote inspection, troubleshooting, firmware updates, and control logic modifications for the exhaust gas treatment system.

Upon my arrival onboard the yacht, there was a router already in place which was not working well. Initial problem with the old router was traffic getting blocked by the firewall which was easily resolved by verifying the router was trying to access legit sites and allowing it to do so by modifying firewall rules.

Other problem was router dropping connection even though ship’s Internet connection was stable. Upon reporting these issues to the supplier, it was acknowledged as a known problem with the router, prompting the dispatch of a replacement from a different brand.

Moving forward to the installation process, after physically mounting the new router in place of the old one and connecting the 24VDC power supply, the next steps involved the connection of two Ethernet cables.

One cable established a link between the router and the network switch, located within the same cabinet, which served as an interface between the router's LAN port and the exhaust gas treatment system's PLC.

The second Ethernet cable connected the router's WAN port to one of the ship's Ethernet sockets, which would serve as an Internet access. Wired Ethernet connection was necessary because this router had no possibility to connect to WAN wirelessly.

Unlike wireless devices that seamlessly join our network, all Ethernet-connected devices require explicit authorization. To authorize the router, it was necessary to assign it to the appropriate VLAN, configure its IP address, and optionally provide a device description, a practice I find beneficial for easy device identification. This authorization process was seamlessly executed within our network management tool, Jetselect.

I opted for a static IP address over a dynamic one because I anticipated firewall-related issues, identical to those encountered with the previous router. The use of static IP addresses streamlines device identification and facilitates troubleshooting of potential firewall restrictions.

Upon completing the router's authorization, including assigning a description and enabling network access, I successfully pinged the router from my office PC. Note that my office PC is in different VLAN but I was able to ping the router because of the access rule that allowed the traffic from office PC's VLAN to router's VLAN.

According to the supplier that sent us the router, all that was necessary was allowing the router to the Internet and it would find its way to the cloud-based platform, which would then be accessible to the shore side technician.

Since I did all that was necessary from our side, I went to check the LED indications of the router to see if the router is connected to the Internet and WAN LED was not lit, indicating Internet connection was not established.

I immediately suspected firewall is denying it traffic, just like it did to the previous router.

But hey, while I am here in the engine room already, I could try power cycling the router, maybe it still wasn't assigned the address and got authorized. Lo and behold, in a matter of seconds, router powered up and WAN LED lit up. Beautiful!

Quick call with the shore side technician confirmed he has access to our exhaust gas treatment plant and he can proceed with the inspection and troubleshooting.

By the way, it had me wondering why the firewall wasn’t blocking this router's traffic and then I realized it is connecting to a different cloud platform than the old one, which our firewall sees as legit.

From the cyber security perspective, we want absolute control over the remote sessions taking place. In this instance, this can be achieved fairly simply by keeping the Ethernet cable between the router and the ship's network disconnected and connecting it only during the times of the arranged remote sessions with the shore support.