Solved this by Wireguard Client Add-on. thx
Do I need to do something to get my DNS to work? I’m trying to point to my pi-hole server and its not working. Here are not settings:
server:
host: SERVER.duckdns.org
addresses:
- 172.27.66.1
dns:
- 192.168.0.6
peers:
- name: aaron
addresses:
- 172.27.66.2
allowed_ips: []
client_allowed_ips:
- 0.0.0.0/0
Looks like it tries to resolve the VPN host based on the DNS server in the VPN profile… That’s why it didn’t work with my setup (I have adguard installed and my DNS is 192.168.100.100)
Changed the host in the client application to my IP instead of the domain - and now it works!
I have some really basic question, but in this tread there are some very confusing information.
Let’s assume very basic installation.
HA with cloudflared addon and accessible via ha.mydomain.com
so i just keep
host: ha.mydomain.com
addresses:
- 172.27.66.1
dns: []
- Do I need to enter anything in DNS? 8.8.8.8 or local router ip address or local HA server IP?
- if I am using cloudflared addon and own domain instead of duckdns, and remote access to ha using cloudflare domain is working on ha.mydomain.com, do I still need to make A record on Cloudflare as it is writen on some tutorails?
the issue is that I have configured Wireguard on Pixel 7 by scaning QR code, but when vpn is on on the phone, I can not access any website, but also not any local IP on my home network.
But my most importanf future usecase is esphome wireguard for remote location.
I tried also new tunel vpn.mydomail.com pointed to IP of local HomeAssistant server (with :8123 and without), and put it as host, but no success
Same problem for me as well. I had it working months ago. I checked the other day after a update and now I can access my home network from outside of home on either data on my phone or someone else’s Wi-Fi
server:
host: myhome.duckdns.org
addresses:
- 182.27.66.1
dns: []
peers:
- addresses:
- 182.27.66.2
allowed_ips: []
client_allowed_ips: []
name: iPhone
I’ve been searching for hour on how to fix this, without any success
are you sure about the IP-Addresses starting with 182?
Sorry… Typo should be 192.27.66.x
Is this WireGuard Add-On a VPN just to access HA UI remotely, or does it provide general IPv4 access to the whole network (LAN/WLAN) on which the HA instance is also connected?
Last one. Complete vpn solution
1 Like
This is what worked for me:
On the rpi host, add a route to your wireguard subnet via the ip address of the wireguard container on the hassio network (assuming 172.30.33.10 here):
sudo ip route add 172.27.66.0/24 via 172.30.33.10
Then add this to iptables:
sudo iptables -A FORWARD -i enp1s0 -o hassio -s 192.168.0.0/24 -d 172.27.66.0/24 -j ACCEPT
Be sure to replace enp1s0 with your LAN interface.
Then in your router config, add a static route pointing the wireguard subnet to the rpi ip address on your LAN. So if your rpi’s IP on your LAN is 192.168.0.5, set the static route up with Network Destination=172.27.66.0, Subnet Mask=255.255.255.0, and Default Gateway=192.168.0.5.
Now any computer in the local subnet should be able to ping a WireGuard peer such as 172.27.66.2 and receive a response. The static route forwards it to your rpi, and your rpi will know to send it to the wireguard container, which will send it to the connected peer.
1 Like
Wireguard is up and running for me and I have local en internet access on my phone.
I want to add another phone to be able to use my wireguard vpn but I only want some local devices to be reachable / block some other local devices and have internet access on it.
I think I need to configure the allowed ip’s? I tried adding some local devices with the router/gateway included but then I get no internet or local acess at all. I think I’m missing out on some essential ip’s.
I don’t think there is an option to block certain devices / ip’s ?
Thx in advance.
And thank you Frenck for this great add-on.
I have HA running on an iMac, which is connected via Ethernet to my local Network which sits behind a Fritzbox.
I have installed the Wireguard add-on and followed the instructions to set it up as server and to add a peer.
Portforwarding on Fritzbox points to HA‘s IP address.
I have tried all tutorials what to do on the iMac in order to forward IP traffic into my LAN so that I can access those devices remotely
Unfortunately I just can not get it to work and am desperate.
Anyone out there who got it working with HA on an iMac?
Many thanks in advance for any help someone can provide!!!
Regards,
Joop
Hello everyone.
Here I am, with my problem. Trying to setup a kind of a “mesh” WG site-to-site between three sites + a “road warrior” setup for two mobile clients using the Home Assistant OS on an old Intel NUC.
LAN1: 5 VLANS, 10.0.0.0/16 (VLANS 10.0.10.0/24, 10.0.20.0/24…), double NAT-ed with an ISP router @ 192.168.100.1, WG Add-on address on WG 10.11.0.1
LAN2: 5 VLANS, 10.1.0.0/16 (VLANS 10.1.10.0/24, 10.0.20.0/24…), WG Add-on address on WG 10.11.0.2
LAN3: 1 subnet, 10.3.0.0/24, double NAT-ed with an ISP router @ 192.168.1.1, WG Add-on address on WG 10.11.0.3
mobile_client1: address “on WG” 10.11.0.4
mobile_client2: address “on WG” 10.11.0.5
LAN2 and LAN3 have Homeassistant and the WG Add-on as a method of creating / maintaining tunnels. LAN2 will run everything on Unraid, but I’m still setting up the LAN2-LAN3 connection, so that’ll have to wait for another time.
LAN1 Config (WG Add-on):
server:
host: lan1.dynamicdns.address
addresses:
- 10.11.0.1/32
dns:
- 172.30.32.1
private_key: "!secret wireguard-lan1-private_key"
public_key: "!secret wireguard-lan1-public_key"
peers:
- name: lan2
addresses:
- 10.11.0.2/32
private_key: "!secret wireguard-lan2-private_key"
public_key: "!secret wireguard-lan2public_key"
allowed_ips:
- 10.11.0.2/32
- 10.1.0.0/16
client_allowed_ips:
- 10.11.0.1/32
- 10.0.0.0/16
- 192.168.100.0/24
persistent_keep_alive: 25
endpoint: lan2.dynamicdns.address:51820
pre_shared_key: "!secret wireguard-preshared_key"
- name: lan3
addresses:
- 10.11.0.3/32
private_key: "!secret wireguard-lan3-private_key"
public_key: "!secret wireguard-lan3-public_key"
allowed_ips:
- 10.11.0.3/32
- 10.3.0.0/24
- 192.168.1.0/24
client_allowed_ips:
- 10.11.0.1/32
- 10.0.0.0/16
- 192.168.100.0/24
persistent_keep_alive: 25
endpoint: lan3.dynamicdns.address:51820
pre_shared_key: "!secret wireguard-preshared_key"
- name: mobile_client1
addresses:
- 10.11.0.5/30
private_key: "!secret wireguard-mobile_client1-private_key"
public_key: "!secret wireguard-mobile_client1-public_key"
allowed_ips:
- 10.11.0.5/32
client_allowed_ips:
- 10.11.0.1/32
- 10.0.0.0/16
- 192.168.100.0/24
persistent_keep_alive: 25
pre_shared_key: "!secret wireguard-preshared_key"
- name: mobile_client2
addresses:
- 10.11.0.6/32
private_key: "!secret wireguard-mobile_client2-private_key"
public_key: "!secret wireguard-mobile_client2-public_key"
allowed_ips:
- 10.11.0.6/32
client_allowed_ips:
- 10.11.0.1/32
- 10.0.0.0/16
- 192.168.100.0/24
persistent_keep_alive: 25
pre_shared_key: "!secret wireguard-preshared_key"
LAN3 Config (WG Add-on):
server:
host: lan3.dynamicdns.address
addresses:
- 10.11.0.3/32
dns:
- 172.30.32.1
private_key: "!secret wireguard-lan3-private_key"
public_key: "!secret wireguard-lan3-public_key"
peers:
- name: lan2
addresses:
- 10.11.0.2/32
private_key: "!secret wireguard-lan2-private_key"
public_key: "!secret wireguard-lan2-public_key"
allowed_ips:
- 10.11.0.2/32
- 10.1.0.0/16
client_allowed_ips:
- 10.11.0.3/32
- 10.3.0.0/24
- 192.168.1.0/24
persistent_keep_alive: 25
endpoint: lan2.dynamicdns.address:51820
pre_shared_key: "!secret wireguard-preshared_key"
- name: lan1
addresses:
- 10.11.0.1/32
private_key: "!secret wireguard-lan1-private_key"
public_key: "!secret wireguard-lan1-public_key"
allowed_ips:
- 10.11.0.1/32
- 10.0.0.0/16
- 192.168.100.0/24
client_allowed_ips:
- 10.11.0.3/32
- 10.3.0.0/24
- 192.168.1.0/24
persistent_keep_alive: 25
endpoint: lan1.dynamicdns.address:51820
pre_shared_key: "!secret wireguard-preshared_key"
- name: mobile_client1
addresses:
- 10.11.0.5/32
private_key: "!secret wireguard-mobile_client1-private_key"
public_key: "!secret wireguard-mobile_client1-public_key"
allowed_ips:
- 10.11.0.5/32
client_allowed_ips:
- 10.11.0.3/32
- 10.3.0.0/24
- 192.168.1.0/24
persistent_keep_alive: 25
pre_shared_key: "!secret wireguard-preshared_key"
- name: mobile_client2
addresses:
- 10.11.0.6/32
private_key: "!secret wireguard-mobile_client2-private_key"
public_key: "!secret wireguard-mobile_client2-public_key"
allowed_ips:
- 10.11.0.6/32
client_allowed_ips:
- 10.11.0.3/32
- 10.3.0.0/24
- 192.168.1.0/24
persistent_keep_alive: 25
pre_shared_key: "!secret wireguard-preshared_key"
When I establish a tunnel from mobile_client to either of the two currently set up WG Add-ons (LAN1 & LAN3), I can access everything I expected on the respective local networks of WG endpoints (all the wanted devices on their respective VLANs), using their IP addresses on their respective (V)LANs. Judging by the log on both of the Add-ons, there is traffic flowing between the peers (LAN1 ↔ LAN3 and mobile_client ↔ LAN1/LAN3). I’ve setup static routes in the respective routers on LAN1 and LAN3. Unfortunatelly, judging by the tracert, the Home Assistant “servers” on both of the locations don’t know what to do with the traffic that gets sent to them as instructed by the said static routes. I’m a total noob and I don’t know how to explain it better, so here’s an example. When I do a tracert from a device on LAN1 to a device on LAN2, the traffic is directed to my local Home Assistant “server” IP, but it stops there as there’s no routes in the Home Assistant itself which would instruct where to send the traffic next (I suspect).
Could anyone try and explain to me what I need to do to create appropriate routes in the Home Assistant, or whatever it is I need to do to be able to access a device on LAN1/2 from a device on LAN2/3 “through” the Home Assistant Add-on on the respective site/lan?
Thanks in advance
EDIT: Here’s the log from WG Add-on startup on HomeAssistant @ LAN1:
[14:24:40] INFO: Starting WireGuard...
s6-rc: info: service legacy-services successfully started
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.11.0.1/32 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] resolvconf -a wg0 -m 0 -x
[#] ip -4 route add 10.11.0.6/32 dev wg0
[#] ip -4 route add 10.11.0.5/32 dev wg0
[#] ip -4 route add 10.11.0.3/32 dev wg0
[#] ip -4 route add 10.11.0.2/32 dev wg0
[#] ip -4 route add 192.168.1.0/24 dev wg0
[#] ip -4 route add 10.3.0.0/24 dev wg0
[#] ip -4 route add 10.1.0.0/16 dev wg0
[#] iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
It seems the routes are set up here, but when I do “ip route” @ Home Assistant (through ssh) I get:
default via 10.0.10.1 dev eno1 src 10.0.10.20 metric 100
default via 10.0.60.1 dev wlo2 src 10.0.60.20 metric 20600
10.0.10.0/24 dev eno1 scope link src 10.0.10.20 metric 100
10.0.60.0/24 dev wlo2 scope link src 10.0.60.20 metric 600
172.30.32.0/23 dev hassio scope link src 172.30.32.1
172.30.232.0/23 dev docker0 scope link src 172.30.232.1
so - no routes for LAN2/3 traffic here.
You may want to check out this post above, and the one right above it. For me, that “sensor” config solved the missing routing info in a similar situation.
Thank you vary very much for your answer. I don’t know how I could have missed it. Seems I’m not as proficient in searching as I imagine.
In any case, I’ve added the command as the original answerer suggested and appended the src address (using my Home Assistant IP on the local network). On both the HomeAssistants routes now show as I believe(d) they should. Now I can ping devices on the remote lan (LAN3) from Home Assistant 1 (LAN1) and vice versa - from Home Assistant 2 (LAN3) I can ping devices on local lan (LAN1). Unfortunately, still the devices from LAN1 can’t reach any devices on LAN3.
Well, I can assume the devices on LAN1 have just one route going out, which is their default gateway, which points to the local (ISP?) router. That router in turn does not know where LAN3 is, so traffic goes to the bitbucket.
To have a full working mesh you need a bit more work. Either place static routes on the devices on LAN1, that point to the HA instance for all the remote prefixes WG routes for, or put just one set of statics on the router itself. The latter option means one more hop for inter-LAN traffic but much less work. Same needs to be done on the other end, so that return traffic can also find its way back.
Thank you once again for you time and good will. I should’ve been clearer in my first response. I did, in fact, set up static routes and appropriate firewall rules for subnets/devices that should be able to reach the remote lan (devices) as far as I can tell.
The current situation is as follows:
- both Home Assistant instances can ping each other across WG (10.0.10.20 ↔ 10.3.0.20) and are in fact connected (remote home asisstant, HA1 getting picture from remote HA3 cameras etc)
- both Home Assistant instances can ping devices on remote (v)lan(s) they should be able to ping (firewall rules)
- devices on neither of the lans can ping neither the Home Assistant instance on the remote (v)lan, nor any of the devices they should be able to ping on remote (v)lan(s)
The traceroute from Home Assistant on LAN1 to the Home Assistant on LAN3
~ # traceroute 10.3.0.20
traceroute to 10.3.0.20 (10.3.0.20), 30 hops max, 46 byte packets
1 a0d7b954-wireguard.local.hass.io (172.30.33.6) 0.026 ms 0.007 ms 0.007 ms
2 10.11.0.3 (10.11.0.3) 3.795 ms 3.895 ms 3.567 ms
3 10.3.0.20 (10.3.0.20) 4.158 ms 3.893 ms 5.480 ms
The traceroute from my desktop on LAN1 to the Home Assistant on (remote) LAN3:
PS C:\Users\User> tracert 10.3.0.20
Tracing route to 10.3.0.20 over a maximum of 30 hops
1 2 ms 2 ms 2 ms 10.0.40.1
2 5 ms 3 ms 4 ms HomeAssistant [10.0.10.20]
3 * * * Request timed out.
4 * * * Request timed out.
And I can normally ping 10.0.10.20 from my desktop:
Pinging 10.0.10.20 with 32 bytes of data:
Reply from 10.0.10.20: bytes=32 time=2ms TTL=63
Reply from 10.0.10.20: bytes=32 time=3ms TTL=63
Reply from 10.0.10.20: bytes=32 time=3ms TTL=63
It seems the packets know they have to get through Home Assistant (ip 10.0.10.20) to get to the 10.3.0.0/24 subnet, but once they arive to 10.0.10.20, they get dropped or something.
I’m a bit lost as to how to investigate further.
Problem with addon wireguard client (WireGuard Client Current version: 0.2.2 on HA Core 2024.5.5, Supervisor 2024.05.1,Operating System 12.3): works perfectly with hardware reboot or manually started from the addon sub page. But when the router is offline for a short time (daily at 03:00), only the LAN IP remains reachable, not the wireguard IP (solution either hardware reboot or manually starting from web-interface). I want to restart the service (not the host) via cli (or some script or some crontab entry) in the form:
ha addons restart wireguard???
but did not find the correct name of the addon (did not appear in the list ha add-ons info).
Any ideas or links to solve this problem?
In general, you can debug such issues by trying to capture network traffic and see just how far each packet is going, using tools such as tcpdump (Linux/Unix/MacOS) and/or Wireshark (Windows). This may become tedious, but sometimes it’s the only way.
Specifically to your case, the first thing I’d look into is the forward firewalling on the HA OS. It uses iptables and by default, forwarding is blocked. You did mention at some point that firewalling is taken care of, but you were not specific so I thought I’d offer that.
Logged into the HA OS, you can
iptables -S
to see the existing chains, and specifically, the FORWARD chain.
As a first, very crude, debugging step you can do, on both your HA OS’s:
iptables -P FORWARD ACCEPT
and see if it makes a difference. If it does, then you know where the problem is, and you’d probably want to narrow it down to what’s really needed.
Note that these commands do not survive a restart.
Thanks, somehow I do not see how to execute linux commands in the cli, for example iptables seems not to be installed, apt is not to be found. Or do I have to go inside the docker container? Sadly the watchdog inside the wiregate addon does not seem to work, that would be the best solution.
The script uses iptables in this configuration:
post_up: >-
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE; iptables -A FORWARD -p
tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
post_down: >-
iptables -t nat -D POSTROUTING -o wg0 -j MASQUERADE; iptables -D FORWARD -p
tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
edit 2024-05-27: working solution for me: since crontab does not work, installed addon “ping”, configured automation testing if wireguard server is reachable, if not restart wireguard client after 5 minutes
alias: wireguard_watchdog
description: ""
trigger:
- type: not_connected
platform: device
device_id: xxx...
entity_id: yyy...
domain: binary_sensor
for:
hours: 0
minutes: 5
seconds: 0
condition: []
action:
- service: hassio.addon_restart
metadata: {}
data:
addon: fd24a922_wireguard_client
mode: single