Roon over Wireguard with remote Roon Bridge

Tinkering
1

Here’s my setup:

  • Roon Core running on a dedicated machine in my home network. The router there is a FritzBox with Beta software that runs a Wireguard server.
  • MacBook Air running Roon client in my partner’s home network. This machine connects to roon over a Wireguard VPN connection to the abovementioned FritzBox.
  • Raspberry PI with Hifiberry Digi board connected to a DAC in my partner’s home network, running on Hifiberry OS.

I tried several option to have the Raspberry Pi with Hifiberry OS (essential Roon Bridge on a Linux OS) recognized by the remote Roon Core, to no avail.

So instead of Hifiberry OS, I installed DietPi on the Raspberry Pi. DietPi makes it easy to install Roon Bridge and Wireguard on the Raspberry. I connected the Raspberry to the FritzBox Wireguard server (you need a dedicated entry for each client on the server), and voilà: now that the Raspberry Pi endpoint has an IP address on the same network as the Roon Core, it’s being recognized by the Core.

So basically on the remote network both the laptop running Roon Client and the endpoint running Roon Bridge establish a VPN connection to the network where the Roon Core is located, and I can play to my partner’s stereo with the DAC connected (of course the DAC could also be a board on the Raspberry PI itself).

Hope that helps.

4 Likes
2

Very interesting, so having a private IP address within the same subnet seems to be enough to make a remote Roon bridge connect to a remote Roon core?

3

I use Wireguard on my unRAID server to connect to Roon on my laptop when away from home and on my work PC. It works great, some minor issues with RAATserver not seeing my laptop as an endpoint after my laptop sleeps but I wrote a batch file to quickly restart RAATserver to get around this easily. Overall it works really well.

4

So it seems. And my experiment seems to verify this. I’ll share further observations.

5

Oh great. I’ll rebuild the setup using my Mikrotik router tonight to see whether a Room remote app will be able to connect and stream. I’ll keep you updated as well.

1 Like
6

I guess that you’re not running Linux, otherwise we could have connected the restart task to the hibernate target automating the fix restarting the RAAT server when waking up from sleep mode

7

I’m running Windows unfortuately

8

As it turns out my issue was caused by modern standby. I disabled that and no more issues. It’s better anyway since that is better for battery life and I don’t mind waiting 30 seconds for my PC to wake from sleep.

Edit: better solution. I’m going to disable sleep unless I close the screen of my laptop, then set a scheduled task to restart raatserver.exe when my machine comes out of modern standby.

Edit 1: This is working great, tested quite a bit already. Finally no more issues using Roon on my laptop!

I made a post here explaining my solution to this, I was able to resolve it with task scheduler: GUIDE: Local Windows Endpoint Disappears after Sleep when using VPN, solution using task scheduler

9

Lucky you, I wasn’t able to establish communication using an Android device running a wireguard tunnel over LTE. i could control Roon endpoints but I wasn’t able to stream music back to the wireguard client (Android). I will give it another shot and install wireguard together with Roon bridge on a RPI4. I’ll keep you updated.

10

I found that when configuring the peer in wireguard you want to ensure that you are not pushing the lan but tunneling all traffic through the VPN. On my unraid server which has wireguard built in it calls it “remote tunneled access” but it may be different in different implementations.

11

If you don’t mind sharing the platform you are running Wireguard on I can try and help. I have this working with unRAID so it may be similar.

12

I’m running a Mikrotik router using version 7.6 that supports wireguard since the last major update. Roon is running as docker container with 3 IP interfaces each running with static IP. For all interfaces the Mikrotik router is the gateway. In that particular case I’m running a subnet 10.60.205.0/24 with the router being 10.60.205.1/24, the Roon instance got 10.60.205.10/24 assigned. The wireguard server interface got 10.60.205.80/24 while the wireguard client (Android) got 10.60.205.81/24. It appears that when creating a wireguard interface, the router creates a second route entry for the same subnet. Both entries have the same priority.

Android wireguard client configuration:

[Interface]
PrivateKey = ClientPrivateKey
Address = 10.60.205.81/32
DNS = 10.60.200.5

[Peer]
PublicKey = RouterPubkey
AllowedIPs = 0.0.0.0/0
Endpoint = router.url.se:13256

Router configuration is

