You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
And on systems that maintain separate IPv4/IPv6 address space this works as well:
--https-port=[::]:3333,0.0.0.0:3333
This is all good. However, when listing multiple addresses in the https-port parameter, the addresses end up bound to the addresses/ports as expected, but only the last server address in the list actually functions correctly.
For instance, when using:
--https-port=[::]:3333,0.0.0.0:3334
connections to port 3333 on IPv6 will function as expected. However connections to port 3334 on IPv4 will fail with ERR_SSL_PROTOCOL_ERROR.
connections to port 3333 on the IPv6 address will function as expected, however connections to port 3333 on the IPv4 address will fail with ERR_SSL_PROTOCOL_ERROR. Further, it appears that the server running on the IPv4 address is actually HTTP rather than HTTPS, and returns an error 302.
I assume this is not the intended behavior?
The text was updated successfully, but these errors were encountered:
OS names: Linux, FreeBSD
ntopng version: 6.2 and prior
The --https-port (-W) option accepts a comma separated list of addresses to bind to. Examples:
And on systems that maintain separate IPv4/IPv6 address space this works as well:
This is all good. However, when listing multiple addresses in the https-port parameter, the addresses end up bound to the addresses/ports as expected, but only the last server address in the list actually functions correctly.
For instance, when using:
connections to port 3333 on IPv6 will function as expected. However connections to port 3334 on IPv4 will fail with ERR_SSL_PROTOCOL_ERROR.
Similarly, when using:
connections to port 3333 on the IPv6 address will function as expected, however connections to port 3333 on the IPv4 address will fail with ERR_SSL_PROTOCOL_ERROR. Further, it appears that the server running on the IPv4 address is actually HTTP rather than HTTPS, and returns an error 302.
I assume this is not the intended behavior?
The text was updated successfully, but these errors were encountered: