GUIDE: Setting up Transmission with OpenVPN and PIA

[fireball_ch]

Hi

Dak180 Thank you very much for your script

I have 2 questions :

I become this as output :

Code:

| Transmission Port Forward 2020-11-21 23:09:59
| VPN connection up.
Connection to google.com 80 port [tcp/http] succeeded!
| Closed port detected.
| Loading port forward assignment information..
| New port: 44214
| Cannot set the port.
root@Transmission:/ # localhost:9091/transmission/rpc/ responded: "success"

Cannot set the port ? Is that a normal behavior ?

And at the end the port in transmission is well chnage by the script but still as " closed " You know why ?

 

[MadMungo]

You may want to checkout my script for PIA's 4 gen servers.

Hi dak180

Any idea if this can adapted for use with deluge?
I have had a crack but know nothing of writing scripts or there syntax so when I hit an error or the script fails silently I cannot fix it.

What I did was set the variables for deluge etc then replaced all of the transmission-remote commands with the following deluge console
command.
line 88 json="$(deluge-console -d 192.168.0.69 -U user -P pass config listen_ports 2>&1)" in place of json="$(transmission-remote -pt 2>&1)"
Line199 if ! deluge-console -d x.x.x.x -U user -P pass "config --set listen_ports (${PORTNUM} ${PORTNUM})" &> /dev/null; then in place of if ! transmission-remote -p "${PORTNUM}" &> /dev/null; then

I think the error is being caused by the line 88 entry which outputs Listen_Ports (xxxx, xxxx).

Any idea how to fix it, would be greatly appreciated.

 

[dak180]

I think the error is being caused by the line 88 entry which outputs Listen_Ports (xxxx, xxxx).

I would say you are right since transmission-remote -pt outputs either Port is open: Yes or Port is open: No which is what the following code is looking for.

As I do not use and am not familiar with deluge and it's command line interface I cannot tell you what the correct command would be.

 

[MadMungo]

I would say you are right since transmission-remote -pt outputs either Port is open: Yes or Port is open: No which is what the following code is looking for.

As I do not use and am not familiar with deluge and it's command line interface I cannot tell you what the correct command would be.

Thanks for your help. Worth a shot.

 

[fireball_ch]

Hi dak180

Could you please help me ? Or you need more info ?

 

[dak180]

Could you please help me ? Or you need more info ?

Cannot set the port ? Is that a normal behavior ?

Cannot set port means that the port number is not numeric but it is also supposed to output an error message containing what it was trying to use as a port number in that case which it is not, so not sure what is happening. Have you customized or edited the script in any way?

 

[fireball_ch]

Hi,

Thank you for your message.

I modfied only the log in info ( xxx and yyy replace by my PIA Login und PW)

Code:

#passFile="${vpnDir}/pass.txt"
#mapfile -t auth < "${passFile}"
PIA_USER="xxx"
PIA_PASS="yyy"

And the only log who is modify is the auth.log

Code:

Nov 28 17:04:25 Transmission sudo:     root : TTY=pts/0 ; PWD=/ ; USER=transmission ; COMMAND=/usr/bin/nc -zw 1 google.com 80

and hen on the message log I got :

Code:

Nov 28 17:06:35 Transmission transmission-daemon[79531]: Couldn't connect socket 22 to xxx.xxx.xxx.xxx, port 33070 (errno 13 - Permission denied) (/wrkdirs/usr/ports/net-p2p/transmission-daemon/work/transmission-3.00/libtransmission/net.c:340)

Where xxx.xxx.xxx.xx is my VPN adress and port is the output of your script

 

[dak180]

And the only log who is modify is the auth.log

Code:

Nov 28 17:04:25 Transmission sudo:     root : TTY=pts/0 ; PWD=/ ; USER=transmission ; COMMAND=/usr/bin/nc -zw 1 google.com 80

and hen on the message log I got :

Code:

Nov 28 17:06:35 Transmission transmission-daemon[79531]: Couldn't connect socket 22 to xxx.xxx.xxx.xxx, port 33070 (errno 13 - Permission denied) (/wrkdirs/usr/ports/net-p2p/transmission-daemon/work/transmission-3.00/libtransmission/net.c:340)

Where xxx.xxx.xxx.xx is my VPN adress and port is the output of your script

Unfortunately none of this information is particularly useful in determining why this is not working for you; additionally it is not enough info to give me any idea of what info would be useful.

 

[Mannekino]

I'm currently still using the script from @dak180 and made sure it's up to date with the Github repository.

