Tor over Openvpn

[mr-canoehead]

Tor over Openvpn

[mr-canoehead]

Unfortunately I can't help with this issue as I have zero experience with Tor. I've added the 'help wanted' label, perhaps someone else will be able to contribute some useful info!

[farisoftfry]

I'm trying to do something to solve this problem. The first thing to do is to use VPN in tcp protocol, not udp because Tor doesn't works in udp. It could be easily done changing into the server.conf file deleting udp and adding tcp but the problem, for now, are vpn kill rules. They doesn't works for tcp. I know Pia could works without any problem in tcp. Could you help me adjusting vpn kill switch to be compatible with tcp? I think it should be changed something about ports connection. Thanks

[mr-canoehead]

Connecting using TCP is straightforward, all we need to do is allow outbound access to the TCP ports in the firewall script. I added the following lines to my firewall script, and I'm now able to connect to PIA using TCP.

1. List of TCP ports (these are the ones supported by PIA)
   OPENVPN_TCP_PORTS="80,110,443,501,502"

2. Allow those ports in the 'allow outbound services' section via the following rule:
   iptables -A OUTPUT -o eth0 -p tcp -m multiport --dports $OPENVPN_TCP_PORTS -m comment --comment "openvpn TCP" -j ACCEPT

I have attached the firewall rule script I'm testing with TCP. At some point I should add this change to the firewall config script.

fw-script-tcp-ports.zip

For reference, here's my server.conf:

client
dev tun
proto tcp
remote aus.privateinternetaccess.com 502
resolv-retry infinite
nobind
persist-key
persist-tun
cipher aes-128-cbc
auth sha1
tls-client
remote-cert-tls server
auth-user-pass auth.txt
comp-lzo
verb 1
reneg-sec 0
crl-verify crl.rsa.2048.pem
ca ca.rsa.2048.crt
disable-occ

[farisoftfry]

Hello, your script works well for tcp now but I think there is something wrong with vpn killswitch. It doesn't stop data after vpn failure, but it let reveal the real ip. I don't know when this problem start, if from when you add wireless hotspot or tcp but now it doesn't works like it should. Could you check the vpn killswitch please?

[mr-canoehead]

