LGM-OS
documentation

VPN, DNS and DHCP.

The NAS's network services (VPN, DNS and DHCP)

These three features turn the NAS into the centre of your home network: you get in from outside as if you were in the living room (VPN), your machines are called by name instead of by IP (DNS) and it is the NAS —not the router— that hands out the addresses (DHCP).

They are configured in Control Panel → Network services, each on its own tab.

ServiceWhat it doesPortWhat happens if it fails
VPN (WireGuard)Encrypted remote access to your whole network51820/UDPYou lose access from outside. Inside the house, nothing changes
DNS (dnsmasq)Local names, caching and forwarding53 TCP+UDPThe machines using it stop resolving names: it will look like "there is no internet"
DHCP (dnsmasq)Hands out IP, mask, gateway and DNS67/68 UDPMachines stop getting an IP: the whole house is left without a network

They are ordered by risk, and that is also the order in which to turn them on. The VPN cannot break anything that already works; DHCP can. If you are only going to turn one on, make it the VPN. If you are going to turn DHCP on, read the whole of section 3 —and especially "If you lose the network"before touching anything.

0. Before you start

Whichever of the three you are going to use, have this at hand and written down on paper or on your phone (not in a document that lives on the NAS or that needs the internet to open).

  • A fixed IP for the NAS. A DHCP reservation on the router or a static IP in Control Panel → Network. A NAS that changes IP breaks the VPN port forwarding, the DNS records and its own DHCP.
  • The router's IP and its admin password (usually on the sticker on the device). You will need it to open the VPN port and to turn its DHCP off.
  • Physical access to the NAS (keyboard and monitor) or SSH already working. The console shows the machine's IP and the lgm command gives you the recovery menu.
  • Do it with time to spare and with nobody connected. Changing DHCP in the middle of somebody else's video call has social consequences.
  • Never make these changes remotely, from outside the house: if something goes wrong, the very connection you are administering the NAS with is the first thing to drop.

1. VPN (WireGuard)

With the VPN on, your phone or laptop join the home network from anywhere: the NAS panel, the shared folders, the printer or the cameras answer on their local IP just as if you were on the sofa. And without publishing a single service on the internet: the router only has one UDP port open that answers absolutely nothing to anyone without the right key.

Compared with publishing the NAS with a reverse proxy, the VPN is the safest option and the one that needs the least maintenance. Its drawback: you have to install a client on every device, so it is no use for sharing with people outside your household.

1.1 Opening the port on the router

A single port forward:

External portProtocolDestinationWhat for
51820UDPNAS-IP:51820The whole tunnel

Two classic mistakes: choosing TCP (WireGuard is UDP and only UDP; with TCP not a single packet comes back) and forwarding to a NAS IP that later changes.

That forward is the only manual part: the NAS firewall is managed by the panel itself. When you turn the VPN on, the udp 51820 rule is added on its own (it appears in Security → Firewall as "WireGuard VPN (managed by LGM-OS)") and turning it off withdraws it. Do not add it by hand: the rule you create will have a different identifier, the panel will not recognise it and the port will stay open forever even if you turn the VPN off.

Dynamic IP: your public IP changes every few days, and the client needs to know where to call. Set up a dynamic domain (DDNS) following step 3 of the external access guide and use that name (myhouse.duckdns.org) as the VPN's server instead of the IP.

If you are behind CGNAT (your ISP does not give you your own public IP) the forward will not work, and neither will the VPN. Check by comparing curl -s https://api.ipify.org with the WAN IP the router shows: if they do not match, or if the router's starts with 100.64.100.127., there is CGNAT. The fix: ask your ISP for a public IP (it is usually free).

1.2 Creating each device's profile

