pantz.org banner
OpenVPN with Private Internet Access and port forwarding
Posted on 11-11-2017 03:50:03 UTC | Updated on 11-11-2017 04:20:29 UTC
Section: /software/openvpn/ | Permanent Link

Intro

This post will show my setup using PIA (Private Internet Access) with OpenVPN on a Linux machine. Specifically, where only certain applications will utilize the VPN and the rest of the traffic will go out the normal ISP's default route. It will also show how to access the PIA API via a shell script, to open a forwarding port for inbound traffic. Lastly, I will show how to take all of the OpenVPN and PIA information and feed it to programs like aria2c or curl. The examples below were done on Ubuntu 16.04.

Packages and PIA Setup

Go signup for a PIA account.

# Install the packages you need, example uses apt-get
sudo apt-get install openvpn curl unzip

# make dir for PIA files and scripts
sudo mkdir -p /etc/openvpn/pia
cd /usr/local/etc/openvpn

# grab PIA openvpn files and unzip
url='https://www.privateinternetaccess.com/openvpn/openvpn.zip'
sudo curl -o openvpn.zip $url && sudo unzip openvpn.zip

OpenVPN password file

Now that we have PIA login info lets make password file so we don't have to put in a password every time we start OpenVPN. We just need to make a file with the PIA username on one line and the PIA password on the second line. So just use you favorite text editor and do this. The file should be called "pass" and put in the "/etc/openvpn/pia" directory. The scripts that are used later depend on this file being called "pass" and put in this specific directory. An example of what the file looks like is below.

piausername
piapassword123

Change permission on this file so only root can read it

sudo chmod 600 /etc/openvpn/pia/pass

OpenVPN config file

This is the OpenVPN config file that works with PIA, and that also utilizes the scripts that will be talked about further down in the page. Use your favorite editor and copy and paste this text to a file called "pia.conf" and put in the "/etc/openvpn/pia" directory.

# PIA OpenVPN client config file 
client
dev tun

# make sure the correct protocol is used
proto udp

# use the vpn server of your choice
# only use one server at a time
# the ip addresses can change, so use dns names not ip's
# find more server names in .ovpn files
# only certain gateways support port forwarding
#remote us-east.privateinternetaccess.com 1198
#remote us-newyorkcity.privateinternetaccess.com 1198
#remote aus.privateinternetaccess.com 1198
#remote us-west.privateinternetaccess.com 1198
remote ca-toronto.privateinternetaccess.com 1198

resolv-retry infinite
nobind
persist-key
persist-tun
cipher aes-128-cbc
auth sha1

# ca.crt and pem files from openvpn.zip downloaded from pia
ca /etc/openvpn/pia/ca.rsa.2048.crt
crl-verify /etc/openvpn/pia/crl.rsa.2048.pem

tls-client
remote-cert-tls server

# path to password file so you don't have to input pass on startup
# file format is username on one line password on second line
# make it only readable by root with: chmod 600 pass
auth-user-pass /etc/openvpn/pia/pass

# this suppresses the caching of the password and user name
auth-nocache

comp-lzo
verb 1
reneg-sec 0
disable-occ

# allows the ability to run user-defined script
script-security 2

# Don't add or remove routes automatically, pass env vars to route-up
route-noexec

# run our script to make routes
route-up "/etc/openvpn/pia/openvpn-route.sh up"

OpenVPN route script

This is the script that the OpenVPN client will run at the end of startup. The magic happens in this script. Without this script OpenVPN will start the client and make the default route for the box the vpn connection. If you want that then go into the pia.conf file and comment out the "script-security 2", "route-noexec", and "route up ..." lines, and just fire up the client "sudo openvpn --config /etc/openvpn/pia/pia.conf" and your done.

If you don't want the vpn to take over your default route then let's keep going. Now that you have left those lines in the pia.conf file, the following script will be run when the client starts, and it will set up a route that does not take over the default gateway, but just adds secondary vpn gateway for programs to use. Open your favorite text editor and copy in the script below into the file "/etc/openvpn/pia/openvpn-route.sh".

#!/bin/sh
# script used by OpenVPN to setup a route on Linux.
# used in conjunction with OpenVPN config file options
# script-security 2, route-noexec, route-up 
# script also requires route table rt2
# sudo bash -c 'echo "1 rt2" >> /etc/iproute2/rt_tables

# openvpn variables passed in via env vars
rtname="rt2"
ovpnpia="/etc/openvpn/pia"
int=$dev
iplocal=$ifconfig_local
ipremote=$ifconfig_remote
gw=$route_vpn_gateway

