PCNS redirecting to different IP address

[BillP]

I have PCNS 4.0 running on an OS X system that has multiple IP interfaces.

Connections to the HTTP interface get redirected to HTTPS but on a different IP address than the initial HTTP connection (see below).

Since that IP address is not reachable from the client the redirection fails.

Is there any way to change this behavior e.g. by limiting the IP addresses PCNS listens on or redirecting to the same IP address the HTTP connection went to?

Stefan

% telnet 192.168.1.211 3052
Trying 192.168.1.211...
Connected to 192.168.1.211.
Escape character is '^]'.
GET / HTTP/1.0

HTTP/1.1 302 Found
Location: https://172.16.142.1:6547
Content-Length: 0
Server: Jetty(9.1.3.v20140225)

Connection closed by foreign host.

[BillP]

Stefan,

What IP address is listed in pcnsconfig.ini? Also, are you entering the IP address or domain name in the web browser and if domain name what IP address is associated with that name?

Note: When you attempted to connect to PCNS using http it will automatically redirect you to https for security.

[BillP]

Hi Bill,

IP address listed as localHostAddress in the Networking section of pcnsconfig.ini is 192.168.1.211 (see below).

In the browser I enter http://192.168.1.211:3052 and get redirected to https://172.16.142.1:6547

The client has no route to 172.16.142.1 and the browser times out after a while, complaining that the server at 172.16.142.1 takes too long to respond (naturally). 

The system running PCNS has several IP addresses, one of which is 172.16.142.1, but the only IP address accessible from the LAN the web client is sitting on is 192.168.1.211.

It seems that PCNS does not use localHostAddress to construct the URI for the HTTP 302 redirect.

Any other solution available for multihomed systems?

Stefan

/Users/Shared/Applications/APC/PowerChute/group1/pcnsconfig.ini
...

[Networking]
protocol = https
httpPort = 3052
httpsPort = 6547
NetworkConfig = IPV4
VirtualInstall =
MulticastAddress =
IPv6NetworkConfig = unicast
localHostAddress = 192.168.1.211
UnicastAddress =
...

[BillP]

The same problem still exists in 4.1.

I'm running is on a RHEL 6.7 cluster node with a public interface bond0 (192.168.12.55) and a private cluster inteconnect bond1 (192.168.12.2).

The IP Address 192.168.12.55 in UPS Configuration - PowerChute Agents links to http://192.168.12.55:3052/ but then the browser gets redirected to https://192.168.12.2:6547/

That is certainly useless because the cluster interconnect is just a crossover cable between the nodes and not accessible to the client.

PCNS will apparently always redirect to the lowest non-loopback IP in the system.

What one would expect is a more deterministic behavior e.g. redirect to 

a) the same IP address the client is connecting to or

b) to the IP address specified in pcnsconfig.ini => Networking => localHostAddress

Can this please be fixed in a future release?

Thanks

Stefan

/opt/APC/PowerChute/group1/pcnsconfig.ini:

[Networking]

protocol = https
httpPort = 3052
httpsPort = 6547
NetworkConfig = IPV4
VirtualInstall =
MulticastAddress =
IPv6NetworkConfig = unicast
localHostAddress = 192.168.12.55
UnicastAddress =

$ ip addr show bond0 scope global
7: bond0: mtu 1500 qdisc noqueue state UP
link/ether b8:2a:72:d1:94:32 brd ff:ff:ff:ff:ff:ff
inet 192.168.12.55/24 brd 192.168.12.255 scope global bond0
inet 192.168.12.86/24 brd 192.168.12.255 scope global secondary bond0
inet 192.168.12.82/24 brd 192.168.12.255 scope global secondary bond0
inet 192.168.12.81/24 brd 192.168.12.255 scope global secondary bond0
inet 192.168.12.164/24 brd 192.168.12.255 scope global secondary bond0
inet 192.168.12.85/24 brd 192.168.12.255 scope global secondary bond0
inet 192.168.12.80/24 brd 192.168.12.255 scope global secondary bond0
[root@aspendpc5 ~]# ip addr show bond1 scope global
8: bond1: mtu 1500 qdisc noqueue state UP
link/ether b8:2a:72:d1:94:33 brd ff:ff:ff:ff:ff:ff
inet 192.168.168.2/24 brd 192.168.168.255 scope global bond1

[BillP]

Stefan,

When you open your browser and type https://192.168.12.55:6547 is the user interface opened or are you being redirected to https://192.168.12.2:6547? And to verify, when you open a browser and type http://192.168.12.55:3052 you get redirected to https://192.168.12.2:6547? 

[BillP]

> When you open your browser and type https://192.168.12.55:6547 is the user interface opened

Yes

> or are you being redirected to https://192.168.12.2:6547?

No

> when you open a browser and type http://192.168.12.55:3052 you get redirected to https://192.168.12.2:6547?

Yes.

[BillP]

There is a workaround for this issue.

 On the PCNS machine you can add the IP address that PCNS is re-directing to, to the /etc/hosts file or C:\Windows\system32\drivers\etc\hosts file and re-start the PCNS service/daemon.

Example: We have PCNS installed on a machine with multiple NICs including some which use VirtualBox private IP range (192.168.56.x). When we enter http://correct IP:3052, PCNS re-directs to https://192.168.56.1:6547 similar to what's happening at your location.

As a workaround we added 192.168.56.1 to C:\Windows\system32\drivers\etc\hosts file and re-started the service. Then when we enter http://10.216.254.162:3052, PCNS will re-direct using the FQDN instead of the IP address.

[BillP]

Bill,

The workaround does not work for us:

1) we have an entry for the private IP in /etc/hosts and it has a name that cannot be deleted

2) we are not using DNS: referral to a FQDN will not succeed

3) results of the workaround are erratic: on one system it works, on the other it doesn't

Stefan

[Anonymous user]

On 9/23/2015 1:06 AM, Stefan said:

PCNS will apparently always redirect to the lowest non-loopback IP in the system.

If that is indeed the case, then it would seem that the simplest workaround would be to just move your private, disconnected networks (be they cluster crossover, internal VMs, or whatever) to numerically higher subnets - 192.168.254.0/24, for example.

[BillP · Accepted solution]

I guess I was wrong with that assumption.

The address it is redirecting to is the highest one in the system: 192.168.168.1/24

$ ip addr  | grep inet\ 

    inet 127.0.0.1/8 scope host lo

    inet 169.254.0.2/16 brd 169.254.255.255 scope global idrac

    inet 192.168.12.44/24 brd 192.168.12.255 scope global bond0

    inet 192.168.12.83/24 brd 192.168.12.255 scope global secondary bond0

    inet 192.168.12.81/24 brd 192.168.12.255 scope global secondary bond0

    inet 192.168.12.164/24 brd 192.168.12.255 scope global secondary bond0

    inet 192.168.12.80/24 brd 192.168.12.255 scope global secondary bond0

    inet 192.168.168.1/24 brd 192.168.168.255 scope global bond1

Nevertheless thanks for your suggestion. Will try to assign a higher one as secondary IP on the public interface and see if that works.