In Control Panel → Network services → VPN: turn the server on and add one device ("peer") for every phone, tablet or computer that is going to connect.

  • One profile per device, always. Do not reuse the same one on your phone and your laptop: both would have the same address inside the tunnel and would tread on each other. Separate profiles also let you revoke only the one on the phone you lost.
  • Which traffic goes through the tunnel (what WireGuard calls AllowedIPs):
    • Only the home network (for example 192.168.1.0/24): you browse over your mobile carrier and only what goes to the NAS or the printer enters the tunnel. It uses less battery and does not slow the rest down.
    • All traffic (0.0.0.0/0): as well as reaching home, you go out to the internet over your home connection. That is what you want on hotel or airport Wi-Fi, and also if you use the NAS's DNS while away.
  • The profile includes the device's private key. The NAS does not need it at all after handing it to you: if you lose the profile, another is generated; it is not "recovered".

1.3 Installing the client

SystemWhere fromWhat it is called
AndroidGoogle PlayWireGuard, by WireGuard Development Team
iPhone / iPadApp StoreWireGuard, by the same author
Windowshttps://www.wireguard.com/install/WireGuard for Windows
macOSApp Store or the same pageWireGuard
Linuxsudo apt install wireguardused with wg-quick

Always download from the official store or from wireguard.com. There are clones in the stores with similar names that ask for permissions that make no sense.

1.4 On a phone: scanning the QR code

  1. In the panel, open the device's profile and press View QR code.
  2. On the phone, open WireGuard and tap the + button (bottom right).
  3. Choose Scan from QR code and grant the camera permission.
  4. Point it at the computer screen. When it recognises it, it asks for a name for the tunnel (Home, for example). Accept.
  5. Turn the tunnel's switch on. The first time, Android or iOS will ask you to authorise a "VPN configuration": that is normal, accept it.
⚠️ That QR is the key to your network. It contains the device's private key in the clear: whoever photographs it can get into your house from anywhere in the world. Do not share it, do not paste it into a chat and do not leave it in a screenshot. If a phone is lost or you replace it, delete its profile in the panel: that key stops working instantly.

1.5 On a computer: importing the configuration file

  1. In the panel, Download configuration saves a .conf file (for example laptop.conf).
  2. Windows / macOS: open WireGuard → Import tunnel(s) from file → pick the .confActivate.
  3. Linux:
sudo install -m 600 laptop.conf /etc/wireguard/home.conf
sudo wg-quick up home                       # connect now
sudo systemctl enable --now wg-quick@home   # ...and on every boot
  1. Delete the .conf from your downloads folder once imported: it is as sensitive as the QR.

1.6 Checking the tunnel really works

Test from outside the house. With the phone on mobile data and Wi-Fi off; if you test it from your own Wi-Fi it may fail even when everything is right (many routers cannot forward a connection back into their own network: it is called hairpin NAT).

On the client, with the tunnel active, look at the latest handshake: if it shows a recent time and the data counters go up, the tunnel is up. Then the real test:

ping 192.168.1.50            # the NAS's local IP, from the connected machine

and open https://192.168.1.50:5000 in the browser: the panel should appear. If you also use the full tunnel, https://api.ipify.org has to return your home's public IP, not your mobile carrier's.

From the NAS itself, the view from inside:

sudo wg show

For each device you will see latest handshake (how long ago it spoke) and transfer (how much data has passed). A peer that has never done a handshake has never connected at all: the problem is in the router or in the profile, not in the NAS.

1.7 If the VPN does not connect

SymptomUsual causeWhat to do
There is never a handshakeThe port does not reach the NASCheck the 51820 UDP forward, the firewall rule and that there is no CGNAT
Never a handshake, and the DDNS is newThe name does not resolve yet or points at the old IPgetent hosts myhouse.duckdns.org; wait a few minutes
There is a handshake but I cannot reach the NASThe tunnel does not include your local networkCheck the profile's allowed traffic (it has to cover 192.168.1.0/24)
There is a handshake, it works at a friend's house but not on another networkRange clash: that network uses the same 192.168.1.x as your houseChange your home range to an uncommon one (192.168.37.0/24) and adjust the profile
It connects but pages load halfwayMTU: some mobile networks do not swallow big packetsLower the client's MTU to 1280
It drops a minute after you stop using itThe NAT in between closes the sessionTurn PersistentKeepalive (25 s) on in the profile
It connects, but names do not resolveThe profile carries no DNSSet the NAS as the tunnel's DNS (and see section 2)