if [ -z $int ] || [ -z $iplocal ] || [ -z $ipremote ] || [ -z $gw ]; then
  echo "No env vars found. Use this script with an OpenVPN config file "
  exit 1
fi

help() {
  echo "For setting OpenVPN routes on Linux."
  echo "Usage: $0 up or down"
}

down() {
  # delete vpn route if found
  ip route flush table $rtname
  if [ $? -eq 0 ]; then
    echo "Successfully flushed route table $rtname"
  else
    echo "Failed to flush route table $rtname"
  fi    
}

up() {
  # using OpenVPN env vars that get set when it starts, see man page
  echo "Tunnel on interface $int. File /tmp/vpnint"
  echo $int > /tmp/vpnint
  echo "Local IP is         $iplocal. File /tmp/vpnip"
  echo $iplocal > /tmp/vpnip
  echo "Remote IP is        $ipremote"
  echo "Gateway is          $gw"

  down # remove any old routes

  ip route add default via $gw dev $int table $rtname
  if [ $? -eq 0 ]; then
    echo "Successfully added default route $gw"
  else
    echo "Failed to add default route for gateway $gw"
  fi
  ip rule add from $iplocal/32 table $rtname
  if [ $? -eq 0 ]; then
    echo "Successfully added local interface 'from' rule for $iplocal"
  else
    echo "Failed to add local interface 'from' rule for $iplocal"
  fi
  ip rule add to $gw/32 table $rtname
  if [ $? -eq 0 ]; then
    echo "Successfully added local interface 'to' rule for $gw"
  else
    echo "Failed to add local interface 'to' rule for $gw"
  fi

  # PIA port forwarding, only works with certain gateways
  # No US locations, closest US is Toronto and Montreal
  # no network traffic works during exec of this script
  # things like curl hang if not backgrounded
  $ovpnpia/pia_port_fw.sh &
}

case $1 in
  "up") up;;
  "down") down;;
  *) help;;
esac

# always flush route cache 
ip route flush cache

Now run some final commands to get the script ready to work

# make the new script executable
sudo chmod 755 /etc/openvpn/pia/openvpn-route.sh

# make a new route table rt2 in linux for the script to use
# this only has to be run once before you connect the first time
sudo bash -c 'echo "1 rt2" >> /etc/iproute2/rt_tables'

PIA port forward script

The following script is run by the openvpn-route.sh script. It will contact a PIA server and tell it to open a port for incoming traffic on your vpn connection. This is so people on the internet can contact your machine through the vpn connection. Just a important note that currently only a certain list of PIA gateways support port forwarding. See the PIA support article on this for more info. Now, open your favorite text editor and copy in the script below into the file "/etc/openvpn/pia/pia_port_fw.sh".

#!/bin/bash
# Get forward port info from PIA server

client_id=$(head -n 100 /dev/urandom | sha256sum | tr -d " -")
url="http://209.222.18.222:2000/?client_id=$client_id"

echo "Making port forward request..."

curl --interface $(cat /tmp/vpnint) $url 2>/dev/null > /tmp/vpnportfwhttp

if [ $? -eq 0 ]; then
  port_fw=$(grep -o '[0-9]\+' /tmp/vpnportfwhttp)
  [ -f /tmp/vpnportfw ] && rm /tmp/vpnportfw
  echo $port_fw > /tmp/vpnportfw
  echo "Forwarded port is $port_fw"
  echo "Forwarded port is in file /tmp/vpnportfw"
else
  echo "Curl failed to get forwarded PIA port in some way"
fi
# make the new script executable
sudo chmod 755 /etc/openvpn/pia/pia_port_fw.sh

Starting OpenVPN

Finally we can start OpenVPN to connect with PIA. To do this run the the following command. It will keep the connection in the foreground so you can watch the output.

sudo openvpn --config /etc/openvpn/pia/pia.conf

During startup the OpenVPN client and both of the scripts we made will report on the screen data about the connection and if there were any errors. The output will look like the following example.

