Hello everyone!

New to the forums here and very much a newb to the PLC world. I am an IT/network guy and don't have to deal with PLCs or modbus that much. I revamped a fairly large size network to work with a new ISP. Here comes the trouble with all the remote PLC sites.

All the remote sites are connected to a central firewall. The Kepware server is doing the same thing, connecting back up to the firewall via IPSec VPN. I can see pings across all remote sites so routing is good. I even went as far as allow all traffic for testing.

When the kepware server talks to the PLC on the remote site, it does the TCP handshake but then immediately gets disconnected passing no data. I will be doing more testing tomorrow with trying to use the Concepts program at the central firewall to see if I can talk to the remote PLCs.

Anyone have any experience with IPSec VPN and modbus tcp?

Thanks,
Eradz

 

Modbus/TCP shouldn't care - it is merely TCP/IP on port 502. But 20 years of experience says the end device MIGHT not have the correct 'gateway router' config'd, which means the socket hits the PLC, but the return path is blocked.

So first confirm that ANY router IP is configured, then confirm that it is the correct one, as many people working with fixed IP (as opposed to DHCP-driven mentality) will just assume (for example) that 192.168.10.1 is the gateway, whereas nothing stops it from being 192.168.10.217 - especially if the VPN is using smaller subnets.

 

>Modbus/TCP shouldn't care - it is merely TCP/IP on port
>502. But 20 years of experience says the end device MIGHT

---- sniped by moderator ----

>whereas nothing stops it from being 192.168.10.217 -
>especially if the VPN is using smaller subnets.

Here is the image from my packet cap:

http://s28.postimg.org/crs644225/Modbus_IPSec.jpg

Kepware is 53.90 and the end point PLC is 219.106

Pings work fine from server to end point. All other types of traffic flow fine, its just the modbus tcp traffic that is not acting right.

Tomorrow I am going to try a serial to ethernet converter then see how it acts vs going directly into the PLC with ethernet.

Let me know what you think!

Eradz

 

Wow - that is pretty weird! As you can see, the TCP [SYN] packets seem to work fine.

Are you sure the 'unit id' of zero is okay? Some devices default to assume '1' is default (aka: they are mapping Modbus/TCP to serial RTU, where '0' is an unanswered broadcast.) If '1' is required, then the PLC would NOT response ... as you are seeing.

That details should NOT have changed due to adding a VPN, but it can be important detail.

- LLinse @ cradlepoint.com

 

It is still set to 0 still. I had to revert the PLC data back to the way it was originally configured. I will have to do some testing on a single site so everything is not down lol.

I guess next step is to test it across just a single VPN jump. Another weird thing, I tried to look at the PLC by the outside IP, after I set it up to forward the data to the internal IP, but I still got the same results on the packet capture.

Another weird issue, out of all the sites, one does work. Its connected to the firewall that is at the center of the network, that all the other VPN connections converge into.

Another setup, I tried to VPN from a PLC site directly to the Firewall at the kepserver, same results. I figured if I skipped the main firewall, that would be one less jump to have to troubleshoot.

All the same results tho... Thanks for the help. I will keep this updated as I troubleshoot this issue.

Eradz

 

Ok, I know this thread is older but I got some good updated info after much troubleshooting. I am hoping someone can help me out.

>It is still set to 0 still. I had to revert the PLC data
>back to the way it was originally configured. I will have to
>do some testing on a single site so everything is not down
>lol.
>
>I guess next step is to test it across just a single VPN
>jump. Another weird thing, I tried to look at the PLC by the
>outside IP, after I set it up to forward the data to the
>internal IP, but I still got the same results on the packet
>capture.
>
>Another weird issue, out of all the sites, one does work.
>Its connected to the firewall that is at the center of the
>network, that all the other VPN connections converge into.
>
>Another setup, I tried to VPN from a PLC site directly to
>the Firewall at the kepserver, same results. I figured if I
>skipped the main firewall, that would be one less jump to
>have to troubleshoot.

I think this is a processor issue with talking across the network, not the LAN, but over the internet / VPN.

TSX Momentum 171CCC96029:

The one that does not talk across the internet is PV:04 RL:07 SV:1.08 DOM:04-2004 - I think the kernel on this one is 1.01

The one that will talk(both are same model) across the internet: PV:11 RL:18 SV:01.30 DOM:1148

I am assuming PV is the year is was made just like the DOM. It would almost have to be a kernel issue between these causing the problems? Is there anyway to see release / update notes on the kernels throughout the years?

Thanks,
Eradz

 

Finally found the issue to this problem. There are 2 issues here. First was the firewall blocking the traffic and the second was the way the PLC was handling the TCP 3-way handshake. At the last leg of the handshake, the PLC was trying to push data before completing the handshake. The firewall didn't like that idea and was dropping the packets.

PaloAlto 3050 was the firewall in question. Here is the exact issue.

https://live.paloaltonetworks.com/t...Networks-TCP-Settings-and-Counters/ta-p/54049

So I hope this helps someone!

Thanks,
Eradz