Diagnostics on the NAS:

sudo systemctl status wg-quick@wg0
sudo wg show
sudo ss -lunp | grep 51820        # is it listening?
sudo journalctl -u wg-quick@wg0 -n 50

2. DNS server

DNS translates names into addresses. With the NAS's one on you get three things:

  • Names for your gadgets: nas.casa instead of 192.168.1.50, printer.casa, camera.casa. No more memorising IPs or looking them up on a scrap of paper.
  • Caching: repeated queries are answered from the NAS, without going out to the internet.
  • One single place to change things: if the NAS changes IP, you fix it in one record and the whole house finds out.

It works the same through the VPN: connected from outside, nas.casa still resolves.

2.1 Turning the service on

In Control Panel → Network services → DNS you choose the forwarders (where the NAS asks about what it does not know: your ISP's, 1.1.1.1, 9.9.9.9…), the local domain and the local records. On save, the panel writes the configuration and starts the service.

Port 53 has to be free. A normal Debian 12 installation does not occupy it, but many virtual machine and cloud images ship with systemd-resolved on, and then the DNS server does not start. Check it and free it:

sudo ss -lunp | grep ':53'          # who is listening on 53?
sudo systemctl disable --now systemd-resolved

If you disable systemd-resolved, make sure the NAS itself keeps a valid DNS or it will be left unable to resolve names (and unable to update):

ls -l /etc/resolv.conf              # if it is a link to ../run/systemd/resolve/...:
sudo rm /etc/resolv.conf
# The first is the NAS's own dnsmasq; the second is the safety net so the machine keeps
# resolving while the service is stopped.
printf 'nameserver 127.0.0.1\nnameserver 1.1.1.1\n' | sudo tee /etc/resolv.conf

2.2 The local records

A record is a name → IP pair:

NameIPWhat it is
nas.casa192.168.1.50The NAS
printer.casa192.168.1.20The network printer
camera.casa192.168.1.31The garden camera

About the domain you choose:

  • Do not use `.local`: it is reserved for mDNS/Bonjour (Apple, printers, Chromecast) and using it for ordinary DNS produces intermittent failures that are very hard to diagnose.
  • Good options: .casa, .lan or .home.arpa (the last one is officially reserved for home networks).
  • If you have your own domain, an internal subdomain (internal.mydomain.com) is the cleanest and also lets you use valid certificates inside the house.

Machines that get their IP from the NAS's DHCP can register themselves with the name they announce, so the two pieces complement each other.

2.3 Pointing the machines at the NAS

Three ways, least work first:

  1. With the NAS's DHCP on: nothing to do, the DHCP itself hands the NAS out as the DNS server to the whole house.
  2. From the router (the most practical if you are not going to use the NAS's DHCP): in the router's DHCP configuration, change the "DNS server" it hands out and put the NAS's IP. The machines will pick it up when they renew their lease (or when they reconnect).
  3. Machine by machine, useful for testing without affecting anyone:
    • Windows: Settings → Network & Internet → Wi-Fi/EthernetEdit DNS server assignment → Manual → IPv4 → Preferred DNS: the NAS's IP.
    • macOS: System Settings → Network → Details → DNS → +.
    • Linux: nmcli con mod "<connection>" ipv4.dns 192.168.1.50 ipv4.ignore-auto-dns yes and nmcli con up "<connection>".
    • Android/iPhone: in the Wi-Fi network's options, IP settings → static.
Always leave a backup DNS. If the NAS is the only DNS in the house and it goes off or reboots to update, everybody is left "without internet" (what fails is not the connection: it is the names). Putting the router or 1.1.1.1 as secondary avoids the outage, at the cost of some machine occasionally resolving through the secondary and not finding the local names. That is the normal trade-off: yes to a backup, and accept that nas.casa may fail while the NAS is off.

2.4 Checking it works

# Linux / macOS
dig @192.168.1.50 nas.casa +short       # should return the local IP
dig @192.168.1.50 www.google.com +short # should return something: forwarding works
# Windows
nslookup nas.casa 192.168.1.50

And to find out which DNS a machine is really using: ipconfig /all on Windows or resolvectl status / cat /etc/resolv.conf on Linux.

2.5 If DNS does not work

SymptomUsual causeWhat to do
The service does not startPort 53 is taken`sudo ss -lunp \grep ':53'; disable systemd-resolved`
The service starts but does not answerFirewallThe panel opens 53 tcp and udp only; if they do not appear in Security → Firewall, save the DNS again
It resolves local names but not internet onesForwarding misconfiguredCheck the forwarders; try dig @1.1.1.1 google.com from the NAS
One machine still cannot see nas.casaIt kept the old DNS or uses the browser's encrypted DNS (DoH)Renew its IP; turn "secure DNS" off in the browser
One name resolves wrongly and nothing helpsCacheipconfig /flushdns (Windows); restart the service in the panel
sudo systemctl status dnsmasq
sudo journalctl -u dnsmasq -n 50
sudo dnsmasq --test                 # is the configuration valid?

3. DHCP server

DHCP is what gives every machine its IP address, the mask, the gateway and the DNS. Today your router does it. If you move it to the NAS you gain properly managed reservations by MAC, automatic names alongside the DNS and a clear list of what is connected in your house.

### ⚠️ Read this before turning it on A network can only have one DHCP server. Before turning the NAS's on you have to turn the router's off. If both are on at once, every machine that connects shouts a question and keeps the first answer that arrives —sometimes the router's, sometimes the NAS's—, so some devices will work and others will not, changing from one day to the next. It is not "a slightly untidy configuration": it is an intermittent fault that drives anyone mad. And the risk on the other side: with the router's DHCP off, if the NAS's does not work nobody gets an IP and the whole house is left without a network, including the computer you were going to fix it with. That is why the important section of this guide is "If you lose the network".

3.1 Preparation (five minutes that save you an afternoon)

  • [ ] Save this page on your phone (or print it). If you lose the network you will not be able to read it, and that is exactly when you need it.
  • [ ] Write down on paper: the router's IP, the NAS's IP, the mask (almost always 255.255.255.0) and the range the NAS is going to hand out.
  • [ ] Write down the router's password. If it lives in a cloud password manager and you lose the internet, you will not have it.
  • [ ] Copy the reservations by MAC the router already has (printer, cameras, console…). If you do not move them over to the NAS, those devices will change IP and stop answering where you expected.
  • [ ] Have a keyboard and monitor connected to the NAS, or SSH working from a machine with a manually set fixed IP.
  • [ ] Choose the range carefully: it must not include the router's IP, the NAS's or that of any device with a fixed IP. A sane example on a 192.168.1.0/24 network:

| Item | Value | |---|---| | Router (gateway) | 192.168.1.1 | | NAS | 192.168.1.50 | | Devices with fixed IPs | 192.168.1.2192.168.1.99 | | DHCP range | 192.168.1.100192.168.1.200 | | DNS handed out | 192.168.1.50 (the NAS) and, optionally, 1.1.1.1 | | Lease | 2 h while testing; 12–24 h afterwards |

A short lease during the migration makes machines pick up the changes in minutes instead of in days. When everything works, raise it: with long leases, if the NAS goes off the machines keep their IP for many hours and you do not find out about the outage the hard way.

3.2 The right order (do not change it)

  1. Configure DHCP in Control Panel → Network services → DHCP: range, mask, gateway (the router's IP, not the NAS's), DNS and lease. Save without turning it on.
  2. Go into the router and turn its DHCP off. It is usually under LAN → DHCP → "DHCP server: disabled". Machines already switched on keep their IP until their lease expires, so you still have a network.
  3. Turn the NAS's DHCP on from the panel.
  4. Test with one single machine before touching anything else:
ipconfig /release
ipconfig /renew
ipconfig /all          # "DHCP Server" should be the NAS's IP
sudo nmcli con down "<connection>" && sudo nmcli con up "<connection>"   # Linux
nmcli device show <interface> | grep -E 'IP4.ADDRESS|IP4.GATEWAY|IP4.DNS'

On a phone, turning Wi-Fi off and on is enough.

  1. Look at the lease list in the panel: machines should appear with their name and MAC as they renew.
  2. Only when the test goes well, raise the lease to 12–24 h and move the rest of the reservations over.

3.3 What each field means

FieldWhat it isTypical mistake
RangeFrom which IP to which IP it hands outOverlapping the fixed IPs: two machines with the same address
MaskThe size of the network (255.255.255.0 = 254 machines)Changing it "just because": part of the network stops being visible
GatewayThe way out to the internet: the routerPutting the NAS's IP: machines get an IP but do not browse
DNSWhich name server is handed outLeaving it empty: correct IP and not a single website opens
LeaseHow long an IP lasts before renewingToo long while testing: changes take a day to show
ReservationsAlways the same IP for one MACReserving an IP that is inside the dynamic range

3.4 If you lose the network

⛑️ Do not panic: nothing is broken. Only the handing out of addresses has stopped working; the cable, the Wi-Fi, the router and your data are intact. It is fixed in two minutes.

How to recognise it: machines say "no internet" or "connected, no network access", and their IP starts with 169.254. (that is the emergency address a machine invents when nobody answers) or they have none at all.

Plan A — give your computer an IP by hand (works almost always)

With a manually set IP you need no DHCP at all: you will be able to open the router or the NAS and undo the change. Use a free address outside the range you configured, for example 192.168.1.90, with mask 255.255.255.0, gateway 192.168.1.1 (your router) and DNS 1.1.1.1.

Windows (quick, in a command prompt as administrator):

netsh interface ip show config                     # see the exact interface name
netsh interface ip set address name="Ethernet" static 192.168.1.90 255.255.255.0 192.168.1.1
netsh interface ip set dns     name="Ethernet" static 1.1.1.1

Through menus: Settings → Network & Internet → Ethernet (or Wi-Fi) → IP assignmentEditManual → turn IPv4 on → fill in those four values.

macOS: System Settings → Network → your connection → DetailsTCP/IP → "Configure IPv4": Manually → fill in address, mask and router.

Linux:

nmcli con mod "<connection>" ipv4.method manual \
  ipv4.addresses 192.168.1.90/24 ipv4.gateway 192.168.1.1 ipv4.dns 1.1.1.1
nmcli con up "<connection>"

Android: long-press the Wi-Fi network → Modify network → Advanced options → IP settings: Static. iPhone: Settings → Wi-Fi → (i) → Configure IPManual.

With the network back, pick your route:

  • Undo it completely: go into the router (http://192.168.1.1) and **turn its DHCP back on**. The house goes back to normal instantly.
  • Fix the NAS's: go into the panel (https://192.168.1.50:5000) and correct or turn off the NAS's DHCP.

When everything works, put your computer back on automatic, or in a month you will have an IP conflict you cannot explain:

netsh interface ip set address name="Ethernet" dhcp
netsh interface ip set dns     name="Ethernet" dhcp
nmcli con mod "<connection>" ipv4.method auto ipv4.addresses "" ipv4.gateway "" ipv4.dns ""
nmcli con up "<connection>"

Plan B — from the NAS console (keyboard and monitor)

If the NAS is handing out addresses wrongly and you want to stop it now, without depending on having a network:

sudo systemctl stop dnsmasq       # stops handing out IPs (and resolving names) right now
sudo systemctl disable dnsmasq    # ...and not at boot either

Then turn the router's DHCP back on and start again calmly. Note: this stops the DNS server too, because they are the same process; which is exactly what you want in an emergency.

Once you have fixed it, turn it back on from the panel and not with systemctl enable: that way the interface and the service say the same thing and the panel rewrites the configuration with the values you are looking at on screen.

Plan C — I cannot even get into the router

If you do not remember the router's admin password, there is still the factory reset (the reset button with a paperclip, 10 seconds with the device switched on). Its DHCP comes back on —which is what you are after— but the Wi-Fi name and password, the port forwards and any settings of yours are wiped too: you will have to configure everything again, the VPN port included. It is the last resort, not the first.

Plan D — I need the internet to look things up

Share your phone's data over USB or Wi-Fi with the computer. You will have internet to read this guide while you fix the home network, although from there you will not see the NAS.

And for next time

  • Go back to the right order and check every step.
  • The most common mistake, by a mile, is the gateway: if you put the NAS's IP instead of the router's, machines get an IP perfectly and then do not browse.
  • The second, an empty DNS: everything looks fine and no website opens.
  • The third, two DHCP servers on: look at ipconfig /all on a couple of machines; if on one the "DHCP Server" is the router and on another it is the NAS, the router's is still alive.

3.5 Checks and diagnostics

sudo systemctl status dnsmasq
sudo journalctl -u dnsmasq -f        # live: DHCPDISCOVER, DHCPOFFER, DHCPACK
cat /var/lib/misc/dnsmasq.leases     # leases handed out (the same list as the panel)
sudo ss -lunp | grep -E ':(53|67)'   # is it listening for DNS and DHCP?

A healthy sequence in the log is DHCPDISCOVERDHCPOFFERDHCPREQUESTDHCPACK. If you see DISCOVER without OFFER, it is almost always that the range is exhausted or that the request arrives on an interface the service does not serve.


4. How the three pieces fit together

                 Internet
                     │
            router (gateway)                  ← the router's DHCP: OFF
                     │
   ┌─────────────────┴───────────────────┐
   │            home network             │
   │   PC   phone   TV   printer         │
   └─────────────────┬───────────────────┘
                     │  IP + DNS + gateway
                 NAS · dnsmasq  (DHCP 67 · DNS 53)
                     │
                 WireGuard (UDP 51820) ──► your phone, from outside the house

The NAS hands out the addresses and, in the same delivery, announces itself as the DNS server; the DNS knows the names of everything DHCP has placed; and the VPN puts your phone inside that network, names and all, wherever you are.

They can be used separately without any problem: the VPN on its own is perfectly useful, and DNS without DHCP too (it is enough for the router to hand out the NAS's IP as the name server).

5. Command cheat sheet

# VPN
sudo wg show                            # peers, latest handshake and data transferred
sudo systemctl status wg-quick@wg0
sudo journalctl -u wg-quick@wg0 -n 50

# DNS and DHCP (both are dnsmasq)
sudo systemctl status dnsmasq
sudo systemctl stop dnsmasq             # ⛑️ emergency stop for DNS and DHCP
sudo dnsmasq --test                     # validate the configuration
sudo journalctl -u dnsmasq -f
cat /var/lib/misc/dnsmasq.leases

# Ports in use
sudo ss -lunp | grep -E ':(53|67|51820)'

And the client-side commands, which are the ones that really tell you whether the network is well:

ipconfig /all          # IP, DHCP server, DNS and gateway (Windows)
ipconfig /flushdns
nslookup nas.casa
ip addr show           # Linux
nmcli device show <interface>
dig @192.168.1.50 nas.casa +short