Docker-transmission-openvpn: RTNETLINK answers: File exists

Created on 8 Aug 2018  路  28Comments  路  Source: haugene/docker-transmission-openvpn

Hello -

Tried posting this on the already closed ticket with what seems to be the same issue but I guess that doesnt re open the ticket as its still showing as closed so I am submitting a new one.

Old ticket - https://github.com/haugene/docker-transmission-openvpn/issues/135

Docker is installed on an old PC running Ubuntu 18.04 as the underlying OS. PureVPN is used as the configuration

I get the following error -

vpn_1  | STARTING TRANSMISSION
vpn_1  | NO PORT UPDATER FOR THIS PROVIDER
vpn_1  | Transmission startup script complete.
vpn_1  | RTNETLINK answers: File exists
vpn_1  | Tue Aug  7 12:11:17 2018 ERROR: Linux route add command failed: external program exited with error status: 2
vpn_1  | Tue Aug  7 12:11:17 2018 Initialization Sequence Completed

Most helpful comment

Agreed, @nicomarti83 I got more server locations from them, including address for new server in Germany. I'm planning to update some config files this week.

@haugene Would it be okay to update current PureVPN config files and delete those that doesn't have a new server yet?

All 28 comments

Anyone?.....

Hey. I haven't seen this before, but I'm going to set up an old machine with Ubuntu 18.04 one of these days. Then I can try to fire up the container and see if I can reproduce it.

Not sure when though. Hopefully I'll get som play time on Sunday.

Have you installed openvpn on the host? You don't need to configure or start it. This sets up the tun device. There are other ways to do it, but it's the simplest I think.

So. Just did a fresh install of ubuntu server on an old laptop and started the container without installing anything but Docker.

Running uname -r gives kernel version: 4.15.0-30-generic
Running docker -v: Docker version 18.06.0-ce, build 0ffa825

This is my docker run command:

docker run --cap-add=NET_ADMIN --device=/dev/net/tun -d \
        -v /home/myuser/Downloads/Torrents/:/data \
        -v /etc/localtime:/etc/localtime:ro \
        -e OPENVPN_PROVIDER=PIA \
        -e OPENVPN_CONFIG=CA\ Toronto \
        -e OPENVPN_USERNAME=username \
        -e OPENVPN_PASSWORD=password \
        -e WEBPROXY_ENABLED=false \
        -e LOCAL_NETWORK=192.168.0.0/16 \
        --log-driver json-file \
        --log-opt max-size=10m \
        -p 9091:9091 \
        haugene/transmission-openvpn

This might not help a lot, but couldn't reproduce your error...

So this seems to be provider specific. And you've probably already seen this, and it makes sense of course that it has to do with the route configurations in the PureVPN configs: https://askubuntu.com/questions/920486/openvpn-config-client-ovpn-fail-rtnetlink-answers-file-exists

Have there been any updates to the PureVPN configs that haven't been updated here yet. Can you download the current configs and compare to the ones in this project? If they're still up to date you should compare the PureVPN configs to configs from other providers.

This line seems suspicious: https://github.com/haugene/docker-transmission-openvpn/blob/master/openvpn/purevpn/Chicago-udp.ovpn#L15
At least the PIA configs don't have a line like that.

The PureVPN configs are available here: https://support.purevpn.com/openvpn-files

Differences:
File paths obviously.
.ovpn from PureVPN site has a trailing space and newline after final entry auth-nocache.

I can send you a PM or email with my PureVPN credentials if it will help you fully test. It's my understanding that without a un/pw, it won't get to the part that's failing.

Ok - I realised why I wasnt able to ping out from the docker container.

I had mapped a port to 8.8.8.8 as well as specifying 8.8.8.8 in my DNS ooops! Changed that and I can now ping out and the VPN shows my IP address to be in switzerland as per the VPN config added.

I ran a DNS leak test and it brings back google DNS servers in switzerland and says my DNS could be leaking.

I am however still seeing the following line after the VPN comes up

vpn_1  | STARTING TRANSMISSION
vpn_1  | NO PORT UPDATER FOR THIS PROVIDER
vpn_1  | Transmission startup script complete.
vpn_1  | RTNETLINK answers: File exists
vpn_1  | Tue Aug 14 11:32:59 2018 ERROR: Linux route add command failed: external program exited with error status: 2
vpn_1  | Tue Aug 14 11:32:59 2018 Initialization Sequence Completed

