Lost Web UI access with latest update

The update installed and the system rebooted, and no UI from the same LAN… The Nethsecurity appliance works, and I can access the box by logging in with the IP address on port 22 and run commends. Nethsecurity is installed on a Proxmox server. After rebooting the Proxmox the UI still isn’t accessible. Suggestions?

Do you get an error when the UI isn’t reachable?

Maybe it’s reachable on the WAN interface?

Could it be web access is disabled? See Remote access — NethSecurity documentation or ns-ui | NethSecurity

Markus, Thank you for responding so fast.

The message from LAN and WAN is
From the LAN (https://10.20.20.1:9090/) 10.20.20.1 refused to connect ERR_CONNECTION_REFUSED
From the WAN (https://10.20.30.110:9090/) 10.20.30.110 refused to connect. ERR_CONNECTION_REFUSED

I normally use Edge but also tried Chrome and Firefox, same result.

I have never set any firewall rules. I can’t access the web interface to the firewall config. I will look at the documentation in the daytime for ns-ui, but for now, am going back to bed :wink:

Short version:
After following your advice to check the ns-ui config and firewall rules, I still can’t access the web UI from the LAN or WAN interface. I can SSH into both the LAN and WAN IPs.

Details:
I don’t think it affects this issue, but for the record, my Nethsecurity appliance is installed behind and Xfinity router, configured as a router. This configuration has not changed in a month. The LAN side of the router assigns an IP address via DHCP to the Nethsecurity WAN port.

I assigned the ns-ui config parameters, and they look correct to me. I also printed the firewall rules, and although there is no LAN web-ui rule (I presume that is OK), there is a WAN rule enabling web-ui access.

I didn’t learn about the command option: uci show until after I had reset the variables affecting the web UI, but here is the result. Still no access:
ns-ui.config=main
ns-ui.config.luci_enable=‘0’
ns-ui.config.nsui_enable=‘1’
ns-ui.config.nsui_extra_port=‘9090’
ns-ui.config.nsui_extra_enable=‘1’
ns-ui.config.api_server_delay=‘1’

and here are all the firewall rules:
uci show firewall
firewall.ns_defaults=defaults
firewall.ns_defaults.syn_flood=‘1’
firewall.ns_defaults.input=‘REJECT’
firewall.ns_defaults.output=‘ACCEPT’
firewall.ns_defaults.forward=‘REJECT’
firewall.ns_user_include=include
firewall.ns_user_include.path=‘/etc/firewall.user’
firewall.ns_user_include.fw4_compatible=‘1’
firewall.ns_hs_include=include
firewall.ns_hs_include.type=‘script’
firewall.ns_hs_include.path=‘/opt/icaro/dedalo/dedalo.user’
firewall.ns_hs_include.fw4_compatible=‘1’
firewall.ns_d51be989=redirect
firewall.ns_d51be989.src=‘wan’
firewall.ns_d51be989.target=‘DNAT’
firewall.ns_d51be989.dest_ip=‘10.20.30.11’
firewall.ns_d51be989.enabled=‘1’
firewall.ns_d51be989.log=‘0’
firewall.ns_d51be989.name=‘Vonage SIP’
firewall.ns_d51be989.proto=‘tcp’ ‘udp’
firewall.ns_d51be989.reflection=‘0’
firewall.ns_d51be989.src_dport=‘5061’
firewall.ns_3642eaf8=redirect
firewall.ns_3642eaf8.src=‘wan’
firewall.ns_3642eaf8.target=‘DNAT’
firewall.ns_3642eaf8.dest_ip=‘10.20.30.11’
firewall.ns_3642eaf8.enabled=‘1’
firewall.ns_3642eaf8.log=‘0’
firewall.ns_3642eaf8.name=‘RTP’
firewall.ns_3642eaf8.proto=‘tcp’ ‘udp’
firewall.ns_3642eaf8.reflection=‘0’
firewall.ns_3642eaf8.src_dport=‘10000-20000’
firewall.ns_lan=zone
firewall.ns_lan.name=‘lan’
firewall.ns_lan.input=‘ACCEPT’
firewall.ns_lan.output=‘ACCEPT’
firewall.ns_lan.forward=‘ACCEPT’
firewall.ns_lan.network=‘LAN’
firewall.ns_wan=zone
firewall.ns_wan.name=‘wan’
firewall.ns_wan.input=‘REJECT’
firewall.ns_wan.output=‘ACCEPT’
firewall.ns_wan.forward=‘REJECT’
firewall.ns_wan.masq=‘1’
firewall.ns_wan.mtu_fix=‘1’
firewall.ns_wan.network=‘WAN1’
firewall.ns_94d62263=zone
firewall.ns_94d62263.name=‘rwopenvpn’
firewall.ns_94d62263.input=‘ACCEPT’
firewall.ns_94d62263.output=‘ACCEPT’
firewall.ns_94d62263.forward=‘REJECT’
firewall.ns_94d62263.ns_tag=‘automated’
firewall.ns_94d62263.ns_link=‘openvpn/ns_roadwarrior_noremove’
firewall.ns_94d62263.device=‘tunrw1’
firewall.ns_dmz=zone
firewall.ns_dmz.name=‘dmz’
firewall.ns_dmz.input=‘DROP’
firewall.ns_dmz.forward=‘DROP’
firewall.ns_dmz.output=‘ACCEPT’
firewall.ns_lan2wan=forwarding
firewall.ns_lan2wan.src=‘lan’
firewall.ns_lan2wan.dest=‘wan’
firewall.ns_355a6b06=forwarding
firewall.ns_355a6b06.src=‘rwopenvpn’
firewall.ns_355a6b06.dest=‘lan’
firewall.ns_355a6b06.ns_tag=‘automated’
firewall.ns_355a6b06.ns_link=‘openvpn/ns_roadwarrior_noremove’
firewall.ns_528b1b4f=forwarding
firewall.ns_528b1b4f.src=‘lan’
firewall.ns_528b1b4f.dest=‘rwopenvpn’
firewall.ns_528b1b4f.ns_tag=‘automated’
firewall.ns_528b1b4f.ns_link=‘openvpn/ns_roadwarrior_noremove’
firewall.ns_020ef7ad=forwarding
firewall.ns_020ef7ad.src=‘rwopenvpn’
firewall.ns_020ef7ad.dest=‘wan’
firewall.ns_020ef7ad.ns_tag=‘automated’
firewall.ns_020ef7ad.ns_link=‘openvpn/ns_roadwarrior_noremove’
firewall.ns_dmz2wan=forwarding
firewall.ns_dmz2wan.src=‘dmz’
firewall.ns_dmz2wan.dest=‘wan’
firewall.ns_allow_webui=rule
firewall.ns_allow_webui.name=‘Allow-UI-from-WAN’
firewall.ns_allow_webui.proto=‘tcp’
firewall.ns_allow_webui.src=‘wan’
firewall.ns_allow_webui.dest_port=‘443’
firewall.ns_allow_webui.target=‘ACCEPT’
firewall.ns_dhcp_wan=rule
firewall.ns_dhcp_wan.name=‘Allow-DHCP-Renew’
firewall.ns_dhcp_wan.src=‘wan’
firewall.ns_dhcp_wan.proto=‘udp’
firewall.ns_dhcp_wan.dest_port=‘68’
firewall.ns_dhcp_wan.target=‘ACCEPT’
firewall.ns_dhcp_wan.family=‘ipv4’
firewall.ns_ping_wan=rule
firewall.ns_ping_wan.name=‘Allow-Ping’
firewall.ns_ping_wan.src=‘wan’
firewall.ns_ping_wan.proto=‘icmp’
firewall.ns_ping_wan.icmp_type=‘echo-request’
firewall.ns_ping_wan.family=‘ipv4’
firewall.ns_ping_wan.target=‘ACCEPT’
firewall.ns_allow_OpenVPNRW1=rule
firewall.ns_allow_OpenVPNRW1.name=‘Allow-OpenVPNRW1’
firewall.ns_allow_OpenVPNRW1.ns_service=‘custom’
firewall.ns_allow_OpenVPNRW1.src=‘wan’
firewall.ns_allow_OpenVPNRW1.dest_port=‘1194’
firewall.ns_allow_OpenVPNRW1.proto=‘tcp’ ‘udp’
firewall.ns_allow_OpenVPNRW1.target=‘ACCEPT’
firewall.ns_allow_OpenVPNRW1.enabled=‘1’
firewall.ns_allow_OpenVPNRW1.ns_tag=‘automated’
firewall.ns_allow_OpenVPNRW1.ns_link=‘openvpn/ns_roadwarrior1’
firewall.ns_8994694e=redirect
firewall.ns_8994694e.src=‘wan’
firewall.ns_8994694e.target=‘DNAT’
firewall.ns_8994694e.dest_ip=‘10.20.20.25’
firewall.ns_8994694e.enabled=‘1’
firewall.ns_8994694e.name=‘RDP’
firewall.ns_8994694e.reflection=‘0’
firewall.ns_8994694e.src_dport=‘3389’
firewall.ns_8994694e.dest_port=‘3389’
firewall.ns_8994694e.proto=‘udp’ 'tcp

Did you recreate the rule as in your config it’s firewall.ns_allow_webui and in mine it’s firewall.ns_allow_ui (without web)

The https port 443 is allowed but you wanted to reach the firewall at port 9090.
Does it work on 443 like https://10.20.20.1

Here are the settings for that rule to compare:

root@NethSec1:~# uci show firewall.ns_allow_ui
firewall.ns_allow_ui=rule
firewall.ns_allow_ui.name='Allow-UI-from-WAN'
firewall.ns_allow_ui.src='wan'
firewall.ns_allow_ui.dest_port='9090'
firewall.ns_allow_ui.target='ACCEPT'
firewall.ns_allow_ui.ns_service='custom'
firewall.ns_allow_ui.proto='tcp'
firewall.ns_allow_ui.enabled='1'
firewall.ns_allow_ui.log='0'

Are the virtual network devices ok and the fitewall disabled?

No firewall at datacenter or node (and there is only one node)


Here is network config. I can log into both the LAN IP for Proxmox on of 10.20.20.100:8006 and the WAN IP of Proxox at 10.20.30.100:8006. The LAN IP of the Xfinity router is 10.20.30.1, and the WAN port of Nethsecurity is 10.20.30.110 (DHCP reservation in the Xfinity router)

Marcus, I should have added, really good questions. Thanks for the refresher on how to debug this stuff.

There is one odd thing i discovered disabling Threat Shield IP and DNS. Disabling both did not allow the UI to work, so i re-enabled both. There is a reference to unreachable path /etc/firewall.user . Here is the command input sequence and output:

root@Frodowall:~# uci set adblock.global.adb_enabled=1
root@Frodowall:~# uci commit adblock
root@Frodowall:~# /etc/init.d/adblock restart
Section ns_d51be989 (Vonage SIP) does not specify a destination, assuming ‘wan’
Section ns_3642eaf8 (RTP) does not specify a destination, assuming ‘wan’
Section ns_8994694e (RDP) does not specify a destination, assuming ‘lan’
Section ns_user_include specifies unreachable path ‘/etc/firewall.user’, ignoring section
Automatically including ‘/usr/share/nftables.d/chain-pre/input/20-don.nft’
Automatically including ‘/usr/share/nftables.d/chain-pre/srcnat/20netmap.nft’
Automatically including ‘/usr/share/nftables.d/chain-post/dstnat/20netmap.nft’

Markus, Thanks for looking at the rules. I did not create the ns_allow_webui rule, so some config invoked through the UI created that webui rule. Following your allow_ui rule, I added the enabled=1, changed the port to 9090, and set log=0 so it looks like yours except it says allow_webui instead of allow_ui. I still cannot access the UI from the LAN or from the WAN on port 9090.

What I don’t understand is that LAN access is not in the firewall rules file, so that must be enabled by default elsewhere. Here is the rule now: firewall.ns_allow_webui=rule
firewall.ns_allow_webui.name=‘Allow-UI-from-WAN’
firewall.ns_allow_webui.proto=‘tcp’
firewall.ns_allow_webui.src=‘wan’
firewall.ns_allow_webui.dest_port=‘9090’
firewall.ns_allow_webui.target=‘ACCEPT’
firewall.ns_allow_webui.ns_service=‘custom’
firewall.ns_allow_webui.enabled=‘1’
firewall.ns_allow_webui.log=‘0’

Maybe related, please run the commends from that post:

Blank lines inserted before/after commands for readability.
comment lines in output from last command caused the display to be bold and bigger font:

root@Frodowall:~# uci show ns-ui

ns-ui.config=main
ns-ui.config.luci_enable=‘0’
ns-ui.config.nsui_enable=‘1’
ns-ui.config.nsui_extra_port=‘9090’
ns-ui.config.nsui_extra_enable=‘1’
ns-ui.config.api_server_delay=‘1’

root@Frodowall:~# find /etc/nginx/

/etc/nginx/
/etc/nginx/conf.d
/etc/nginx/conf.d/00ns.locations
/etc/nginx/conf.d/_lan.crt
/etc/nginx/conf.d/_lan.key
/etc/nginx/conf.d/ns-ui.conf
/etc/nginx/conf.d/luci.locations.disabled
/etc/nginx/fastcgi_params
/etc/nginx/koi-utf
/etc/nginx/koi-win
/etc/nginx/mime.types
/etc/nginx/module.d
/etc/nginx/module.d/ngx_http_ubus.module
/etc/nginx/module.d/luci.module
/etc/nginx/restrict_locally
/etc/nginx/scgi_params
/etc/nginx/uci.conf
/etc/nginx/uci.conf.template
/etc/nginx/uwsgi_params
/etc/nginx/win-utf

root@Frodowall:~# /usr/sbin/nginx -T -c /etc/nginx/uci.conf

2025/07/23 10:52:31 [emerg] 18613#0: module “ngx_http_ubus_module” is already loaded in /etc/nginx/module.d/ngx_http_ubus.module:1
nginx: configuration file /etc/nginx/uci.conf test failed

root@Frodowall:~# cat /etc/nginx/uci.conf

This file is re-created when Nginx starts.

Consider using UCI or creating files in /etc/nginx/conf.d/ for configuration.

Parsing UCI configuration is skipped if uci set nginx.global.uci_enable=false

For details see: Testing to determine if you are a bot!

UCI_CONF_VERSION=1.2

worker_processes auto;

user root;

include module.d/*.module;

events {}

http {
access_log off;
log_format openwrt
‘$request_method $scheme://$host$request_uri => $status’
’ (${body_bytes_sent}B in ${request_time}s) ← $http_referer’;

    include mime.types;
    default_type application/octet-stream;
    sendfile on;

Which version of NethSecurity do you use?

root@keepout:~# cat /etc/os-release | grep NAME
NAME="NethSecurity"
PRETTY_NAME="NethSecurity 8-24.10.0-ns.1.6.0"

Nginx is not starting because there’s a wrong config.

The module is loaded twice as both files have the same content:

load_module /usr/lib/nginx/modules/ngx_http_ubus_module.so;

I found luci.module on a long running firewall but ngx_http_ubus.module on a fresh testing version. On the other hand luci.module is still mentioned in the code.
So I’d move away the file ngx_http_ubus.module so it can be restored in case something goes wrong:

mv /etc/nginx/module.d/ngx_http_ubus.module ~

Restart nginx:

/etc/init.d/nginx restart

I have been running the latest updates since I installed the first version shortly after it came out. I haven’t done a fresh install in a very long time (not sure i ever did) I don’t recall doing anything that would account for two invocations on
NAME=“NethSecurity”
PRETTY_NAME=“NethSecurity 8.6.0-dev+dd429746d.20250721134104”

following your exact instructions fixed it: THANK YOU.

mv /etc/nginx/module.d/ngx_http_ubus.module ~

Restart nginx:

/etc/init.d/nginx restart

You’re welcome.

But it seems you updated using a development image.

If that’s not wanted you could download a backup to be safe and update the NethSec using a stable image from Download — NethSecurity documentation

EDIT:

I tested the image downgrade to stable and got issues using the update function so you may need to reinstall NethSecurity using a stable image.

I stepped away and was going to write you to confirm that something in the combo of my long history of using Dev stuff and the latest Dev image likely caused the problem, because, like I said, I have only used the UI to change things. I appreciate the suggestion to not do that, but even though i am not a regular Linux CLI user, I am perfectly comfortable with occasional glitches. This is a home system, two people with phones desktops, and streaming TVs, and if I have problems I can bypass Nethsecurity and use my Xfinity router (which i didn’t need to do in this case). Plus, it’s has been fascinating asking Grok how to use the Netserver UI. :slight_smile:

But thinking about your suggestion, it would not be hard for me to do a fresh install, since (a) it’s on Proxmox, and (b) I do config backups.

Hello, I’ve missed completely the discussion! I could’ve easily spotted the issue for you :sweat_smile:

Just to give you some insights, we had an issue while migrating to the new build system for NethSec. Some of the dev builds didn’t have the correct packages compiled/replaced from our forks. The commit that solved the issue is here: build: override packages correctly · NethServer/nethsecurity@f610905 · GitHub.

Nginx got updated recently, but we’re keeping our fork for now due to the config changes that are made to it. Due to the fail in the replacement from upstream, your configuration has been “updated” by the package update, causing the issues.

Just a reminder, don’t try the dev builds if you don’t backup first :beers:
This is cause config will be incrementally updated by the packages, a fresh flash with updated configuration might give some headaches!

Tbaile,

Since I first switched from Nethserver to Nethsecurity, I have been updating pretty much whenever there is one shown in the UI, and while I backup the config frequently, I haven’t bothered backing up the Nethsecurity images. Why not? As long as I am physically at home, I can unplug the Nethserver appliance and be back online by changing about 3 Ethernet cables, not counting whatever diagnoses I have to do before making that decision, and other than the config, there is nothing to lose.

I have the same attitude about Windows. I have been on Canary releases on my two Windows machines since early on in Windows 10’s life. Once in a great while, I get stung.

But I hadn’t given any thought to what your dev builds actually are, Thanks for explaining it. In another lifetime, I’d enjoy a friendly discussion with you folks on the pros and cons of forking open source projects. The costs of doing so always get bigger over time.

Oh don’t get me wrong, if you feel the need to go dev releases, please do so! :grimacing:

This was a one-issue due to the change of the build system, it got smaller and faster. However expect more dev images from now on, since we publish a release every commit in the main branch.

We 100% know, this is why the forks tend to change as little as possible (or not do them at all), in the case of nginx, we needed to add our custom config for managing the NethSec UI, a simple patch was not possible