Port forwarding, Transmission, Pi, OpenVPN and other stuff.

[wfmarcum]

I've setup a RPi2 with transmission and openvpn, using some of the guide you have up for accessing from outside the network, and just about everything works great. I can access the webui from outside the network, torrents do download, but only in passive mode because I can not seem to get a port forwarded on my router to listen for peers. 9091 works just fine and reports open, but I'm currently using 54731 as a peer port and it doesn't report open at all. Based on Mike's comment on the guide I ran netstat -lntp but I believe that I've exceded my knowledge on the subject since I wasn't able to glene any useful information from it myself. Below are the results of the command.

Code:

**@****** ~ $ sudo netstat -lntp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:9091            0.0.0.0:*               LISTEN      6382/transmission-d
tcp        0      0 10.124.1.6:54731        0.0.0.0:*               LISTEN      6382/transmission-d
tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN      2295/smbd
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      2456/sshd
tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN      2295/smbd

---

One thing to note, is that I do believe the issue lies somewhere with the Pi and VPN settings, as even in the DMZ the port is closed, but since the 9091 port works just fine, there must be a solution somewhere.

[Mike]

Can you test an Ubuntu torrent with the VPN disabled and see if that's the culprit?

Which VPN service are you using?

[wfmarcum]

(Jan 07, 2016, 05:11 PM)Mike Wrote: Can you test an Ubuntu torrent with the VPN disabled and see if that's the culprit?

Which VPN service are you using?

I'll test it tonight, I'm running PIA, mostly because I already had a subscription to it. I'm at work and forgot to open up remote shell so I'll try it tonight.

[wfmarcum]

So, first thing I did was disable the VPN, it really only brought up more questions. Firstly I disabled the VPN by commenting out the initialization in rc.local. Tested port, port reports closed still. Checked ps aux | less for openvpn, nothing, checked IP, reports back my IP. 

So then I decided to delete transmission, so I backed up my settings.json, purged transmission, then rebooted. Reinstalled transmission and changed only enough settings to login, suddenly the port forwarding worked. So I copied my old settings back, and then suddenly it stopped working. Obviously a problem with my settings right? So I reset it back to default again, and it works. Then I decide alright, I'll turn on the vpn and play with each setting till I break it. As soon as it boots with VPN port forwarding stops working. So I kill the VPN again, reboot, and port forwarding still isn't working, even though it's the default settings. So I completely purge transmission again, reinstall and then port forwarding works again. So I decide to test each step I've taken one at a time. 

So at least now I know I need to figure out what's different between transmission before the rc.local startup runs, and after, so I run netstat again and see 

Code:

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:9091            0.0.0.0:*               LISTEN      2275/transmission-d
tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN      2320/smbd
tcp        0      0 0.0.0.0:54731           0.0.0.0:*               LISTEN      2275/transmission-d
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      2481/sshd
tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN      2320/smbd

That the local address running for transmission is 0.0.0.0. I assume this is the culprit so knowing I'm using your setting to find the ip automatically in torrentvpn.sh, so I decided to try to change it to what I know are the correct values. So I change it, fire it up, and ... same result. I looked back over the setting file, and without the vpn the bind IP address was still listed as the 10.*whatever so I delete it, go back and load transmission, and suddenly my IP shows up on the torrent IP check as being masked, and I can see the port and download. So then I went back to the file and changed it from if config local, to if config remote (because I don't actually know what that does) but it didn't fix anything. So I changed it back.

At this point it seems to be the problem arises from this line:

Code:

#Plug the VPN IP into transmission, may need to change $ifconfig_local to $ifconfig_remote
sed -i 's/.*"bind-address-ipv4":.*/    "bind-address-ipv4": \"'$ifconfig_local'\",/' /etc/transmission-daemon/settings.json

Since I don't actually know exactly what that is necessary for I'm hesitant to modify it. If you're with me at this point, any advice is greatly appreciated.

Thanks!

[Mike]

I am totally with you, that line was for maximum safety as it it changes the bind address to your VPN local IP (that 10.* IP). You can safely comment this out and restart again. Very curious to know if this fixes everything.

Code:

#sed -i 's/.*"bind-address-ipv4":.*/    "bind-address-ipv4": \"'$ifconfig_local'\",/' /etc/transmission-daemon/settings.json

[wfmarcum]

Went ahead then and commented it out, rebooted to let it fire up and see if it would start everything automatically and it fired right up, IP was masked according to checkmytorrent, port was open and it went away downloading at max speed so.. with that everything seems fixed. Out of curiosity what are the potential security risks with not binding that IP? Obviously there are no guarantee's of privacy but does having it commented out matter that much?

[Mike]

That is great. I have updated the guide to include this correction.

Well, the idea with binding the IP was that even if OpenVPN went down then it wouldn't be able to connect because the bind address was set to the VPN's local ip. The OpenVPN script is already set to stop transmission if the VPN goes down so it was more of a 'best practice' than a necessity.

When gurabli finishes testing another script that forces only transmission through the VPN it will literally block all routes if the VPN goes down and there will be no reason to change the bind address.

[wfmarcum]

Well that's good to know. Thanks for the help, I was just staring at the problem right in front of me for hours playing with things and never thought to just try turning the VPN off (I guess somewhere I just assumed it would work if it was off). Turning it off and going at it with fresh eyes is all it took.

[Mike]

I do the same thing often, it helps to get a fresh pair of eyes to help take a step back and troubleshoot