@bobsupercow If you could PM me some credentials that would be great. Then I can test it and try to figure out what is happening. You can send me a message on Gitter for example? https://gitter.im/docker-transmission-openvpn

PM sent in Gitter chat.

Ok. So I don't have all the answers yet, but here are some findings so far.
I've tried three different cases, and all the configs and logs plus iptables routes are pasted below.

Case 1:
Standard setup, original image, using LOCAL_NETWORK variable to try to make Transmission accessible on my local LAN.

Case 2:
Ditching the LOCAL_NETWORK variable

Case 3:
Same setup as case 2, but I removed the three route commands in the ovpn file.
For reference, the three consecutive lines starting with this one

Result:
In the first case we see two RTNETLINK errors. In the beginning RTNETLINK answers: Invalid argument and then at the end RTNETLINK answers: File exists. Transmission is not available on host:9091, the request just hangs. This is typical behaviour when the local network route is not added, also described in the README. As I also fired up the proxy container I tested connecting through that instead, and it works. So Transmission is running and using http://ipmagnet.services.cbcdn.com/ I could verify that the traffic was routed through the VPN.

But anyways, I figured that the first RTNETLINK error could be the LOCAL_NETWORK route. So I removed that from the config.

In the second case, without the local network settings, as expected the first error is gone.

In the third case, where I also removed the route options from the .ovpn file, the second error is also gone.

In all three cases Transmission is running and the IP check says that the traffic is routed through VPN. The route stuff probably need more investigation to know what's needed and why PureVPN is different from others when it comes to the LOCAL_NETWORK variable and have the route options in their configs.

Later I'll try to compare with PIA that I'm using, but this is as far as I came today. Maybe someone can do some more digging as well?

Config for Case 1:

docker-compose.yml:

version: '3'
services:
  transmission:
    image: haugene/transmission-openvpn
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun
    ports:
      - "9091:9091"
    dns:
      - 8.8.8.8
      - 8.8.4.4
    volumes:
      - /home/kristian/TorrentTest/:/data
    environment:
      - OPENVPN_PROVIDER=PUREVPN
      - OPENVPN_CONFIG=Norway-udp
      - OPENVPN_USERNAME=username
      - OPENVPN_PASSWORD=password
      - OPENVPN_OPTS=--inactive 3600 --ping 10 --ping-exit 60
      - LOCAL_NETWORK=192.168.10.0/16

  proxy:
    image: haugene/transmission-openvpn-proxy
    links:
      - transmission
    ports:
      - 8080:8080

Logs:

Using OpenVPN provider: PUREVPN
Starting OpenVPN using config Norway-udp.ovpn
Setting OPENVPN credentials...
adding route to local network 192.168.10.0/16 via 172.18.0.1 dev eth0
RTNETLINK answers: Invalid argument
Wed Aug 15 21:53:14 2018 WARNING: file '/etc/openvpn/purevpn/Wdc.key' is group or others accessible
Wed Aug 15 21:53:14 2018 OpenVPN 2.4.6 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 24 2018
Wed Aug 15 21:53:14 2018 library versions: OpenSSL 1.0.2g  1 Mar 2016, LZO 2.08
Wed Aug 15 21:53:14 2018 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Wed Aug 15 21:53:14 2018 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Wed Aug 15 21:53:14 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]172.94.70.2:53
Wed Aug 15 21:53:14 2018 UDP link local (bound): [AF_INET][undef]:1194
Wed Aug 15 21:53:14 2018 UDP link remote: [AF_INET]172.94.70.2:53
Wed Aug 15 21:53:14 2018 [PureVPN] Peer Connection Initiated with [AF_INET]172.94.70.2:53
Wed Aug 15 21:53:16 2018 TUN/TAP device tun0 opened
Wed Aug 15 21:53:16 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Wed Aug 15 21:53:16 2018 /sbin/ip link set dev tun0 up mtu 1500
Wed Aug 15 21:53:16 2018 /sbin/ip addr add dev tun0 172.94.70.194/26 broadcast 172.94.70.255
Wed Aug 15 21:53:16 2018 /etc/openvpn/tunnelUp.sh tun0 1500 1558 172.94.70.194 255.255.255.192 init
Up script executed with tun0 1500 1558 172.94.70.194 255.255.255.192 init
Updating TRANSMISSION_BIND_ADDRESS_IPV4 to the ip of tun0 : 172.94.70.194
Generating transmission settings.json from env variables
sed'ing True to true