I'm using OpenVPN 2.5.0 and I keep getting these messages in /var/log/messages:

Code:

Jan  8 12:30:49 transmission2 transmission-daemon[37805]: Couldn't connect socket 36 to <external_ip>, port <my_forwarded_port> (errno 13 - Permission denied) (/wrkdirs/usr/ports/net-p2p/transmission-daemon/work/transmission-3.00/libtransmission/net.c:340)
Jan  8 12:30:51 transmission2 transmission-daemon[37805]: Couldn't connect socket 44 to <external_ip>, port <my_forwarded_port> (errno 13 - Permission denied) (/wrkdirs/usr/ports/net-p2p/transmission-daemon/work/transmission-3.00/libtransmission/net.c:340)

Where <external_ip> is the external IP address I'm getting from PIA and <my_forwarded_port> is the port I got assigned from PIA using the script from @dak180

The socket number in the above error changes. I've had this since I first enabled IPFW and I'm not sure if these messages are to be expected or if something is wrong with my setup.

Below are the contents of my /etc/ipfw.rules file. As you can see it's the basic configuration you see often here on the forums. My Transmission client is not running under the user transmission but under another user for ACL reasons. But I made sure to put the correct user in the IPFW rules.

Code:

#!/usr/local/bin/bash
# Config

# Set rules command prefix
cmd="ipfw -q add"
vpn="tun0"
user="<user_transmission_is_running_under>"
localLan="192.168.178.0/24"

# Flush out the list before we begin
ipfw -q -f flush add

# Allow all local traffic on the loopback interface
${cmd} 00001 allow all from any to any via lo0

# Allow any connection to/from VPN interface
${cmd} 00010 allow all from any to any via ${vpn}

# Allow connection to/from LAN by User
${cmd} 00101 allow all from me to ${localLan} uid ${user}
${cmd} 00102 allow all from ${localLan} to me uid ${user}

# Deny any User connection outside LAN that does not use VPN
${cmd} 00103 deny all from any to any uid ${user}

My Transmission seems to be working, I can download and I'm also seeding some stuff but I'm not 100% if everything is working as it should.

Hopefully someone can shed some light on these messages.

 

[Mannekino]

I'm still working on the problem listed above. I managed to turn on additional logging for IPFW.

I see the following now in /var/log/security on the TrueNAS server itself (not in the Jail).

Code:

Jan 10 15:07:19 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:49417 <external_openvpn_ip>:<forwarded_port> out via epair0b
Jan 10 15:07:19 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:49418 <external_openvpn_ip>:<forwarded_port> out via epair0b
Jan 10 15:07:20 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:49458 <external_openvpn_ip>:<forwarded_port> out via epair0b
Jan 10 15:07:20 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:49459 <external_openvpn_ip>:<forwarded_port> out via epair0b
Jan 10 15:07:21 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:49490 <external_openvpn_ip>:<forwarded_port> out via epair0b
Jan 10 15:07:21 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:49491 <external_openvpn_ip>:<forwarded_port> out via epair0b
Jan 10 15:07:22 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:49495 <external_openvpn_ip>:<forwarded_port> out via epair0b
Jan 10 15:07:22 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:49496 <external_openvpn_ip>:<forwarded_port> out via epair0b
Jan 10 15:07:23 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:49535 <external_openvpn_ip>:<forwarded_port> out via epair0b
Jan 10 15:07:23 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:49536 <external_openvpn_ip>:<forwarded_port> out via epair0b
Jan 10 15:09:50 freenas.<local_domain> ipfw: 103 Deny UDP <local_transmission_ip>:56206 <external_openvpn_ip>:<forwarded_port> out via epair0b
Jan 10 15:09:59 freenas.<local_domain> ipfw[1424]: Last message '103 Deny UDP 192.168' repeated 1 times, suppressed by syslog-ng on freenas.<local_domain>
Jan 10 15:09:59 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:35799 <external_openvpn_ip>:<forwarded_port> out via epair0b
Jan 10 15:09:59 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:18546 <external_openvpn_ip>:<forwarded_port> out via epair0b

That is traffic going over the epair0b interface somehow to or from the internal IP address of my Transmission instance with various random ports. I hope someone can help me understand what's happening here. Shouldn't this all go over the tun0 interface?

Transmission seems to be working well, I'm seeding and downloading right now. But obviously I'm having doubts if I'm connectable for everyone. Currently the contents of my /etc/ipfw.rules file is (I added the log):

Code:

