Can you force RSLinx to use PCCC?

I'm an IT guy trying to help out our process engineers.

Do anyone know a way to force the RSLinx Ethernet driver to use PCCC Encapsulation (TCP 44818) . I've seen the :v4 syntax to force CSPv4.

I have no CSPv4 devices. The 6 packet CSPv4 legacy check (SYN,RESET,SYN,RESET,SYN,RESET) is getting through my SSL VPN but RSLinx is not functioning as expected. I'm thinking that the SSL proxy is providing a SYN-ACK back to RSLinx and RSLinx thinks it has established a CSPv4 connection, so RSLinx never cuts over to port 44818, which is the port that my 1756 device wants to talk on. If RSLinx remembers a prior connection on 44818, it will work through the SSLVPN. This works for our engineers, but not for vendors that haven't been on site before.

You need to know if your customer is looking to do any type of I/O messaging. This would be a big stopper for the Micrologix 1100

You may also want to look at an article I wrote on the Micrologix 1100 that notes the 4 expansion module limitation along with some other things
http://www.twcontrols.com/index.php?option=com_content&task=view&id=20&Itemid=38

I've seen that before

There is no method to force the RSLinx "Ethernet Devices" driver to use EtherNet/IP on port 44818 like there is to limit it to CSPv4 on Port 2222. The RSLinx "Ethernet Devices" driver has to get three "Port Closed" responses (that's the SYN/RESET pair) from it's connection attempts on Port 2222 before it will switch to Port 44818 and EtherNet/IP.

This is a common VPN problem. The VPN's I have seen actually are blocking the SYN/RESET replies rather than providing ACK's by proxy. A traffic sniff will tell you for sure.

Some VPN's will allow through the broadcast message that the "EtherNet/IP" driver in RSLinx uses to discover EtherNet/IP devices on a subnet. You can designate the subnet by selecting the "remote network" option when creating an EtherNet/IP driver instance.

You might also try the "Remote Devices via RSLinx Gateway" driver. That used to be used to connect to 1756-ENET modules, way back when, by treating them like RSLinx Gateway machines. You will have to create a driver instance for each controller, but it might work through your VPN.

By the way, your explanation and troubleshooting on the issue are really good; I usually get "it doesn't work, how come? " with regard to VPN connections.

Can you tell us the brand and implementation style (appliance, server, client s/w?) of your VPN ?

TWControls said:

You need to know if your customer is looking to do any type of I/O messaging. This would be a big stopper for the Micrologix 1100

You may also want to look at an article I wrote on the Micrologix 1100 that notes the 4 expansion module limitation along with some other things
http://www.twcontrols.com/index.php?option=com_content&task=view&id=20&Itemid=38

Click to expand...

I'm sorry about this post. I have no idea how I ended up putting it here. It was suppose to be under this thread
http://www.plctalk.net/qanda/showthread.php?t=27665

It works!!!

Ken thanks for your quick reply. I've seen your name come up quite a bit in my past research of RSLinx access through VPN. You have provided some great information and a very helpful starting point for my own troubleshooting.

I was able to get RSLinx to work with the "Remote Devices via RSLinx Gateway" using the port forwarding capabilities of my SSL VPN appliance. You da' man!!! I saw you recommend this to someone else but I was unsure of the parameters, "Server name" and "Remote driver name" in the driver but I have since found out that you don't need them for a PLC connection. You just need to specify the "Server IP address of hostname" as the PLC's IP address. As a side note, I did not see the "Remote Devices via RSLinx Gateway" driver ever talk on port 2222.

You mentioned sniffing the traffic. I had already done that in my troubleshooting and sniffed both a direct connection and a SSL VPN connection. Sniffing the direct connection showed me the three "Port Closed" responses and then the switch to port 44818.

On a VPN connection, I sniffed the connection between the SSL VPN and the PLC. I also saw the three "Port Closed" responses but the Port 2222 RESETs just kept coming back from the PLC. Sniffing the connection between the SSL VPN client and the RSLinx application is a little more tricky because they don't actually talk to each other through the network card. It is more like a shim in the TCP/IP stack of the client PC. When you sniff the network card, all you see is SSL traffic on port 443.

I haven't dug deep enough into the product, or my own toolkit, to determine if I have diagnostic sniffing capabilities between the application and SSL client. That is why I guessed about the SYN-ACK being generated by the SSL client. What tipped me off to this was something, that I hadn't mentioned before, which was RSlinx Driver Diagnostics showed an Active CSPv4 connection when using the "Ethernet Devices" driver. But the connection didn't work and the RESETs were continually being generated by the PLC.

From what I've learned from you and my sniffer, it should work like this:

TCP 2222 SYN -->
<-- TCP 2222 RST-ACK from PLC
TCP 2222 SYN -->
<-- TCP 2222 RST-ACK from PLC
TCP 2222 SYN -->
<-- TCP 2222 RST-ACK from PLC
RSLinx figures out we don't want to talk CSPv4
TCP 44818 SYN -->
<-- TCP 44818 SYN-ACK from PLC
TCP 44818 ACK -->
Now we are talking PCCC


I'm assuming (and may be completely wrong) that what is happening with my application layer proxy (port forwarder) and the "Ethernet Devices" driver is this:

TCP 2222 SYN -->
<-- TCP 2222 SYN-ACK from proxy
TCP 2222 ACK -->
RSLinx thinks we want to talk CSPv4
<-- TCP 2222 RST-ACK from PLC via proxy
Nope, lets try again
TCP 2222 SYN -->
<-- TCP 2222 SYN-ACK from proxy
TCP 2222 ACK -->
RSLinx thinks we want to talk CSPv4
<-- TCP 2222 RST-ACK from PLC via proxy
Nope, lets try again to infinity and beyond

You asked about my implementation. I'd hate to slight anyones SSL product in public because I can get it to work with the "Ethernet Devices" driver using a different access method on the same SSL appliance. The product has both application level port forwarding (which is what I am working with here) and full layer 3 VPN functionality that has none of the issues we are discussing here. I'd be happy to discuss offline.

Thanks again for your help, Ken!

My PLC protocol terminology is a little fuzzy. Please substitute EtherNet/IP where ever I said PCCC. Sorry about that.