Fri Nov 10 19:40:50 2017 OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jun 22 2017
Fri Nov 10 19:40:50 2017 library versions: OpenSSL 1.0.2g  1 Mar 2016, LZO 2.08
Fri Nov 10 19:40:50 2017 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Fri Nov 10 19:40:50 2017 UDPv4 link local: [undef]
Fri Nov 10 19:40:50 2017 UDPv4 link remote: [AF_INET]172.98.67.111:1198
Fri Nov 10 19:40:50 2017 [dbacd7b38d135021a698ed95e8fec612] Peer Connection Initiated with [AF_INET]172.98.67.111:1198
Fri Nov 10 19:40:53 2017 TUN/TAP device tun0 opened
Fri Nov 10 19:40:53 2017 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Fri Nov 10 19:40:53 2017 /sbin/ip link set dev tun0 up mtu 1500
Fri Nov 10 19:40:53 2017 /sbin/ip addr add dev tun0 local 10.24.10.10 peer 10.24.10.9
Tunnel on interface tun0. File /tmp/vpnint
Local IP is         10.24.10.10. File /tmp/vpnip
Remote IP is        10.24.10.9
Gateway is          10.24.10.9
Successfully flushed route table rt2
Successfully added default route 10.24.10.9
Successfully added local interface 'from' rule for 10.24.10.10
Successfully added local interface 'to' rule for 10.24.10.9
Fri Nov 10 19:40:53 2017 Initialization Sequence Completed
Making port forward request...
Forwarded port is 40074
Forwarded port is in file /tmp/vpnportfw

Using the vpn connection

When the vpn started it dropped some files in /tmp. These files have the ip and port info we need to give to different programs when the startup. The scripts created the following files.

Now you can use this info when you start certain programs. Here are some examples.

# get vpn incomming port
pt=$(cat /tmp/vpnportfw)

# get vpn ip
ip=$(cat /tmp/vpnip)

# get vpn interface
int=$(cat /tmp/vpnint)

# wget a file via vpn
wget --bind-address=$ip https://ipchicken.com

# curl a file via vpn
curl --interface $int https://ipchicken.com

# ssh to server via vpn
ssh -b $ip 

# rtorrent 
/usr/bin/rtorrent -b $ip -p $pt-$pt -d /tmp

# start aria2c and background. use aria2 WebUI to connect download files
aria2c --interface=$ip --listen-port=$pt --dht-listen-port=$pt > /dev/null 2>&1 &

Final notes and warnings

If you start any programs and don't specifically bind them to the vpn interface or its ip address their connection will go out the default interface for the machine. Please remember this setup only sends specific traffic through the vpn so things like DNS requests still go through the non-vpn default gateway.

Remember only certain PIA gateways support port forwarding so if it is not working, try another PIA gateway.

PIA has a Linux vpn client that you can download and use if you are into GUI's.

Del.icio.us! | Digg Me! | Reddit!

Related stories

DNS over TLS. Secure the DNS!
Posted on 04-22-2017 21:59:17 UTC | Updated on 04-22-2017 22:08:25 UTC
Section: /software/unbound/ | Permanent Link

Secure the Web

A while back we had the "secure the web" initiative, where everyone was inspired to enable encryption (https) on their websites. This was so we could thwart things like eavesdropping and content hijacking. In 2016 about about half of website visits where https. This is great and things seem to be only getting better. ISP's can not see the content in https traffic. Not seeing your traffic content anymore makes them sad. What makes them happy? They can still see all of your DNS requests.

Your ISP can see the websites you visit

Every ISP assigns you some of their DNS servers for you to use when you connect to them for your internet connection. Every time you type in a website name in your browser bar, this request goes to their DNS servers to look up an number called an IP address. After this happens an IP address is returned to your computer, and the connection to the website is made. Your ISP now has a log of the website you requested attached to the rest of the information they have about you. Then they build profiles about you, and sell that info to 3rd parties to target advertising to you in many different ways. Think you'll be slick and switch out their DNS servers with someone else's like Google's free DNS servers (8.8.8.8)? Think again. Any request through your ISP to any DNS server on the internet is unencrypted. Your ISP can slurp up all same requests and get the same info they did just like when you were using their DNS servers. Just like when they could see all of your content with http before https. This also means that your DNS traffic could possibly be intercepted and hijacked by other people or entities. TLS prevents this.

Securing the DNS

The thing that secures https is Transport Layer Security (TLS). It is a set of cryptographic protocols that provides communications security over a computer network. Now that we are beginning to secure the websites I think it is high time we secure the DNS. Others seem to agree. In 2016 rfc7858 and rfc8094 was submitted to Internet Engineering Task Force (IETF) which describes the use of DNS over TLS and DNS over DTLS. Hopefully these will eventually become a standard and all DNS traffic will be more secure in transit. Can you have DNS over TLS today? Yes you can!

Trying DNS over TLS now

