On our development server we have winccoa 3.11, 3.12 and 3.13 projects.
Manager monitoring for 3.11 and 3.12 works fine with any browser (local & remote)
But trying to monitor a 3.13 project I have following (reproducable) behavior:
Remote connection: browser can't establish a connection (during tests the firewall was disabled).
Local connection: works with http://localhost:[PMON_PORT], but does not work with http://[SERVERNAME]:[PMON_PORT] or http://[IP]:[PMON_PORT] (same error like remote: couldn't establish connection)
WinCC OA is up to date (just installed WinCC_OA313_Windows_64Bit_P002).
I checked online help, but I didnt find a note that HTTP isn't supported by pmon any more (btw/to be exact: the german topic Projektadministration/Prozess Monitor/Managerüberwachung is cut in the end, so I checked the english one and there I didn't find an according information)
HTTP manager monitoring in 3.13
- leoknipp
- Posts:2928
- Joined: Tue Aug 24, 2010 7:28 pm
Re: HTTP manager monitoring in 3.13
Hello,
access from other computers is disabled (by default) due to security reasons.
Please have a look at the following post for another topic:
https://portal.etm.at/index.php?option= ... =1598#1645
Best Regards
Leopold Knipp
Senior Support Specialist
access from other computers is disabled (by default) due to security reasons.
Please have a look at the following post for another topic:
https://portal.etm.at/index.php?option= ... =1598#1645
Best Regards
Leopold Knipp
Senior Support Specialist
- peka
- Posts:19
- Joined: Wed May 15, 2013 4:46 pm
Re: HTTP manager monitoring in 3.13
Hello Leo,
thanks for reply, thought it could have to do something with security reason, but especially the local behavior (using IP or local hostname instead of localhost does not work) was confusing me.
As far as I got it, and tests results in this action, the config entry localAddress = "" enables access for everybody, so in theory there's no need for ip_allow entries, just ip_deny has an effect.
But how to realize following requirement (or is there a docu how the list is handled internaly according to priority): deny all execpt this/those IP(s) or IP-RANGE(s), what I think the most needed feature would be. Thought it should work like shown below, but it doesn't:
Tried several config entry combinations but none results in the needed/wanted result; as soon as i use ip_deny = "*" all ip's are locked no matter which one I allow later on. And locking all IP-Ranges except e.g. 10.97.120.* using the ip_deny entry doesnt seem really comfortable to me. I hope I did some mistake.
br petr
thanks for reply, thought it could have to do something with security reason, but especially the local behavior (using IP or local hostname instead of localhost does not work) was confusing me.
As far as I got it, and tests results in this action, the config entry localAddress = "" enables access for everybody, so in theory there's no need for ip_allow entries, just ip_deny has an effect.
But how to realize following requirement (or is there a docu how the list is handled internaly according to priority): deny all execpt this/those IP(s) or IP-RANGE(s), what I think the most needed feature would be. Thought it should work like shown below, but it doesn't:
Code: Select all
[pmon]
localAddress = ""
ip_deny = "*"
ip_allow = "127.0.0.1"
ip_allow = "::1"
ip_allow = "10.97.120.*" # e.g. the site's ip range
ip_allow = "10.97.130.*" # e.g. VPN service IP rangebr petr
- mkoller
- Posts:741
- Joined: Fri Sep 17, 2010 9:03 am
Re: HTTP manager monitoring in 3.13
There is a docu how this is checked: System Management -> Settings -> IP access lists for TCP server sockets
(or simply search for ip_allow)
It says:
You can check if a client is authorized according to the following rule:
If the client is included in the ip_allow list, then the access is allowed. Otherwise
if the client is included in the ip_deny list, then the access is denied. Otherwise
access is allowed.
If that does not work for you, please get in contact with the support team, so that they will try to reproduce the problem.
(or simply search for ip_allow)
It says:
You can check if a client is authorized according to the following rule:
If the client is included in the ip_allow list, then the access is allowed. Otherwise
if the client is included in the ip_deny list, then the access is denied. Otherwise
access is allowed.
If that does not work for you, please get in contact with the support team, so that they will try to reproduce the problem.