-------------------------------------
Transmission will run as
-------------------------------------
User name:   root
User uid:    0
User gid:    0
-------------------------------------

STARTING TRANSMISSION
NO PORT UPDATER FOR THIS PROVIDER
Transmission startup script complete.
RTNETLINK answers: File exists
Wed Aug 15 21:53:18 2018 ERROR: Linux route add command failed: external program exited with error status: 2
Wed Aug 15 21:53:18 2018 Initialization Sequence Completed

Output from ip r:

0.0.0.0/1 via 172.94.70.193 dev tun0
default via 172.18.0.1 dev eth0
128.0.0.0/1 via 172.94.70.193 dev tun0
172.18.0.0/16 dev eth0  proto kernel  scope link  src 172.18.0.2
172.94.70.2 via 172.18.0.1 dev eth0
172.94.70.192/26 dev tun0  proto kernel  scope link  src 172.94.70.194

Case 2:

docker-compose.yml:
Same as for Case 1, but without LOCAL_NETWORK line

Logs:

Using OpenVPN provider: PUREVPN
Starting OpenVPN using config Norway-udp.ovpn
Setting OPENVPN credentials...
Wed Aug 15 21:56:12 2018 WARNING: file '/etc/openvpn/purevpn/Wdc.key' is group or others accessible
Wed Aug 15 21:56:12 2018 OpenVPN 2.4.6 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 24 2018
Wed Aug 15 21:56:12 2018 library versions: OpenSSL 1.0.2g  1 Mar 2016, LZO 2.08
Wed Aug 15 21:56:12 2018 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Wed Aug 15 21:56:12 2018 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Wed Aug 15 21:56:12 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]172.94.70.2:53
Wed Aug 15 21:56:12 2018 UDP link local (bound): [AF_INET][undef]:1194
Wed Aug 15 21:56:12 2018 UDP link remote: [AF_INET]172.94.70.2:53
Wed Aug 15 21:56:13 2018 [PureVPN] Peer Connection Initiated with [AF_INET]172.94.70.2:53
Wed Aug 15 21:56:14 2018 TUN/TAP device tun0 opened
Wed Aug 15 21:56:14 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Wed Aug 15 21:56:14 2018 /sbin/ip link set dev tun0 up mtu 1500
Wed Aug 15 21:56:14 2018 /sbin/ip addr add dev tun0 172.94.70.194/26 broadcast 172.94.70.255
Wed Aug 15 21:56:14 2018 /etc/openvpn/tunnelUp.sh tun0 1500 1558 172.94.70.194 255.255.255.192 init
Up script executed with tun0 1500 1558 172.94.70.194 255.255.255.192 init
Updating TRANSMISSION_BIND_ADDRESS_IPV4 to the ip of tun0 : 172.94.70.194
Generating transmission settings.json from env variables
sed'ing True to true

-------------------------------------
Transmission will run as
-------------------------------------
User name:   root
User uid:    0
User gid:    0
-------------------------------------

STARTING TRANSMISSION
NO PORT UPDATER FOR THIS PROVIDER
Transmission startup script complete.
RTNETLINK answers: File exists
Wed Aug 15 21:56:16 2018 ERROR: Linux route add command failed: external program exited with error status: 2
Wed Aug 15 21:56:16 2018 Initialization Sequence Completed

Output from ip r:

0.0.0.0/1 via 172.94.70.193 dev tun0
default via 172.18.0.1 dev eth0
128.0.0.0/1 via 172.94.70.193 dev tun0
172.18.0.0/16 dev eth0  proto kernel  scope link  src 172.18.0.2
172.94.70.2 via 172.18.0.1 dev eth0
172.94.70.192/26 dev tun0  proto kernel  scope link  src 172.94.70.194

Config for Case 3:

docker-compose.yml:
Same as for Case 2. Note that the image is changed as described.

Logs:

