Hi John,
Could it be that the IEM has a default route to the primary NIC and the application is expecting the IED behind that, so the data never reached the 192.168.15.0/24 network? I would use a sniffer to see what goes wrong. Also, it could be a DNS problem, that the EID is resolved outside of the 192.168.15.0/24 network.
Use the etc/hosts file to hard point the EID to the IP of the IED hostname.
I hope this will give you a hint on where to look.
Go Make It
To clarify and add some detail, our IEM has 2 NICs and the networks are not connected.
The IEM Maintenance webpage can be opened and logged on to from either subnet. GOOD
Regardless of which network web address is being used to access the IEM Management page, when I click the Edge Management icon, I am taken to the test subnet address https://192.168.15.41:9443/pp/app/home
Clicking the Sign In icon flashes momentarily and never gives a logon window. Encrypted packets are being sent to the test subnet IP address of the IEM. I suspect that the responses are going out to the firewall network but I cannot monitor that easily.
The Proxy settings are set to not use the proxy with 192.168.0.0/16 as well as 192.168.15.0/24 which is pretty standard.
A workaround.
If I go instead to https://<Firewall IP>:9443/pp/app/home I do get a logon window and am able to access all functions.
So, when I create a provisioning file for an IED and edit it, I see the firewall address of the IEM. If I change it to the Test Subnet IP address of the IEM, it provisions fine and is able to be used as intended with the IEDs.
I have found issues in the past when dealing with our isolated networks on other systems.
Where can I find the root password for the console of the IEM? Or how to access network related files?
That is a very poor design consideration for customers that require isolation of networks. In our case testing.
That is a very poor design consideration for customers that require isolation of networks. In our case testing.