#!/usr/local/bin/bash
# Config

# Set rules command prefix
cmd="ipfw -q add"
vpn="tun0"
user="<transmission_user>"
localLan="<local_network>"

# Flush out the list before we begin
ipfw -q -f flush

# Allow all local traffic on the loopback interface
${cmd} 00001 allow all from any to any via lo0

# Allow any connection to/from VPN interface
${cmd} 00010 allow all from any to any via ${vpn}

# Allow connection to/from LAN by User
${cmd} 00101 allow all from me to ${localLan} uid ${user}
${cmd} 00102 allow all from ${localLan} to me uid ${user}

# Deny any User connection outside LAN that does not use VPN
${cmd} 00103 deny log all from any to any uid ${user}

 

[rizenfrmtheashes]

I'm still working on the problem listed above. I managed to turn on additional logging for IPFW.

I see the following now in /var/log/security on the TrueNAS server itself (not in the Jail).

Code:

Jan 10 15:07:19 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:49417 <external_openvpn_ip>:<forwarded_port> out via epair0b
Jan 10 15:07:19 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:49418 <external_openvpn_ip>:<forwarded_port> out via epair0b
Jan 10 15:07:20 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:49458 <external_openvpn_ip>:<forwarded_port> out via epair0b
Jan 10 15:07:20 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:49459 <external_openvpn_ip>:<forwarded_port> out via epair0b
Jan 10 15:07:21 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:49490 <external_openvpn_ip>:<forwarded_port> out via epair0b
Jan 10 15:07:21 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:49491 <external_openvpn_ip>:<forwarded_port> out via epair0b
Jan 10 15:07:22 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:49495 <external_openvpn_ip>:<forwarded_port> out via epair0b
Jan 10 15:07:22 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:49496 <external_openvpn_ip>:<forwarded_port> out via epair0b
Jan 10 15:07:23 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:49535 <external_openvpn_ip>:<forwarded_port> out via epair0b
Jan 10 15:07:23 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:49536 <external_openvpn_ip>:<forwarded_port> out via epair0b
Jan 10 15:09:50 freenas.<local_domain> ipfw: 103 Deny UDP <local_transmission_ip>:56206 <external_openvpn_ip>:<forwarded_port> out via epair0b
Jan 10 15:09:59 freenas.<local_domain> ipfw[1424]: Last message '103 Deny UDP 192.168' repeated 1 times, suppressed by syslog-ng on freenas.<local_domain>
Jan 10 15:09:59 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:35799 <external_openvpn_ip>:<forwarded_port> out via epair0b
Jan 10 15:09:59 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:18546 <external_openvpn_ip>:<forwarded_port> out via epair0b

That is traffic going over the epair0b interface somehow to or from the internal IP address of my Transmission instance with various random ports. I hope someone can help me understand what's happening here. Shouldn't this all go over the tun0 interface?

Transmission seems to be working well, I'm seeding and downloading right now. But obviously I'm having doubts if I'm connectable for everyone. Currently the contents of my /etc/ipfw.rules file is (I added the log):

Code:

#!/usr/local/bin/bash
# Config

# Set rules command prefix
cmd="ipfw -q add"
vpn="tun0"
user="<transmission_user>"
localLan="<local_network>"

# Flush out the list before we begin
ipfw -q -f flush

# Allow all local traffic on the loopback interface
${cmd} 00001 allow all from any to any via lo0

# Allow any connection to/from VPN interface
${cmd} 00010 allow all from any to any via ${vpn}

# Allow connection to/from LAN by User
${cmd} 00101 allow all from me to ${localLan} uid ${user}
${cmd} 00102 allow all from ${localLan} to me uid ${user}

# Deny any User connection outside LAN that does not use VPN
${cmd} 00103 deny log all from any to any uid ${user}

Hey there Mannekino. I'm actually in the exact same spot you are.
I'm getting these couldn't connect socket errors with permission denied.

Usually permission denied in this case means that certain files or directories couldn't be accessed. Could this be an issue around bad permissions around socket files in the transmission jail? I'm going to try some experiments and see.

 

[dak180]

I see the following now in /var/log/security on the TrueNAS server itself (not in the Jail).

That is traffic going over the epair0b interface somehow to or from the internal IP address of my Transmission instance with various random ports. I hope someone can help me understand what's happening here. Shouldn't this all go over the tun0 interface?

Since I get no such log entries the two things I can suggest are the following: check and be sure that the vpn is up on tun0 and not some other interface; also that you have a line such as the following in your open vpn config:

