[Support] binhex - rTorrentVPN


Recommended Posts

I'm not concerned with my local IP and Routing, but about what could be exposed through the VPN.

 

 

1 hour ago, c0nfuzed said:

 

A few things to consider before you start to worry.

1. This container is not exposed to the internet directly... it uses a VPN.  When connected, it's public IP is not the IP of your machine, but the shared public IP of your VPN server.. often used by hundreds of others. (whole point of VPN for anonymity with torrenting)  So an attacker cannot target your rtorrent server directly.

2. Because your running rtorrent behind a shared IP address, the ONLY way to allow an incoming connection is with a port forward, and in most cases, the only port you would forward would be the rtorrent "listening port", if any, and only if your VPN provider even allows it.

3. When you start the container, you specify ports mappings... there is little reason to create a port mapping for the RPC port 5000 unless you are planning on running rutorrent or other XML-RPC management tools outside the container.  Because rutorrent is included inside, this is very unlikely.

 

That said, even if network.scgi.open_port is set, you are safe using this unless you made some very intentional implementation decisions to expose RPC to the world ( for example added a port mapping for port 5000 in docker and at your VPN provider).

 

Link to comment
5 hours ago, fatalfurry said:

I'm not concerned with my local IP and Routing, but about what could be exposed through the VPN.

 

I understand, and that is what I was addressing. 

 

Now if you have a dedicated routable IP address from your VPN provider, then you might have reason to be concerned.  If your VPN provider was poorly implemented and allowed direct traffic between VPN customers, then you might have reason to be concerned.  But those situations are exceedingly rare.

 

Under normal circumstances, even if there is zero security baked into this image, and even if you made horrible configuration decisions... the fact that your behind NAT at the VPN provider will prevent anyone from leveraging this exploit.  While NAT isn't as secure as a properly configured firewall, its damn effective at preventing exploits like this one.

 