How are you simulating a VPN outage? How are you testing the internet connection during the simulated outage? From which network are you testing the internet connection (e.g. a device on the Pi's WiFi)? Any additional details would be helpful.

[farisoftfry]

To simulate vpn failure I simply write sudo service openvpn stop (so I stop openvpn) then I check with ifconfig if tun0 exist and if not I open the chromium browser on the pi and I open ipleak.com. It works and it give my real IP address. I tried the same in wireless and the result is the same.
I'm not so good with iptables but I've created some rules with ufw and it seems that it works (if I stop openvpn I can't open any website on pi). These are rules on iptables created by ufw:

-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP
-N ufw-after-forward
-N ufw-after-input
-N ufw-after-logging-forward
-N ufw-after-logging-input
-N ufw-after-logging-output
-N ufw-after-output
-N ufw-before-forward
-N ufw-before-input
-N ufw-before-logging-forward
-N ufw-before-logging-input
-N ufw-before-logging-output
-N ufw-before-output
-N ufw-logging-allow
-N ufw-logging-deny
-N ufw-not-local
-N ufw-reject-forward
-N ufw-reject-input
-N ufw-reject-output
-N ufw-skip-to-policy-forward
-N ufw-skip-to-policy-input
-N ufw-skip-to-policy-output
-N ufw-track-forward
-N ufw-track-input
-N ufw-track-output
-N ufw-user-forward
-N ufw-user-input
-N ufw-user-limit
-N ufw-user-limit-accept
-N ufw-user-logging-forward
-N ufw-user-logging-input
-N ufw-user-logging-output
-N ufw-user-output
-A INPUT -j ufw-before-logging-input
-A INPUT -j ufw-before-input
-A INPUT -j ufw-after-input
-A INPUT -j ufw-after-logging-input
-A INPUT -j ufw-reject-input
-A INPUT -j ufw-track-input
-A FORWARD -j ufw-before-logging-forward
-A FORWARD -j ufw-before-forward
-A FORWARD -j ufw-after-forward
-A FORWARD -j ufw-after-logging-forward
-A FORWARD -j ufw-reject-forward
-A FORWARD -j ufw-track-forward
-A OUTPUT -j ufw-before-logging-output
-A OUTPUT -j ufw-before-output
-A OUTPUT -j ufw-after-output
-A OUTPUT -j ufw-after-logging-output
-A OUTPUT -j ufw-reject-output
-A OUTPUT -j ufw-track-output
-A ufw-after-input -p udp -m udp --dport 137 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 138 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp -m tcp --dport 139 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp -m tcp --dport 445 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 67 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 68 -j ufw-skip-to-policy-input
-A ufw-after-input -m addrtype --dst-type BROADCAST -j ufw-skip-to-policy-input
-A ufw-after-logging-forward -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-after-logging-input -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-after-logging-output -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A ufw-before-forward -j ufw-user-forward
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-input -m conntrack --ctstate INVALID -j ufw-logging-deny
-A ufw-before-input -m conntrack --ctstate INVALID -j DROP
-A ufw-before-input -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A ufw-before-input -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A ufw-before-input -j ufw-not-local
-A ufw-before-input -d 224.0.0.251/32 -p udp -m udp --dport 5353 -j ACCEPT
-A ufw-before-input -d 239.255.255.250/32 -p udp -m udp --dport 1900 -j ACCEPT
-A ufw-before-input -j ufw-user-input
-A ufw-before-output -o lo -j ACCEPT
-A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-output -j ufw-user-output
-A ufw-logging-allow -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW ALLOW] "
-A ufw-logging-deny -m conntrack --ctstate INVALID -m limit --limit 3/min --limit-burst 10 -j RETURN
-A ufw-logging-deny -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-not-local -m addrtype --dst-type LOCAL -j RETURN
-A ufw-not-local -m addrtype --dst-type MULTICAST -j RETURN
-A ufw-not-local -m addrtype --dst-type BROADCAST -j RETURN
-A ufw-not-local -m limit --limit 3/min --limit-burst 10 -j ufw-logging-deny
-A ufw-not-local -j DROP
-A ufw-skip-to-policy-forward -j DROP
-A ufw-skip-to-policy-input -j DROP
-A ufw-skip-to-policy-output -j DROP
-A ufw-user-input -i ipv6 -j DROP
-A ufw-user-input -i udp -j DROP
-A ufw-user-input -i eth0 -j DROP
-A ufw-user-input -i wlan0 -j DROP
-A ufw-user-input -p tcp -m tcp --dport 22 -j ACCEPT
-A ufw-user-limit -m limit --limit 3/min -j LOG --log-prefix "[UFW LIMIT BLOCK] "
-A ufw-user-limit -j REJECT --reject-with icmp-port-unreachable
-A ufw-user-limit-accept -j ACCEPT
-A ufw-user-output -o tun0 -j ACCEPT
-A ufw-user-output -o ipv6 -j DROP
-A ufw-user-output -o udp -j DROP
-A ufw-user-output -o eth0 -j DROP
-A ufw-user-output -o wlan0 -j DROP

In other word I blocked all udp, ipv6 and everything that doesn't pass through tun0, on wlan0 and eth0.
I hope this could help

[mr-canoehead]

TCP ports 80 and 443 are allowed outbound connections from the Pi (to allow openvpn to connect via TCP), web browsers also uses those ports to connect to websites so it's no surprise that you can connect via a web browser on the Pi when your VPN is down.
I am not experiencing any issues with the killswitch and WiFi clients; when the VPN goes down, the WiFi clients can't connect to anything.
I suppose it could be an IPv6 issue, I have it disabled on my network. If your device is getting IPv6 router advertisements from your main router, and your browser supports IPv6, it's very possible that it's using IPv6 to connect to websites.

[farisoftfry]

oh ok, I understand. I didn't know that. You are very helpful. So now I know that everything Is ok. Anyway I'm still trying to get tor over vpn and maybe I've found a way. I will test it and if it will works I will post here. cheers

[mr-canoehead]

Closing this issue due to lack of activity, if you have made some progress on it please feel free to create a new issue with updated information.