Code:

route 192.168.0.0 255.255.0.0 net_gateway

 

[Mannekino]

Usually permission denied in this case means that certain files or directories couldn't be accessed. Could this be an issue around bad permissions around socket files in the transmission jail? I'm going to try some experiments and see.

I don't think so, it only start happening when I enable IPFW. The socket errors turn in up /var/log/messages of the Jail. As stated above I've since also enable logging for the deny rules. That gets written to /var/log/security of the TrueNAS root environment.

Since I get no such log entries the two things I can suggest are the following: check and be sure that the vpn is up on tun0 and not some other interface; also that you have a line such as the following in your open vpn config:

Code:

route 192.168.0.0 255.255.0.0 net_gateway

VPN is indeed running on tun0 always uses that.

I've tried adding the line to my OpenVPN configuration file but it did not help. Could there be something not configured properly with my Jail? Maybe you can post your Jail and OpenVPN configuration file so I can compare?

 

[dak180]

Maybe you can post your Jail and OpenVPN configuration file so I can compare?

my openvpn config:

Code:

client
dev tun
proto udp
remote swiss.privacy.network 1197
resolv-retry infinite
nobind
persist-key
persist-tun
cipher aes-256-cbc
data-ciphers AES-256-GCM:AES-256-CBC:BF-CBC
auth sha256
tls-client
auth-nocache
remote-cert-tls server

auth-user-pass /usr/local/etc/openvpn/pass.txt
comp-lzo
verb 1
reneg-sec 0
crl-verify /usr/local/etc/openvpn/crl.rsa.4096.pem
ca /usr/local/etc/openvpn/ca.rsa.4096.crt
disable-occ
mute-replay-warnings


route 192.168.0.0 255.255.0.0 net_gateway

You can find the recipe I use to build my jail here.

 

[Mannekino]

my openvpn config:

I matched my OpenVPN configuration with yours for the most part. I got a up and down script. Doesn't seem to have helped unfortunately. Maybe I need to rebuild my Jail from the ground up.

I see you have the Berkeley Packet Filter enabled in your Jail configuration, could this be it?

Two other things I've noticed with your OpenVPN configuration.

Firstly, are you not getting any warnings/errors related to IPv6 in your log? Because I had to add these two lines to my OpenVPN config.

Code:

pull-filter ignore "ifconfig-ipv6"
pull-filter ignore "route-ipv6"

Secondly, I'm getting this warning with your cipher settings.

Code:

DEPRECATED OPTION: --cipher set to 'aes-256-cbc' but missing in --data-ciphers (AES-256-GCM:AES-256-CBC:BF-CBC). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'aes-256-cbc' to --data-ciphers or change --cipher 'aes-256-cbc' to --data-ciphers-fallback 'aes-256-cbc' to silence this warning.

I had to change the values in the data-cipher to lower case to get rid of those.

Below is my OpenVPN configuration file.

Code:

client
dev tun
proto udp
remote nl-amsterdam.privacy.network 1197
resolv-retry infinite
nobind
persist-key
persist-tun
cipher aes-256-cbc
data-ciphers aes-256-gcm:aes-256-cbc:bf-cbc
auth sha256
tls-client
auth-nocache
remote-cert-tls server
auth-user-pass /usr/local/etc/openvpn/pass.txt
compress
verb 1
reneg-sec 0
pull-filter ignore "ifconfig-ipv6"
pull-filter ignore "route-ipv6"
crl-verify /usr/local/etc/openvpn/PIA/crl.rsa.4096.pem
ca /usr/local/etc/openvpn/PIA/ca.rsa.4096.crt
disable-occ
mute-replay-warnings
route 192.168.0.0 255.255.0.0 net_gateway
script-security 2
up /usr/local/etc/openvpn/openvpn_up.sh
down /usr/local/etc/openvpn/openvpn_down.sh

Do you think it would matter at all if I changed the route line to the following to match my LAN:

Code:

route 192.168.178.0 255.255.255.0 net_gateway

My Jail configuration file:

Code:

