NAT with 9300-ENA

[cajunconfiguratorModeratorKarma: 187Rank: Jedi]

Hello All,

First Post to the Forums. Interesting community here. I am hoping that someone can point me in the right direction as this problem is really starting to get old.

Case: SCADA Poll of L32E CPLX fails every time after the first poll.

I will just give you the broad rundown of the whole problem and not just the specific fix I am trying to implement. I might be totally on the wrong track and yall can get me back on if you know what I am trying to accomplish right?

The local site has a Compact Logix L32E as the primary site controller. the local network is a 192.168.101.xx LAN. There are several other controllers and HMIs and junk on this network, most importantly, a customer metering unit. SCADA network is a public IP 172.50.135.xx network. SCADA connection is a stratix 8K switch and Mesh radio. The public side SCADA gateway is not in the same subnet as the Stratix the gateway is 172.50.0.1.

The design theory for getting this location on SCADA was to use a red lion DSPX (with two NIC) and Port Forward the 172 over to the 192 and poll the controller. The SCADA has a 10 min poll cycle I believe..or 12 min poll cycle. And this works the first poll. After that the SCADA cannot get to PLC until a power off of the DSPX is performed. and so it goes, Power off, Power On, Poll, No Comms. As if the port is getting shut off or blocked by the compact logix.

Now we are trying a NAT instead of a TCP Port Forward, Using a 9300-ENA. set up the device with the Uplink side as the 172.50.135.xx address and GW address 172.50.0.1, the Local side to the same as the IP as the DSPX, and built a NAT route from 172.50.135.xx (xx = unique address to the uplink NIC address) over to 192.168.101.xx (CPLX address) and set the CPLX gateway address to the 9300 local NIC IP.

So the Nat seems to work from the locally connected devices on the public side. I can ping the Nat address from the Stratix switch and the nat address shows in the radio clients. However, any traffic from the gateway that is not coming from the same subnet as the nat address, fails to ping or connect via that NAT address.

Sorry for the super long opener… and Thanks for putting your brain on this with me!

– Scooter

[tfgmedia_adminKeymaster]

Hi Sean and welcome to the forums!

Is it possible for you to upload a network diagram, a picture is sometimes worth a 1000 words… 🙂 I’d like to work through this with you if you can spend some time to put it on paper that would really help. You can then upload the file below.

Fred

[tfgmedia_adminKeymaster]

Just rereading your description here, is the problem you’re facing on the routed network side? It sounds like (if I’m reading this correctly) if you are connected on the public network that’s assigned to the same subnet as the Stratix you can ping the private side network no problem. However, I soon as you move to a different public subnet you are no longer able to reach the Stratix on the public side.

How are you routing between subnets/Vlans? Have you built the routes on your public network? Is there STP configured on the public network – this has been known to cause some issues if the STP protocols aren’t set to match?

[cajunconfiguratorModeratorKarma: 187Rank: Jedi]

PM’d you on linkedin with link to drawings. I dont really want to post them… Im not sure how the company (mine) or the customer would like that?

Ok so yes..Kind of.

The IP schema works like this. Internal “control” network = 192.168.1.xx where xx = the same device on every pad. 192.168.1.10 = MCC Site Control PLC, 192.168.1.4 = Red Lion DSPX (for measurement), .11 MCC PLC, .5 Flow Computer…. ect. What ever equipment is on the site Gas Lift Compressor PLC # 1 = .241, HMI .240 any pad in this area are all built the same like this.

Then we have a separate network that is Public IP’s and is not controls just SCADA. there are only a couple of devices on each pad with direct access to the SCADA side. There are more than 500 sites over 5 counties. Each county has a gateway and all of the radios in that area direct the traffic there, then back into the wired office network.

All of them are 172. addresses. then .20, 24,26 the second octet is the county.

County 1 all addresses are 172.20.xx.xx. County 2 is 172.24.xx.xx

the third octet is the specific “pad” identifier.So  hes a 172.24.60.xx says county 2 pad 60.

then the final octet is the device. so the MCC PLC has a 2nd EBNT that is 172.24.60.21. The red lion DSPX has a 2nd ethernet card that is 172.24.60.31. a second red Lion DSPX is 172.24.60.4 that port forwards to the flowcomputer.

Ok Following that? internal network. 192. External 172. The external network goes from the MCC to a panel with a stratix 8K and then a radio on the pole.

All of the external devices. All of them. EVERY ONE of them, its does not work unless, you give them a gateway of 172.24.0.1 or 172.20.0.1 or 176.0.1 with a netmask of 255.252.0.0 However the NAT IP has no gateway.

 

[cajunconfiguratorModeratorKarma: 187Rank: Jedi]

Fred, All,

I just wanted to follow up with you all on this problem and explain how we solved it,

I spent a whole day with my machine connected locally, and engineers from Allen Bradley, Hirschman, and 3 of them from ABB on a skype meeting with my machine connected and all of them scratching their heads.

What we found was that the radio (ABB Tropos) and the particular firmware that ABB has us running, will not route traffic to addresses without a MAC address.

Since a NAT IP is basically just a listener the radio would ARP the NAT address but wouldnt allow routing to it. So from addresses within the same  subnet, IE, My computer connected to the radio with a 172 address in the same subnet as the radio, could reach the NAT IP, however any traffic coming from anywhere else on the radio side connected past the L3 gateway, were unable to route to that address.

The solution here, was to simply put a made up MAC into the static routes in the radio configuration.

Thanks for anyone who even read this… and Fred I appreciate your time trying to sort through my huge blast of information

 

Cheers – Scooter

 

 

[tfgmedia_adminKeymaster]

Hey Sean,

That’s great. Glad to hear you got it sorted! Admittedly, the complexity of the network you were describing made it difficult for me to really help you out…sorry dude!

Let’s keep fighting the good fight my man!

[Author]

Posts