Whether as a warning for the next guy, or a good laugh, here's a small adventure I had today:
I was running a localhosted version of node-red using Yarn, with some generic flows previously deployed to clients. I was also on our developer VPN, through which we can connect to clients' network gateways, small Linux boxes on which we run node-red, to talk to various PLCs on individual LANs. My localhost node-red was for trying to connect to a modbus server on Gateway A.
My manager was trying to connect through Gateway B to reprogram a PLC, and while said PLC existed on that LAN and was pingable from the network gateway, all attempts at connection through GXWorks3 (PLC programming software) failed.
It wasn't until further investigation revealed that for some reason, my localhost node-red, which hadn't even successfully talked to Gateway A, was chatting nonsense to Gateway B and effectively DDOSing it.
Is there a specific setting we should enable to avoid this in future? Or are some flows just likely to spam the network? Strangely, these same flows have no issues when deployed onto all our network gateways, only when running off localhost on my work PC.
@TotallyInformation the idea was to test connection between 2x node-red servers, one of which was a newly-deployed production device (Gateway A) and the other, well, a harmless local server on my PC. We could have isolated them on a VPN, but didn't think node-red would flood the network.
@Colin only addresses it was explicitly trying to reach were
10.91.1.166:10502,
192.168.127.254:502,
192.168.127.4:502,
192.168.127.6:502,
10.91.1.190:5562, (Modbus Read "testbench", IP of Gateway B)
192.168.127.10:502
but I believe most of those were unused. Gateway B's address was 10.91.1.190, but we had no issues connecting to that, only to a PLC that was hidden behind that, and (I believe) on a different port, which node-red shouldn't be able to access.
I'll try and post the flows and log in the next posts.
That harmless little testbench modbus reader pile of nodes was actually trying to communicate on the same port that our programming software used. The issue arose because the network Gateway B was previously sitting on a testbench in the office where I connected to it, and we kept the same connection credentials on it after deployment.
And, though it was firmly tongue-in-cheek, as an Enterprise Architect, I stand by my previous statement. If only due to the very real Murphy's Law, if it could go wrong, it most certainly will. In our environments, doing experiments with live networks and services would not be allowed.
Not criticising, we've all been there and done it. And have the scars to prove it!
Surely a recipe for disaster.