{
    "CONFIG_VERSION": "28",
    "allow_chflags": 0,
    "allow_mlock": 0,
    "allow_mount": 1,
    "allow_mount_devfs": 1,
    "allow_mount_fusefs": 0,
    "allow_mount_nullfs": 0,
    "allow_mount_procfs": 0,
    "allow_mount_tmpfs": 0,
    "allow_mount_zfs": 0,
    "allow_quotas": 0,
    "allow_raw_sockets": 1,
    "allow_set_hostname": 1,
    "allow_socket_af": 0,
    "allow_sysvipc": 0,
    "allow_tun": 1,
    "allow_vmm": 0,
    "assign_localhost": 0,
    "available": "readonly",
    "basejail": 0,
    "boot": 0,
    "bpf": 0,
    "children_max": "0",
    "cloned_release": "11.4-RELEASE-p6",
    "comment": "none",
    "compression": "lz4",
    "compressratio": "readonly",
    "coredumpsize": "off",
    "count": "1",
    "cpuset": "off",
    "cputime": "off",
    "datasize": "off",
    "dedup": "off",
    "defaultrouter": "192.168.178.1",
    "defaultrouter6": "none",
    "depends": "none",
    "devfs_ruleset": "4",
    "dhcp": 0,
    "enforce_statfs": "2",
    "exec_clean": 1,
    "exec_created": "/usr/bin/true",
    "exec_fib": "0",
    "exec_jail_user": "root",
    "exec_poststart": "/usr/bin/true",
    "exec_poststop": "/usr/bin/true",
    "exec_prestart": "/usr/bin/true",
    "exec_prestop": "/usr/bin/true",
    "exec_start": "/bin/sh /etc/rc",
    "exec_stop": "/bin/sh /etc/rc.shutdown",
    "exec_system_jail_user": "0",
    "exec_system_user": "root",
    "exec_timeout": "60",
    "host_domainname": "none",
    "host_hostname": "transmission2",
    "host_hostuuid": "transmission2",
    "host_time": 1,
    "hostid": "9a596e85-d38f-11e8-b057-0025907457e1",
    "hostid_strict_check": 0,
    "interfaces": "vnet0:bridge0",
    "ip4": "new",
    "ip4_addr": "vnet0|192.168.178.10/24",
    "ip4_saddrsel": 1,
    "ip6": "disable",
    "ip6_addr": "none",
    "ip6_saddrsel": 1,
    "ip_hostname": 0,
    "jail_zfs": 0,
    "jail_zfs_dataset": "iocage/jails/transmission2/data",
    "jail_zfs_mountpoint": "none",
    "last_started": "2021-01-09 17:00:36",
    "localhost_ip": "none",
    "login_flags": "-f root",
    "mac_prefix": "02ff60",
    "maxproc": "off",
    "memorylocked": "off",
    "memoryuse": "off",
    "min_dyn_devfs_ruleset": "1000",
    "mount_devfs": 1,
    "mount_fdescfs": 1,
    "mount_linprocfs": 0,
    "mount_procfs": 0,
    "mountpoint": "readonly",
    "msgqqueued": "off",
    "msgqsize": "off",
    "nat": 0,
    "nat_backend": "ipfw",
    "nat_forwards": "none",
    "nat_interface": "none",
    "nat_prefix": "172.16",
    "nmsgq": "off",
    "notes": "none",
    "nsem": "off",
    "nsemop": "off",
    "nshm": "off",
    "nthr": "off",
    "openfiles": "off",
    "origin": "readonly",
    "owner": "root",
    "pcpu": "off",
    "plugin_name": "none",
    "plugin_repository": "none",
    "priority": "99",
    "pseudoterminals": "off",
    "quota": "none",
    "readbps": "off",
    "readiops": "off",
    "release": "12.2-RELEASE-p2",
    "reservation": "none",
    "resolver": "/etc/resolv.conf",
    "rlimits": "off",
    "rtsold": 0,
    "securelevel": "2",
    "shmsize": "off",
    "stacksize": "off",
    "stop_timeout": "30",
    "swapuse": "off",
    "sync_state": "none",
    "sync_target": "none",
    "sync_tgt_zpool": "none",
    "sysvmsg": "new",
    "sysvsem": "new",
    "sysvshm": "new",
    "template": 0,
    "type": "jail",
    "used": "readonly",
    "vmemoryuse": "off",
    "vnet": 1,
    "vnet0_mac": "02ff60bb2e01 02ff60bb2e02",
    "vnet0_mtu": "auto",
    "vnet1_mac": "none",
    "vnet1_mtu": "auto",
    "vnet2_mac": "none",
    "vnet2_mtu": "auto",
    "vnet3_mac": "none",
    "vnet3_mtu": "auto",
    "vnet_default_interface": "auto",
    "vnet_default_mtu": "1500",
    "vnet_interfaces": "none",
    "wallclock": "off",
    "writebps": "off",
    "writeiops": "off"
}

