Cannot access web UI except if my IP address in specific range

[shrinkingmedic]

Running latest OS.

All internal addresses start with 10.0.x with a subnet mask of 255.255.0.0

My NAS is at 10.0.2.3

I cannot access the web administration interface unless my IP is in range 10.0.0.x (not just 10.0.x as I would expect given subnet mask)

For example, my computer at 10.0.3.4 cannot access the web ui at 10.0.2.3, but any interface at 10.0.0.x can.

I've submitted a help ticket, but I'm sure one of you folks has an easy solution to this simple problem.

Cheers,
Dave

[dolbyman]

"Latest OS" is bogus ... Please always state the NAS model and OS (with version and build)

With so little info given my guess is either on QuFirewall or access protection enabled..please check those

[dosborne]

Although it is likely one of the two things dolbyman mentioned, it could also be your atypical netmask. This could be topology related / misconfigured (a switch for example) or simply that the unspecified firmware version doesn't handle a non-typical mask properly.

[lmann]

I'm having this same issue, or very close to it:

My QNAP is on a 10/24 subnet (eg 10.1.2.10/24), and I can access the admin web screens from anything in that subnet (10.1.2.x), but if I try to load the admin screens from a machine in a different subnet (eg 10.1.3.x) the admin pages will not load. My physical switch and router are fine, as I can load pages from any other server on the QNAP's subnet fine, and I can even ping the QNAP fine from the other subnet, but I cannot load the admin screens (either http or https). If I SSH into the QNAP, the net mask is correct at 255.255.255.0, the default gateway showing in netstat -r is correct, and I can ping from the QNAP to hosts on other subnets in question. I'm sure this must be something simple, but I can't figure it out yet. Running QTS 5.1.1.2491 on a TS-673. Any ideas anyone?

[dosborne]

Disable the QNAP firewall if you are running it.
Check you Allow/Deny list setting in the admin GUI.

[lmann]

LOL, so simple...you were correct that it was the Allow/Deny list in the network security screen that had an entry to allow only from the host subnet. Not sure where that came from, perhaps container station or something, but in any case it's fixed now, so thank you very much.