Ubuntu/Bespin/Old/AP PIA Tunnel

From charlesreid1

The last step here is to provide an internet gateway for the AP, and to do it via the VPN tunnel.

The current network setup is as follows:

  • wlan0 on 192.168.0.0/24 - provides internet connection
  • wlan1 on 192.168.10.0/24 - access point network
  • tun1 on 10.96.10.0/24 - private IP for VPN tunnel

Bridged network vs routed network

There are (at least) two ways we can do this:

  • Bridged network - this uses a virtual network device called a bridge to allow two network interfaces to see traffic from each other. This can be thought of as connecting two network interfaces to a switch, done virtually on the local machine.
  • Routed network - this keeps the two network interfaces separate, and uses iptables to forward traffic from one device to another. This uses masquerading, which means that the server takes packets destined for external networks and proxies them, sending them out over the VPN tunnel, and returning the result to the client when it arrives.

Bridged networks are useful if you want clients on the AP to obtain IP addresses from the wifi router providing bespin with internet. In this scenario, clients would see the 192.168.0.0/24 network, just like bespin does, and would receive IP addresses on that network instead of 192.168.10.0/24.

Routed networks keep the networks associated with each network interface isolated. Packets only pass from one network interface to another if iptables has a rule to do that.

We will use a routed network for this setup.

Creating the routed network

Start by installing the netfilter-persistent tool, which will make it easy to save the iptables configuration: 

sudo apt-get -y install netfilter-persistent

Creating the routed network requires packet forwarding to be enabled (see AP setup for instructions). Set up the routed network by adding iptables rules with the following script: 

#!/bin/bash
set -e

ipt="sudo /sbin/iptables"

# start by flushing all rules and setting defaults
$ipt -F
# should we do this?
#$ipt -P INPUT DROP
#$ipt -P FORWARD DROP
$ipt -P INPUT ACCEPT
$ipt -P FORWARD ACCEPT
$ipt -P OUTPUT ACCEPT
$ipt -t nat -F
$ipt -t mangle -F
$ipt -F
$ipt -X

##################################
# PIA VPN Tunnels

# These are PIA tunnels that handle traffic from APs
PIA_AP_TUNNELS="tun1"
for TUN in TUNNELS; do
    # Accept all traffic coming in from tunnel
    $ipt -A INPUT -i ${TUN} -j ACCEPT
    # Masquaerade outgoing traffic leaving via the tunnel
    $ipt -t nat -A POSTROUTING -o ${TUN} -j MASQUERADE
done

##################################
# AP-PIA Tunneling

# Forward outgoing traffic for APs through tunnel
AP="wlan1"
TUN="tun1"
# Allow traffic on the TUN interface.
$ipt -A INPUT   -i ${TUN} -j ACCEPT
$ipt -A FORWARD -i ${TUN} -j ACCEPT
$ipt -A OUTPUT  -o ${TUN} -j ACCEPT
# Allow forwarding traffic from the VPN
$ipt -A FORWARD -i ${TUN} -o ${AP} -j ACCEPT
$ipt -A FORWARD -i ${AP} -o ${TUN} -j ACCEPT

# Make rules persistent
sudo netfilter-persistent save

hat tip:

This stores the iptables configuration in /etc/iptables/

Testing Joining AP

Join the wifi network from another laptop or phone.

Verify that you receive an IP address and that your device can be pinged from bespin.

Check your IP address from the device (whatsmyip.org) to ensure it is coming from the PIA region specified.

Troubleshooting EAPOL Timeout

If your test computer/laptop/phone connects to the network and authenticates okay but the EAPOL handshake step keeps timing out, it's a problem with the DNS server (dnsmasq) not being set up properly. You can see the EAPOL handshake timeout messages when you run hostapd in debug mode (sudo hostapd -d /etc/hostapd/hostapd.conf) and try to join the wifi network with another computer.

Troubleshooting Joining Wifi

View the kernel IP routing table and review it to make sure things are wired up correctly: 

netstat -rn

Check iptables rules with this command: 

sudo iptables -S
# or
sudo iptables -L

To limit to input/output rules only, do this: 

sudo iptables -L INPUT
sudo iptables -L OUTPUT

To check that traffic is flowing okay:

On bespin, run tcpdump -i tun1 (monitoring the openvpn tunnel) and tcpdump -i wlan1 (monitoring traffic on the AP) in side by side windows. Then join the AP from the phone or device and try to access the internet.

You should see packets related to the request that show up in both the tun1 and wlan1 traffic streams, which verifies that traffic is correctly being forwarded from the AP client through bespin and on to the final destination.

The packets should also be going in both directions - to and from the AP client. If they are only going one direction (from the client to the destination) and none are returning, double-check the iptables rules.

Help from here: [5]

More Troubleshooting

If you restart the networking service on bespin, like this 

sudo service networking restart

then you'll lose your wifi connection. This is because the networking interface reverts back to looking for the old network interface name (the one with the entire mac address in the name), instead of the renamed version.

We specified the device name as part of udev, specifically the file /etc/udev/rules.d/70-persistent-net.rules

So we need to reload udev: 

sudo udevadm control --reload-rules && udevadm trigger

Well crap, that doesn't work. If you reload the networking service, wifi breaks because wpa_supplicant reverts to a stupid network interface scheme, and apparently you're hosed until you restart.

Retrieved from "https://charlesreid1.com/w/index.php?title=Ubuntu/Bespin/Old/AP_PIA_Tunnel&oldid=28501"