A home NAS is a lot more useful when you can reach it from outside the house — pulling a file on the road, checking a service, or getting at your home network while you’re away. The safe way to do that isn’t to expose the OpenMediaVault web interface to the internet; it’s to run a WireGuard VPN on the server and dial into your own network from your laptop or phone. OMV’s WireGuard plugin makes most of this point-and-click. There’s just one thing it gets wrong every time, and it’s the reason most people end up “connected but unable to reach anything.” We’ll set the whole thing up and cover that fix.
What you need first
- OpenMediaVault with the WireGuard plugin installed (it comes from the omv-extras repository).
- The WireGuard app on whatever you’re connecting from — laptop, phone, tablet.
- A way for the outside world to reach home: UDP port 51820 forwarded on your router to the OMV box, and ideally a domain or dynamic-DNS name pointing at your home connection so a changing IP doesn’t break things.
1. Create the server tunnel
In OMV, go to Services → WireGuard → Tunnels and click +. Fill it in like this:
- Enable: on.
- Tunnel number:
1. (Some plugin versions refuse0— if it won’t accept the number, just use 1.) - Name:
wg0. - Network adapter: your physical ethernet interface — usually
enp3s0oreth0. If Docker is running you’ll see a long pile ofveth*entries and awlo1; ignore those. Theveth*ones are virtual Docker interfaces andwlo1is Wi-Fi. Pick the real wired adapter. - Endpoint: your public address —
vpn.yourdomain.net, your dynamic-DNS hostname, or your WAN IP. - Port:
51820. - Configure iptables: on (this lets the tunnel route properly).
- Persistent keepalive:
25. - Local IP: the tunnel’s own subnet, e.g.
10.192.1.254/24. This is an internal VPN range, separate from your home LAN. - MTU:
0(WireGuard defaults to 1420).
Save and Apply.
2. Add a client
Now create the device that will connect in. Go to Services → WireGuard → Clients → +:
- Enable: on.
- Client number:
1. - Tunnel: select
wg0. - Name: something recognisable, e.g.
my-laptop. - Persistent keepalive:
25. - DNS Servers:
1.1.1.1(or your own). - Restrict routing:
VPN + Local— so you can reach both the tunnel and your home network.
Save and Apply. Add one client per device you want to connect from.
3. Download the config — don’t write it by hand
You don’t create the .conf file yourself; OMV generates it. Back in Services → WireGuard → Clients, your my-laptop client is now listed with a row of action icons next to it — click the download icon to grab its .conf. Then, in the WireGuard app on that device, choose Import tunnel from file and point it at the file you just downloaded. (On a phone, the same client can be shown as a QR code to scan instead.)
4. The one fix everyone needs: add your LAN to AllowedIPs
This is the step that makes or breaks the whole thing. The OMV plugin generates the client config with only the VPN subnet in the AllowedIPs line — something like 10.192.1.0/24. That’s enough to connect to the tunnel, but it tells your device “only send traffic for the VPN subnet through here” — so the moment you try to reach a device on your actual home network (your NAS at 192.168.1.x, say), the traffic has nowhere to go and nothing works. You’re connected, but blind.
The fix is to add your home LAN subnet to that line by hand. Before activating the tunnel in the WireGuard app, edit it and find AllowedIPs in the [Peer] section. Change it from just the VPN subnet to include your home network too:
- Generated (incomplete):
AllowedIPs = 10.192.1.0/24 - What you want:
AllowedIPs = 10.192.1.0/24, 192.168.1.0/24
Swap 192.168.1.0/24 for whatever your home LAN actually is (check your router — it’s commonly 192.168.1.0/24 or 192.168.0.0/24). Save, then activate.
The good news: this is a one-time edit. As long as you don’t delete and re-import the tunnel on the client, the fix stays put permanently. The plugin will never add your LAN subnet on its own, so if the keys ever change and you have to re-import, just re-add that subnet the same way.
5. Open the door: port forward and DNS
For a client on the road to reach home, your router has to let it in. Forward UDP 51820 to the OMV server’s LAN IP. If your home IP address changes (most residential connections), set up dynamic DNS — through your router, your domain registrar, or a service like DuckDNS — and use that hostname as the tunnel’s Endpoint, so a new IP doesn’t silently break your VPN.
Test it properly
Test from outside your home network, not on your home Wi-Fi — put your phone on mobile data, or tether the laptop to it. Activate the tunnel, then try to reach something on your home LAN by its address: ping your NAS’s LAN IP, or open the OMV web interface at its home address. If that loads, remote access is working end to end.
When it won’t cooperate
- Connects but can’t reach any home device — the classic one: your LAN subnet isn’t in
AllowedIPs. Go back to step 4. - The plugin rejects tunnel number 0 — use
1instead. - No handshake at all — check the UDP 51820 port forward, confirm the Endpoint hostname resolves to your home IP, and make sure keepalive is set so the connection stays alive.
- You picked the wrong adapter — the network adapter must be your physical ethernet (
enp3s0/eth0), not aveth*Docker interface or Wi-Fi.
The short version
Install the WireGuard plugin on OMV, create a server tunnel on your physical ethernet adapter (keepalive 25, iptables on, port 51820), add a client, and download the config OMV generates for it. Then — the crucial bit — manually add your home LAN subnet to the client’s AllowedIPs alongside the VPN subnet, because the plugin never does. Forward UDP 51820, point a DDNS name at home, test from mobile data, and you can reach your whole home network from anywhere.