Unknown user: Admin moved page Ubuntu/Bespin/AP PIA Tunnel to Ubuntu/Bespin/Old/AP PIA Tunnel

2020-08-19T00:49:27Z

Admin moved page Ubuntu/Bespin/AP PIA Tunnel to Ubuntu/Bespin/Old/AP PIA Tunnel

← Older revision

Revision as of 00:49, 19 August 2020

Unknown user: Created page with "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..."

2020-08-19T00:07:36Z

Created page with "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: * <code>wlan0</code> on 192.168.0.0..."

New page

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:
* <code>wlan0</code> on 192.168.0.0/24 - provides internet connection
* <code>wlan1</code> on 192.168.10.0/24 - access point network
* <code>tun1</code> 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:

<pre>
sudo apt-get -y install netfilter-persistent
</pre>

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:

<pre>
#!/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
</pre>

hat tip:
* [https://serverfault.com/questions/431593/iptables-forwarding-between-two-interface]
* [https://www.raspberrypi.org/documentation/configuration/wireless/access-point-routed.md]
* [https://serverfault.com/questions/453254/routing-between-two-networks-on-linux]
* [https://www.digitalocean.com/community/tutorials/how-to-list-and-delete-iptables-firewall-rules]

This stores the iptables configuration in <code>/etc/iptables/</code>

==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 (<code>sudo hostapd -d /etc/hostapd/hostapd.conf</code>) 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:

<pre>
netstat -rn
</pre>

Check iptables rules with this command:

<pre>
sudo iptables -S
# or
sudo iptables -L
</pre>

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

<pre>
sudo iptables -L INPUT
sudo iptables -L OUTPUT
</pre>

To check that traffic is flowing okay:

On bespin, run <code>tcpdump -i tun1</code> (monitoring the openvpn tunnel) and <code>tcpdump -i wlan1</code> (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: [https://serverfault.com/questions/453254/routing-between-two-networks-on-linux]

===More Troubleshooting===

If you restart the networking service on bespin, like this

<pre>
sudo service networking restart
</pre>

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 <code>/etc/udev/rules.d/70-persistent-net.rules </code>

So we need to reload udev:

<pre>
sudo udevadm control --reload-rules && udevadm trigger
</pre>

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.

[[Category:Bespin]]
[[Category:Machine]]
[[Category:PIA]]
[[Category:VPN]]
[[Category:Hostapd]]

Ubuntu/Bespin/Old/AP PIA Tunnel - Revision history

Unknown user: Admin moved page Ubuntu/Bespin/AP PIA Tunnel to Ubuntu/Bespin/Old/AP PIA Tunnel

Unknown user: Created page with "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..."

Unknown user: Created page with "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..."