0

Long story short, I made a silly mistake.

I had setup my QNAP NAS to use the IP address 192.168.1.1/24 and 192.168.1.254 as the default gateway.

Using the web configuration interface, I then changed from this network to another and the first thing I did was to change the static IP to 192.168.123.1/24. Unfortunately, the default gateway setting isn't available in the same place, so I just thought I'd change it just after setting the new IP and netmask.

This locked me out of the NAS: when I try to reach it using HTTP on its new IP adress, the packets are routed correctly, but the NAS never responds (I think that's because it's instructed to route via 192.168.1.254, which is on a different subnet than its network interface, so the packets never leave the NAS).

Is there any way I could reach it again via HTTP ? I tried different things using Wireshark to debug and multiple interface settings on my computer but I never receive responses to the TCP packets sent to the NAS.

Interesting fact: ping works. It don't know ICMP very well so I don't understand how the responses are sent to my computer, but they sure are!

As a sidenote, I can't reset the network configuration of the NAS as I had disabled the quick reset via the reset button. The ultimate step would be to extract the disks, copy the data and start a new configuration from scratch.

MFlop
  • 101
  • Just to confirm, did you try to put your computer on 182.168.123.? – davidgo May 13 '20 at 08:35
  • Yes, I assigned 192.168.123.45/24 to my computer and Wireshark confirms the packets are sent, but the response never comes and my computer sends TCP retransmissions :( – MFlop May 13 '20 at 08:40
  • If your computer has an ip address in the same network as the NAS then the DG address configured in the NAS has nothing to do with it. Traffic on the same network doesn't go through the DG, as evidenced by your ping. Something else is going on. Have you tried power cycling the NAS and trying again? – joeqwerty May 13 '20 at 11:15
  • I did try to power cycle the NAS. I agree with you on the fact it shouldn't try to reach the DG as both interfaces are in the same subnet but these are the only settings I changed. I'll run a port scan to see if I can reach any other service. The http server could be faulty but it has no reason to be. – MFlop May 13 '20 at 11:22
  • nmap reports all the following TCP ports as filtered: ftp/ssh/http/netbios/rsync. I'm trying to wonder if the internal firewall could be the culprit. – MFlop May 13 '20 at 13:03

2 Answers2

0

I'll provide my own answer as I managed to recover from my very own mistake.

I didn't remember that I had setup access whitelists a long time ago. So when I changed the subnet of the network interface, the new subnet wasn't whitelisted and couldn't access any of the NAS services. The only thing allowed was ICMP.

I discovered when booting the NAS that the SSH service starts before firewall rules are applied. It's possible to connect using SSH for a few seconds during boot. I monitored the ethernet link and spammed the 22 port when necessary and was able to establish an SSH connection just before the NAS locks me out.

Then, I openend QNAP's configuration file (/etc/config/uLinux.conf) and disabled firewall whitelists by replacing "IP Security = 1" by "IP Security = 3" (disabled).

Next step was to reboot and everything was fine again.

MFlop
  • 101
-1

You could try to access the server on the local link IPv6 address.

First get the local link address of the host.

Then setup a tunnel with ssh, connecting to any host (even localhost) in the same network segment. Something like:

$ ssh -L 8181:[fe80::2254:e912:fe32:20d0%eth0]:80 chosenhost

This will forward your local port 8181 (IPv4) to port 80 of the NAS (IPv6). Change ports if necessary (443 for example) and put the actual network device after the %.

Then visit http://localhost:8181 (or https://) and, if the NAS is listening on the local link IPv6 address, you will be able to access it.

You need the tunnel because I don't know of any browser that can visit a local link IPv6 address. If your browser does, you could then you could visit the NAS directly.

Eduardo Trápani
  • 1,210
  • 8
  • 12
  • Thank you for your answer. That was a good idea but unfortunately I had disabled IPv6 and the ssh server doesn't allow port forwarding. I ended up finding the problem and will post a detailed solution if it can help other people. – MFlop May 14 '20 at 08:35