Home Assistant Community Add-on: WireGuard

Installation Home Assistant OS
,
457

Hmmmm I am being super dumb I think. I’ve had Wireguard working perfectly with my own (Cloudflare) domain for well over a year, using the Cloudflared integration. It’s worked a treat. I previously used duckdns.

Yesterday I upgraded my HA from Pi 4 to Pi 5 by creating a backup, creating a new HA SSD using Pi imager and applying the backup. When the new system came up I put it on the old IP address on my LAN and gave the old system a different address so I could look at them side by side. I’ve not changed the routing in my router, which is still correct.

So much has happened since then but everything seems OK except Wireguard. From my Android it fails to handshake.

Wireguard and Cloudflared both look OK in the logs. I’ve not done any fancy configuration. Putting my domain name into a browser in a device not on my network takes me to my HA.

I’ve de- and re-installed both Wireguard and Cloudflared, rebooting probably more than necessary, and created a new connection on my Android each time, ensuring I am using the current QR code file, and made sure that the config matches my old config. The only difference I made to the Wireguard config was to change it to point at my domain instead of Duckdns. Also the server address change to 172.xx.xx.xx from 10.10.10.3 but I have tried changing that back with no change. I also changed the server to DuckDNS but that didn’t help.

So I still have the old HA online and if I change the port forward to that it still works on the old connection. So somewhere between Cloudflared and Wireguard something is not working but I have run out of ideas. The only stuff which looks useful in the log is below.

I’d be grateful for any ideas.

Log snippet:

01-08 19:34:40.908 8649 8690 D WireGuard/GoBackend/fd: peer(b2SZ…R0xA) - Sending handshake initiation
01-08 19:34:46.138 8649 8690 D WireGuard/GoBackend/fd: peer(b2SZ…R0xA) - Handshake did not complete after 5 seconds, retrying (try 2)
01-08 19:34:46.138 8649 8690 D WireGuard/GoBackend/fd: peer(b2SZ…R0xA) - Sending handshake initiation
01-08 19:34:51.239 8649 9310 D WireGuard/GoBackend/fd: peer(b2SZ…R0xA) - Handshake did not complete after 5 seconds, retrying (try 2)

458

Hello,
I have a problem seeing my ESP32 on the local network when using wireguard and remote connection over my iPhone hotspot.

The following log shows how the handshake is successful, first, on the local network and then, second, when I change the network to the iPhone hotspot as well. However, since it has connected to the iPhone hotspot, it shows “disconnected” in the ESP HOME dashboard, along with all sensors being unavailable, of course.

If I connect my iPhone to the VPN made by the wireguard addon, I have no traffic constraints. Therefore, I am not suspicious about traffic forwarding. Also, if I use SSH in home assistant addon to check forwarding, it shows everything is forwarded from the docker higher to my VM running HA.

Any idea what could be wrong?

[11:41:46] INFO: Requesting current status from WireGuard...
interface: wg0
  public key: JFwkTW.....
  private key: (hidden)
  listening port: 51820
peer: KRmA........
  endpoint: 62.178.21.xxx:59927
  allowed ips: 192.168.3.2/32
  latest handshake: 23 seconds ago
  transfer: 2.38 KiB received, 41.29 KiB sent
  persistent keepalive: every 25 seconds
peer: 3P5Jr1.........
  allowed ips: 192.168.3.3/32
  persistent keepalive: every 25 seconds
[11:42:17] INFO: Requesting current status from WireGuard...
interface: wg0
  public key: JFwkT.....
  private key: (hidden)
  listening port: 51820
peer: KRm.....
  endpoint: 37.48.24.xxx:18605
  allowed ips: 192.168.3.2/32
  latest handshake: 16 seconds ago
  transfer: 2.55 KiB received, 41.41 KiB sent
  persistent keepalive: every 25 seconds
peer: 3P5......
  allowed ips: 192.168.3.3/32
  persistent keepalive: every 25 seconds