DNS over TLS is in its infancy currently, but there are ways to try it out now. You could try using Stubby, a program that acts as a local DNS Privacy stub resolver (using DNS-over-TLS). You will have compile Stubby on Linux or OS X to use it. You could also setup your own DNS server at home and point it to some upstream forwarders that support DNS over TLS. This is what I have done to start testing this. I use Unbound as my local DNS server on my lan for all of my client machines. I used the configuration settings provided by our friends over at Calomel.org to setup my Ubound server to use DNS over TLS. Here is a list of other open source DNS software that can use DNS over TLS. With my Unbound setup, all of my DNS traffic is secured from interception and modification. So how is my testing going?

The early days

Since this is not a IETF standard yet, there are not a lot of providers of DNS over TLS resolvers. I have had to rearrange my list of DNS over TLS providers a few times when some of the servers were just not resolving hostnames. The latency is also higher than using your local ISP's DNS servers or using someones like Googles DNS servers. This is not very noticeable since my local DNS server caches the lookups. I have a feeling the generous providers of these DNS over TLS services are being overwhelmed and can not handle the load of the requests. This is where bigger companies come into play.

Places like Google or OpenDNS do not support DNS over TLS yet, but I'm hoping that they will get on board with this. Google especially since they have been big proponents of making all websites https. They also have the infrastructure to pull this off. Even if someone like Google turned this on, that means they get your DNS traffic instead of your ISP. Will this ever end?

Uggh, people can still see my traffic

Let's face it, if your connected to the internet, at some point someone gets to see where your going. You just have to choose who you want/trust to give this information to. If you point your DNS servers to Google they get to see your DNS requests. If I point my DNS at these test DNS over TLS servers then they get to see my DNS traffic. It seems like the lesser of 2 evils to send your DNS to 2nd party DNS servers then to your ISP. If you use your ISP's DNS servers they know the exact name attached to the IP address they assigned you and the customer that is making the query. I have been holding off telling you the bad news. https SNI will still give up the domain names you visit.

Through all of this even if you point your DNS traffic to a DNS over TLS server your ISP can still see many of the sites you go to. This is thanks to something in https called Server Name Indication (SNI). When you make a connection to an https enabled website there is a process called a handshake. This is the exchange of information before the encryption starts. During this unencrypted handshake (ClientHello) one of the things that is sent by you is a remote host name. This allows the server on the other end to choose appropriate certificate based on the requested host name. This happens when multiple virtual hosts reside on the same server, and this a very common setup. Unfortunately, your ISP can see this, slurp it up, and log this to your account/profile. So now what?

Would a VPN help? Yes, but remember now your DNS queries go to your VPN provider. What is nice is your ISP will not see any of your traffic anymore. That pesky SNI issue mentioned above goes away when using a VPN. But now your trusted endpoint is your VPN provider. They now can log all the sites you go to. So choose wisely when picking a VPN provider. Read their policy on saving logs, choose one that will allow you to pay with Bitcoin so you will be anonymous as possible. With a VPN provider you also have to be careful about DNS leaking. If your VPN client is not configured right, or you forget to turn it on or, any other myriad of ways a VPN can fail, your traffic will go right back to your ISP.

Even VPN's don't make you anonymous

So you have encrypted your DNS and web traffic with TLS and your using a VPN. Good for you, now your privacy is a bit better, but not anonymity. Your still being tracked. This time it is AD networks and services you use. I'm not going to go into this as many other people have written on this topic. Just know that your being tracked one way or another.

I know this all seems hopeless, but securing the web's infrasturcture bit by bit helps improve privacy just a little more. DNS like http is unencrypted. There was a big push to get websites to encrypt their data, now there needs to be the same attention given to DNS.

Del.icio.us! | Digg Me! | Reddit!

Related stories

Gmail and their IPV6 spam filter
Posted on 08-14-2016 22:30:28 UTC | Updated on 08-14-2016 22:33:51 UTC
Section: /software/smtp/ | Permanent Link

Failing forwards

Earlier this week Gmail's servers decided that any email sent from Gmail and then forwarded from pantz.org back to Gmail was now, as their servers put it "likely unsolicited mail". People sending mail from Gmail to pantz.org were getting bounce messages, which looks bad. All other email from any other domain was coming in without issue. I have been forwarding email from Gmail accounts for many years now without issue.

Time to recheck settings

  1. DNS A,AAAA and PTR records for IPV4,6 setup and work correctly
  2. SPF record setup correctly, but this is a forward so it always shows fail. The bounce message passes SPF, so that's nice.
  3. SMTP w/TLS working and available
  4. pantz.org does not modify, remove or shuffle message headers or modify the body of the message in any way.
  5. No increase in spam getting through. pantz.org filters most mail before it is forwarded.
  6. Not using Sender Rewriting Scheme (SRS).
  7. No DKIM setup

