NetLinx Processor Remote Connection

kousios

Generally we prefer visiting a site to investigate a customer's reported problem, but there are many cases in which these problems could easily be solved from the office. This is why we are trying to establish remote processor connections in all of our projects. We use port forwarding to accomplish this and to be more specific we are forwarding: port 1319 to port 1319 (ICSP), port 10180 to port 80 (HTTP) and port 10123 to port 23 (Telnet). Port 1319 works great when we try to connect to the processor remotely using NetLinx Studio and port 10180 works just as well when we are remotely connecting to the processor's web interface. On the other hand, when we are remotely connected to the processor in NetLinx Studio and we are trying to create a telnet session using port 10123 we get a terminal but with no command line, just a black window..

Does anyone have any suggestions on what we might be doing wrong here??

Also, most of these customer reported problems might not even be actual problems. They would, most of the time, be a rather misinterpreted system's behavior that was rightfully exhibited according to the customer's actions. However, to prove this we have to be able to access the processor's log file which should contain a lot of useful information.

Are you aware of the existence of such a file? If such a file exists how do we access it? If there isn't such a file could someone help me to create one?

Thank you guys

ericmedley

You might consider another method of remote access that will facilitate much more flexibility: VPN. It's also a lot safer too. I've oft wondered if there are any evil AMX hackers out there sniffing around on public IPs for port 1319 open.

Plus any telnet port open to the public is subject to a plain old brute force attack. Granted the Netlinx controller does have a 'three strikes you're out' delay. But, this only slows the brute force attack down, not eliminate it.

A VPN can be setup with a much more sophisticated attack prevention scheme, can report attempts to hack in, basically puts your remote PC on their network with full access and encrypts the traffic back and forth.

DHawthorne

I've had hackers much around with an unsecured VNC port (basically, they were turning the guy's stereo and lights on and off my accessing his panel), but not 1319. You would need to be an AMX programmer to even know what to do with it. I did, once upon a time, hack into a rep's system during a conference, and he was not pleased at all when I showed him all the run-time errors. Next time I went there, it was secured .

What I would try, as a starting point, instead of mapping 10123 to 23, is to set the NetLinx itself to port 10123 on Telnet. If that works, the router isn't doing the NAT correctly. If it still doesn't go, I'd run a port scan to see if it's blocked. I've had some networks do soe really funky stuff when it comes to blocking ports. One in particular wouldn't let anything at all through, no matter how I set the outer, not even on the DMZ port. Then I found out he had two other routers running on the network; I still can't figure how it worked at all.