459

I think that there is something really wrong here. My client on the iPhone shows “connected” even though the WireGuard server, the addon, is not running. And I am not alone https://www.reddit.com/r/WireGuard/comments/1fj5enr/wireguard_client_showing_connected_when_its/

Ah, ok, so that’s because the protocol is UDP but why somebody uses a term “handshake” when UDP does not support two way communication but just broadcast encrypted packets?

460

Hi seb5594 Sebastian.

Thank you for the interesting code, I managed to create everything except the card.
I don’t know where to get binary_sensor.:

binary_sensor.wireguard_*

I didn’t find anything like that on mine.

461

I am suspicious that my ISP Magenta in Vienna/Austria is blocking WireGuard. I tried WireGuard with my other server with Home Assitant in Prague/Czechia and it works immediately. I called them but they said nothing is blocked.

Have anybody dealt with the problem of being blocked by the ISP?

462

Hi!

I am running a Wireguard server on the internet.
I would like to connect my HA (based on HAOS) with the server.
On my other devices (phone, PC, etc.) I am successfully using conf files likes this:

[Interface]
PrivateKey = [privatekey]
Address = 10.8.3.3/32

[Peer]
PublicKey = [publickey]
Endpoint = [IP]:[port]
PersistentKeepalive = 25

How can use a conf file with the add-on?
If that is not possible, how can I recreate my on YAML? It seems, not all parameters are accepted (i.e endpoint).

Edit:
I can see that there is a conf file in the file system, but it gets overwritten, when the add-on is started.

463

So finally resolved my problem and this SHOULD BE WRITTEN everywhere. Home Assistant DO NOT route from itself to the container of the WireGuard Addon for ESP Home or between the containers of WireGuard and ESP Home, simply routing inside home assistant does not work. The server, the addon, works for any other device but does not put the ESP device from the ESP home on the same network, it does not route between the subnets. It is a persistent problem for years, see here

My solution? A new TP Link router with built in wireguard server and everything works within a single second. I wasted about 50 hours of my life. Second problem was CGNAT when you have dynamic IP, so it works only on static IPs

@mcgalactor

You must define PORT separately and yaml does not accept /32 after the IP address, it’s not necessary.

wireguard:
  address: 10.5.5.3
  private_key: "MF/oAUc+................"
  peer_endpoint: home.biospace.xxx
  peer_port: 51820
  peer_public_key: "JeK+/zIitBVBU...................."
  peer_allowed_ips:
    - 0.0.0.0/0
  peer_persistent_keepalive: 25s
464

(post deleted by author)

465

Hello,

since recently (not sure when exactly), I’m having troubles with routing traffic from local LAN devices to remote HA and LAN devices and vice-versa. The setup has worked without a hitch for about a year (thanks to help from Doron), but sometime recently stopped working without me changing anything in any of the HA installations and/or networks and I can not, for the life of me, find out why.

Both of the HA instances are installed as “Home Assistant” (previously known as “Hass.io”) - HAssOS, Supervisor and add-ons on identical NUC systems.

LOCAL NETWORK:

SUBNETS:
10.0.0.0/16
192.168.100.0/24

HA IP:
10.0.10.20
10.0.60.20

REMOTE NETWORK:

SUBNETS:
10.3.0.0/24
192.168.1.0/24

HA IP
10.3.0.20

I have a local HA and a remote HA with installed Wireguard Add-ons. I’ve set up a site-to-site config…

LOCAL SERVER:

host: <HIDDEN>
addresses:
  - 10.11.0.1/32
dns:
  - 172.30.32.1
private_key: <HIDDEN>
public_key: <HIDDEN>
mtu: 1280

LOCAL PEERS:

- name: <HIDDEN>
  addresses:
    - 10.11.0.3/32
  private_key: <HIDDEN>
  public_key: <HIDDEN>
  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
    - 172.30.32.1
  persistent_keep_alive: 25
  endpoint: <HIDDEN>:51820
  pre_shared_key: "!secret wireguard-preshared_key"