I just keep getting these messages in my security log, really scratching my head over this. It seems that my Transmission client is still trying to connect to peers over the epair0b' would you agree with this conclusion?

Code:

Jan 11 15:27:50 freenas.<local_domain> ipfw: 103 Deny TCP <my_local_ip>:53428 <unknown_ip>:80 out via epair0b
Jan 11 15:27:50 freenas.<local_domain> ipfw: 103 Deny TCP <my_local_ip>:55700 <unknown_ip>:80 out via epair0b
Jan 11 15:27:50 freenas.<local_domain> ipfw: 103 Deny TCP <my_local_ip>:19081 <unknown_ip>:1337 out via epair0b
Jan 11 15:27:53 freenas.<local_domain> ipfw: 103 Deny TCP 10.30.110.78:46459 <unknown_ip>:1337 out via epair0b
Jan 11 15:28:00 freenas.<local_domain> ipfw: 103 Deny TCP <my_local_ip>:44188 <unknown_ip>:1337 out via epair0b
Jan 11 15:28:39 freenas.<local_domain> ipfw: 103 Deny UDP <my_local_ip>:<forwarded_port> <external_openvpn_ip>:<forwarded_port> out via epair0b
Jan 11 15:28:48 freenas.<local_domain> ipfw[1424]: Last message '103 Deny UDP <my_local_ip>' repeated 14 times, suppressed by syslog-ng on freenas.<local_domain>
Jan 11 15:28:48 freenas.<local_domain> ipfw: 103 Deny TCP <my_local_ip>:20932 <external_openvpn_ip>:<forwarded_port> out via epair0b
Jan 11 15:28:48 freenas.<local_domain> ipfw: 103 Deny TCP <my_local_ip>:20933 <external_openvpn_ip>:<forwarded_port> out via epair0b
Jan 11 15:28:48 freenas.<local_domain> ipfw: 103 Deny UDP <my_local_ip>:<forwarded_port> <external_openvpn_ip>:<forwarded_port> out via epair0b
Jan 11 15:28:50 freenas.<local_domain> ipfw: 103 Deny TCP <my_local_ip>:20980 <external_openvpn_ip>:<forwarded_port> out via epair0b
Jan 11 15:28:50 freenas.<local_domain> ipfw: 103 Deny TCP <my_local_ip>:20981 <external_openvpn_ip>:<forwarded_port> out via epair0b
Jan 11 15:28:52 freenas.<local_domain> ipfw: 103 Deny TCP <my_local_ip>:21047 <external_openvpn_ip>:<forwarded_port> out via epair0b

 

[dak180]

Do you think it would matter at all if I changed the route line to the following to match my LAN:

In fact you should do exactly this.

I see you have the Berkeley Packet Filter enabled in your Jail configuration, could this be it?

This is because my jails use dhcp and fixed mac addresses to get their ip addresses.

Firstly, are you not getting any warnings/errors related to IPv6 in your log? Because I had to add these two lines to my OpenVPN config.

I only get one referring to ipv6 not being configured though this may be because I have turned off ipv6 for for the vlan subnet the jail is on at the router. Since I made some changes I now receive no warnings from openvpn:

Code:

client
dev tun
proto udp
remote swiss.privacy.network 1197
resolv-retry infinite
nobind
persist-key
persist-tun
data-ciphers-fallback AES-256-CBC
data-ciphers AES-256-GCM:AES-256-CBC:BF-CBC
auth sha256
tls-client
auth-nocache
remote-cert-tls server
pull-filter ignore "route-ipv6"

auth-user-pass /usr/local/etc/openvpn/pass.txt
comp-lzo
verb 1
reneg-sec 0
crl-verify /usr/local/etc/openvpn/crl.rsa.4096.pem
ca /usr/local/etc/openvpn/ca.rsa.4096.crt
disable-occ
mute-replay-warnings

route 192.168.0.0 255.255.0.0 net_gateway

I just keep getting these messages in my security log, really scratching my head over this. It seems that my Transmission client is still trying to connect to peers over the epair0b' would you agree with this conclusion?

It seems likely though I have no idea as to why as the only line in my security log is the one noting the log file's creation.

 

[Mannekino]

In fact you should do exactly this.

I've done some testing with this. When I use your line:

Code:

route 192.168.0.0 255.255.0.0 net_gateway

I don't see any error messages in /var/log/messages/ in my Jail. However, when I change the line to match my /24 local network I get the following error:

Code:

