TCPView software was used to diagnose the TCP/IP communications between the commercial and process computers. When run on the client and server computers it was established that the "synsent" TCP signal was sent, and that TCP "synrec" was responded by the server. Also shown were the IP addresses involved.

The problem identified was that the response from the server used commercial LAN IP addresses which were not present on the process LAN. The server response had to be directed to the firewall, where addresses would be known and so passed through to the commercial LAN computer.

This was achieved by using routing on the process LAN.

These following dot points give a solution overview.

• Any commercial LAN internet client request for process LAN server IP addresses were routed by the commercial router, to the process / commercial firewall IP address. (192.168.204.x to 192.168.0.46).
• The firewall allowed the process IP address request to pass through to the process side via dedicated ports. It was found that the commercial side of the firewall required all tcp ports to be open, as the router would use a randomly selected tcp port to communicate with the commercial side of the firewall. (firewall process side IP=192.168.0.91 ports 2072 - 2079 + ftp ports 20&21 + ftp / tcp; firewall commercial side IP=192.168.204.46 all tcp ports + ftp + ftp / tcp.
• The configured firewall passed commercial IP address requests to the process LAN server (synsend).
• The process LAN server responded with a request received response (synrec). The problem was that the response used a commercial IP address, which did not exist on the process network. In the absence of a process LAN router, individual IO / trend / alarm / report server computers required local routes to route any commercial IP address to the firewall IP address. At the command prompt the following was entered, "route -p add 192.168.204.0 mask 255.255.255.0 192.168.0.91". It is critical that " -p " be included as this makes the route permanent. (as I found out when computers were rebooted and all routes were lost). When a commercial IP address requests data that is served by another server (other than the internet server) the request is responded to by the appropriate server. Again to route the response to the firewall local routes were configured in these servers.
• The configured firewall allowed server responses to pass to the requesting commercial IP address.
• The commercial IP address responds with an acknowledgement (SynAck) to the process IP address, which was routed by the commercial router back to the firewall.
• The firewall passes the acknowledgement to the internet server, which responds back via the firewall to the commercial IP address with an establishment signal (established)
• From this point on the internet server connection will toggle between established and wait modes, depending on data requests.

The firewall was used for two main reasons,

1. Reduce risk of virus damage to the process LAN computers. 

          No virus protection software is used on the process LAN computers.

2. Regulating network traffic.

          Considering the importance of process LAN traffic, it is important to regulate traffic and "keep it clean",
          the networks don't want to pass rubbish between them, or have broadcast traffic congesting the systems.

Any 2 LANs that are mutually exclusive and separately administered (i.e. UNTRUSTED), need a security blanket that both parties can agree on.

The system has worked well for internet clients and plant2business is now using the firewall also with success. Plans are in place to install a process router so that route configuration will be easier to manage in the future.

Post Script : I would like to acknowledge the assistance of Mackay Sugar Co-Op IT department's Justin Toon in finding a solution to this problem.