REMOTE SERVER:

host: <HIDDEN>
addresses:
  - 10.11.0.3/32
dns:
  - 172.30.32.1
private_key: <HIDDEN>
public_key: <HIDDEN>

REMOTE PEERS:

- name: <HIDDEN>
  addresses:
    - 10.11.0.1/32
  private_key: <HIDDEN>
  public_key: <HIDDEN>
  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
    - 172.30.32.1
  persistent_keep_alive: 25
  endpoint: <HIDDEN>
  pre_shared_key: <HIDDEN>

Both of the HA instances connect to each other normally, can ping each other and the devices on the remote network(s). The iptables forward rules have been set up on both of the HA installations.

LOCAL IPTABLES:

-A FORWARD -d 10.3.0.0/24 -j ACCEPT
-A FORWARD -d 192.168.1.0/24 -j ACCEPT

REMOTE IPTABLES:

-A FORWARD -d 10.0.0.0/16 -j ACCEPT
-A FORWARD -d 192.168.100.0/24 -j ACCEPT

as have the routes (via the “sensor method”)

LOCAL ip route:

...
10.3.0.0/24 via 172.30.33.7 dev hassio  src 10.0.10.20
...
192.168.1.0/24 via 172.30.33.7 dev hassio  src 10.0.10.20

REMOTE ip route:

...
10.0.0.0/16 via 172.30.33.7 dev hassio  src 10.0.10.20
...
192.168.100.0/24 via 172.30.33.7 dev hassio  src 10.0.10.20

Local and remote static routes on their respective routers are also in place and unchanged from when the setup was working normally.

tracert from pc’s in both the LOCAL and REMOTE network “disappear” (time out) when reaching their respective local HA ips.

Does anyone have a clue what could be the reason for the setup failing when it has been working like this for quite a long time? I’m using it to help out some people by letting them use my local printers when they need to and providing them with storage as they’re quite short on money and need/deserve my help.

Thank you in advance!

466

If anyone encounters the same problem, here’s how I solved it (for now)… Seems that inserting the needed FORWARD rules in HAOS iptables before other forward rules did the trick.

I’ve substituted (removed those)

-A FORWARD -d 192.168.1.0/24 -j ACCEPT
-A FORWARD -d 10.3.0.0/24 -j ACCEPT

I’ve had in iptables, with the following ( by iptables -I FORWARD -i eno1...)

-A FORWARD -s 10.0.0.0/16 -d 192.168.1.0/24 -i eno1 -j ACCEPT
-A FORWARD -s 10.0.0.0/16 -d 10.3.0.0/24 -i eno1 -j ACCEPT

Did it a bit tighter (by specifying -s and -i), not sure why, as I think I’ve got most of the security done on the network firewall/router level. In case anyone sees anything I might have done wrong / insecurely, please do chime in.

467

Hi everyone, I’d like to know if it’s possible to configure WireGuard so that clients can use it only for geolocation (e.g. streaming services), without having any access to devices or services on my LAN.

I’m running the WireGuard add-on on HAOS, behind a TP-Link Deco router that doesn’t support VLANs or custom firewall rules.

The purpose of this VPN is to share it with family members.

1 Like
468

If I understand your goal correctly, then one way to do that would be using a “post_up” tag in the “server” section, and add filtering rules such as these:

iptables -A FORWARD -s <client_ip_range> -d <local_network> -i %i -j DROP; 
iptables -A FORWARD -i %i -j ACCEPT;
iptables -A FORWARD -o %i -j ACCEPT;
iptables -A POSTROUTING -o eth0 -j MASQUERADE

You can tune and refine that, but what it does is block access from the client to the local LAN, while allowing other traffic from same clients.

