Nordlynx on Synology NAS

[b-kamphorst]

Hi all,

It seems to be non-trivial to configure the Nordlynx container so that it runs successfully on Synology NAS. The main forum for the discussion used to be #1, but it seems about right to move the comments into a dedicated discussion. Not only does #1 get to be an actual welcome, but also this makes it much easier for others to find and refer to the discussion.

The goal of this discussion is two-fold. First, we aim to find a working configuration for Synology NAS (to my knowledge that has not been shared yet). Doesn't have to be optimal, doesn't have to be fully understood. Second, with the community, we can extract a minimal configuration and possibly discuss some additions that relate to a common need.

During and/or after this process, the results should be documented concisely in the wiki. I'm looking forward to our joint effort!

[b-kamphorst]

First, I installed Wireguard on my Synology as explained here. Next, I could get started with Nordlynx. Below, you find (part of) my current docker compose file.

This configuration runs successfully on Synology DS218+ for several days now (apart from seemingly random hickup that was also experienced by others, cf. #38). I don't particularly like latest tags for reproducibility reasons, so in my actual setup nordlynx is pinned to 2022-02-12. Also, I installed Wireguard on my Synology as explained here first.

services:
  nordlynx:
    image: ghcr.io/bubuntux/nordlynx:latest
    container_name: nordlynx
    restart: unless-stopped
    security_opt:
      - no-new-privileges:true
    cap_add:
      - NET_ADMIN
      - NET_RAW
      - SYS_MODULE
    sysctls:
      - net.ipv6.conf.all.disable_ipv6=1  # Recommended if using ipv4 only
    ports:
      - 51413:51413  # Transmission torrent TCP port
      - 51413:51413/udp  # Transmission torrent UDP port
    volumes:
      - /lib/modules:/lib/modules:ro # Required to install wireguard module
    environment:
      - PRIVATE_KEY=[INSERT_YOUR_KEY]=
      - DNS=103.86.96.100,103.86.99.100,127.0.0.11
      - ALLOWED_IPS=0.0.0.0/1,128.0.0.0/2
      - NET_LOCAL=10.0.0.0/8,172.16.0.0/12,192.168.0.0/16

As mentioned in the OP, this is hopefully a working example for most of us. If it works for you, please indicate so through a comment or by upvoting. If it works for others as well, I'd like to optimize it together. I'm quite sure that it can be improved upon (e.g. the cap_add)

I'll walk through all arguments to motivate them and suggest topics of discussion.

cap_add

The three capabilities mentioned were copied from an earlier version of the README. Apparently they were removed again in e1b627d, but I only saw that now. Would be interesting to see if we can remove some of them.

sysctls

Perhaps due to the additional container capabilities, I was not able to also pass ipv4.conf.all.src_valid_mark=1. Trying to do so resulted in invalid argument "ipv4.conf.all.src_valid_mark=1" for "--sysctl" flag: sysctl 'ipv4.conf.all.src_valid_mark=1' is not whitelisted.

volumes

Mounting /lib/modules was also suggested in the earlier README. I added the read-only flag only after several attempts, so perhaps something was already changed on the host in my first attempts. If so, you may need to remove :ro to make it work.

environment

• DNS: I added the Docker DNS address 127.0.0.11 hoping that I could ping containers by name. From my transmission container I am able to ping nordlynx, but no other containers that use the nordlynx network. Not sure if this is expected behavior. In any case, this is not Synology related so we may as well ignore it in the discussion.
• ALLOWED_IPS: This took me a long time to figure out. Ideally, you would provide 0.0.0.0/0 (default), but that does not work for Synology. The suggestion 0.0.0.0/1 works, but (rightfully) drops all traffic from 128.0.0.0/1. This explains why people successfully pinged 1.1.1.1 and 8.8.8.8, but were unable (ping: sendto: Operation not permitted) to ping google.com (which resolves to e.g. 142.251.36.46).
  Unfortunately, the obvious solution 0.0.0.0/1,128.0.0.0/1 didn't work for me either (no reply when pinging 8.8.8.8 and unable to resolve google.com: ping: bad address 'google.com'). Limiting the range to 0.0.0.0/1,128.0.0.0/2 solved my problems.
  Others have suggested a more fine-tuned approach, but I figured that this may be too much for a minimal working example. However, they make an potentially interesting remark that the server address should be excluded from ALLOWED_IPS. Perhaps this could help us pinpoint the actual issue?
• NET_LOCAL: Just the common local IP ranges, even though one probably doesn't need all of them.

Looking forward to your thoughts!

[milopalmer]

Where specifically are you changing the endpoint and gateway settings? I'm not able to follow what file/setting is being altered to get it to function on my DS1821+ Docker setup. Thanks! @b-kamphorst

[ginodesilva]

The commands are to be entered in the console. Attach to the docker container.

docker exec -it /bin/bash

Then execute the commands as mentioned above.

[milopalmer]

Thanks for the tip @ginodesilva ! This solution is indeed working for me too. Previously with bubuntux/Nordvpn using Nordlynx technology, I also used SOCKS5 Proxy Server in qBittorrent is that useful still? I did need to change the Network Interface under Advanced in qBT to wg0 to get good speed.

For the extra commands referenced above, do they need to be run each time Nordlynx is restarted? Possible to add it to my Portainer stack/compose?

[ginodesilva]

Previously with bubuntux/Nordvpn using Nordlynx technology, I also used SOCKS5 Proxy Server in qBittorrent is that useful still? I did need to change the Network Interface under Advanced in qBT to wg0 to get good speed.

For the extra commands referenced above, do they need to be run each time Nordlynx is restarted? Possible to add it to my Portainer stack/compose?

I don't think SOCKS5 proxy is needed since you are already anonymous through your NordVPN. I can't verify the torrent speeds since unfortunately I only have access to public trackers and aren't getting double download digits through them. The wg0 interface is the wireguard interface so your qBT should use that.

Everytime you (re)connect the IP address changes, so yeah. That's why I hope the dynamic solution b-kamphorst used instead of my specific solution for troubleshooting can be implemented in bubuntux nordlynx container upon connecting as well as upon reconnecting.

[b-kamphorst]

Adding the following environmental variables worked for me!

POST_UP="ip -4 route add $(wg | awk -F'[: ]' '/endpoint/ {print $5}') via $(ip route | awk '/default/ {print $3}')"
PRE_DOWN="ip -4 route del $(wg | awk -F'[: ]' '/endpoint/ {print $5}') via $(ip route | awk '/default/ {print $3}')"

I'll present the updated configuration in a new post so that we can see if that is optimal.

For now the above, minor change seems to solve our problems. Note that the Wireguard documentation describes a solution based on network namespaces that appears to handle our issue by default, but this requires a big change to the nordlynx codebase and I cannot oversee if this solution is superior in general. @bubuntux, do you have thoughts on that?

[b-kamphorst]

Starting on Synology NAS with Wireguard installed, please consider the following updated config proposal that includes the above fix for the ALLOWED_IPS issue:

# nordlynx.yml
services:
  nordlynx:
    image: ghcr.io/bubuntux/nordlynx:latest
    container_name: nordlynx
    restart: unless-stopped
    security_opt:
      - no-new-privileges:true
    cap_add:
      - NET_ADMIN
    sysctls:
      - net.ipv6.conf.all.disable_ipv6=1  # Recommended if using ipv4 only
    ports:
      - 51413:51413  # Transmission torrent TCP port
      - 51413:51413/udp  # Transmission torrent UDP port
    env_file:
      - nordlynx.env

# nordlynx.env
PRIVATE_KEY=[INSERT_YOUR_KEY]=
ALLOWED_IPS=0.0.0.0/1,128.0.0.0/1
NET_LOCAL=10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
POST_UP="ip -4 route add $(wg | awk -F'[: ]' '/endpoint/ {print $5}') via $(ip route | awk '/default/ {print $3}')"
PRE_DOWN="ip -4 route del $(wg | awk -F'[: ]' '/endpoint/ {print $5}') via $(ip route | awk '/default/ {print $3}')"

One can make this work with the environmental variables in the compose file, which includes some escaping here and there, but I prefer to have it in somewhat less unreadable format.

Optionally, one may add the following environmental variable:

DNS=103.86.96.100,103.86.99.100,127.0.0.11

This line complements default nordlynx DNS by docker DNS. By doing so, containers behind nordlynx can resolve nordlynx and other containers that directly connect to the current docker network (e.g. not via nordlynx). Since docker DNS is not aware of the containers behind nordlynx, their names can not be resolved (as far as I know, but please correct me).

Does this configuration look like a good (minimal) start? Please provide your feedback! If the community approves, I'll add it to the wiki.

[ginodesilva]

So, I once again did a lot of troubleshooting with echos on all PRE and POST variables. Am not going to bother with all the output. What I discovered was the following problem:
After the RECONNECT timer has run out, a new connection will be established. There is a /32 route to the wg endpoint we're trying to delete with the PRE_DOWN. However, during the PRE_DOWN the wg endpoint can already be renewed! So deleting the route according to the variable from the wg output will fail on that occasion.

Alright, a small sample of echos from my troubleshooting. Can't help myself.

 
[2022-03-12T01:57:12+01:00] Connecting...
[#] 
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.5.0.2/32 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] resolvconf -a wg0 -m 0 -x
[#] ip -4 route add 128.0.0.0/1 dev wg0
[#] ip -4 route add 0.0.0.0/1 dev wg0
[#] echo '****POST_UP****';echo 'adding route to:'; wg | awk -F'[: ]' '/endpoint/ {print $5}';ip -4 route add $(wg | awk -F'[: ]' '/endpoint/ {print $5}') via $(ip route | awk '/default/ {print $3}');
****POST_UP****
adding route to:
213.232.87.75
[2022-03-12T01:57:12+01:00] Connected! \(ᵔᵕᵔ)/
[2022-03-12T01:57:12+01:00] Reconnecting in 60 seconds
[2022-03-12T00:58:12+00:00] Connection summary:
interface: wg0
 <...>
***PRE_DOWN****
route present:
213.232.87.75   172.17.0.1      255.255.255.255 UGH   0      0        0 eth0
new wg endpoint
  endpoint: 213.232.87.99:51820
deleting old route to:
213.232.87.75
****END PRE_DOWN****
[#] ip link delete dev wg0
[#] resolvconf -d wg0 -f
[#] 
[2022-03-12T01:58:12+01:00] Finding the best server...
[2022-03-12T01:58:13+01:00] Using server: {
...etc

I don't know why this is happening. As stated before, I don't know how the wireguard reconnect works and if the PRE_DOWN is executed beforehand. Also, why is it happening to my setup more? Perhaps my older (and therefore slower) model Synology? Most likely.

I think I solved the problem by retrieving the variable for deleting the route not from the wg output but from the current routing table itself. The new correct route isn't there yet since it will be added in POST_UP.

My PRE_DOWN is: ip -4 route del $(route -n | awk '/255.255.255.255/ {print $1}') via $(ip route | awk '/default/ {print $3}')

Going to let it run for the entire night, reconnecting every 5 minutes and will report back the findings.

Edit: Seeing lots of server changes in the logfile but never a failed route delete. This PRE_DOWN is working for me.

****PRE_DOWN****
route present: 213.232.87.198  172.17.0.1      255.255.255.255 UGH   0      0        0 eth0
new wg endpoint: 213.232.87.111
deleting route to: 213.232.87.198
****END PRE_DOWN****

[b-kamphorst]

It turns out I am able to replicate, but my RECONNECT was set too low. I have a slightly different hypothesis from you, which I'll explain below (disclaimer: still a beginner). Long story short: I think the issue is rooted in NordVPN -- although I do have some open questions -- your solution works and if we are able to cook up a simple, more verbose version that'd be nice.

As you suggested, the wg endpoint during POST_UP is sometimes different from the wg endpoint during PRE_DOWN. However, I think this is not because of the reconnect itself. Some investigation indicates that nordlynx uses with-contenv, which is basically responsible for the wireguard service. The script for wireguard just sleeps indefinitely unless RECONNECT is provided, in which case the process terminates after the provided interval. with-contenv then runs the script again. In particular, the wireguard service is not reconnecting in some special way -- it is terminated and started again. PRE_DOWN should be called before the wireguard process is terminated, so this shouldn't be able to interfere with the new process that is only started after termination (with-contenv isn't even aware of what the process does).

Instead, the wireguard homepage explains that a server (resp. client) may change its endpoint and that the client (resp. server) configuration will be updated automatically. This would fully explain why (1) the wg endpoint can change over time and (2) why the issue only surfaced with a 'longer' RECONNECT interval (the server had time to change its endpoint).

Open questions:

• Why do NordVPN servers change their endpoints and is this behavior expected?
• Why does the routing still work even though we didn't add a new endpoint? (Probably wireguard magic.)

Now for the solution you propose: nice job for fixing the issue! Perhaps a matter of taste, but I think I prefer your earlier suggestion to use environment variables as it is more verbose to the user. However, my attempts all failed as variables exported in POST_UP do not live during PRE_DOWN (or even directly after POST_UP). If we can easily make this work, that'd be a nice bonus.

Just out of curiosity: why do you set RECONNECT?

[ginodesilva]

I'm using a RECONNECT for the off chance an issue occurs with the endpoint I'm connecting to. It may be the best/fastest upon reconnecting but that may not be the case in the future. It may not be necessary, it might. Just a precaution.

And I'm guessing you're talking about the built-in roaming of wireguard? I somewhat concur. Let me show you the following output from my logfile:

****POST_UP****
adding route to:
213.232.87.198
[2022-03-12T11:36:34+01:00] Connected! \(ᵔᵕᵔ)/
[2022-03-12T11:36:34+01:00] Reconnecting in 300 seconds
[2022-03-12T10:41:34+00:00] Connection summary:
interface: wg0
<...>

peer: XXXX
  endpoint: 213.232.87.111:51820
<...>
****PRE_DOWN****
route present:
213.232.87.198  172.17.0.1      255.255.255.255 UGH   0      0        0 eth0
wg endpoint
  endpoint: 213.232.87.111:51820
deleting route:
213.232.87.198
****END PRE_DOWN****

The log shows a route is being added after a successful connection to 213.232.87.198. After the RECONNECT timer runs out, wireguard/finish echoes Connection summary: with a new endpoint IP address. wg-quick shuts down the wg0 and THEN the PRE_DOWN is executed showing the new endpoint IP address.

The question is: when did the endpoint address change? Sometime during the RECONNECT period or immediately after the timer ran out and before wireguard/finish is executed?
I think the latter because before my troubleshooting, I had the RECONNECT set to a whole week. I ran without problems. Only after that week, my connection failed due to a change in endpoint IP address. I have it set to two days now and the endpoint address hasn't changed during that time. I hope that someone with a better understanding of NordLynx and wireguard can provide a definitive answer on when the address changes. For now I think the POST_UP and PRE_DOWN works for us (until proven otherwise).

That leaves us with the following for a working NordLynx setup on a Synology NAS (if you agree).

1. Without going into why, Synology needs a ALLOWED_IPS=0.0.0.0/1, 128.0.0.0/1 . This allows all IP address to be reached through the VPN.
2. A specific /32 route is needed to reach the endpoint through the default gateway, outside the VPN itself. This is done by the following POST_UP="ip -4 route add $(wg | awk -F'[: ]' '/endpoint/ {print $5}') via $(ip route | awk '/default/ {print $3}')"
3. When shutting down the VPN or the RECONNECT timer runs out, the route created in POST_UP needs to be removed. This is achieved with the following PRE_DOWN="ip -4 route del $(route -n | awk '/255.255.255.255/ {print $1}') via $(ip route | awk '/default/ {print $3}')"
4. The syntax of the above POST_UP and PRE_DOWN creates the need of an env_file. My coding skills are limited therefore I don't exactly know which characters need to be escaped. Suggestions are welcome!

I think the wiki can be safely updated. The ALLOWED_IPS in the wiki is wrong and the POST_UP now present isn't needed.

[b-kamphorst]

OK thanks for explaining.

I was talking about IP roaming indeed. I altered the image so that it prints the current endpoint every minute. RECONNECT is set to 10 minutes. The issue surfaced after 18 hours, below you find the relevant part of the logs:

[2022-03-14T16:15:01+01:00] Connected! \(ᵔᵕᵔ)/
[2022-03-14T16:15:01+01:00] Reconnecting in 600 seconds
[2022-03-14T16:15:01+01:00] Current endpoint: 213.232.87.115
[2022-03-14T16:16:01+01:00] Current endpoint: 213.232.87.81
[2022-03-14T16:17:01+01:00] Current endpoint: 213.232.87.81
[2022-03-14T16:18:01+01:00] Current endpoint: 213.232.87.81
[2022-03-14T16:19:01+01:00] Current endpoint: 213.232.87.81
[2022-03-14T16:20:01+01:00] Current endpoint: 213.232.87.81
[2022-03-14T16:21:01+01:00] Current endpoint: 213.232.87.81
[2022-03-14T16:22:01+01:00] Current endpoint: 213.232.87.81
[2022-03-14T16:23:01+01:00] Current endpoint: 213.232.87.81
[2022-03-14T16:24:01+01:00] Current endpoint: 213.232.87.81
[2022-03-14T15:25:01+00:00] Connection summary:
interface: wg0
  public key: XXXX=
  private key: (hidden)
  listening port: 51820
peer: XXXX=
  endpoint: 213.232.87.81:51820
  allowed ips: 0.0.0.0/1, 128.0.0.0/1
  latest handshake: 9 minutes, 59 seconds ago
  transfer: 2.98 KiB received, 224.91 KiB sent
  persistent keepalive: every 25 seconds
[#] ip -4 route del $(wg | awk -F'[: ]' '/endpoint/ {print $5}') via $(ip route | awk '/default/ {print $3}')
RTNETLINK answers: No such process
[2022-03-14T16:25:01+01:00] Finding the best server...
curl: (28) Failed to connect to api.nordvpn.com port 443 after 213658 ms: Operation timed out

Click for full session log

[2022-03-14T16:15:00+01:00] Finding the best server...
[2022-03-14T16:15:01+01:00] Using server: {
  "id": 973274,
  "created_at": "2020-08-24 12:31:37",
  "updated_at": "2022-03-14 15:12:30",
  "name": "Netherlands #892",
  "station": "213.232.87.115",
  "ipv6_station": "",
  "hostname": "nl892.nordvpn.com",
  "load": 5,
  "status": "online",
  "cpt": 100,
  "locations": [
    {
      "id": 5,
      "created_at": "2017-06-15 14:06:47",
      "updated_at": "2017-06-15 14:06:47",
      "latitude": 52.35,
      "longitude": 4.916667,
      "country": {
        "id": 153,
        "name": "Netherlands",
        "code": "NL",
        "city": {
          "id": 6076868,
          "name": "Amsterdam",
          "latitude": 52.35,
          "longitude": 4.916667,
          "dns_name": "amsterdam",
          "hub_score": 0
        }
      }
    }
  ],
  "groups": [
    {
      "id": 11,
      "created_at": "2017-06-13 13:43:00",
      "updated_at": "2017-06-13 13:43:00",
      "title": "Standard VPN servers",
      "identifier": "legacy_standard",
      "type": {
        "id": 3,
        "created_at": "2017-06-13 13:40:17",
        "updated_at": "2017-06-13 13:40:23",
        "title": "Legacy category",
        "identifier": "legacy_group_category"
      }
    },
    {
      "id": 15,
      "created_at": "2017-06-13 13:43:38",
      "updated_at": "2017-06-13 13:43:38",
      "title": "P2P",
      "identifier": "legacy_p2p",
      "type": {
        "id": 3,
        "created_at": "2017-06-13 13:40:17",
        "updated_at": "2017-06-13 13:40:23",
        "title": "Legacy category",
        "identifier": "legacy_group_category"
      }
    },
    {
      "id": 19,
      "created_at": "2017-10-27 14:17:17",
      "updated_at": "2017-10-27 14:17:17",
      "title": "Europe",
      "identifier": "europe",
      "type": {
        "id": 5,
        "created_at": "2017-10-27 14:16:30",
        "updated_at": "2017-10-27 14:16:30",
        "title": "Regions",
        "identifier": "regions"
      }
    }
  ],
  "specifications": [
    {
      "id": 8,
      "title": "Version",
      "identifier": "version",
      "values": [
        {
          "id": 257,
          "value": "2.1.0"
        }
      ]
    }
  ],
  "ips": [
    {
      "id": 297620,
      "created_at": "2021-04-15 07:53:15",
      "updated_at": "2021-04-15 07:53:15",
      "server_id": 973274,
      "ip_id": 93432,
      "type": "entry",
      "ip": {
        "id": 93432,
        "ip": "213.232.87.115",
        "version": 4
      }
    }
  ]
}
[2022-03-14T16:15:01+01:00] Connecting...
[#] 
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.5.0.2/32 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] resolvconf -a wg0 -m 0 -x
[#] ip -4 route add 128.0.0.0/1 dev wg0
[#] ip -4 route add 0.0.0.0/1 dev wg0
[#] ip -4 route add $(wg | awk -F'[: ]' '/endpoint/ {print $5}') via $(ip route | awk '/default/ {print $3}')
[2022-03-14T16:15:01+01:00] Connected! \(ᵔᵕᵔ)/
[2022-03-14T16:15:01+01:00] Reconnecting in 600 seconds
[2022-03-14T16:15:01+01:00] Current endpoint: 213.232.87.115
[2022-03-14T16:16:01+01:00] Current endpoint: 213.232.87.81
[2022-03-14T16:17:01+01:00] Current endpoint: 213.232.87.81
[2022-03-14T16:18:01+01:00] Current endpoint: 213.232.87.81
[2022-03-14T16:19:01+01:00] Current endpoint: 213.232.87.81
[2022-03-14T16:20:01+01:00] Current endpoint: 213.232.87.81
[2022-03-14T16:21:01+01:00] Current endpoint: 213.232.87.81
[2022-03-14T16:22:01+01:00] Current endpoint: 213.232.87.81
[2022-03-14T16:23:01+01:00] Current endpoint: 213.232.87.81
[2022-03-14T16:24:01+01:00] Current endpoint: 213.232.87.81
[2022-03-14T15:25:01+00:00] Connection summary:
interface: wg0
  public key: XXXX=
  private key: (hidden)
  listening port: 51820
peer: XXXX=
  endpoint: 213.232.87.81:51820
  allowed ips: 0.0.0.0/1, 128.0.0.0/1
  latest handshake: 9 minutes, 59 seconds ago
  transfer: 2.98 KiB received, 224.91 KiB sent
  persistent keepalive: every 25 seconds
[#] ip -4 route del $(wg | awk -F'[: ]' '/endpoint/ {print $5}') via $(ip route | awk '/default/ {print $3}')
RTNETLINK answers: No such process
[2022-03-14T16:25:01+01:00] Finding the best server...
curl: (28) Failed to connect to api.nordvpn.com port 443 after 213658 ms: Operation timed out
curl: (28) Failed to connect to api.nordvpn.com port 443 after 213657 ms: Operation timed out
curl: (28) Failed to connect to api.nordvpn.com port 443 after 213666 ms: Operation timed out
curl: (28) Failed to connect to api.nordvpn.com port 443 after 213633 ms: Operation timed out
[2022-03-14T16:39:23+01:00] Unable to select a server ¯\_(⊙︿⊙)_/¯

As you can see, the endpoint changed during the session (1-2 minutes after the connection was established), not in the proximity of a reconnect. I'll make an issue for this to confirm this behavior is expected. I'll also run a second experiment to see if this behavior surfaces if we fix the NordVPN server (I'd expect so).

I agree with the configuration. I'll update the wiki (and probably the readme) shortly (probably tomorrow).

[b-kamphorst]

Took too long, but finally fixed the escaping. We needed to put "KEY=VALUE" in quotes and escape all $ like so: $$. Took me ages to get the quotes right. See next post.

Also, I haven't been able to successfully formulate a QUERY that allows me to always connect to the same server, so that experiment will have to wait.

[b-kamphorst]

After a pleasant joint troubleshooting effort with @ginodesilva, we have come to the following configuration for Synology NAS (Wireguard installed):

services:
  nordlynx:
    image: ghcr.io/bubuntux/nordlynx:2022-03-01
    container_name: nordlynx
    restart: unless-stopped
    security_opt:
      - no-new-privileges:true
    cap_add:
      - NET_ADMIN
    sysctls:
      - net.ipv6.conf.all.disable_ipv6=1  # Recommended if using ipv4 only
    environment:
      - PRIVATE_KEY=[INSERT_YOUR_KEY]=
      - ALLOWED_IPS=0.0.0.0/1,128.0.0.0/1
      - NET_LOCAL=10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
      - "POST_UP=ip -4 route add $$(wg | awk -F'[: ]' '/endpoint/ {print $$5}') via $$(ip route | awk '/default/ {print $$3}')"
      - "PRE_DOWN=ip -4 route del $$(route -n | awk '/255.255.255.255/ {print $$1}') via $$(ip route | awk '/default/ {print $$3}')" 

Synology specifics:

• ALLOWED_IPS can not be 0.0.0.0/0, which is why we split the full range into two halves.
• POST_UP adds a route for directing all traffic to the nordvpn server endpoint to the gateway (otherwise it gets stuck).
• PRE_DOWN removes the custom route above (needed for reconnect). Since the endpoint may have changed during the connection, we cannot extract its address from wg like we did in POST_UP.

[ginodesilva]

Hi @styggiti , sorry for the late reply.
A couple of things regarding the networking questions you have.
To my knowledge, double NAT should work for regular use. You are the one initiating the tunnel setup and traffic so your double NAT allows the traffic to be forwarded to the NordVPN endpoints on the Internet. The NAT routers keep track of the IP addresses and ports used in order for return traffic to be forwarded to the correct IP addresses. So setting up the VPN should work out of the box (mind you your Synology firewall should allow traffic to the docker networks (learned that the hard way).
The double NAT does pose a challenge if you need services to be reachable from the Internet outside the VPN. In that case, each NAT router should have a forwarding to the appropriate IP address since the outside doesn't know a thing about the inside networks.
That being said, to my knowledge, once the tunnel has been set up, there basically is a direct link between your client and the NordVPN endpoint through your double NAT. All traffic is being directed through the tunnel and the NAT routers keep track of where to sent the tunneled traffic. The ports you want to be reachable through the VPN are the ports in your NordLynx env variables (your torrent, raddarr, etc). No extra ports are necessary.

Now your routing table. Your end of the tunnel has an IP address of 10.5.0.2. The other end is in the example you provided, 91.196.220.38. The routing table states that 0.0.0.0/1 and 128.0.0.0/1 (both the lower half and upper half of all IPv4 addresses) are being sent to the wg0 interface (your NordVPN connection). That's why you don't see the 10.5.0.2 address in your routing table.

When comparing your compose with mine, I don't have the 10.0.0.0/8 as allowed_IPS. I'm not using that network in my home network. Also, I have net.ipv4.conf.all.src_valid_mark=1 . Try that.

[styggiti]

@ginodesilva Thanks for the thorough explanation RE double NAT and the IP routing. I'm only trying to use the VPN for outbound connections, so as you mentioned, it shouldn't be an issue.

I tried removing 10.0.0.0/8 as my internal network is in the 192 range, but it made no difference. Same for adding net.ipv4.conf.all.src_valid_mark=1 as well.

Unfortunately I'm out of ideas for where else to look/what to troubleshoot at this point.

[ginodesilva]

What can you ping and what can't you? Can you ping the nordlynx endpoint (probably a 'not permitted'). Can you ping the dns servers? Other dns servers such as 8.8.8.8. Can you curl ifconfig.me (or any other website) via IP address instead of fqdn?

I'm trying to figure out where the issues are. Is it connection related? Is it dns related?

Perhaps sharing the iptables is useful as well.

[styggiti]

@ginodesilva I can't seem to ping anything. Posting my current docker compose for starters:

version: "3"
services:
  nordlynx:
    image: ghcr.io/bubuntux/nordlynx
    container_name: nordlynx
    restart: unless-stopped
    security_opt:
      - no-new-privileges:true
    cap_add:
      - NET_ADMIN
    sysctls:
      - net.ipv6.conf.all.disable_ipv6=1  # Recommended if using ipv4 only
      - net.ipv4.conf.all.src_valid_mark=1
    environment:
      - PRIVATE_KEY=[myKey]
      - ALLOWED_IPS=0.0.0.0/1,128.0.0.0/1
      - NET_LOCAL=10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
      - DNS=103.86.96.100,103.86.99.100
      - TABLE=auto      
      - "POST_UP=ip -4 route add $$(wg | awk -F'[: ]' '/endpoint/ {print $$5}') via $$(ip route | awk '/default/ {print $$3}')"
      - "PRE_DOWN=ip -4 route del $$(route -n | awk '/255.255.255.255/ {print $$1}') via $$(ip route | awk '/default/ {print $$3}')"

And wg, route -n, and various pings:

root@c68b9d894915:/# wg
interface: wg0
  public key: x2Zki/m2ngPtWynfDKEd/tuLAk/g0pCkfiyVFJybOAs=
  private key: (hidden)
  listening port: 51820

peer: V1WC7wt34kcSDyqPuUhN56NJ0v+GlqY9TwZR5WlzzB4=
  endpoint: 139.28.216.243:51820
  allowed ips: 0.0.0.0/1, 128.0.0.0/1
  transfer: 0 B received, 592 B sent
  persistent keepalive: every 25 seconds
root@c68b9d894915:/# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         0.0.0.0         128.0.0.0       U     0      0        0 wg0
0.0.0.0         172.29.0.1      0.0.0.0         UG    0      0        0 eth0
10.0.0.0        172.29.0.1      255.0.0.0       UG    0      0        0 eth0
128.0.0.0       0.0.0.0         128.0.0.0       U     0      0        0 wg0
139.28.216.243  172.29.0.1      255.255.255.255 UGH   0      0        0 eth0
172.16.0.0      172.29.0.1      255.240.0.0     UG    0      0        0 eth0
172.29.0.0      0.0.0.0         255.255.0.0     U     0      0        0 eth0
192.168.0.0     172.29.0.1      255.255.0.0     UG    0      0        0 eth0
root@c68b9d894915:/# curl ifconfig.me
curl: (6) Could not resolve host: ifconfig.me
root@c68b9d894915:/# ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1): 56 data bytes
^C
--- 1.1.1.1 ping statistics ---
67 packets transmitted, 0 packets received, 100% packet loss
root@c68b9d894915:/# ping 34.117.59.81
PING 34.117.59.81 (34.117.59.81): 56 data bytes
^C
--- 34.117.59.81 ping statistics ---
64 packets transmitted, 0 packets received, 100% packet loss
root@c68b9d894915:/# ping 139.28.216.243
PING 139.28.216.243 (139.28.216.243): 56 data bytes
ping: sendto: Operation not permitted
root@c68b9d894915:/# ping 103.86.96.100
PING 103.86.96.100 (103.86.96.100): 56 data bytes
^C
--- 103.86.96.100 ping statistics ---
16 packets transmitted, 0 packets received, 100% packet loss

[egrofalnoraa]

Can anyone help me get my private key so I can implement this? I've been fighting this for days!

DS224+
DSM 7.2

sudo docker run --rm --cap-add=NET_ADMIN -e TOKEN='redacted' ghcr.io/bubuntux/nordvpn:get_private_key
Password:
Waiting for daemon to start up...
Whoops! /run/nordvpn/nordvpnd.sock not found.
Invalid token. ¯_(ツ)_/¯

[Hex-99]

I have a similar issue on a QNAP NAS, but with no changes it eventually works after stopping\restarting the container multiple times.
(Also needing to use 0.0.0.0/1,128.0.0.0/2) It seems there is a possible failure on the VPN connect that isn't trapped (similar to the invalid private key). Looks connected but actually isn't.

[b-kamphorst]

Hi @Hex-99, note that 0.0.0.0/1,128.0.0.0/2 skips a forth of all IPv4 addresses as discussed earlier in this discussion. The proposed config removes that limitation.

It is not entirely clear to me whether you just wanted to share your experience, or you currently experience issues that you'd like to receive help for. In case of the latter, make sure to try the proposed config, verify that the issue persists and get back to us with more details (logs, compose). Cheers!

[Hex-99]

I totally missed the change from 128.0.0.0/2 to 128.0.0.0/1. With the added POST-UP it appears to be working great.
It looks like QNAP NAS implementation is very similar to Synology.

[589290]

Does anyone have any idea how to properly escape these two env variables used with a docker run command?

docker run -d \
  -e POST_UP="ip -4 route add $$(wg | awk -F'[: ]' '/endpoint/ {print $$5}') via $$(ip route | awk '/default/ {print $$3}')" \
  -e PRE_DOWN="ip -4 route del $$(route -n | awk '/255.255.255.255/ {print $$1}') via $$(ip route | awk '/default/ {print $$3}')" \
  ghcr.io/bubuntux/nordlynx

^ above doesn't work and results in:

[#] ip -4 route add 75093(wg | awk -F'[: ]' '/endpoint/ {print 750935}') via 75093(ip route | awk '/default/ {print 750933}')
/usr/bin/wg-quick: eval: line 295: syntax error near unexpected token `('

Either does using an .env file formatted like

ALLOWED_IPS=0.0.0.0/1,128.0.0.0/1
POST_UP="ip -4 route add $$(wg | awk -F'[: ]' '/endpoint/ {print $$5}') via $$(ip route | awk '/default/ {print $$3}')"
PRE_DOWN="ip -4 route del $$(route -n | awk '/255.255.255.255/ {print $$1}') via $$(ip route | awk '/default/ {print $$3}')"

^ above results in:

[#] "ip -4 route add $$(wg | awk -F'[: ]' '/endpoint/ {print $$5}') via $$(ip route | awk '/default/ {print $$3}')"
/usr/bin/wg-quick: line 295: ip -4 route add 189(wg | awk -F'[: ]' '/endpoint/ {print 1895}') via 189(ip route | awk '/default/ {print 1893}'): No such file or directory

I've tried so many different ways to escape the POST_UP/DOWN strings with no success 😖

[bubuntux]

you could put them into script files, mount the path with the scripts and point to those in the POST_UP variable ,that way you don't have to worry about formatting/scaping,

[589290]

@bubuntux BRILLIANT IDEA! Finally have working wg on Synology! Cheers!

[appleimperio]

Hi my synology is connecting ok if I turn off the firewall if I turn it on this guy shows up "Unable to select a server ¯_(⊙︿⊙)_/¯" In the Synology firewall I add the port 51820 and in the docker compose I add the Listen_port 51820 but I can't get rid of that guy is there any other port I need to open in the firewall? here is my docker compose

version: '3.3'
services:
  nordlynx:
    image: ghcr.io/bubuntux/nordlynx
    container_name: nordlynx
    restart: unless-stopped
    security_opt:
      - no-new-privileges:true
    cap_add:
      - NET_ADMIN
    sysctls:
      - net.ipv6.conf.all.disable_ipv6=1  # Recommended if using ipv4 only
    environment:
      - PRIVATE_KEY=THEKEY=
      - ALLOWED_IPS=0.0.0.0/1,128.0.0.0/1
      - "POST_UP=ip -4 route add $$(wg | awk -F'[: ]' '/endpoint/ {print $$5}') via $$(ip route | awk '/default/ {print $$3}')"
      - "PRE_DOWN=ip -4 route del $$(route -n | awk '/255.255.255.255/ {print $$1}') via $$(ip route | awk '/default/ {print $$3}')" 

[Flashlab2]

Hi all,

I'm struggling to get the private key from NordVPN. The instructions to get it end up in a message that nordvpnd.sock is not found.

[wiston81]

Hi
I have a Ds220+ DSM 7.1.1-42962 Update 4, no firewall and Wireguard installed.
I have port-forwarded 51820 on my router (fritzbox 7530)

This is my conf:

version: '3.3'
services:
  nordvpn:
    container_name: nordlynx
    image: ghcr.io/bubuntux/nordlynx
    security_opt:
      - no-new-privileges:true
    cap_add:
      - NET_ADMIN #required
    ports:
      - 8089:8089 # QbitTorrent
    sysctls:
      - net.ipv6.conf.all.disable_ipv6=1 # Recommended if using ipv4 only
    environment:
      - PRIVATE_KEY=[MY_PRIVATE_KEY] #required
      - ALLOWED_IPS=0.0.0.0/1,128.0.0.0/1
      - NET_LOCAL=10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
      - "POST_UP=ip -4 route add $$(wg | awk -F'[: ]' '/endpoint/ {print $$5}') via $$(ip route | awk '/default/ {print $$3}')"
      - "PRE_DOWN=ip -4 route del $$(route -n | awk '/255.255.255.255/ {print $$1}') via $$(ip route | awk '/default/ {print $$3}')"
  qbittorrent:
    image: linuxserver/qbittorrent:latest
    network_mode: service:nordvpn
    container_name: qbittorrent-nordvpn
    depends_on:
      - nordvpn
    environment:
      - WEBUI_PORT=8089
      - PUID=1026
      - PGID=100
      - UMASK=002
      - TZ=Europe/Rome
    volumes:
      - /volume1/docker/appdata/qbittorrent-nordvpn:/config
      - /volume1/data/torrents:/data/torrents
    restart: unless-stopped

The logs say:

[2023-04-14T09:45:12+00:00] Connecting...
[#] 
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.5.0.2/32 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] resolvconf -a wg0 -m 0 -x
[#] ip -4 route add 128.0.0.0/1 dev wg0
[#] ip -4 route add 0.0.0.0/1 dev wg0
[#] ip -4 route add $(wg | awk -F'[: ]' '/endpoint/ {print $5}') via $(ip route | awk '/default/ {print $3}')
[2023-04-14T09:45:12+00:00] Connected! \(ᵔᵕᵔ)/

The nordlynx container status is unhealty.
If I try to ping to 8.8.8.8 the result is 100% loss

root@b183dc77f31f:/# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
^C
--- 8.8.8.8 ping statistics ---
8 packets transmitted, 0 packets received, 100% packet loss
root@b183dc77f31f:/# ^C

What am I doing wrong?

[jarlbrak]

Having the exact same issue...

[jarlbrak]

Getting the same as above... nothing but dropped packets...

root@a16bb058ec99:/# wg
interface: wg0
  public key: XXXX
  private key: (hidden)
  listening port: 51820

peer: 1GaNB9RbeGNzekcuRDcxTXvqtXWFe2K9GtUd+EjNuyI=
  endpoint: 212.102.47.35:51820
  allowed ips: 0.0.0.0/1, 128.0.0.0/1
  transfer: 0 B received, 1.59 KiB sent
  persistent keepalive: every 25 seconds
root@a16bb058ec99:/# ifconfig
eth0      Link encap:Ethernet  HWaddr XXXX
          inet addr:172.20.0.2  Bcast:172.20.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:502 errors:0 dropped:0 overruns:0 frame:0
          TX packets:510 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:351481 (343.2 KiB)  TX bytes:2576097 (2.4 MiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:657 errors:0 dropped:0 overruns:0 frame:0
          TX packets:657 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1 
          RX bytes:1646088 (1.5 MiB)  TX bytes:1646088 (1.5 MiB)

wg0       Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.5.0.2  P-t-P:10.5.0.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP  MTU:1420  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:24 errors:0 dropped:107 overruns:0 carrier:0
          collisions:0 txqueuelen:1 
          RX bytes:0 (0.0 B)  TX bytes:3552 (3.4 KiB)

version: '3.8'

services:
    vpn:
        container_name: vpn
        image: ghcr.io/bubuntux/nordlynx:2022-03-01
        restart: unless-stopped
        security_opt:
          - no-new-privileges:true
        cap_add:
          - NET_ADMIN
        sysctls:
          - net.ipv6.conf.all.disable_ipv6=1
          - net.ipv4.conf.all.src_valid_mark=1
        environment:
          - "PRIVATE_KEY=XXXXX"
          - ALLOWED_IPS=0.0.0.0/1,128.0.0.0/1
          - NET_LOCAL=192.168.0.0/16
          - "POST_UP=ip -4 route add $$(wg | awk -F'[: ]' '/endpoint/ {print $$5}') via $$(ip route | awk '/default/ {print $$3}')"
          - "PRE_DOWN=ip -4 route del $$(route -n | awk '/255.255.255.255/ {print $$1}') via $$(ip route | awk '/default/ {print $$3}')" 

[jarlbrak]

Eh, I'm done messing with it. Just switched to SurfShark and Glutun and it worked on the first run... Glad I switched.

[appleimperio]

Good to know other options. It works with the firewall on? if it is I'm going to make the jump too

[jarlbrak]

Unsure. I don't use the synology firewall.

[wiston81]

Eh, I'm done messing with it. Just switched to SurfShark and Glutun and it worked on the first run... Glad I switched.

Can you please paste your configuration file?

Thanks :)

[jarlbrak]

Eh, I'm done messing with it. Just switched to SurfShark and Glutun and it worked on the first run... Glad I switched.

Can you please paste your configuration file?

Thanks :)

version: '3.8'
services:
    vpn:
        container_name: vpn
        image: qmcgaw/gluetun
        cap_add:
            - NET_ADMIN
        environment:
            - VPN_SERVICE_PROVIDER=surfshark
            - VPN_TYPE=wireguard
            - WIREGUARD_PRIVATE_KEY=<your_wireguard_private_key>
            - WIREGUARD_ADDRESSES=10.14.0.2/16
            - SERVER_COUNTRIES=United States
        ports:
            - 9117:9117
            - 8989:8989
            - 7878:7878
            - 8112:8112
    deluge:
        container_name: deluge
        depends_on:
            - vpn
        network_mode: service:vpn
        environment:
            - PUID=1000
            - PGID=27
            - TZ=America/Los_Angeles
        volumes:
            - '/volume1/Downloads:/downloads'
            - '/volume1/docker/deluge/config:/config'
        image: 'linuxserver/deluge:latest'
    jackett:
        container_name: jackett
        depends_on:
            - vpn
        network_mode: service:vpn
        environment:
            - PUID=1000
            - PGID=27
            - TZ=America/Los_Angeles
        volumes:
            - '/volume1/docker/jackett/config:/config'
            - '/volume1/Downloads:/downloads'
        image: 'linuxserver/jackett:latest'
    sonarr:
        container_name: sonarr
        depends_on:
            - vpn
        network_mode: service:vpn
        environment:
            - PUID=1000
            - PGID=27
            - TZ=America/Los_Angeles
        volumes:
            - '/volume1/docker/sonarr/config:/config'
            - '/volume1/Media/TVShows:/tv'
            - '/volume1/Downloads:/downloads'
        image: 'linuxserver/sonarr:latest'
    radarr:
        container_name: radarr
        depends_on:
            - vpn
        network_mode: service:vpn
        environment:
            - TZ=America/Los_Angeles
            - PUID=1000
            - PGID=27
        volumes:
            - '/volume1/docker/radarr/config:/config'
            - '/volume1/Downloads:/downloads'
            - '/volume1/Media/Movies:/movies'
        image: 'linuxserver/radarr:latest'