Jump to content


Photo
- - - - -

Rslinx Comms Over Vpn


  • Please log in to reply
6 replies to this topic

#1 wander_who

wander_who

    Sparky

  • MrPLC Member
  • PipPipPip
  • 29 posts
  • Country:Australia
    Australia

Posted 14 March 2006 - 08:58 PM

Hi all,

I have a strange problem with RSLinx comms over VPN..
We have a couple of similar set-ups, where we connect to our customer's network via a VPN connection. We're in Australia, and the last two projects have been in the USA.

I have found that I can still see the devices in RSLinx when connected via the VPN, regardless of where I connect from, as long as the devices are still in the RSWho window (old "not found" devices/history - I don't know the correct term)

When finishing with that project/customer for example, and moving on to another, I used to remove the old devices from the RSWho windows so they did not constantly show up as "not found".
(I have since realised that I maybe should have used "Projects" in RSLinx to seperate things.?. :disgust: )

Anyway, the problem is as once I have cleared out the old "not found" devices in RSWho, when I connect back to the previous project/customer, RSLinx can no longer see any of the devices...
I can still ping them no problems. Also, RSLinx running on the local PC (the customer's) can see all the devices (using pcanywhere over the VPN I can see this)

The two projects in question used:
- One CompactLogix L35E & two PanelView 600's for one project (frst site)
- One CompactLogix L32E & one PanelView Plus 1250 for another (second site)
Now that I am using an upgraded install of RSLinx (so there are no old "not found" devices), I cannot see any devices in RSWho, at either of the sites!

Is this a bug? A feature?
Is there a workaround?
Or a way to "force" RSLinx to see the devices again? short of travelling back to the USA an hooking up locally of course...

Help!

Cheers,
Andrew W

#2 Ken Roach

Ken Roach

    Propeller Head

  • MrPLC Member
  • PipPipPipPipPipPip
  • 2217 posts

Posted 15 March 2006 - 02:50 AM

Andrew,

It's not too uncommon to have VPN's behave in an unusual fashion for protocols other than common Web and remote access features. You're probably going to have to get your IT department involved in this investigation.

I'll ask you three of my usual questions:

1. Are you using the AB_ETH driver (the one with the IP/Station list into which you enter IP addresses) or the EtherNet/IP driver ?

2. What brand and type of VPN circuit are you using ? Is it a hardware/hardware or software/hardware or software/server sort of VPN ?

3. Can you PING the devices from your side of the VPN ? Can you get the HTTP pages from the Ethernet interfaces on the controllers ?

Sometimes getting a VPN to work is as simple as asking the administrator to open the two TCP and UDT ports used by RSLinx; Port 2222 and Port 44818.

#3 wander_who

wander_who

    Sparky

  • MrPLC Member
  • PipPipPip
  • 29 posts
  • Country:Australia
    Australia

Posted 15 March 2006 - 11:28 PM

Hi Ken,

Thanks for your reply.

1. I'm using the AB_THIP (Ethernet/IP) driver. I did try using the AB_ETH driver and adding the station numbers and ip addresses, but it still would not find any devices.


2. I don't know which type it would be - at both sites, we are using the Cisco VPN client software on our end (provided by the customer).
I don't actually know if the Cisco VPN client software talks to software on their end, or to hardware?
I know that both customers use mostly cisco equipment though.


At the 1st site, the PLC network is connected to their IT network with a simple home/office ethernet switch (yuk, but at least its not a hub).
At the 2nd site, the PLC network is connected to their IT network, but as a separate VLAN, using two new Cisco 2950C ethernet switches
(actually the 2nd site is the same one from my previous post, re: the communication problem)


3. I can ping the devices from my side of the VPN, and also from the local PC while connected via VPN.
RSLinx on the local PC can see the devices, but RSLinx on my side of the VPN cannot.
I just tried the HTTP controller pages for both sites, I can view them on my side of the VPN for both.



I'll try getting the ports for RSLinx opened at one of these sites, to see if that works.

Cheers,

Andrew W

#4 Ken Roach

Ken Roach

    Propeller Head

  • MrPLC Member
  • PipPipPipPipPipPip
  • 2217 posts

Posted 16 March 2006 - 11:44 AM

I was about to recommend checking the Default Gateway setting in your controllers' Ethernet configuration, because that is a very common reason for "I can see it locally, but not over a router/vpn/bridge" problem.

But then I noticed this key comment:

... I can still see the devices in RSLinx when connected via the VPN, regardless of where I connect from, as long as the devices are still in the RSWho window


This leads me to think that this might be an interaction between RSLinx and the VPN software. Here are my top three hypotheses:

1. The VPN blocks the EtherNet/IP browse because it is an uncommon port. VPN's typically are set up to only support the common kinds of traffic that PC users need; Hypertext, e-mail transfer, file transfer, printing, etc. They'll block uncommonly used TCP ports to reduce the encryption engine load, and to prevent mis-use of the VPN circuit by malicious software.

Fortunately this is moderately easy to fix if the IT techs will help out by opening up TCP ports 2222 and 44818, and UDP ports 2222 and 44818.

2. The VPN blocks the EtherNet/IP browse because it is a broadcast packet. That's the case with the CheckPoint VPN software that my company uses internally. If I want to use the EtherNet/IP browse function I have to disable CheckPoint on my Ethernet adapter, or use a separate (PCMCIA, USB, or WiFi) Ethernet adapter for my PLC communications. This might not be as easy to disable in the VPN software.

3. The VPN is blocking the RSLinx A-B Ethernet (not EtherNet/IP) browse because it looks like an attack vector or because of a bug in the VPN system.

The A-B Ethernet driver needs to connect to both legacy PLC-5E and SLC-5/05 controllers using the proprietary A-B "CSPv4" protocol and to EtherNet/IP devices like PV+ and CompactLogix. It does this by attempting to connect first on the old protocol's TCP port (2222) and if that port is closed then RSLinx will try to connect using the new TCP port (44818).

The RSWho browser remembers which TCP port it connected on, and will thereafter connect only on that TCP port. That's why you were able to "see" devices that had previously been browsed.

RSLinx requests a connection to port 2222 three times, and needs to get a "port closed" message three times before it will try to connect to port 44818. I call this the "Matthew 26:74" mechanism.

Unfortunately, that mechanism of purposely requesting a connection to an unusual TCP port is also used by port scanners and other kinds of network intrusion, so some VPN systems will block it. I recently ran into a bug in Cisco PIX 500-series firewalls that will incorrectly block that packet. The only way to troubleshoot this is to get network sniffers on both sides of the VPN tunnel and go to work.


At this point you're probably saying "that's very nice, a little complicated, but I'd just like to connect to my controllers, please".

We have to accept that if we're going to connect to our control systems half a world away, there's going to have to be a little fine-tuning with the IT group. Let us know what they say about Port Numbers.

#5 wander_who

wander_who

    Sparky

  • MrPLC Member
  • PipPipPip
  • 29 posts
  • Country:Australia
    Australia

Posted 16 March 2006 - 08:06 PM

Hi Ken

I could not have asked for a more helpful collection of replys. Thanks!

Your last post makes a lot of sense.
It wasn't too complicated for me, if I do say so myself :dance:

Right now I am asking the IT people at the first site to test out opening those ports (I can't honestly call the guys at the second site "IT" people!)
I'll post here with the results.

Again, thanks a lot.

Cheers,
Andrew

#6 wander_who

wander_who

    Sparky

  • MrPLC Member
  • PipPipPip
  • 29 posts
  • Country:Australia
    Australia

Posted 29 March 2006 - 08:01 PM

Well, I have investigated this with the customer's IT people, and found that all ports are open when connecting via the VPN (cisco vpn client).
So no luck getting the AB_ETHIP driver working...

However, they did fix some mis-configured routing/setting on their router or server, so now the AB_ETH driver that I had previously tried is working.
(I also tried the AB_ETH driver on the second site and it also works now, though I'm not aware that they changed anything)

Their IT people said broadcast packets will not work across the VPN, or any microsoft based network...
So is it true to say that the AB_ETHIP driver will never work (when initially browsing for devices anyway) because it is broadcasting? (UDP multicast?)
If not, is there any reason to pursue the issue of the AB_ETHIP driver, seeing as I can now connect with the AB_ETH driver ?
eg will I run into problems using the AB_ETH driver to connect to devices that only support AB_ETHIP?
Any other differences between the drivers?

The downside to not using the AB_ETHIP driver is that I have to keep changing the station ID/IP address list whenever I change from one customer to another...
Or do I? I noticed the station numbers can be any number, and I can just add IP addresses from different sites to the list, and it will only "find" the devices for the site I am currently connected to via VPN.


Cheers,

Andrew W

#7 Ken Roach

Ken Roach

    Propeller Head

  • MrPLC Member
  • PipPipPipPipPipPip
  • 2217 posts

Posted 30 March 2006 - 02:32 PM

The practical approach is to use the AB_ETH driver whenever you use VPN's. That driver will work with any SLC, PLC-5 or ControlLogix Ethernet interface, even ones that only support EtherNet/IP and not CSPv4.

One variation is to create multiple AB_ETH driver instances, and put only the IP addresses for each project in each driver instance. These configurations can be backed up using the RSLinx configuration backup tool.

Your 'IT guys' are only partially correct about broadcast packets. I tend not to try to contradict the professional computing infrastructure staff, as they tend to be petulant and are essential to my continued supply of shiny toys.

VPN's aren't "Microsoft networks". Although Microsoft does have some VPN technologies available, many other vendors compete successfully in the marketplace, and I presume there are many Unix or Linux based systems using VPN technologies with no Microsoft products in sight.

I have a specific example of the EtherNet/IP driver browsing successfully across two Cisco PIX 515e firewalls with VPN connecting them across the Internet.




Just for kicks, here is an example of an Ethernet traffic capture of an EtherNet/IP browse request and response. The two networks are connected via Cisco VPN firewalls.

No. Time Source Destination Protocol Info
2 3.535712 192.168.1.2 255.255.255.255 ENIP List Identity (Req)

Frame 2 (66 bytes on wire, 66 bytes captured)
Arrival Time: Jan 12, 2006 12:12:23.821733000
Time delta from previous packet: 3.535712000 seconds
Time since reference or first frame: 3.535712000 seconds
Frame Number: 2
Packet Length: 66 bytes
Capture Length: 66 bytes
Protocols in frame: eth:ip:udp:enip
Ethernet II, Src: DellEsgP_dc:70:8e (00:0b:db:dc:70:8e), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Source: DellEsgP_dc:70:8e (00:0b:db:dc:70:8e)
Type: IP (0x0800)
Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 255.255.255.255 (255.255.255.255)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 52
Identification: 0x4318 (17176)
Flags: 0x00
0... = Reserved bit: Not set
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: UDP (0x11)
Header checksum: 0x35f7 [correct]
Good: True
Bad : False
Source: 192.168.1.2 (192.168.1.2)
Destination: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: 3073 (3073), Dst Port: 44818 (44818)
Source port: 3073 (3073)
Destination port: 44818 (44818)
Length: 32
Checksum: 0x1ff0 [correct]
EtherNet/IP (Industrial Protocol), Session: 0x00000000, List Identity
Encapsulation Header
Command: List Identity (0x0063)
Length: 0
Session Handle: 0x00000000
Status: Success (0x00000000)
Sender Context: 0000000000000000
Options: 0x00000000

0000 ff ff ff ff ff ff 00 0b db dc 70 8e 08 00 45 00 ..........p...E.
0010 00 34 43 18 00 00 80 11 35 f7 c0 a8 01 02 ff ff .4C.....5.......
0020 ff ff 0c 01 af 12 00 20 1f f0 63 00 00 00 00 00 ....... ..c.....
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0040 00 00 ..

No. Time Source Destination Protocol Info
3 0.001323 192.168.1.21 192.168.1.2 ENIP List Identity (Rsp), 1756-ENBT/A

Frame 3 (117 bytes on wire, 117 bytes captured)
Arrival Time: Jan 12, 2006 12:12:23.823056000
Time delta from previous packet: 0.001323000 seconds
Time since reference or first frame: 3.537035000 seconds
Frame Number: 3
Packet Length: 117 bytes
Capture Length: 117 bytes
Protocols in frame: eth:ip:udp:enip
Ethernet II, Src: Allen-Br_2a:e7:f5 (00:00:bc:2a:e7:f5), Dst: DellEsgP_dc:70:8e (00:0b:db:dc:70:8e)
Destination: DellEsgP_dc:70:8e (00:0b:db:dc:70:8e)
Source: Allen-Br_2a:e7:f5 (00:00:bc:2a:e7:f5)
Type: IP (0x0800)
Internet Protocol, Src: 192.168.1.21 (192.168.1.21), Dst: 192.168.1.2 (192.168.1.2)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 103
Identification: 0xd236 (53814)
Flags: 0x00
0... = Reserved bit: Not set
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: UDP (0x11)
Header checksum: 0x24e8 [correct]
Good: True
Bad : False
Source: 192.168.1.21 (192.168.1.21)
Destination: 192.168.1.2 (192.168.1.2)
User Datagram Protocol, Src Port: 44818 (44818), Dst Port: 3073 (3073)
Source port: 44818 (44818)
Destination port: 3073 (3073)
Length: 83
Checksum: 0x5e54 [correct]
EtherNet/IP (Industrial Protocol), Session: 0x00000000, List Identity
Encapsulation Header
Command: List Identity (0x0063)
Length: 51
Session Handle: 0x00000000
Status: Success (0x00000000)
Sender Context: 0000000000000000
Options: 0x00000000
Command Specific Data
Item Count: 1
Type ID: List Identity Response (0x000c)
Length: 45
Encapsulation Version: 1
Socket Address
sin_family: 2
sin_port: 44818
sin_addr: 192.168.1.21 (192.168.1.21)
sin_zero: 0000000000000000
Vendor ID: Rockwell Automation/Allen-Bradley (0x0001)
Device Type: Communications Adapter (12)
Product Code: 58
Revision: 3.03
Status: 0x0060
Serial Number: 0x00282a1c
Product Name Length: 11
Product Name: 1756-ENBT/A
State: 0x03

0000 00 0b db dc 70 8e 00 00 bc 2a e7 f5 08 00 45 00 ....p....*....E.
0010 00 67 d2 36 00 00 40 11 24 e8 c0 a8 01 15 c0 a8 .g.6..@.$.......
0020 01 02 af 12 0c 01 00 53 5e 54 63 00 33 00 00 00 .......S^Tc.3...
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0040 00 00 01 00 0c 00 2d 00 01 00 00 02 af 12 c0 a8 ......-.........
0050 01 15 00 00 00 00 00 00 00 00 01 00 0c 00 3a 00 ..............:.
0060 03 03 60 00 1c 2a 28 00 0b 31 37 35 36 2d 45 4e ..`..*(..1756-EN
0070 42 54 2f 41 03 BT/A.



"All very nice, Ken, but I'd like to just communicate with my controllers now".




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users