#429 Xigma NAS webgui not responding to clients outside LAN
I cannot get Xigma NAS WebGUI to respond to clients outside the LAN that the NAS is sitting on. I can watch traffic on the LAN from another system on the same LAN. I see packets from the external client heading to the NAS port 80, but I see no responses going back to the client outside the network. Just to confirm that the packets are, in fact, reaching the NAS box, I pulled up a console shell on the Xigma NAS itself to run tcpdump and repeated the experiment. I saw the incoming packets, but no return packets.
My "external" network is not really external. The typical home configuration would have the ISP link from the modem as the external network. Here, the network outside the LAN where the xigma nas is located is actually another IANA private range address network (RFC1918?). ISP addresses would be publicly-addressable.
I suspect that Xigma NAS might be refusing the incoming requests silently because it sees these as a threat. In the typical scenario, that would be sensible and necessary precaution. The problem is when a user has a different type of network configuration. So, if my theory is close, there would need to be some kind of override or procedure to permit RFC1918 addresses.
I have carefully checked the LAN configurations, and the routers, and I do not find any problems. I am able to reach a webserver on port 80 on that other host on the same LAN I referred to earlier. The router forwarding is configured to allow port 80 regardless of the target host within the LAN.
I have to conclude that problem is the result of sensible configuration on the part of xigma NAS, but somewhat inflexible for slightly different network configurations. I can work around this for the time being, but I hope that a supported solution will be offered going forward. Thank you.
System> General configuration
Authorized Hosts :Empty: only lan guests are allowed.So either you specify external ip or you authorize everyone by checking the item:
Bypass Host Authorization Rules
There is no bug, it's more of a help topic on the forum.
Last edit: sleid 2020-12-06
I have tried these steps numerous times now, but to be fair, I tried them again today.
I have tried disabling (bypass host auth rules), I have tried setting the source IP address (external ip), and I have tried doing both together. There has been no change in behavior.
Again, I enabled tcpdump on the xigma nas console, and I still see requests coming in, but no response from the xigma nas.
One thing I note is that, in the console interface, when I go into the "configure hosts allow," it doesn't seem to be saving my selections. The webgui interface does save my changes (even over a logout/login again). But, no matter what I have tried, I still cannot seem to get this to work.
(The IP addresses I enter into the bypass field is the same as the source IP address I see in the tcpdump output. And I have tried entering the exact IP address, as well as the cidr network address to no avail.) Thank you for your response.
EDIT: Is a reboot required after any of these changes in order to take effect? I don't think I've tried that, but I'd think that would be unnecessary.
Last edit: HarryM 2020-12-06
I think there may have a misconfiguration -- when I do a netstat -rn in a xigma nas shell, I do not see a default route. The only routes defined are for the local network and the xigma nas host itself.
Now this all makes sense. So when another system on the same LAN with the NAS hits the webgui, xigma NAS can respond because it has a route defined for the LAN. But when a packet arrives from outside the LAN, the nas will fail to reply (it will error). It doesn't have a route back to the source, which is outside the local area network. So a default route MUST be defined. (I don't recall monkeying around with the routing table on xigma NAS, but maybe that occurred as the result of other configuration, I really don't know.)
I'm not a BSD guy, and my networking knowledge is not vast. I know how to do these things on Linux systems, and the man page for bsd route indicates a system file where these things can be configured. Some direction here would be helpful.
Thanks again.
You can add routes in Network > Static Routes.
You can review routes in Diagnostics > Routing Tables
Default gateway should be configured by default in future releases of xigma NAS.
I added a route entry with the destination as 0.0.0.0/32 and applied it. But it does not show up in the routing tables (it is persistently seen in the network->static routes though). And I still cannot reach the NAS from outside the lan.
The default route is there and it is using the gateway of the LAN interface.
If the static route is not showing in the routing tables, usually the gateway address of that route is wrong.
The below netstat shows a default route using gateway 192.168.0.11. In addition, a 2nd network (192.168.2.0/24) is at gateway 192.168.0.110;
xigmanasa: ~# netstat -nrW -f inet
Routing tables
Internet:
Destination Gateway Flags Use Mtu Netif Expire
default 192.168.0.11 UGS 42 1500 em0
127.0.0.1 link#4 UH 0 16384 lo0
192.168.0.0/24 link#1 U 3923 1500 em0
192.168.0.44 link#1 UHS 0 16384 lo0
192.168.2.0/24 192.168.0.110 UGS 0 1500 em0
xigmanasa: ~#
/etc/rc.conf:
...
defaultrouter="192.168.0.11"
...
route_conf_d5db1c8a_9f47_4fd9_85ef_0c5144d87123="-net 192.168.2.0/24 192.168.0.110"
static_routes=" conf_d5db1c8a_9f47_4fd9_85ef_0c5144d87123"
...
If you want to learn more about routing/gateways, please read https://www.freebsd.org/doc/handbook/network-routing.html
I think I've figured out where the locus of this problem is even if it does not solve the problem. The reason I am resurrecting this issue is because I recently made some changes to my LAN which resulted in this same stubborn problem arising again after a few years of a working xigmanas (and LAN) configuration. (I had finally gotten it working after my last post, and thank you for help.)
The difficulty seems to be in the way that /etc/rc.d/lighttpd generates the lighttpd.conf file. Now, I admit I am not familiar with all of the implementational details of xigmanas, but I can see that the rc script always generates
$HTTPS["remoteip"] == "192.168.x.y"where that address seems to come from the information for the network interface.The trouble with this is that it does not allow for CIDR type addresses. So, for instance, for a xigmanas IP address like 192.168.12.10/28, the result would look like
I am assuming that this setting is passed more or lessver batim to the perl interpreter. It won't match for a remote address like 192.168.12.50 (where the webgui client would ideally be located); it will result in a failed match, and I can verify this by running lighttpd in with debugging enabled. The remote address is on a different subnet for a CIDR/28 network, and that is precisely the problem. (And don't worry, I made a copy of the lighttpd.conf file as well as the rc.d init script file for my investigation). This will, of course, result in blocking the remote 192.168.12.50 web client from accessing the webgui.
The problem is that one would need something more like
$HTTPS["remoteip"] =~ "[some PCRE here]"or similar for a match to be successful. And that would require a change to the rc script.
Now, I note that the rc script does provide for an alternate mechanism for obtaining authorized webgui clients, but I don't know how to make that work. It seems to rely on xigmanas's XML configuration file, and while I think I can see where to hack it manually to insert the necessary fields, I'd prefer not to. I'm sure you would not recommend that. Perhaps there is a means to accomplish the same through the webgui, but I have not found that as of yet. I looked at the docs but cannot tell where to look to address this issue.
The modifications I have made to my LAN seem to have all been successful. I have about 8 NFS clients on the LAN, which consists of a number of subnets, and every one of them is able to mount an NFS share from the xigmanas. Also, I can ping all of my hosts from the webgui by their (local) DNS hostnames using the very handy built-in diagnostics page. I have a dnsmasq server elsewhere on the network and I have double-checked all of the addresses. So I have not defined or re-defined any hosts in the xigmanas (under network->hosts). Furthermore, the other hosts on the LAN, even outside the subnets involved here, can all talk directly to each other without issue. I am pretty confident there is no LAN configuration problem here.
The only issue I am having after the LAN changes is accessing the webgui on xigmanas from outside the subnet to which the xigmanas is connected. I have to use another host, which is OK, but a bit inconvenient. I could move the xigmanas to an address on the same subnet where the desired webgui client is, but that isn't my goal really. I want to keep these separate for a while until I have completed some other changes to the LAN.
There are multiple options available, no need to change the rc script.
a) Specify required network addresses / ranges manually in the Hosts Allow field, i.e.
192.168.12.50 192.168.12.10/28 127.0.0.1. This will overwrite the default (LAN boxip/netmask + localhost).b) Add your special configuration to the Additional Parameters field, i.e.
$HTTP["remoteip"] =~ "[your pcre]" { url.access-deny = ( "~", ".inc", ".htpasswd" ) }Ah, OK. That's what I needed to know. It wasn't clear to me from the documentation where to do this. And the name "Additional Parameters" just wasn't calling out to me.
So maybe an update to the docs then? Include the example you just gave.
And thanks again.