Using OpenVPN provider: PUREVPN
Starting OpenVPN using config Norway-udp.ovpn
Setting OPENVPN credentials...
Wed Aug 15 22:04:14 2018 WARNING: file '/etc/openvpn/purevpn/Wdc.key' is group or others accessible
Wed Aug 15 22:04:14 2018 OpenVPN 2.4.6 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 24 2018
Wed Aug 15 22:04:14 2018 library versions: OpenSSL 1.0.2g  1 Mar 2016, LZO 2.08
Wed Aug 15 22:04:14 2018 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Wed Aug 15 22:04:14 2018 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Wed Aug 15 22:04:15 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]217.170.199.2:53
Wed Aug 15 22:04:15 2018 UDP link local (bound): [AF_INET][undef]:1194
Wed Aug 15 22:04:15 2018 UDP link remote: [AF_INET]217.170.199.2:53
Wed Aug 15 22:04:16 2018 [PureVPN] Peer Connection Initiated with [AF_INET]217.170.199.2:53
Wed Aug 15 22:04:17 2018 TUN/TAP device tun0 opened
Wed Aug 15 22:04:17 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Wed Aug 15 22:04:17 2018 /sbin/ip link set dev tun0 up mtu 1500
Wed Aug 15 22:04:17 2018 /sbin/ip addr add dev tun0 217.170.199.98/27 broadcast 217.170.199.127
Wed Aug 15 22:04:17 2018 /etc/openvpn/tunnelUp.sh tun0 1500 1558 217.170.199.98 255.255.255.224 init
Up script executed with tun0 1500 1558 217.170.199.98 255.255.255.224 init
Updating TRANSMISSION_BIND_ADDRESS_IPV4 to the ip of tun0 : 217.170.199.98
Generating transmission settings.json from env variables
sed'ing True to true

-------------------------------------
Transmission will run as
-------------------------------------
User name:   root
User uid:    0
User gid:    0
-------------------------------------

STARTING TRANSMISSION
NO PORT UPDATER FOR THIS PROVIDER
Transmission startup script complete.
Wed Aug 15 22:04:17 2018 Initialization Sequence Completed

Output from ip r:

0.0.0.0/1 via 217.170.199.97 dev tun0
default via 172.18.0.1 dev eth0
128.0.0.0/1 via 217.170.199.97 dev tun0
172.18.0.0/16 dev eth0  proto kernel  scope link  src 172.18.0.2
217.170.199.2 via 172.18.0.1 dev eth0
217.170.199.96/27 dev tun0  proto kernel  scope link  src 217.170.199.98

I got my container working with LOCAL_NETWORK after removing those three route commands from my Norway-tcp.ovpn, changing 4th line to remote vleu-no2-ovpn-tcp.pointtoserver.com 80 and replacing contents of ca.crt with

