Why not just use VLANS and ACL's to control traffic between them?

that is not an option as we are not able to make them create VLANs (that was my first thought btw). their current network equipment apparently doesn't allow for VLAN creation

that is what I initially thought too, but my lack of experience and knowledge may be a hurdle there. what I mean by that is the fact that static NAT won't work there because the ports the equipment uses are dynamically determined by the PLC. I am not sure how to set that up yet. I thought about static NAT but we cannot set the port on which the PLCs listen. also the ports they use when they send packets are dynamically determined

the other thought I had (not sure if it is even possible) is to use a VPN withing a VPN

finally the PLCs communicate using UDP ports

Igor

"the ports the equipment uses are dynamically determined by the PLC"

Not sure i follow. The statement

static (inside,outside) 192.168.1.10 10.0.0.10 netmask 255.255.255.255

doesn't care about ports only the IP address so it won't interfere with the ports within the packet headers, it will just leave them as they are.

Now because you have dynamic ports you may need to make your access-list on the outside interface very open so you can get through to the PLC's. Is this what worries you ?

Jon

Jon,

sorry about being confusing, but again, my lack of experience is certainly what is contributing to this. anyway

please try to follow my logic here:

1. we establish a VPN tunnel to the customer site

2. we can ping hosts on their internal network (192.168.1.0/24)

3. we can get to the outside interface of our ASA (192.168.1.200 for example)

4. we need to talk to a PLC that is on the inside interface (10.0.0.0/8) of the ASA

at this point if I need to talk to a PLC (10.0.0.10) on our inside network, I am not sure how the ASA would know how and to where to forward that packet. It's outside interface is 192...... and the destination IP is 10..... (this is where I thought about using static NAT, but I can't do that I believe because I would have to know the ports that are being forwarded right???)

I am sorry again if I am not quite understanding your suggestion

Igor

No need to apologize, i am not explaining it very well.

If you establish a VPN to the customer site and you can then ping 192.168.1.x hosts then if you add this to your ASA

static (inside,outside) 192.168.1.10 10.0.0.10 netmask 255.255.255.255

and then add this acl onto your ASA

access-list PLCIN permit udp 172.16.5.0 255.255.255.0 192.168.1.10

access-group PLCIN in interface outside

where 172.16.5.0/24 are the source IP addresses of your remote network, then you now have full access to the PLC's on any UDP port.

Obviously in the above example 192.168.1.10 must not be used for any other device within the customer metwork.

If it helps think of

static (inside,outside) 192.168.1.10 10.0.0.10 netmask 255.255.255.255

as allowing you to forward all ports TCP/UDP directed to 192.168.1.10 on to 10.0.0.10.

Does this help or am i not understanding your setup properly.

Jon

if i understand this right you are forwarding all traffic from 192.168.1.10 to a single IP/PLC(10.0.0.10) on the inside network

OR is the 10.0.0.10 the ASA inside interface IP?

also the part that is still confusing me is this:

assuming 172. is my source network and I want to contact a PLC with IP 10.0.0.15 why would the outside interface of the ASA even acknoledge that packet and not drop it?

"if i understand this right you are forwarding all traffic from 192.168.1.10 to a single IP/PLC(10.0.0.10) on the inside network "

Yes, altho you can control what traffic actually gets through the firewall with your access-list.

"OR is the 10.0.0.10 the ASA inside interface IP?"

Nope, this is the inside address of the PLC device.

"assuming 172. is my source network and I want to contact a PLC with IP 10.0.0.15 why would the outside interface of the ASA even acknoledge that packet and not drop it?"

Not sure i understand. If you wanted to contact 10.0.0.15 you wouldn't use that as the destination address, you would use a 192.168.1.x address so

src IP = 172.16.5.20 (note this was just an example, you have to use your real source IPs)

dst IP = 192.168.1.25

on ASA

static (inside,outside) 192.168.1.25 10.0.0.15 netmask 255.255.255.255

access-list on ASA

access-list PLCIN permit udp 172.16.5.0 255.255.255.255 host 192.168.1.25

When you add the static statement as above this tells the ASA to respond to any queries for 192.168.1.25. That's why the ASA acknowledges and forwards the packet onto 10.0.0.15.

Jon

ok, I think I may have wrapped my mind around what you are saying....

Are you suggesting to use 1-1 IP mapping?

meaning, assume I have 10 PLCs (10.0.0.10-10.0.0.20) I would need to essentially ask the customer to "reserve" 10 192 IPs (192.168.1.100-192.168.1.110) and set static mappings on the ASA for those IPs?

I hope I am getting this right by now :-)

all this and one expression would have saved us a lot of typing :-)

let me try this setup (have a test env set up in our offices) and I will let you know how it goes

Many thanks for the patience and effort

Jon,

your idea was great and for the most part it is working. However there is one stumbling block right now that I am not sure about

It appears that the development software for our PLCs uses ENIP protocol to detect the presence of the PLCs on a given network (it just sends a broadcast using ENIP)

I have opened up every single protocol in the ACL and I still can't get through the ASA. As a matter of fact I don't even see those packets hitting the outside interface (logging in the ASDM interface).

What am I doing wrong? I don't see ENIP as a protocol in the default list

Igor

Not familiar with the ENIP protocol. Remember that the the pix firewall deals with IP traffic only. Does ENIP run over IP or is it a separate protocol ?

Jon