That said... here are the firewall rules inside the container on my system, 192.168.15.0/24 is my "LAN_NETWORK" in my startup command, it does appear to accept all incoming connections from the tun0 (VPN) interface... which is not ideal. (I may be reading this wrong, and I'm not sure how iptables and openVPN work together... perhaps the openvpn connection adds its own set of rules and this is normal).

-P INPUT DROP
-P FORWARD ACCEPT
-P OUTPUT DROP
-A INPUT -i tun0 -j ACCEPT
-A INPUT -s 172.18.0.0/16 -d 172.18.0.0/16 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --sport 1195 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 9080 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --sport 9080 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 9443 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --sport 9443 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 3000 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --sport 3000 -j ACCEPT
-A INPUT -s 192.168.15.0/24 -i eth0 -p tcp -m tcp --dport 5000 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A OUTPUT -o tun0 -j ACCEPT
-A OUTPUT -s 172.18.0.0/16 -d 172.18.0.0/16 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --dport 1195 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --dport 9080 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 9080 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --dport 9443 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 9443 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --dport 3000 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 3000 -j ACCEPT
-A OUTPUT -d 192.168.15.0/24 -o eth0 -p tcp -m tcp --sport 5000 -j ACCEPT
-A OUTPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT


 

Link to comment

I'm having problems with binhex-rtorrentvpn. It won't save stuff i do in settings in rutorrent most of the time but not all the time.

 

Also i have a problem with port 6881. i want to change it to something else but i don't know where to change stuff like that i don't use DHT if that helps.

 

when i restart the docker the settings goes back to what they wore so my changes are gone.

 

Also why is my appdata\binhex-rtorrentvpn\access.log getting so big (about 2-3 days and 30mb)

Edited by DigitalLF
Link to comment
1 hour ago, DigitalLF said:

I'm having problems with binhex-rtorrentvpn. It won't save stuff i do in settings in rutorrent most of the time but not all the time.

 

Also i have a problem with port 6881. i want to change it to something else but i don't know where to change stuff like that i don't use DHT if that helps.

 

when i restart the docker the settings goes back to what they wore so my changes are gone.

 

Also why is my appdata\binhex-rtorrentvpn\access.log getting so big (about 2-3 days and 30mb)

 

IIRC settings saved in the ruTorrent GUI don't persist if you restart the container. You need to edit the rtorrent config file directly, which lives in the binhex-rtorrentvpn appdata folder (appdata/binhex-rtorrentvpn/rtorrent/config/rtorrent.rc). Here's an example of what this file will look like: https://github.com/rakshasa/rtorrent/blob/master/doc/rtorrent.rc

 

Do this with the Docker container turned off, then restart it after saving your changes. You can disable DHT and change the default port(s) within this config file.

  • Like 1
Link to comment

I just found a bug, it only appears to have started recently so I suspect something changed at my VPN provider.

 

The script that detects my public IP fails about 90% of the time because ... 

# from /root/getvpnextip.sh
$(dig -b ${vpn_ip} TXT +short o-o.myaddr.l.google.com @${pri_ns} 2> /dev/null | tr -d '"')

returns a IPv6 address rather than IPv4 as expected by the script.

 

Additionally, and I'm not sure why, but when it does return an IPV4 address it is always different than what I get from 

curl ipinfo.io/ip

by exactly 1... so if google's dns is reporting my IP is 1.1.1.1 then ipinfo.io/ip is reporting that it's 1.1.1.2... I don't fully understand why they would be different, but I fear that googles dns is wrong... might explain why I am not seeding as well as I would like.

Edited by c0nfuzed
Link to comment
11 hours ago, DigitalLF said:

eally bad that the settings won't be saved when all the confs are on my cache drive and not inside the container

 

they are saved, if you modify the right configuration file, see here for more details rtorrentvpn faq q1:-

 

 

 

Link to comment
8 hours ago, c0nfuzed said:

I just found a bug, it only appears to have started recently so I suspect something changed at my VPN provider.

 

The script that detects my public IP fails about 90% of the time because ... 


# from /root/getvpnextip.sh
$(dig -b ${vpn_ip} TXT +short o-o.myaddr.l.google.com @${pri_ns} 2> /dev/null | tr -d '"')

returns a IPv6 address rather than IPv4 as expected by the script.

 

Additionally, and I'm not sure why, but when it does return an IPV4 address it is always different than what I get from 


curl ipinfo.io/ip

by exactly 1... so if google's dns is reporting my IP is 1.1.1.1 then ipinfo.io/ip is reporting that it's 1.1.1.2... I don't fully understand why they would be different, but I fear that googles dns is wrong... might explain why I am not seeding as well as I would like.

 

please follow the below procedure:-

 

 

Link to comment

Ok... got a successful and failed log file for you, and here is an example of why I suspect it's failing on the second one:

[root@84f63622d18b /]# dig -b 10.9.0.3 TXT +short o-o.myaddr.l.google.com @ns1.google.com
"2606:6080:1001:5::1d"

On a subsequent boot I grabbed this... it just doesn't make sense how inconsistent it is (these are about 1 second apart):

[root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com
"2606:6080:1001:5::1d"
[root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com
"2606:6080:1001:5::1d"
[root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com
"2606:6080:1001:5::1d"
[root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com
"2606:6080:1001:5::1d"
[root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com
"2606:6080:1001:5::1d"
[root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com
"2606:6080:1001:5::1d"
[root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com
"2606:6080:1001:5::1d"
[root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com
"2606:6080:1001:5::1d"
[root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com
"184.75.214.130"
[root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com
"184.75.214.130"
[root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com
"184.75.214.130"
[root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com
"184.75.214.130"
[root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com
"184.75.214.130"
[root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com
"184.75.214.130"

And notice, even when it does work... I'm not sure I'm getting the right address its always one bit smaller than what ipinfo.io reports:

[root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com
"184.75.214.130"
[root@84f63622d18b /]# curl ipinfo.io/ip
184.75.214.131

The most obvious indication when it fails to get my public IP is that the address in "IP/Hostname to report to tracker" in ruTorrent is listed as my internal vpn IP (10.x.x.x) rather than an internet routable address.  Needless to say, this will prevent seeding and may even violate some private tracker rules.

 

supervisord.log

supervisord.log.worked

Link to comment
52 minutes ago, Tatux said:

Hi Guys, 

 

I really don't know what i'm doing wring here.

 

This is the current log file.

 

The VPN is failing to connect, i'm using the 'Custom' provider. I've placed the ovpn files and cert stuff in the correct path.

tempings.txt

 

this is your issue:-

04T18:26:03.229458479Z Sun Mar  4 18:26:03 2018 neither stdin nor stderr are a tty device and you have neither a controlling tty nor systemd - can't ask for 'Enter Private Key Password:'.

 

in short you need to remove the password you have put on the private key, as you cannot input the password to get passed the prompt.

Link to comment
5 minutes ago, Tatux said:

Thank you for the very quick reply, the file we're generated by the vpn provider, i'm not sure how to actually do that.

 

i cant help you with that, each vpn provider is different, support ticket to them to see how you generate a private key that isnt password protected perhaps?

Link to comment
2 hours ago, c0nfuzed said:

Ok... got a successful and failed log file for you, and here is an example of why I suspect it's failing on the second one:


[root@84f63622d18b /]# dig -b 10.9.0.3 TXT +short o-o.myaddr.l.google.com @ns1.google.com
"2606:6080:1001:5::1d"

On a subsequent boot I grabbed this... it just doesn't make sense how inconsistent it is (these are about 1 second apart):


[root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com
"2606:6080:1001:5::1d"
[root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com
"2606:6080:1001:5::1d"
[root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com
"2606:6080:1001:5::1d"
[root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com
"2606:6080:1001:5::1d"
[root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com
"2606:6080:1001:5::1d"
[root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com
"2606:6080:1001:5::1d"
[root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com
"2606:6080:1001:5::1d"
[root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com
"2606:6080:1001:5::1d"
[root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com
"184.75.214.130"
[root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com
"184.75.214.130"
[root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com
"184.75.214.130"
[root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com
"184.75.214.130"
[root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com
"184.75.214.130"
[root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com
"184.75.214.130"

And notice, even when it does work... I'm not sure I'm getting the right address its always one bit smaller than what ipinfo.io reports:


[root@84f63622d18b /]# dig -b 10.9.0.4 TXT +short o-o.myaddr.l.google.com
"184.75.214.130"
[root@84f63622d18b /]# curl ipinfo.io/ip
184.75.214.131

The most obvious indication when it fails to get my public IP is that the address in "IP/Hostname to report to tracker" in ruTorrent is listed as my internal vpn IP (10.x.x.x) rather than an internet routable address.  Needless to say, this will prevent seeding and may even violate some private tracker rules.

 

supervisord.log

supervisord.log.worked

 

ok some/all of your issues are related to the name server you are using, for whatever reason its not working correctly, see output:-

;; flags: qr tc rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 

note the fact you query but receive no answer, if i perform the same query on my machine i recieve 4 answers for the hostname that was queried, so switch back to the default name server values, at least for now and try again.

 

as for ipv6 replies, i can filter those out to prevent dig picking up ipv6 addresses, as to why it was incrementing the last octet by 1...well thats just odd, it is possible it again is linked to that bad name server.

Link to comment

Anyone else have issues with this container automatically switching the default download directory?

I want the download location to be /data/Torrents but every time the docker restarts (Every morning because of backups) it switches back to /data/incomplete.

 

This causes an issue in Windows because Windows sees both incomplete and Incomplete and I can't see any files in either folder. Sonarr and Radarr are also denied access to that folder as well so they can't post-process anything from the incomplete folder.

 

Any help would be greatly appreciated.

Link to comment
Anyone else have issues with this container automatically switching the default download directory?
I want the download location to be /data/Torrents but every time the docker restarts (Every morning because of backups) it switches back to /data/incomplete.
 
This causes an issue in Windows because Windows sees both incomplete and Incomplete and I can't see any files in either folder. Sonarr and Radarr are also denied access to that folder as well so they can't post-process anything from the incomplete folder.
 
Any help would be greatly appreciated.
Are you setting this in the rtorrent.rc file? Changes for this setting do not save in the rutorrent ui

Sent from my SM-G935F using Tapatalk

  • Upvote 1
Link to comment
5 minutes ago, binhex said:

Are you setting this in the rtorrent.rc file? Changes for this setting do not save in the rutorrent ui

Sent from my SM-G935F using Tapatalk
 

 Ah yes, that is the issue. I discovered that config file right as you were posting this. Tested and restarted and all is working now. Thank you!

Link to comment
3 hours ago, binhex said:

 

ok some/all of your issues are related to the name server you are using, for whatever reason its not working correctly, see output:-


;; flags: qr tc rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 

note the fact you query but receive no answer, if i perform the same query on my machine i recieve 4 answers for the hostname that was queried, so switch back to the default name server values, at least for now and try again.

 

as for ipv6 replies, i can filter those out to prevent dig picking up ipv6 addresses, as to why it was incrementing the last octet by 1...well thats just odd, it is possible it again is linked to that bad name server.

 

Not exactly sure what is wrong with that output you referenced... further down it says:

;; WARNING: The answer packet was truncated; you might want to
;; query again with TCP (-t argument), or EDNS0 (-b for buffer size)

Trying to use nslookup and dig via my host server does something similar (note the "Truncated, retrying in TCP mode."), not sure why dig in the docker container isn't retrying in TCP mode automatically?:

/opt/appdata/rtorrent-openvpn/openvpn$ nslookup ca-on.mullvad.net 193.138.219.228
;; Truncated, retrying in TCP mode.
Server:         193.138.219.228
Address:        193.138.219.228#53

Non-authoritative answer:
Name:   ca-on.mullvad.net
Address: 199.66.90.112
Name:   ca-on.mullvad.net
Address: 199.66.90.208
Name:   ca-on.mullvad.net
Address: 162.219.176.250
Name:   ca-on.mullvad.net
Address: 184.75.214.130

/opt/appdata/rtorrent-openvpn/openvpn$ dig ca-on.mullvad.net @193.138.219.228
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.10.3-P4-Debian <<>> ca-on.mullvad.net @193.138.219.228
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7688
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 3, ADDITIONAL: 7

What are the "default" DNS servers?  The one that I provided is the non-logging DNS server hosted by my VPN provider, and I would like to use it if possible.  Besides, I think all of the issues I have found are fixable... and may save other folks some headaches.

 

 

Follow up... from within in the container, I tested the Drill command and it works without fail.  I assume that's because it is on the VPN and therefore the DNS queries are actually being redirected to their internal DNS servers per Mullvad's FAQ: 

Quote

It's worth noting that all our VPN servers hijack calls to our public DNS server and that the DNS requests are processed on a local non-logging DNS server installed on that VPN server. This is done to process requests faster and to leak less information to the internet."

 

I suspect the solution to this particular issue is simply to put a -t on /root/start.sh line 176 like so:

echo "[debug] Show name resolution for VPN endpoint ${VPN_REMOTE}" ; drill -t "${VPN_REMOTE}"

obviously, this just fixes the output in the debug log... doesn't change anything functionally.

 

 

Edited by c0nfuzed
More information
Link to comment
3 hours ago, Tatux said:

Hey again,

 

So not gettin gthe cert error anymore but still not connecting , any advise?

baa.txt

 

this is your problem:-

08T13:05:59.018363971Z Thu Mar  8 13:05:59 2018 Error: private key password verification failed

how you fix this im not sure, but thats def your issue.

Link to comment

I have fucked up.

 

I used SSH into unRAID (not the docker itself) and edited rtorrent.rc and now it won't start and i only change the "encryption" line and changed it back after that with NANO as ROOT so maybe it changed file permission or something? I'm not that good with file permission in Linux.

 

i checked the the supervisord.log and all i find is this! and the WARNING and option at the end is just stuff i need help with fixing?

 

How should the file permission be sett for "vpn.conf"? chmod ___ ? chown xxx.yyy vpn.conf

i don't know what it means by "explicit-exit-notify"?

 



2018-03-12 01:04:02,376 DEBG 'rtorrent-script' stdout output:
[info] Attempting to start rTorrent...

2018-03-12 01:04:02,378 DEBG 'rtorrent-script' stdout output:
Script started, file is /home/nobody/typescript

2018-03-12 01:04:02,398 DEBG 'rtorrent-script' stdout output:
Script done, file is /home/nobody/typescript

2018-03-12 01:04:31,514 DEBG 'rtorrent-script' stdout output:
[warn] Wait for rTorrent process to start aborted

2018-03-12 01:05:01,635 DEBG 'rtorrent-script' stdout output:
[info] rTorrent not running

2018-03-12 01:05:01,636 DEBG 'rtorrent-script' stdout output:
[info] Removing any rtorrent session lock files left over from the previous run...


Mon Mar 12 00:57:00 2018 WARNING: file '/config/openvpn/ovpn-tls.key' is group or others accessible
Mon Mar 12 00:57:07 2018 Option 'explicit-exit-notify' in [PUSH-OPTIONS]:6 is ignored by previous <connection> blocks 

 

 

/mnt/cache/appdata/binhex-rtorrentvpn/
drwxrwxrwx 1 nobody users  40 Mar 11 01:54 rtorrent/
drwxrwxrwx 1 nobody users  42 Mar  4 01:45 rutorrent/

/mnt/cache/appdata/binhex-rtorrentvpn/rtorrent
drwxrwxr-x 1 nobody users  22 Mar  4 01:45 config/
drwxrwxr-x 1 nobody users  36 Mar 11 01:54 scripts/
drwxrwxrwx 1 nobody users 20K Mar 11 22:45 session/

/mnt/cache/appdata/binhex-rtorrentvpn/rtorrent/config
-rwxrwxr-x 1 nobody users 5.4K Mar 11 22:54 rtorrent.rc*


/mnt/cache/appdata/binhex-rtorrentvpn/openvpn
-rwxrwxr-x 1 nobody users  601 Feb  1 13:20 ovpn-tls.key*

Anyone know what i might have done wrong?

Link to comment
5 hours ago, DigitalLF said:

I used SSH into unRAID (not the docker itself) and edited rtorrent.rc and now it won't start and i only change the "encryption" line and changed it back after that with NANO as ROOT so maybe it changed file permission or something? I'm not that good with file permission in Linux.

 

i checked the the supervisord.log and all i find is this! and the WARNING and option at the end is just stuff i need help with fixing?

 

How should the file permission be sett for "vpn.conf"? chmod ___ ? chown xxx.yyy vpn.conf

i don't know what it means by "explicit-exit-notify"?

 


Mon Mar 12 00:57:00 2018 WARNING: file '/config/openvpn/ovpn-tls.key' is group or others accessible
Mon Mar 12 00:57:07 2018 Option 'explicit-exit-notify' in [PUSH-OPTIONS]:6 is ignored by previous <connection> blocks 

 

 


/mnt/cache/appdata/binhex-rtorrentvpn/
drwxrwxrwx 1 nobody users  40 Mar 11 01:54 rtorrent/
drwxrwxrwx 1 nobody users  42 Mar  4 01:45 rutorrent/

/mnt/cache/appdata/binhex-rtorrentvpn/rtorrent
drwxrwxr-x 1 nobody users  22 Mar  4 01:45 config/
drwxrwxr-x 1 nobody users  36 Mar 11 01:54 scripts/
drwxrwxrwx 1 nobody users 20K Mar 11 22:45 session/

/mnt/cache/appdata/binhex-rtorrentvpn/rtorrent/config
-rwxrwxr-x 1 nobody users 5.4K Mar 11 22:54 rtorrent.rc*


/mnt/cache/appdata/binhex-rtorrentvpn/openvpn
-rwxrwxr-x 1 nobody users  601 Feb  1 13:20 ovpn-tls.key*

Anyone know what i might have done wrong?

 

A warning is not an error.  If you read the warning, it's simply saying that your .key file is readable by more than just the owner of the file.  It warns of this because this may be a security concern on a shared system.  I suspect this is not indicating the issue your experiencing.

 

I would attach your full logs (redact your username password).

 

That said.... you could just change the config directory in your run command, which would create a whole new set of files and just copy the ones over that you need from the old directory.  That's what makes docker so great... nothing is permanent... you can just flush a container and start clean in a matter of seconds.

Link to comment
17 hours ago, c0nfuzed said:

 

A warning is not an error.  If you read the warning, it's simply saying that your .key file is readable by more than just the owner of the file.  It warns of this because this may be a security concern on a shared system.  I suspect this is not indicating the issue your experiencing.

 

I would attach your full logs (redact your username password).

 

That said.... you could just change the config directory in your run command, which would create a whole new set of files and just copy the ones over that you need from the old directory.  That's what makes docker so great... nothing is permanent... you can just flush a container and start clean in a matter of seconds.

 

Thank you for guiding me in the right direction! :)

 

i spent a few more hours on it the error was in rtorrent.rc

 

But the warnings are not a error correct. but i still want to secure my credentials :)

Edited by DigitalLF
Link to comment

Hi everyone, i am having trouble connecting to my VPN for some reason, i logged into rutorrent this morning and it was fine, but when i got home, it had stopped working.

It spits out this error:

 

2018-03-13 21:47:42,125 DEBG 'start-script' stdout output:
-P INPUT DROP
-P FORWARD ACCEPT
-P OUTPUT DROP
-A INPUT -i tun0 -j ACCEPT
-A INPUT -s 172.17.0.0/16 -d 172.17.0.0/16 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --sport 1197 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 9080 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --sport 9080 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 9443 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --sport 9443 -j ACCEPT
-A INPUT -s 192.168.87.0/24 -i eth0 -p tcp -m tcp --dport 5000 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A OUTPUT -o tun0 -j ACCEPT
-A OUTPUT -s 172.17.0.0/16 -d 172.17.0.0/16 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --dport 1197 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --dport 9080 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 9080 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --dport 9443 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 9443 -j ACCEPT
-A OUTPUT -d 192.168.87.0/24 -o eth0 -p tcp -m tcp --sport 5000 -j ACCEPT
-A OUTPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT

2018-03-13 21:47:42,125 DEBG 'start-script' stdout output:
--------------------

2018-03-13 21:47:42,126 DEBG 'start-script' stdout output:
[info] Starting OpenVPN...

2018-03-13 21:47:42,136 DEBG 'start-script' stdout output:
Tue Mar 13 21:47:42 2018 WARNING: file 'credentials.conf' is group or others accessible

Tue Mar 13 21:47:42 2018 OpenVPN 2.4.4 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Sep 26 2017
Tue Mar 13 21:47:42 2018 library versions: OpenSSL 1.1.0f 25 May 2017, LZO 2.10

2018-03-13 21:47:42,137 DEBG 'start-script' stdout output:
[info] OpenVPN started
Tue Mar 13 21:47:42 2018 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2018-03-13 21:47:42,140 DEBG 'start-script' stdout output:
Tue Mar 13 21:47:42 2018 RESOLVE: Cannot resolve host address: nl.privateinternetaccess.com:1197 (Name or service not known)

2018-03-13 21:47:42,140 DEBG 'start-script' stdout output:
Tue Mar 13 21:47:42 2018 RESOLVE: Cannot resolve host address: nl.privateinternetaccess.com:1197 (Name or service not known)
Tue Mar 13 21:47:42 2018 Could not determine IPv4/IPv6 protocol
Tue Mar 13 21:47:42 2018 SIGHUP[soft,init_instance] received, process restarting

I have tried all the different .opvn files available by PIA, putting in the default DNS values and retyping my password and username, but nothing works

When i turn the vpn off everything works fine.

 

Can anyone help me?

 

EDIT: Update fixed it

Edited by mlebjerg
Link to comment
  • binhex locked this topic
Guest
This topic is now closed to further replies.