route 192.168.178.0 255.255.255.0 net_gateway

Code:

Jan 12 12:58:25 transmission2 openvpn[32965]: ERROR: FreeBSD route add command failed: external program exited with error status: 1

The VPN connection does get established. I'm way out of my depth with this networking stuff :(.

It seems likely though I have no idea as to why as the only line in my security log is the one noting the log file's creation.

So, this is easily explained. The IPFW messages are only logged if you put the log statement in a IPFW rule. They will show up in /var/log/security of your TrueNAS server not the Jail (most likely). For example:

Code:

${cmd} 00103 deny log all from any to any uid ${user}

Now that I know more about your configuration could you please check the following for me? It all started with these kinds of errors in my /var/log/messages/ in the Jail. But those errors are logged by Transmission and since you have the Transmission log in another file, could you check your Transmission log for these types of errors?

Code:

Couldn't connect socket 75 to <pia_external_ip_address>, port <random_port> (errno 13 - Permission denied) (/wrkdirs/usr/ports/net-p2p/transmission-daemon/work/transmission-3.00/libtransmission/net.c:340)

I did some further testing based on the errors I get in /var/log/security overnight I saw the following pattern:

Code:

Jan 12 03:45:23 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:20337 <pia_external_ip>:<pia_forwarded_port> out via epair0b
Jan 12 03:46:07 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:57015 <pia_external_ip>:<pia_forwarded_port> out via epair0b
Jan 12 03:46:45 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:12846 <pia_external_ip>:<pia_forwarded_port> out via epair0b
Jan 12 04:04:48 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:23436 <pia_external_ip>:<pia_forwarded_port> out via epair0b
Jan 12 04:07:55 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:57395 <pia_external_ip>:<pia_forwarded_port> out via epair0b
Jan 12 04:08:53 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:57239 <pia_external_ip>:<pia_forwarded_port> out via epair0b
Jan 12 04:25:29 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:50530 <pia_external_ip>:<pia_forwarded_port> out via epair0b
Jan 12 04:26:26 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:13556 <pia_external_ip>:<pia_forwarded_port> out via epair0b
Jan 12 04:26:50 freenas.<local_domain> ipfw: 103 Deny UDP <local_transmission_ip>:56206 <pia_external_ip>:<pia_forwarded_port> out via epair0b
Jan 12 04:26:59 freenas.<local_domain> ipfw[1424]: Last message '103 Deny UDP 192.168' repeated 1 times, suppressed by syslog-ng on freenas.<local_domain>
Jan 12 04:26:59 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:13484 <pia_external_ip>:<pia_forwarded_port> out via epair0b
Jan 12 04:26:59 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:18014 <pia_external_ip>:<pia_forwarded_port> out via epair0b
Jan 12 04:36:09 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:20747 <pia_external_ip>:<pia_forwarded_port> out via epair0b
Jan 12 04:41:06 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:56742 <pia_external_ip>:<pia_forwarded_port> out via epair0b
Jan 12 04:41:35 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:64684 <pia_external_ip>:<pia_forwarded_port> out via epair0b
Jan 12 04:43:09 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:30751 <pia_external_ip>:<pia_forwarded_port> out via epair0b
Jan 12 04:51:00 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:30700 <pia_external_ip>:<pia_forwarded_port> out via epair0b
Jan 12 04:54:22 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:52980 <pia_external_ip>:<pia_forwarded_port> out via epair0b
Jan 12 04:54:25 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:52993 <pia_external_ip>:<pia_forwarded_port> out via epair0b
Jan 12 04:56:50 freenas.<local_domain> ipfw: 103 Deny UDP <local_transmission_ip>:56206 <pia_external_ip>:<pia_forwarded_port> out via epair0b
Jan 12 04:56:59 freenas.<local_domain> ipfw[1424]: Last message '103 Deny UDP 192.168' repeated 1 times, suppressed by syslog-ng on freenas.<local_domain>
Jan 12 04:56:59 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:44801 <pia_external_ip>:<pia_forwarded_port> out via epair0b
Jan 12 04:56:59 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:38432 <pia_external_ip>:<pia_forwarded_port> out via epair0b
Jan 12 04:57:32 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:27184 <pia_external_ip>:<pia_forwarded_port> out via epair0b
Jan 12 04:59:52 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:51019 <pia_external_ip>:<pia_forwarded_port> out via epair0b
Jan 12 05:04:03 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:59259 <pia_external_ip>:<pia_forwarded_port> out via epair0b
Jan 12 05:04:37 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:15498 <pia_external_ip>:<pia_forwarded_port> out via epair0b
Jan 12 05:05:30 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:51817 <pia_external_ip>:<pia_forwarded_port> out via epair0b
Jan 12 05:07:55 freenas.<local_domain> ipfw: 103 Deny TCP <local_transmission_ip>:24166 <pia_external_ip>:<pia_forwarded_port> out via epair0b