-----BEGIN CERTIFICATE-----
MIIE6DCCA9CgAwIBAgIJAMjXFoeo5uSlMA0GCSqGSIb3DQEBCwUAMIGoMQswCQYD
VQQGEwJISzEQMA4GA1UECBMHQ2VudHJhbDELMAkGA1UEBxMCSEsxGDAWBgNVBAoT
D1NlY3VyZS1TZXJ2ZXJDQTELMAkGA1UECxMCSVQxGDAWBgNVBAMTD1NlY3VyZS1T
ZXJ2ZXJDQTEYMBYGA1UEKRMPU2VjdXJlLVNlcnZlckNBMR8wHQYJKoZIhvcNAQkB
FhBtYWlsQGhvc3QuZG9tYWluMB4XDTE2MDExNTE1MzQwOVoXDTI2MDExMjE1MzQw
OVowgagxCzAJBgNVBAYTAkhLMRAwDgYDVQQIEwdDZW50cmFsMQswCQYDVQQHEwJI
SzEYMBYGA1UEChMPU2VjdXJlLVNlcnZlckNBMQswCQYDVQQLEwJJVDEYMBYGA1UE
AxMPU2VjdXJlLVNlcnZlckNBMRgwFgYDVQQpEw9TZWN1cmUtU2VydmVyQ0ExHzAd
BgkqhkiG9w0BCQEWEG1haWxAaG9zdC5kb21haW4wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDluufhyLlyvXzPUL16kAWAdivl1roQv3QHbuRshyKacf/1
Er1JqEbtW3Mx9Fvr/u27qU2W8lQI6DaJhU2BfijPe/KHkib55mvHzIVvoexxya26
nk79F2c+d9PnuuMdThWQO3El5a/i2AASnM7T7piIBT2WRZW2i8RbfJaTT7G7LP7O
pMKIV1qyBg/cWoO7cIWQW4jmzqrNryIkF0AzStLN1DxvnQZwgXBGv0CwuAkfQuNS
Lu0PQgPp0PhdukNZFllv5D29IhPr0Z+kwPtrAgPQo+lHlOBHBMUpDT4XChTPeAvM
aUSBsqmonAE8UUHEabWrqYN/kWNHCNkYXMkiVmK1AgMBAAGjggERMIIBDTAdBgNV
HQ4EFgQU456ijsFrYnzHBShLAPpOUqQ+Z2cwgd0GA1UdIwSB1TCB0oAU456ijsFr
YnzHBShLAPpOUqQ+Z2ehga6kgaswgagxCzAJBgNVBAYTAkhLMRAwDgYDVQQIEwdD
ZW50cmFsMQswCQYDVQQHEwJISzEYMBYGA1UEChMPU2VjdXJlLVNlcnZlckNBMQsw
CQYDVQQLEwJJVDEYMBYGA1UEAxMPU2VjdXJlLVNlcnZlckNBMRgwFgYDVQQpEw9T
ZWN1cmUtU2VydmVyQ0ExHzAdBgkqhkiG9w0BCQEWEG1haWxAaG9zdC5kb21haW6C
CQDI1xaHqObkpTAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IBAQCvga2H
MwOtUxWH/inL2qk24KX2pxLg939JNhqoyNrUpbDHag5xPQYXUmUpKrNJZ0z+o/Zn
NUPHydTSXE7Z7E45J0GDN5E7g4pakndKnDLSjp03NgGsCGW+cXnz6UBPM5FStFvG
dDeModeSUyoS9fjk+mYROvmiy5EiVDP91sKGcPLR7Ym0M7zl2aaqV7bb98HmMoBO
xpeZQinof67nKrCsgz/xjktWFgcmPl4/PQSsmqQD0fTtWxGuRX+FzwvF2OCMCAJg
p1RqJNlk2g50/kBIoJVPPCfjDFeDU5zGaWGSQ9+z1L6/z7VXdjUiHL0ouOcHwbiS
4ZjTr9nMn6WdAHU2
-----END CERTIFICATE-----

According to http://ipmagnet.services.cbcdn.com, my traffic is routed through PureVPN and atleast Transmission Remote GUI is working correctly.

And no RTNETLINK answers: File exists error!

So for me it works now like it used to!

I hope this information is helpful for you @haugene :)

That's great @Othou, and thanks for sharing. But if you're changing host address and certificate, does that mean there are updated config files for PureVPN? Thought @bobsupercow checked that earlier in this thread...

I haven't found any config files yet with that host address, i got that address and certificate from PureVPN's support team today. For example if i download linux configs from here, 4th line in Norway-tcp.ovpn is remote vleu-no1-ovpn-tcp.pointtoserver.com 80 and i got this vleu-no2-ovpn-tcp.pointtoserver.com address from PureVPN support along with the certificate that just works fine. If i understood correctly, that is an address for a new server.

I got total 14 new addresses to different locations for both TCP and UDP:

United Kingdom | ukl2-ovpn-tcp.pointtoserver.com | ukl2-ovpn-udp.pointtoserver.com
Netherland | nl2-ovpn-tcp.pointtoserver.com | nl2-ovpn-udp.pointtoserver.com
United States | us2.ovpn-tcp.pointtoserver.com | us2.ovpn-udp.pointtoserver.com
Sweden | se2-ovpn-tcp.pointtoserver.com | se2-ovpn-udp.pointtoserver.com
Canada | ca2-ovpn-tcp.pointtoserver.com | ca2-ovpn-udp.pointtoserver.com
Germany | de2-ovpn-tcp.pointtoserver.com | de2-ovpn-udp.pointtoserver.com
Australia | au2-ovpn-tcp.pointtoserver.com | au2-ovpn-udp.pointtoserver.com
Belgium | vleu-be2-ovpn-tcp.pointtoserver.com | vleu-be2-ovpn-udp.pointtoserver.com
France | fr2-ovpn-tcp.pointtoserver.com | fr2-ovpn-udp.pointtoserver.com
Italy | it2-ovpn-tcp.pointtoserver.com | it2-ovpn-udp.pointtoserver.com
Norway | vleu-no2-ovpn-tcp.pointtoserver.com | vleu-no2-ovpn-udp.pointtoserver.com
Panama | vlus-pa2-ovpn-tcp.pointtoserver.com | vlus-pa2-ovpn-udp.pointtoserver.com
Taiwan | tw2-ovpn-tcp.pointtoserver.com | tw2-ovpn-udp.pointtoserver.com