The clients should have “allowed_ips” set to 0.0.0.0/0 - which would also mean that as long as they are connected to the WG VPN, all their traffic would be routed through it.

Is this what you were after?

1 Like
469

This is an interesting discussion as I can see a use for exactly this. I presume you could have different client files with different ip ranges so you could have some with LAN access and some without?

470

Absolutely. Just tailor those iptables rules to your needs.

1 Like
471

Unfortunately, I can’t edit the ‘iptables’ on my HAOS.

472

You don’t need to. Just use the “post_up” tag on your WireGuard add-on configuration.
Here’s a fuller example (EDITED to better match the questions):

host: myhost.mydomain.net
addresses:
  - 192.168.2.10/32
dns:
  - 192.168.1.1
post_up: >-
  iptables -A FORWARD -i %i -s 192.168.2.80/30 -d 192.168.1.0/24 -j DROP; iptables -A FORWARD
  -i %i -j ACCEPT;  iptables -A FORWARD -o %i -j ACCEPT;  iptables -t nat -A
  POSTROUTING -o eth0 -j MASQUERADE
post_down: >-
  iptables -D FORWARD -i %i -s 192.168.2.80/30 -d 192.168.1.0/24 -j DROP; iptables -D FORWARD
  -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D
  POSTROUTING -o eth0 -j MASQUERADE
1 Like
473

image
image501×372 17.2 KB

sensor:
  - platform: rest
    name: WireGuard VPN Clients
    unique_id: wireguard_vpn_clients
    resource: http://a0d7b954-wireguard
    icon: mdi:vpn
    value_template: "OK"
    json_attributes:
      - PHONE-xxx

template:
  - binary_sensor:
      - name: WireGuard Client - PHONE-xxx
        unique_id: wireguard_client_phone_xxx
        icon: mdi:vpn
        state: >-
          {% set client = state_attr('sensor.wireguard_vpn_clients', 'PHONE-xxx') %}
          {{ client and (client.latest_handshake | int) > (as_timestamp(now()) - 160) }}
        attributes:
          endpoint: >-
            {{ state_attr('sensor.wireguard_vpn_clients', 'PHONE-joao').endpoint }}
          latest_handshake: >-
            {% set ts = state_attr('sensor.wireguard_vpn_clients', 'PHONE-xxx').latest_handshake %}
            {% if ts and ts != 0 %}
              {{ ts | timestamp_custom('%a %d-%m-%Y %-I:%M %p') }} 
            {% else %}
              (none)
            {% endif %}
          transfer_tx: >-
            {% set bytes = state_attr('sensor.wireguard_vpn_clients', 'PHONE-xxx').transfer_tx %}
            {{ (bytes / 1024 / 1024) | round(2) }} MB
          transfer_rx: >-
            {% set bytes = state_attr('sensor.wireguard_vpn_clients', 'PHONE-xxx').transfer_rx %}
            {{ (bytes / 1024 / 1024) | round(2) }} MB

I am using this configuration to get information about when the clients/peers connect to the VPN, and I noticed that there is a significant delay before the sensor switches on/off. Is there any way to improve this?

474

Hi,

  • HAOS in bridge mode
  • WireGuard Add-on installed
  • VPN clients can ping 172.27.66.1
  • Cannot access HA on 8123

Setup:

server:
host: ..***
addresses:
- 172.27.66.1
dns:
- 192.168.2.1
peers:

  • name: hassio
    addresses:
    • 172.27.66.2
      allowed_ips:
    • 192.168.2.0/24 # ← Internal network
    • 172.27.66.0/24 # < WG VPN network
      client_allowed_ips:
    • 192.168.2.0/24
    • 172.27.66.0/24
  • http.server_host: 0.0.0.0
  • AllowedIPs = 172.27.66.1/32
    TCP traffic seems blocked from the WG Add-on container.
    Goal: VPN clients should access only HA safely.
    Has anyone got this working? Any tips or workarounds?