So what I figured out by trial and error is that the local IP address of the Transmission Jail is sending and receiving traffic to my external PIA IP address over the epair0b interface. After I added these two lines for testing to my IPFW rules I no longer got errors in the my security or messages log.

Code:

${cmd} 00020 allow log all from <local_transmission_ip>/32 to <pia_external_ip>/32 via epair0b
${cmd} 00020 allow log all from <pia_external_ip>/32 to <pia_external_ip>/32 via epair0b

I enabled logging and I see a whole bunch of Accept hits in the security log now.

So what's going on here? Why is there traffic going from and to my Transmission Jail IP address to my external PIA IP address over the epair0b interface? This traffic being blocked doesn't seem to hinder my Transmission functionality. I can still download and I seem to be seeding also.

I really hope someone who understands this material can help me out and explain this.

 

[Mannekino]

@dak180 I've reached the end of my patience with this issue unfortunately. I've been talking on some Discord servers also and some people there commented I should ditch PIA because there have been more complaints about "weird issues" with PIA and OpenVPN. I will be cancelling my PIA subscription, thankfully I was paying on a monthly basis.

I decided to give something else a shot based on the talks I had. I bought a month's time with Mullvad and switched to WireGuard. Immidiatly all the problems I had went away. I even kept your IPFW rules in place and not a single error so far in just over two hours since the switch. I only had to change the VPN tunnel adapter variable in the IPFW rules.

Some things to note:

• The moment I switched to WireGuard and Mullvad many more Torrents "activated" in Transmission and started seeding immediately. Previously Torrents would be "activated" in the UI but I never actually saw any bandwidth going to other peers. Since the switch I've been pretty much at my set rate limit the whole time. As you can see here:
  
  
• You can setup a port forward on the control panel of Mullvad. No keep-alive script nessacary or any complication port forwarding scripts. I just got a port from Mullvad and set it in Transmission by hand and done.
• No errors in /var/log/security on my TrueNAS server or in /var/log/messages in the Jail from Transmission. It's been silent for 2+ hours.
• I do have one issue with WireGuard. When I stop the service it clears my /etc/resolv.conf which would normally have the local IP address of my router and then DNS queries no longer work, I need to figure out how to fix this.

 

[rizenfrmtheashes]

@dak180 I've reached the end of my patience with this issue unfortunately. I've been talking on some Discord servers also and some people there commented I should ditch PIA because there have been more complaints about "weird issues" with PIA and OpenVPN. I will be cancelling my PIA subscription, thankfully I was paying on a monthly basis.

I decided to give something else a shot based on the talks I had. I bought a month's time with Mullvad and switched to WireGuard. Immidiatly all the problems I had went away. I even kept your IPFW rules in place and not a single error so far in just over two hours since the switch. I only had to change the VPN tunnel adapter variable in the IPFW rules.

Some things to note:

• The moment I switched to WireGuard and Mullvad many more Torrents "activated" in Transmission and started seeding immediately. Previously Torrents would be "activated" in the UI but I never actually saw any bandwidth going to other peers. Since the switch I've been pretty much at my set rate limit the whole time. As you can see here:
  View attachment 44202
• You can setup a port forward on the control panel of Mullvad. No keep-alive script nessacary or any complication port forwarding scripts. I just got a port from Mullvad and set it in Transmission by hand and done.
• No errors in /var/log/security on my TrueNAS server or in /var/log/messages in the Jail from Transmission. It's been silent for 2+ hours.
• WireGuard uses i
• I do have one issue with WireGuard. When I stop the service it clears my /etc/resolv.conf which would normally have the local IP address of my router and then DNS queries no longer work, I need to figure out how to fix this.

Hey Mannekino,

I think I'm having the same problems you are and it's leading to slow downloads and uploads as a result. I'm convinced that I want to switch to a scheme like yours with wireguard and probably a different provider. Would you be willing to put together a short guide on how you set up wireguard +Mullvad in your transmission Jail?

Thanks.

 

[Mannekino]

@rizenfrmtheashes sure, will do so tomorrow. I'm going to sleep now :)