Kali/OpenVPN/PIA

In this scenario, we install and configure OpenVPN on a machine running Kali Linux, and set it up to automatically connect to PIA's VPN servers.

Setup

These instructions assume you have installed OpenVPN.

See Kali/OpenVPN for setup instructions. Or just do the good ol lazy apt-get install openvpn

PIA Configuration

Conveniently, PIA provides OpenVPN configuration files to connect to their VPN servers.

Download PIA OpenVPN Config Files

wget https://www.privateinternetaccess.com/openvpn/openvpn.zip
unzip openvpn.zip -d openvpn

This is a folder of .ovpn files, one for each PIA country/region.

Copy Certificate Authority

Start by copying the PIA certificate authority and CRL (?) into place in /etc/openvpn:

sudo cp ca.rsa.2048.crt crl.rsa.2048.pem /etc/openvpn/.

Authentication

Credentials

Put your PIA credentials into a file in /etc/openvpn:

touch /etc/openvpn/pia_credentials
echo "$PIA_USERNAME" >> /etc/openvpn/pia_credentials
echo "$PIA_PASSWORD" >> /etc/openvpn/pia_credentials
chmod 600 /etc/openvpn/pia_credentials

Modify OpenVPN Profiles

Modify all of the OpenVPN profiles to point to this credentials file:

sed -i -e 's|auth-user-pass|& /etc/openvpn/pia_credentials|' *.ovpn

Install PIA Profiles for Select Regions

Now copy whatever profiles you want into /etc/openvpn/, here's the US and Canada profiles:

sudo cp us_* ca_* /etc/openvpn/.

Test Configuration

Test the configuration by manually starting an interactive OpenVPN session in a terminal.

1. Check your IP before starting OpenVPN:

curl -4 icanhazip.com

2. Start OpenVPN interactively with a PIA config file:

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

(Note: you should not be asked for your credentials.)

3. Open a new terminal window and confirm the IP address has changed (and that you can reach the outside internet):

curl -4 icanhazip.com

Troubleshooting

Use tcpdump to monitor packets traveling through interfaces.

DNS Broken

If you can't connect to the internet using domain names like icanhazip.com, check if you can use an IP address.

ping 8.8.8.8

If this command works, it means you can reach the internet, but DNS is broken. You can also use the dig command,

dig example.com

or specify a DNS server to use:

dig @8.8.8.8 example.com

To fix my DNS problems, I had to open the Network Manager GUI interface (Menu > Settings > Advanced Network Settings) and modify the wifi interface to specify the following:

• for IPv4, set DNS servers to use 8.8.8.8 and 8.8.4.4
• for IPv6, disabled IPv6 entirely. PIA does not play well with IPv6, due to the possibility of leaks, so disabling IPv6 when using PIA VPN is a good idea anyway.

After making both of these changes, I restarted, and was able to start up the OpenVPN network, connect, and successfully do DNS lookups with dig, which were performed via the OpenVPN network.

Interference with other network interfaces

I had two network interfaces, wlan1 (an access point/wifi hotspot) and wlan2 (a wifi connection to the internet), connected via iptables so that hotspot traffic on wlan1 was forwarded through to the wifi connection on wlan2. However, this broke when OpenVPN was started with the PIA config file.

To troubleshoot, run tcpdump and watch the wlan1 interface, which hosts the hotspot:

tcpdump -i wlan1

Now visit duckduckgo.com on a client on the hotspot and ensure you see that traffic passing through.

(If you monitor wlan1, running the hotspot, the traffic is generated from/to the hotspot client hostname. If you monitor wlan2, connected to the wifi internet gateway, the traffic is generated from/to the hotspot host computer running hostapd.)

While monitoring a normal connection, packets will travel from the hotspot client to the remote destination, then from the remote destination back to the client:

