Thanks for the reply. Your last sentence points points to our problem, which is this: We have a large number of PLCs in the field at various customers' sites, most sites with multiple PLCs. We need to be able to monitor these PLCs over the internet from a central data server. We have two methods of doing this. We can either access a particular PLC using port forwarding in the remote router, or we can set up a VPN tunnel between the central server's internet gateway and the remote site's internet gateway. In the former case we would set up a link to the remote gateway's IP address and forward port 28784 to the PLC behind the firewall. In the latter case, we would activate the VPN tunnel and set up the link to the local IP address of the PLC on the remote LAN. The port forwarding method only works if you have a single PLC on the remote LAN, because you are limited to port 28784. Your response implies that you can use different port numbers to get through the router, but in our experience, the vast majority of routers are not capable of forwarding a message and simultaneously changing the port number (i.e. taking a message coming in on Port 10000 and forwarding it to a local IP address on Port 28784). If this is not the case, or you know of a way around this limitation, I'd love to hear about it.
The VPN method isn't adequate either, because we have multiple remote sites with the same local IP addressing scheme. Thus, we may have VPN tunnels set up to three different sites, all with local IP addresses of 192.168.1.xxx. If we have three PLCs on the multi-tunnel virtual network all with IP addresses of 192.168.1.10, there is no way to independent address them.
This is why we would like to be able to assign each PLC (ECOM) in the field a unique port number. Then we could use simple port forwarding with a unique link to each PLC. It would solve the problem of multiple PLCs on the same network and also the problem of non-unique local IP addressing.
Regarding your objections, it seems to me that in hardware and software of all types, there are a multiple of useful parameters that are set to a default value, and if you don't know what you are doing and/or have no reason to change them, you leave them alone and you stay out of trouble. If you DO need to change them, it's a darn good thing they are there.
In the case of NetEdit, frequently one must find connected ECOMs without knowing what IP address they are set to. That's what the IPX protocol provides, isn't it? Wouldn't it see the ECOMs completely independently of both the IP address and port settings?
Could you elaborate on what you mean by proxy connections? Is that possibly a solution for us?