Home Assistant Community Add-on: WireGuard

IT WORKS! You are a lifesaver. Thank you very very much. It totally slipped my mind there’s a “HA OS” underneath it all. I’ve checked for iptables in HA and there were none so I assumed it was a routing issue.

Now I just have to learn to formulate an iptables rule to forward (just) what I need forwarded and (just) where I need it forwarded to and make it persist and I’m golden. This is in no way an ask towards you, your help up 'till now has been invaluable and you’ve made far too much travel on your keyboard keys for unknown me, but, on the other hand, if and just if you have a suggestion lingering in your brain… I won’t be offended :smiley:

In any case, thanks once again for your good will. Hope I can repay / pass it forward one day.

All the best.

Glad it worked for you, that’s cool. You have a setup that’s even more complex than mine, so it was worth a shot :slight_smile:

In terms of iptables, it’s quite straightforward:

iptables -A FORWARD -d 10.0.0.0/16 -j ACCEPT

as one example (when the remote destination is 10.0.0.0/16). You’d need a bunch of these on both ends :smile:

In terns if making it persistent, I don’t have a good answer for you - haven’t looked into that; please post when you find an elegant way to do that.

Thanks once again (sorry for late response - life/work got in the way :blush: ).

Your solution, as is usual per my experience, works. I’ll try and see what can I do to make them persist or be “reapplied” on reboot and be sure to write about it for posterity.

Thanks man

This is more of a general replay. but can solve someones problem. I am just putting it out there.

I had the vpn set up, and had a handshake. Can ping the host. But could not get any internet access, also the local webpages.

I found the problem here:

it turns out the mtu was set to high.
in the solution thy set is to 1340 with netsh. But you can also set it as a option on your client side wireguard configuration.

[Interface]
MTU = 1340

1 Like

Hello Doron.
it seems I have the same issue, if I look at the routing, this is pointing towards the IP of the wireguard addon, however, it seems that packets are dropped at the host itself.
now I noticed that you are referring to iptables, however my hassos does not have iptables enabled. do you maybe have any other thoughts how I can enable packet flow?

Thanks!

Hi @broker . Are you actually running HASSOS (and a recent one)? Assuming you do, I believe it does have iptables (essentially nf_tables) installed and applied. Are you sure you’re connecting to a shell at the OS level? If you’re using UI “Terminal” or something like that, then you’re not at the OS level and indeed you will not see iptables.

Hello @doron:
these are the versions I am running:

  • Core2024.7.2
  • Supervisor2024.06.2
  • Operating System12.4
  • Frontend20240710.0
    I am issuing the commands from the “advanced SSH & Web Terminal” with protection mode disabled.

what I think is strange if I do a traceroute from the terminal to my remote network (192.168.1.1) it gets forwarded to the wireguard-addon

if I am pinging from 192.168.1.0 network to other network 192.168.178.0 I get results
however if I ping from 192.168.178.0 to 192.168.1.0 there is none, i just cannot figure out what is causing that.

just a bit background, I am running a HA server in 192.168.178.0 space that connects to a UDM Pro SE the has the 192.168.1.0 space

just to make sure I am overseeing any issues in my config this is reflected when the tunnel is issued:
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
s6-rc: info: service legacy-services successfully started
[#] ip -4 address add 192.168.3.3/32 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] resolvconf -a wg0 -m 0 -x
[#] ip -4 route add 192.168.3.1/32 dev wg0
[#] ip -4 route add 192.168.1.0/24 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

as an addon, if I check the settings of the wireguard docker:
docker exec -it e20bc7fdd12a route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 172.30.32.1 0.0.0.0 UG 0 0 0 eth0
172.30.32.0 * 255.255.254.0 U 0 0 0 eth0
192.168.1.0 * 255.255.255.0 U 0 0 0 wg0
192.168.3.1 * 255.255.255.255 UH 0 0 0 wg0

from the docker I am able to ping 192.168.1.1 & 192.168.3.1 (peer subnet)

docker exec -it e20bc7fdd12a iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all – anywhere anywhere
ACCEPT all – anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

many many thanks!

Hi @broker
I’ll look at the details tomorrow - a bit busy right now, but a quick comment:
It sounds as if you are doing everything inside dockers (different dockers at that), and not at the OS level. To get to the OS level you need to enable SSH access to that level. Have you done that? If not, here is a guide as to how to go about that.

@doron, you were right. after going through the steps. and adding the route and issuing the iptables solved the problem., now I need to check how I can make this persistent.

Thanks !

Cool, glad it worked for you.
When you find a good solution for making it persistent, please post it here.

@doron , that was my idea. but it seems very difficult, unless I am doing something wrong, as i seem not to have write access to the disk. I have tried to put a file in /etc/network/if-pre-up.d/ every time I try a touch or vi and safe, it gives me the error that the disk is read-only

any suggestions?