17:16:34.656310 IP 53.224.186.35.bc.googleusercontent.com.https > hotspot-client.54842: Flags [P.], seq 8524:9942, ack 6393, win 1518, options [nop,nop,TS val 3849395358 ecr 707483349], length 1418
17:16:34.659508 IP 53.224.186.35.bc.googleusercontent.com.https > hotspot-client.54842: Flags [P.], seq 9942:10118, ack 6393, win 1518, options [nop,nop,TS val 3849395361 ecr 707483349], length 176
17:16:34.659552 IP hotspot-client.54842 > 53.224.186.35.bc.googleusercontent.com.https: Flags [.], ack 9942, win 2025, options [nop,nop,TS val 707483436 ecr 3849395358], length 0
17:16:34.659634 IP 53.224.186.35.bc.googleusercontent.com.https > hotspot-client.54842: Flags [P.], seq 10118:10164, ack 6393, win 1518, options [nop,nop,TS val 3849395362 ecr 707483349], length 46
17:16:34.661258 IP hotspot-client.54842 > 53.224.186.35.bc.googleusercontent.com.https: Flags [.], ack 10118, win 2045, options [nop,nop,TS val 707483437 ecr 3849395361], length 0
17:16:34.665523 IP hotspot-client.54842 > 53.224.186.35.bc.googleusercontent.com.https: Flags [.], ack 10164, win 2047, options [nop,nop,TS val 707483437 ecr 3849395362], length 0
17:16:34.667707 IP hotspot-client.54842 > 53.224.186.35.bc.googleusercontent.com.https: Flags [P.], seq 6393:6439, ack 10164, win 2048, options [nop,nop,TS val 707483437 ecr 3849395362], length 46
17:16:34.900925 IP 53.224.186.35.bc.googleusercontent.com.https > hotspot-client.54842: Flags [P.], seq 10118:10164, ack 6393, win 1518, options [nop,nop,TS val 3849395604 ecr 707483437], length 46
17:16:34.933654 IP hotspot-client.54842 > 53.224.186.35.bc.googleusercontent.com.https: Flags [P.], seq 6393:6439, ack 10164, win 2048, options [nop,nop,TS val 707483710 ecr 3849395362], length 46
17:16:34.934487 IP hotspot-client.54842 > 53.224.186.35.bc.googleusercontent.com.https: Flags [.], ack 10164, win 2048, options [nop,nop,TS val 707483710 ecr 3849395604,nop,nop,sack 1 {10118:10164}], length 0
17:16:35.132975 IP 53.224.186.35.bc.googleusercontent.com.https > hotspot-client.54842: Flags [P.], seq 10118:10164, ack 6393, win 1518, options [nop,nop,TS val 3849395828 ecr 707483437], length 46
17:16:35.133947 IP hotspot-client.54842 > 53.224.186.35.bc.googleusercontent.com.https: Flags [.], ack 10164, win 2048, options [nop,nop,TS val 707483910 ecr 3849395828,nop,nop,sack 1 {10118:10164}], length 0
17:16:35.144157 IP 53.224.186.35.bc.googleusercontent.com.https > hotspot-client.54842: Flags [.], ack 6439, win 1518, options [nop,nop,TS val 3849395848 ecr 707483710], length 0

Packets travel both directions.

While monitoring the hotspot wifi interface while the OpenVPN connection was on, packets only travel one direction, always from the hotspot-client, never to return:

17:22:07.638732 IP hotspot-client.54993 > ec2-50-18-200-106.us-west-1.compute.amazonaws.com.https: Flags [S], seq 4098234318, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 707813996 ecr 0,sackOK,eol], length 0
17:22:07.812703 IP hotspot-client.54842 > 53.224.186.35.bc.googleusercontent.com.https: Flags [.], seq 0:1368, ack 1, win 2048, options [nop,nop,TS val 707814181 ecr 3849705318], length 1368
17:22:08.203870 IP hotspot-client.54837 > 204.127.154.104.bc.googleusercontent.com.4070: Flags [P.], seq 0:176, ack 1, win 2681, options [nop,nop,TS val 707814571 ecr 317275988], length 176
17:22:08.380826 IP hotspot-client.54992 > ec2-50-18-200-106.us-west-1.compute.amazonaws.com.https: Flags [S], seq 253767486, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 707814747 ecr 0,sackOK,eol], length 0

The solution was to modify the iptables rules to forward traffic from wlan1 (hotspot) to tun1 (OpenVPN tunnel connected to PIA).

See Kali/OpenVPN/Hotspot#Setting_iptables_rules for details on the iptables rules to set to forward traffic from wlan1 to tun1.