Now looks fine, they are using topology subnet, not net30, I've no idea if it changes the setup.
you can start testing transmission, also with user transmission with a bash shell like I mentioned before with echoip.com
Now looks fine, they are using topology subnet, not net30, I've no idea if it changes the setup.
you can start testing transmission, also with user transmission with a bash shell like I mentioned before with echoip.com
Just tried it again and that second route is not always there. Very intermittent for some reason
I am curious about the gateway .237 it should be .60
hmm what is happening is after 20 secs of inactivity the vpn is restarting
Tue Sep 15 20:20:56 2015 [ugauyeighaew.openvpn.ipredator.se] Inactivity timeout (--ping-restart), restarting
after the restart the second route has gone and the vpn ip address can also change.
This is because I'm not running the script from "up"
Yes, well that's a problem, go back to the default conf in your vpn provider if it has the same behavior, I think the only change was route-nopull
I put the script back into the .conf and removed the route-nopull, now there are no restarts and the second route stays even during restarting openvpn.
DHT is working but Trackers are not and the checkMyTorrentIp.png torrent doesn't show any IP address.
Oh and because of the route-nopull being removed the OMV Update manager is using the vpn
Well, I say I have no idea then. You should look at the logs before the restart, maybe there is something else, but is alway better to look at the server log, which in this case is not possible.
flush the iptables of you want the transmission to start traffickin again you have rUles from the script there
ok, i went to ask for a testing account there and i found this service quite different from other ones. I was chatting in IRC with some people there.
So you need to modify the script a little bit, because the connection needs a route to the vpn server through the non-vpn connection. In this case instead of route-nopull use route-noexec (this is to pass env vars to script) and use route-up for the iptables script
In the link is the modified script
http://sprunge.us/EOhF
Then you will also need a down script with ip route del $route_network_1 just to clean the main table after vpn is down.
The disconnection was because the server is configured send a restart signal if no activity (normal policy), without the route mentioned before there wasn't any activity, that's why.
Hope this works
You have really gone above and beyond what I would say is the "normal" level of help and I thank you very much
I have made the changes but ran into a little question regarding the scripts.
The ipredator.conf runs the following to add in their DNS servers
I was reading you cannot have multiple up or down lines in this .conf
The update-resolv-conf is
#!/bin/bash
#
# Parses DHCP options from openvpn to update resolv.conf
# To use set as 'up' and 'down' script in your openvpn *.conf:
# up /etc/openvpn/update-resolv-conf
# down /etc/openvpn/update-resolv-conf
#
# Used snippets of resolvconf script by Thomas Hood <jdthood@yahoo.co.uk>
# and Chris Hanson
# Licensed under the GNU GPL. See /usr/share/common-licenses/GPL.
#
# 05/2006 chlauber@bnc.ch
#
# Example envs set from openvpn:
# foreign_option_1='dhcp-option DNS 193.43.27.132'
# foreign_option_2='dhcp-option DNS 193.43.27.133'
# foreign_option_3='dhcp-option DOMAIN be.bnc.ch'
[ -x /sbin/resolvconf ] || exit 0
case $script_type in
up)
for optionname in ${!foreign_option_*} ; do
option="${!optionname}"
echo $option
part1=$(echo "$option" | cut -d " " -f 1)
if [ "$part1" == "dhcp-option" ] ; then
part2=$(echo "$option" | cut -d " " -f 2)
part3=$(echo "$option" | cut -d " " -f 3)
if [ "$part2" == "DNS" ] ; then
IF_DNS_NAMESERVERS="$IF_DNS_NAMESERVERS $part3"
fi
if [ "$part2" == "DOMAIN" ] ; then
IF_DNS_SEARCH="$IF_DNS_SEARCH $part3"
fi
fi
done
R=""
for SS in $IF_DNS_SEARCH ; do
R="${R}search $SS
"
done
for NS in $IF_DNS_NAMESERVERS ; do
R="${R}nameserver $NS
"
done
echo -n "$R" | /sbin/resolvconf -a "${dev}.inet"
/etc/openvpn/firewall.sh
;;
down)
/sbin/resolvconf -d "${dev}.inet"
ip route del $route_network_1
;;
esac
Alles anzeigen
Is it ok to add the lines 49 & 53 as I have done? There doesn't appear to be any errors when openvpn starts or stops with # openvpn --config /etc/openvpn/IPredator-CLI-Password.conf
This is what I get not running any torrents in transmission usingh iftop -i eth0 -P -n -N
192.168.0.255:54915 => 192.168.0.4:54915
192.168.0.12:2122 => 192.168.0.4:50016
192.168.0.12:37306 => 46.246.62.2:1194
and with iftop -i tun0 -P -n -N
46.246.62.75:51413 => 72.226.0.10:16017
239.255.255.250:1900 => 46.246.62.46:60477
46.246.62.75:51413 => 107.209.165.34:48874
46.246.62.75:51413 => 78.139.209.117:43437
46.246.62.75:51413 => 175.137.225.48:6881
46.246.62.75:51413 => 93.71.192.123:29253
46.246.62.75:51413 => 162.144.80.134:51413
46.246.62.75:56216 => 112.210.9.231:52681
The ip addresses change frequently
You can try múltiple up lines (don't know if it works), if you put multiple scripts in one line there will be treated as arguments or vars.
or as you want you can paste the resolv script inside the iptables script. That should work also, I guess.
Looks like is working apparently.
I stopped and restarted openvpn during a torrent download then checked tun0. I was surprised to see the lines with connections to 192.168.0.12 is that normal?
46.246.62.70:51413 => 96.250.167.251:51413 10.4kb 10.8kb 4.24kb
<= 503kb 549kb 196kb
239.255.255.250:1900 => 46.246.62.46:60477 0b 0b 0b
<= 0b 322b 107b
46.246.62.70:33063 => 83.42.147.61:15005 0b 0b 16b
<= 0b 96b 48b
46.246.62.70:51413 => 80.98.128.10:14116 0b 69b 46b
<= 0b 0b 0b
176.9.62.182:64403 => 192.168.0.12:51413 0b 0b 0b
<= 232b 46b 96b
46.246.62.70:51413 => 31.172.63.225:80 0b 35b 12b
<= 0b 0b 0b
46.246.62.70:51413 => 95.91.173.222:64916 0b 0b 152b
<= 0b 0b 41b
46.246.62.70:51413 => 93.71.192.123:29253 0b 0b 33b
<= 0b 0b 84b
24.43.1.206:49783 => 192.168.0.12:51413 0b 0b 0b
<= 0b 0b 33b
24.43.1.206:1344 => 192.168.0.12:51413 0b 0b 0b
<= 0b 0b 33b
73.194.143.73:41208 => 192.168.0.12:51413 0b 0b 0b
<= 0b 0b 33b
83.42.147.61:15005 => 192.168.0.12:51413 0b 0b 0b
<= 0b 0b 31b
167.88.118.245:51413 => 192.168.0.12:51413 0b 0b 0b
<=
Alles anzeigen
the lines with 192.168.0.12 eventually disappeared
46.246.62.70:48983 => 87.104.231.45:80 20.5kb 20.8kb 22.1kb
<= 906kb 775kb 756kb
46.246.62.70:51413 => 96.250.167.251:51413 7.52kb 14.2kb 9.76kb
<= 419kb 747kb 529kb
46.246.62.70:48984 => 87.104.231.45:80 11.5kb 14.2kb 21.1kb
<= 260kb 444kb 606kb
46.246.62.70:48982 => 87.104.231.45:80 15.2kb 13.1kb 17.4kb
<= 464kb 418kb 566kb
46.246.62.70:48981 => 87.104.231.45:80 12.8kb 15.4kb 15.7kb
<= 308kb 412kb 433kb
46.246.62.70:51413 => 78.139.209.117:43437 0b 98b 24b
<= 0b 244b 61b
46.246.62.70:51413 => 72.226.0.10:16017 0b 0b 0b
<= 0b 210b 157b
46.246.62.70:51413 => 95.91.173.222:64916 0b 74b 206b
<= 0b 38b 944b
46.246.62.70:51413 => 70.197.1.152:5237 0b 69b 34b
<= 0b 0b 0b
46.246.62.70:51413 => 108.173.226.19:32133 0b 0b 24b
<= 0b 0b 63b
46.246.62.70:51413 => 77.49.91.182:39180 0b 0b 17b
<= 0b 0b 19b
46.246.62.70:15955 => 203.153.122.10:15398 0b 0b 0b
<= 0b 0b 30b
46.246.62.70:51413 => 86.192.164.183:46381 0b 0b 0b
<= 0b 0b 26b
46.246.62.70:51413 => 24.115.199.79:50528 0b 0b 0b
<= 0b 0b 26b
46.246.62.70:51413 => 37.229.228.106:6881 0b 0b 0b
<=
Alles anzeigen
It could be something that leaked, you can maybe add a reject input rule for eth0 on peer port.
I'm a little confused.
If 176.9.62.182:64403 is sending data to 192.168.0.12:51413 is that connecting via my real ip address? because if tun0 is down then the default gateway is used, is that right? If the default gateway is used then 176.9.62.182 is seeing my real ip address so a Input rule won't stop that.
Just checked and Trackers are working but DHT is being blocked. In think DHT needs port 51413 open to work correctly. Adding INPUT rules doesn't fix it.
Transmission has port checker, does it show as open?
Oh I just found that it shows it is Closed
As a sanity check maybe after openvpn starts restart transmission daemon just to reset all connections that might be open through eth0. Just saw a few i think they were coming from before, after a daemon restart all goes through tun
Stopped transmission and openvpn services
iptables -F
ip route flush table vpn
ip route flush cache
Started transmission and 51413 was open. Trackers and DHT working through my real IP
Removed script and route-noexec from .conf
Started openvpn and transmission. Port 51413 was open. Trackers and DHT working through my vpn IP
Reinstated script and route-noexec from .conf
Started openvpn and transmission. Port 51413 was closed. Trackers and DHT not working through my vpn IP
Restarted transmission and port 51413 was closed but Trackers and DHT working
Tried this a number of times and whether the Trackers are working is a bit intermittent.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!