Sweet. If the new servers work better we should consider adding them. Also more folks should test dropping the route lines. If that works better then we could do a bulk update of the existing configs.

So yeah, as you can see i made couple commits for easier testing. It's my first time doing pull request in Github so i hope i did everything correctly :) So with that change in OPENVPN_CONFIG you can (if/when my commits gets pulled) type Norway2-tcp or Norway2-udp that has the new address and uses the new certificate aswell.

I only added Norway since i don't know is this the right solution. I can add more locations if you guys find this as working solution.

Thank you @Othou. Had a full day yesterday so didn't get to this before now, but the changes looks good and I've merged them to the dev branch so they should be available on the dev tag shortly.

Hopefully more people from this thread can verify that this fixes the problem and we can add the other new profiles as well :)

Tested this today, I can also confirm that using The norway .ovpn file with the new server address and updating the .crt file works for me. Removing the 3 route lines in the .ovpn file also removes the RTNETLINK error as well.

Thanks @Othou !

Just build an image from the dev branch and switched to Norway2 profile. Can confirm it works.

Thanks guys!

This vpn provider is really messy... it would be really cool that they maintain the linux config archive up to date instead of giving informations pieces by pieces throug the support team... by the way I was looking to the conf files of purevpn in the source and I didn't find the germany one, why ?

Agreed, @nicomarti83 I got more server locations from them, including address for new server in Germany. I'm planning to update some config files this week.

@haugene Would it be okay to update current PureVPN config files and delete those that doesn't have a new server yet?

Hey @Othou. I would say that's an improvement to the current situation, so let's clean it up. The list of servers isn't that big, but at least there will be a good choice of working connections instead of the mess @nicomarti83 describes.

Would be great if you'd use a git client to make it all in one commit. Just delete it all and replace it with the new servers. If you're not that familiar with git - the web ui way is also ok :)

Thanks again for helping out!

So the container was running fine until this morning, now I've got error "could not connect to tracker" on all my torrents. I tried to use ipmagnet but I had no return (I guess this is not a tracker problem but a container or vpn server problem). The weird think is I don't have errors on my container logs...

@nicomarti83 I had that aswell couple days ago, but after restarting my container the error was gone and didn't get it anymore. I guess something was up with PureVPN servers, do you still have that issue?

Also i added some server configs to dev branch and removed the old ones. I will add more servers later.

Following this thread closely since I found it. Facing exactly the same issues with PureVPN on my Asustor NAS with docker. Am testing the dev branch and all works well with the Norway2-udp config. Have commented on your latest commits about an error in the one for Netherlands-udp.

FYI I did add --float to the OPENVPN_OPTS to get rid of the 'TCP/UDP: Incoming packet rejected from [AF_INET]xxxx' errors.

@Othou yesterday I had the error again. The impossibility to connect torrents to tracker and no error in docker's logs. I tried to ssh into the container and ping google.com but it fail. I restarted the container for less than 1 day and for now everything work fine. I'll keep you in touch.

@nicomarti83 I'm actually having same problems here. But i found out that my modem reboots after starting this container up. And seems like this container is not able to reconnect to vpn after host reconnecting.
Maybe check your router/modem uptime to see does it match with the container disconnecting? It would make my troubleshooting way easier to know does this happen to anybody else.

@Othou it not seem to be the problem in my side, my box is synchronized since twelve days...

Have been testing with the Norway config for a month and it's working great. Can we push these changes to the public branch so all the configs will be available?

Cleaning up open issues. Closing this since #589 was merged.
If anyone still have problems I would suggest opening a new issue and linking here, as this is very long and a new issue could be more specific ;)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

callahan22 picture callahan22  路  4Comments

PriamX picture PriamX  路  3Comments

stefanahman picture stefanahman  路  4Comments

coulterj picture coulterj  路  4Comments

SuperJakish picture SuperJakish  路  4Comments