Netgate SG-1000 microFirewall

Author Topic: ntopng https redirect / protocol error after configuration in version 2.4.1  (Read 247 times)

0 Members and 1 Guest are viewing this topic.

Offline ProgressCity

  • Jr. Member
  • **
  • Posts: 28
  • Karma: +1/-0
    • View Profile
Greetings all!

I'm running pfsense with webconfigurator using https on a nonstandard port (not 443), anti-lockout rule disabled, and webgui redirects disabled.  I'm NOT running anything behind HAPROXY currently.     I'm having an issue with getting ntopng to properly redirect after an installation. Once I set my general options (password, Interfaces, DNS mode, Local Nets etc etc), and update my GeoIP Data. I enable Ntoppng, and save.
Once the configuration is there, I click Diagnostics>ntopng and am immediately redirected to a browser error page:
Chrome: This site canít provide a secure connection
<firewall> uses an unsupported protocol. ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Unsupported protocol The client and server don't support a common SSL protocol version or cipher suite.
Secure Connection Failed
An error occurred during a connection to https://<firewall>:3000. Cannot communicate securely with peer: no common encryption algorithm(s). Error code: SSL_ERROR_NO_CYPHER_OVERLAP
The page you are trying to view cannot be shown because the authenticity of the received data could not be verified. Please contact the website owners to inform them of this problem.
This page canít be displayed
Turn on TLS 1.0, TLS 1.1, and TLS 1.2 in Advanced settings and try connecting to https://<firewall>:3000 again. If this error persists, it is possible that this site uses an unsupported protocol or cipher suite such as RC4 (link for the details), which is not considered secure. Please contact your site administrator.
I've tried:
uninstalling, deleting the configs and /var/db/ntopng directory and reinstalling and reconfiging.
made sure redis server was running and listening on with proper entries in /etc/rc.conf for reboots
Verified ntopng was running and at least listening on port 3000.
Verified the /usr/local/etc/redis.conf configs were correct

After some messing around I'm sure this has something to do with HTTPS / HSTS. I've tried configuring a DNS entry resolving to just a single hostname (and FQDN obviously) to bypass the limitation, though it's not working not with HTTP or HTTPS. I've tried using an additional CARP IP, I've tried tying it to the LAN Physical IP. For anyone familiar with configuring darkstat (http only with a webconfigurator on https) I tried to work around it in a similar way, however there is no such option for a web hostname as there is in darkstat.
Aside from known bugs with limiters and the like, I'm not having any other issues but this one seems a bit weird.
Content of redis.conf
Code: [Select]
protected-mode yes
port 6379
tcp-backlog 511
timeout 0
tcp-keepalive 300
daemonize yes
supervised no
pidfile /var/run/redis/
loglevel notice
logfile /var/log/redis/redis.log
databases 16
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename dump.rdb
dir /var/db/redis/
slave-serve-stale-data yes
slave-read-only yes
repl-diskless-sync no
repl-diskless-sync-delay 5
repl-disable-tcp-nodelay no
slave-priority 100
appendonly no
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes
lua-time-limit 5000
slowlog-log-slower-than 10000
slowlog-max-len 128
latency-monitor-threshold 0
notify-keyspace-events ""
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
list-max-ziplist-size -2
list-compress-depth 0
set-max-intset-entries 512
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
hll-sparse-max-bytes 3000
activerehashing yes
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
hz 10
aof-rewrite-incremental-fsync yes
<END OF redis.conf>

No errors in ntopng log
Any assistance would be helpful and greatly appreciated!