The fix

After seeing that everything checked out, I hit up Google to see if anyone else was having this issue. From the results it seems that many people have had this same issue. Some people just started using SRS to fix their issue. Others had to fix their PTR records in DNS. The last group of people had to stop using IPV6 for mail delivery. Since all of the other pantz.org mail server settings were correct, the only thing I could try was implementing SRS or turn off IPV6. Turning off IPV6 delivery was the easiest test. After turning off IPV6 mail delivery, and just leaving IPV4, all mail from Gmail being forwarded through pantz.org was now being accepted again. How dumb is that?

What is up with IPV6?

It seems Gmail has changed a setting (or I hit some new threshold) on their side dealing with only IPV6. Since Google will not tell you why certain mail is considered "unsolicited mail" we can not figure out what was done to try to fix the issue. If I had to speculate on what is happening, my guess is they turned up the sensitivity on email coming from IPV6 as it is obvious that IPV4 filter is not as sensitive. It is not just my server as it is happening to many other people as well.

I had also noticed that mail coming in from a friend whose server delivers mail to my server via IPV6, and then was forwarded to Gmail via IPV6 was being marked as spam every time. According to Google if the user is in your contacts list (and his email address is) the email is not supposed to be marked as spam. That is straight broken. Now that I switched back to just IPV4 delivery, all of his mail is not being marked as spam anymore. I believe Google has an issue with IPV6 mail delivery and spam classification.

What now?

I hate that I had to turn off IPV6 for mail forwarding to Gmail. My next likely step is to implement SRS for forwarding, and see if I can turn IPV6 back on. The best article I found on setting this up on Postfix is here. It also shows how to setup DKIM which might be fun to do as well.

Del.icio.us! | Digg Me! | Reddit!

Related stories


RSS Feed RSS feed logo
About


3com
3ware
alsa
alsactl
alsamixer
amd
android
apache
areca
arm
ati
auditd
awk
badblocks
bash
bind
bios
bonnie
cable
carp
cat5
cdrom
cellphone
centos
chart
chrome
cifs
cisco
cloudera
comcast
commands
comodo
compiz-fusion
corsair
cpufreq
cpufrequtils
cpuspeed
cron
crontab
crossover
cu
cups
cvs
database
dbus
dd
dd_rescue
ddclient
debian
decimal
dhclient
dhcp
diagnostic
diskexplorer
disks
dkim
dns
dos
dovecot
drac
dsniff
dvdauthor
e-mail
echo
editor
emerald
ethernet
expect
ext3
ext4
fat32
fedora
fetchmail
fiber
filesystems
firefox
firewall
flac
flexlm
floppy
flowtools
fonts
format
freebsd
ftp
gdm
gmail
gnome
greasemonkey
greylisting
growisofs
grub
hacking
hadoop
harddrive
hba
hex
hfsc
html
html5
http
https
idl
ie
ilo
intel
ios
iperf
ipmi
iptables
ipv6
irix
javascript
kde
kernel
kickstart
kmail
kprinter
krecord
kubuntu
kvm
lame
ldap
linux
logfile
lp
lpq
lpr
maradns
matlab
memory
mencoder
mhdd
mkinitrd
mkisofs
moinmoin
motherboard
mouse
movemail
mplayer
multitail
mutt
myodbc
mysql
mythtv
nagios
nameserver
netflix
netflow
nginx
nic
ntfs
ntp
nvidia
odbc
openbsd
openntpd
openoffice
openssh
openssl
openvpn
opteron
parted
partimage
patch
perl
pf
pfflowd
pfsync
photorec
php
pop3
pop3s
ports
postfix
power
procmail
proftpd
proxy
pulseaudio
putty
pxe
python
qemu
r-studio
raid
recovery
redhat
router
rpc
rsync
ruby
saltstack
samba
schedule
screen
scsi
seagate
seatools
sed
sendmail
sgi
shell
siw
smtp
snort
solaris
soundcard
sox
spam
spamd
spf
sql
sqlite
squid
srs
ssh
ssh.com
ssl
su
subnet
subversion
sudo
sun
supermicro
switches
symbols
syslinux
syslog
systemrescuecd
t1
tcpip
tcpwrappers
telnet
terminal
testdisk
tftp
thttpd
thunderbird
timezone
ting
tls
tools
tr
trac
tuning
tunnel
ubuntu
unbound
vi
vpn
wget
wiki
windows
windowsxp
wireless
wpa_supplicant
x
xauth
xfree86
xfs
xinearama
xmms
youtube
zdump
zeromq
zic
zlib