add allowed-address=10.60.205.81/32 comment=music-Pixel4 endpoint-address=10.60.205.81/32 endpoint-port=13256 interface=wireguard1 public-key="ClientPubkey"

I’ve followed this configuration guide => WireGuard - RouterOS - MikroTik Documentation

Docker setup

roon:
    image: steefdebruijn/docker-roonserver:debian-11-slim
    init: true
    container_name: "roon"
    hostname: roon
    domainname: home.myurl.se
    restart: unless-stopped
    environment:
      TZ: "Europe/Stockholm"
    volumes:
      - roon-app:/app
      - roon-db:/data
      - /mnt/media/music:/music:ro
        # - /mnt/extSSD/roon-backups:/backup
    labels:
      - "traefik.enable=false"
    networks:
      macvlan201:
        ipv4_address: 10.60.201.10
      macvlan202:
        ipv4_address: 10.60.202.10
      macvlan205:
        ipv4_address: 10.60.205.10
...
networks:
  macvlan201:
    name: vlan201
    driver: macvlan
    driver_opts:
      parent: enp0s20u3.201
    ipam:
      config:
        - subnet: 10.60.201.0/24
          gateway: 10.60.201.1
  macvlan202:
    name: vlan202
    driver: macvlan
    driver_opts:
      parent: enp0s20u3.202
    ipam:
      config:
        - subnet: 10.60.202.0/24
          gateway: 10.60.202.1
  macvlan205:
    name: vlan205
    driver: macvlan
    driver_opts:
      parent: enp0s20u3.205
    ipam:
      config:
        - subnet: 10.60.205.0/24
          gateway: 10.60.205.1

Notes:

  • connecting to Roon is working when setting IP addresses on the wireguard interface that are not part of any existing IP subnet inside the router. So having the WG server interface inside 10.60.205.0/24 is not working. Setting 10.60.110.2/24 (creates a new route to 10.60.110.0/24) and 10.60.110.101/32 on WG client (Android) works - Roon remote control, but not streaming.
13

I never set up Wireguard over the command line so I have no clue how to configure this sorry. I do use it under unRAID and the option I selected that works unRAID calls remote tunneled access. I’d suggest you look into how that gets configured and then see if you can use those settings in your configuration. Mine is done through a pretty simple GUI so I’m not sure how I can otherwise help.

14

I understand. Sometimes it just magically works. I’ll do some research in how it has been implemented in unRaid.

Screenshot_20221130_224514_Roon
Screenshot_20221130_224514_Roon1080×2400 164 KB

1 Like
15

As a test maybe try running Wireguard on the same machine your Roon docker is running on. I’m running my docker and wireguard on my unraid server. Maybe that will get it working for you?

16

Yeah, it could be a solution. But from a network point of view I do not want to have a Wireguard entity inside the “secure” zone. Even if I think that it would probably solve the problem. But it would be a bad network design.
I hoped that Roon would actually present a best practice guide in how to achieve a reliable remote connection using wireguard #feedback:feature-suggestions #support. Not every single use case, but at least - in the very same way as Mikrotik did it (see link above). I would love to collaborate to achieve this.

1 Like
18

I had some trouble with the configuration I described above, but I can now say that the order of starting services seems to matter. I could reliably restart everything in this order:
1st) Wireguard on the DietPi system
2nd) Roon Bridge on the DietPi system
3rd) Roon Core on the remote network
If anyone else is lucky with a similar setup, I’d love to hear about it.

19

You need to ensure you are tunneling all traffic including internet traffic over the vpn. Try setting allowed IPs to 0.0.0.0/0. That is how mine is set up and that also helped another poster that I was discussing this with.

20

Not necessary here, and actually not what I want either, since the Raspberry Pi should also be available for streaming requests from the local network when I don’t use it for Roon.

Here’s the output of “route -n” on the Raspberry Pi (under DietPi):

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.178.1 0.0.0.0 UG 0 0 0 eth0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wg0
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

So 192.168.0.0/24 is the remote network where the Core is located,
192.168.178.0/24 is the network the Raspberry Pi resides on.

I haven’t encountered any problem with this.

21

Another detail: It seems like all three need to be on the same subnet in order to establish the connection – the Roon Core, Roon Client and Roon Bridge. Once the Core has learned about the bridge, it doesn’t matter any more where the client lives.

I’m curious now how exactly those negotiations between Core, Client and Bridge work. Who is sending out UDP packages when and at which intervals?