#Wireguard Add-on site-to-site troubles and tribulations.

1 messages · Page 1 of 1 (latest)

pure bolt
#

I'm having troubles with routing LAN-to-REMOTE_LAN traffic through HA/Wireguard recently (after working without a burp for a year or so). I have three HA instances, two of which are connected through Wireguard (Add-on), the third is still on the OpenVPN provided by network routers/firewalls, waiting for me to solve the problems I'm having with the first two to jump over to the same config. Let's name the relevant HA installations as HOME_HA and REMOTE_HA, relevant networks as HOME_LAN and REMOTE_LAN.

Both of the HAs in question are "HassOS" method of installation on two identical Intel NUCs (Pentium Silver J5005). I have/had them provide site-to-site connectivity and sometime in the last month or so the client connectivity died. Nothing in the HOME or REMOTE location has changes, so my thoughts are - it must be something in the HA / Wireguard Add-on must have changed.

Both of the HA instances can connect to the remote LAN clients (remote storage/backup), "just" the LAN clients can't. Also, I have a peer config in both of the HA instances' Wireguard Add-ons for me to be able to connect to both LANs for testing / "support" purposes. When I connect with my phone, I can connect to both the respective LAN clients and HA instances.

My tests uptodate. Ping HOME_HA <-> REMOTE_HA ✅ , ping HOME_HA -> REMOTE_LAN client ✅ , ping HOME_LAN client -> REMOTE_HA ❌, HOME_LAN client -> REMOTE_LAN client ❌ . Ping REMOTE_LAN client -> HOME_HA ❌, REMOTE_LAN client -> HOME_LAN client ❌ . Traceroute HOME_LAN client -> REMOTE_HA makes the hops it's supposed to (local router/firewall -> HOME_HA), but times out when it reaches HOME_HA (third hop); the same is true for REMOTE. Traceroute from HOME_HA - REMOTE_HA shows traffic is routed through Wireguard Add-on (docker) and reaches REMOTE_HA, same for REMOTE.

Could anyone please help me with diagnosing/fixing the problem? If needed, can post relevant configs, just didn't want to scare people off with a wall of text.

Thanks in advance

pure bolt
#

Noone, no ideas? Come on, please

spare anvil
#

Hi there! I use wireguard but not as an addon in HA. Is there any error log in wireguard addons? Are your ports forwarded correctly on the routers to point to WG in HA (i think :51280 udp)? Does the config look correct? with allowed ips, client ips, hosts, etc? Are your home/remote clients connected yo WG per WG's logs? Will you be able to post the configs?

pure bolt
# spare anvil Hi there! I use wireguard but not as an addon in HA. Is there any error log in w...

Howdy! Thanks a lot for taking the ime / interest in my problem. It seems the problem is not in the Wireguard Add-on (maybe I'm wrong?), as the connection between the sites (Home Add-on and Remote Add-on) functions correctly, as does VPN-ing from my phone to each of the locations. There are no errors in the Wireguard log, it just shows normal stuff - peers, traffic flowing... Also, the ports are forwarded and apropriate firewall rules in place on both locations (as is evident from the normal traffic flow throgh tunnel(s)).

#

From the traceroute done from any of the (home or remote) LAN clients, it's evident that the traffic reaches the HA - ergo the routes in the local router(s)/firewall(s) are set appropriately. The traceroute shows traffic reaching the HA instance but it seems it's not forwarded to the Add-on (docker?) itself even though the iptables rules in the underlying OS and the routes in HA have been set and were functioning for about a year without a hitch. I'm a noob and totally lost as to how to even pinpoint the exact "location" where things go wrong.

spare anvil
#

Do you have any dns overrides (adblocker etc), which could fail to pass it to WG ip? Did anything change in network like subnet or dns server etc? Also, maybe you can just keep instance of WG on home network and connect all devices to that WG with same peer? (Maybe im wrong) If you could, please paste your WG configs.

pure bolt
# spare anvil Do you have any dns overrides (adblocker etc), which could fail to pass it to WG...

Just went over everything you asked about... Subnets all the same as they've been for 5y+, on both locations (LOCAL 10.0.0.0/16 and 192.168.100.0/24; REMOTE 10.3.0.0/24, 192.168.1.0/24). I also have a third location, but connected through OpenVPN othat's runinng on my ancienct local and remote Unify USGs and they work normally. I do have a couple of AdGuard instances (2 local, 2 remote) running, but strictly as DNS, including DNS rewrites for local services (like mealie.lan, myserver.lan) and the name resolution works normally when connecting through my cellphone to both the local and remote WG add-ons.

#

my local config. frist peer is site-to-site, the second and third are for me and my girlfriend to be able to connect when on the road...

#

local_server_config

`host: <hidden>
addresses:

  • 10.11.0.1/32
    dns:
  • 172.30.32.1
    private_key: "!secret wireguard-<hidden>-private_key"
    public_key: "!secret wireguard-<hidden>-public_key"
    mtu: 1280`

local_peers_config

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

  • name: <hidden>
    addresses:
    • 10.11.0.5/32
      private_key: "!secret wireguard-<hidden>-private_key"
      public_key: "!secret wireguard-<hidden>-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
    • 172.30.32.1
      persistent_keep_alive: 25
      pre_shared_key: "!secret wireguard-preshared_key"
  • name: <hidden>
    addresses:
    • 10.11.0.6/32
      private_key: "!secret wireguard-<hidden>-private_key"
      public_key: "!secret wireguard-<hidden>-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
    • 172.30.32.1
      persistent_keep_alive: 25
      pre_shared_key: "!secret wireguard-preshared_key"`
#

remote_server_config

`host:<hidden>
addresses:

  • 10.11.0.3/32
    dns:
  • 172.30.32.1
    private_key: "!secret wireguard-<hidden>r-private_key"
    public_key: "!secret wireguard-<hidden>r-public_key"`

remote_peers_config

`- name: <hidden>
addresses:
- 10.11.0.1/32
private_key: "!secret wireguard-<hidden>-private_key"
public_key: "!secret wireguard-<hidden>-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
- 172.30.32.1
persistent_keep_alive: 25
endpoint: vpn.<hidden>.monster:51820
pre_shared_key: "!secret wireguard-preshared_key"

  • name: <hidden>
    addresses:
    • 10.11.0.5/32
      private_key: "!secret wireguard-<hidden>-private_key"
      public_key: "!secret wireguard-<hidden>-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
    • 172.30.32.1
      persistent_keep_alive: 25
      pre_shared_key: "!secret wireguard-preshared_key"
  • name: <hidden>
    addresses:
    • 10.11.0.6/32
      private_key: "!secret wireguard-<hidden>-private_key"
      public_key: "!secret wireguard-<hidden>-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
    • 172.30.32.1
      persistent_keep_alive: 25
      pre_shared_key: "!secret wireguard-preshared_key"`
spare anvil
#

It's a bit late for me, but can you try allowed ips: [] and client_allowed_ips: []? Basically opening up those ip ranges. Also, try without adguard dns, something like 8.8.8.8 (google dns) or anyother public dns.

#

Im still not getting why you need 2 WGs. Wouldn't keeping 1 WG and connecting all devices to it work for you? (Im not an expert in networks, lol, so bare my excuse)