[1.820] Public IP show's HASH Value [KNOWNISSUE]

[Henrik]

In the /etc/location file on the ASG appliance is the IP Address of my
ACC Server which is configured to be the Up2Date Cache server.

If I understand you right, you say that behaviour is ok. But I don't think
so, because this IP Address is used for the public IP on the ACC. Now
if I use the ACC Server for Up2Date Cache for all my ASG's all public IP's
would be the same for all.

I hope I could explain right. If not, please let me know.

Regards,
Henrik

[r2d2]

If you have ACC cache defined it works as you described. We will discuss how to handle this scenario.

Regards

[Henrik]

There needs to be some other issue. All my appliances have the same
location.

Regards,
Henrik

[Thorsten Zachmann]

This can happen

1. if they all have the same public IP e.g. if they are behind the same router
2. e.g. their public ip addresses are all from the same network and ip -> location gives for all the same result.

What are the public IP addresses of the ASGs?

Thorsten

[Henrik]

Hi,

well here's the thing. Before 1.820 everything was ok. Each appliance had
it's own location.

If I go to the homepage of GeoIP and test all IP addresses I have, the same
location is returned for all IP's.

So I guess there is the problem and not on the ACC. But I still don't agree
that the public IP for the appliance is the ip of the ACC if I configured an up2date cache.

Regards,
Henrik

[megaposer]

Hello,

my finishing words to this:

The IP address used for the actual GeoIP lookup is determined as follows:

1) If the device is not using a cache/proxy

The IP is either the address of the outgoing interface of the device used to reach the Up2Date Servers or the address of the last masquerading router/firewall on the path to the Up2Date Servers.

2) If the device is using a cache/proxy

The IP is either the address of the outgoing interface of the cache/proxy used to reach the Up2Date Servers or the address of the last masquerading router/firewall on the path to the Up2Date Servers.

I agree that the behavior should be changed, that the IP from the original requester should be taken (as long it is not an RFC 1918 address). But this will not be easily fixable for now.

Regards,
Henning