nginx warning duplicate network "::0/0"

[kwen1x]

Hi,

I noticed following warning being logged after updating our pix certificate:

[warn] 11366#11366: duplicate network "::0/0", value: "0", old value: "1" in /etc/nginx/sites-enabled/3cxpbx:14

3cxpbx file contains following lines:

geo $is_remote {
default 1;
192.168.0.0/16 0;
172.16.0.0/12 0;
10.0.0.0/8 0;
127.0.0.1 0;
::0/0 0;
}

this looks similar to the console restrictions config page (web gui) where it says:

"The Link-local IPv4, Link-local IPv6, and Private IPv4 addresses are pre-populated already and cannot be deleted."
But this pages lists following ranges in the web gui:
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
169.254.0.0/16
fe80::/10

So I see that:
the nginx config file refers to gui refers to 169.254.0.0/16 which is not present in Nginx config file ?!
the nginx config file refers to fe80::/10 range where gui refers to ::0/0 0 ?!

Maybe I misunderstood some stuff and are these 2 observations unrelated, but these are my questions:

1. (now) console is accessible from any where over internet, although I enabled ' Allow Access from specific IP Addresses' from the web gui ??
   I must admit however that I was not able to login to pbx admin site, although correct credentials were given.
   So it seems the nginx engine does reply to an initial web page request in order to block access further down the login process ?
   But I would have expected Nginx to be configured to simply refuse to show the login page all together, which is the behaviour it used to do in the past if my memory serves me correctly ??
   
   
2. Is this warning normal ?
   How can we get rid of it ?

 

[ChrisC_3CX]

I noticed following warning being logged after updating our pix certificate:

Sorry for my ignorance but what do you mean by pix certificate? Are you referring to ssl certificates perhaps, and what does it have to do with the nginx configuration, did you make modifications?

this looks similar to the console restrictions config page (web gui) where it says:

"The Link-local IPv4, Link-local IPv6, and Private IPv4 addresses are pre-populated already and cannot be deleted."
But this pages lists following ranges in the web gui:
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
169.254.0.0/16
fe80::/10

So I see that:
the nginx config file refers to gui refers to 169.254.0.0/16 which is not present in Nginx config file ?!
the nginx config file refers to fe80::/10 range where gui refers to ::0/0 0 ?!

These two are completely unrelated so the differences you see mean nothing.

(now) console is accessible from any where over internet, although I enabled ' Allow Access from specific IP Addresses' from the web gui ??
I must admit however that I was not able to login to pbx admin site, although correct credentials were given.
So it seems the nginx engine does reply to an initial web page request in order to block access further down the login process ?
But I would have expected Nginx to be configured to simply refuse to show the login page all together, which is the behaviour it used to do in the past if my memory serves me correctly ??

Enabling Console restrictions from the 3CX MC will not prevent users from seeing the login page but will prevent them from logging in exactly as you describe. This has always been this way.

Is this warning normal ?
How can we get rid of it ?

Have you checked all available syslog files? Every how often does this appear and is it perhaps after a specific event (system reboot, or anything else, etc)

 

[kwen1x]

>>Sorry for my ignorance but what do you mean by pix certificate
I meant to write 'pbx' certificate... (thanks spellchecker...)

 

[kwen1x]

Sorry for my ignorance but what do you mean by pix certificate? Are you referring to ssl certificates perhaps, and what does it have to do with the nginx configuration, did you make modifications?


These two are completely unrelated so the differences you see mean nothing.



Enabling Console restrictions from the 3CX MC will not prevent users from seeing the login page but will prevent them from logging in exactly as you describe. This has always been this way.


Have you checked all available syslog files? Every how often does this appear and is it perhaps after a specific event (system reboot, or anything else, etc)

>>These two are completely unrelated so the differences you see mean nothing.
ok, glad to hear that

>>This has always been this way.
OK, my memory appears to be degraded

>>Have you checked all available syslog files?
Which logfiles do you need ?
I saw this in the nginx error.log file, since this is the one I always check when I renew the pbx certificate (reload of nginx), just to make sure nginx is happy with everything. Since I update these certificates manually every 3 months, I cannot recall having seen this message, but maybe I'm being fooled by my memory (again) ?

Thanks for your feedback