From charlesreid1

(Flags)
(Flags)
Line 102: Line 102:
  
 
=Flags=
 
=Flags=
 +
 +
{{HotspotFlag}}
  
 
{{KaliFlag}}
 
{{KaliFlag}}

Revision as of 05:29, 2 December 2019

In this scenario, we configure OpenVPN to connect to PIA's VPN servers and make our Kali machine a node on the PIA VPN network.

Diagram:

Openvpn diagram.png

Setup

These instructions assume you have set up OpenVPN and it has created an interface tun0 at the IP address 10.8.0.1.

See Kali/OpenVPN for setup instructions.

PIA Configuration

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

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

Copy the profile and certs into /etc/openvpn/:

sudo cp openvpn/ca.rsa.2048.crt openvpn/crl.rsa.2048.pem /etc/openvpn/
sudo cp "openvpn/US California.ovpn" /etc/openvpn/US.conf

Test Configuration

To test that your OpenVPN is routing traffic through PIA as expected:

1. Check your IP (one way is to search "whats my ip" on duckduckgo, which will tell you your IP and a geolocation)

2. Start OpenVPN (interactively) with the PIA config file:

openvpn --config /etc/openvpn/US.conf

3. Repeat step 1 and confirm the IP and geolocation have changed

Troubleshooting

Use tcpdump to monitor packets traveling through interfaces.

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.

Related

Flags