Raspberry Pi as OpenVPN Access Point

Question

I am trying to setup Raspberry Pi as VPN-WiFi access point connecting to AWS VPC. I followed Raspberry Pi as an access point

Here are the all steps I performed in sequence

Installed fresh full Raspbian Stretch on Raspberry Pi 3+, which is connected to local network over ethernet.

#Update Raspbian
sudo apt-get update -y
sudo apt-get dist-upgrade -y
sudo reboot

sudo apt install dnsmasq hostapd -y

sudo nano /etc/dhcpcd.conf 
#Added following after # Example static IP configuration:
interface wlan0
    static ip_address=192.168.4.1/24
    nohook wpa_supplicant

sudo systemctl restart dhcpcd

sudo mv /etc/dnsmasq.conf /etc/dnsmasq.conf.orig
sudo nano /etc/dnsmasq.conf
#Added following 
interface=wlan0      # Use the require wireless interface - usually wlan0
dhcp-range=192.168.4.2,192.168.4.20,255.255.255.0,24h

sudo systemctl reload dnsmasq

sudo nano /etc/hostapd/hostapd.conf

interface=wlan0
driver=nl80211
ssid=MyWiFi
hw_mode=g
channel=7
wmm_enabled=0
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=AccessMyNetwork
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

sudo nano /etc/default/hostapd
#Added following line
DAEMON_CONF="/etc/hostapd/hostapd.conf"

sudo systemctl unmask hostapd
sudo systemctl enable hostapd
sudo systemctl start hostapd

sudo nano /etc/sysctl.conf
#Added 
net.ipv4.ip_forward=1

sudo apt install hostapd bridge-utils -y

sudo nano /etc/dhcpcd.conf
#Added following lines just before interface wlan0 config I added above
denyinterfaces wlan0
denyinterfaces eth0

sudo nano /etc/network/interfaces
# Added following after source-directory
# Bridge setup
auto br0
iface br0 inet manual
bridge_ports eth0 wlan0

sudo ifup br0
sudo systemctl restart dhcpcd

sudo nano /etc/hostapd/hostapd.conf
#Added bridge=br0 below the interface=wlan0 line and comment out the driver line 
bridge=br0
#driver=nl80211

sudo systemctl unmask hostapd
sudo systemctl enable hostapd
sudo systemctl start hostapd

sudo reboot

This what network interface

pi@accesspoint:~ $ ifconfig
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.24.11.15  netmask 255.255.255.0  broadcast 10.24.11.255
        inet6 fe80::4152:f5f5:5bee:6082  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:8e:38:ee  txqueuelen 1000  (Ethernet)
        RX packets 92  bytes 10655 (10.4 KiB)
        RX errors 0  dropped 3  overruns 0  frame 0
        TX packets 75  bytes 10841 (10.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether b8:27:eb:db:6d:bb  txqueuelen 1000  (Ethernet)
        RX packets 64  bytes 8284 (8.0 KiB)
        RX errors 0  dropped 1  overruns 0  frame 0
        TX packets 102  bytes 14518 (14.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether b8:27:eb:8e:38:ee  txqueuelen 1000  (Ethernet)
        RX packets 29  bytes 3519 (3.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 38  bytes 6341 (6.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

After doing above steps I cant ssh directly to accesspoint, I have to connect to WiFi Access point (MyWiFi)created on Raspberry pi first and then ssh to Raspberry pi IP. Is there any way to avoid this ?

OpenVPN Client Installation :

sudo apt-get install openvpn -y

sudo cp /etc/openvpn/client1.ovpn /etc/openvpn/client.conf

sudo systemctl start openvpn@client

pi@accesspoint:~ $ ifconfig
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.24.11.15  netmask 255.255.255.0  broadcast 10.24.11.255
        inet6 fe80::4152:f5f5:5bee:6082  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:8e:38:ee  txqueuelen 1000  (Ethernet)
        RX packets 2355  bytes 1999824 (1.9 MiB)
        RX errors 0  dropped 108  overruns 0  frame 0
        TX packets 894  bytes 108321 (105.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether b8:27:eb:db:6d:bb  txqueuelen 1000  (Ethernet)
        RX packets 4094  bytes 2863772 (2.7 MiB)
        RX errors 0  dropped 18  overruns 0  frame 0
        TX packets 3289  bytes 660002 (644.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 16  bytes 1631 (1.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 16  bytes 1631 (1.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.8.0.2  netmask 255.255.255.0  destination 10.8.0.2
        inet6 fe80::48dd:8f8b:8dcd:a059  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)
        RX packets 1  bytes 76 (76.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 95  bytes 5492 (5.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether b8:27:eb:8e:38:ee  txqueuelen 1000  (Ethernet)
        RX packets 2600  bytes 546612 (533.8 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2446  bytes 1014039 (990.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


pi@accesspoint:~ $ sudo ip route
0.0.0.0/1 via 10.8.0.1 dev tun0
default via 10.24.11.1 dev br0 src 10.24.11.15 metric 204
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.2
10.24.11.0/24 dev br0 proto kernel scope link src 10.24.11.15 metric 204
35.166.225.161 via 10.24.11.1 dev br0
128.0.0.0/1 via 10.8.0.1 dev tun0

pi@accesspoint:~ $ sudo route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.8.0.1        128.0.0.0       UG    0      0        0 tun0
0.0.0.0         10.24.11.1      0.0.0.0         UG    204    0        0 br0
10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0
10.24.11.0      0.0.0.0         255.255.255.0   U     204    0        0 br0
35.166.225.161  10.24.11.1      255.255.255.255 UGH   0      0        0 br0
128.0.0.0       10.8.0.1        128.0.0.0       UG    0      0        0 tun0

10.24.11.0/24 Local Ethernet Network

10.2.0.0/16 is VPC network

10.2.2.101 IP of OpenVPN server Private IP

10.8.0.2 is VPN IP for accesspoint and 10.8.0.1 is VPN IP for OpenVPN server openvpn

Connectivity :

pi@accesspoint:~ $ ping 10.2.2.101
PING 10.2.2.101 (10.2.2.101) 56(84) bytes of data.
64 bytes from 10.2.2.101: icmp_seq=1 ttl=64 time=81.2 ms

pi@accesspoint:~ $ ping 10.2.1.145
PING 10.2.1.145 (10.2.1.145) 56(84) bytes of data.
64 bytes from 10.2.1.145: icmp_seq=1 ttl=63 time=80.5 ms

pi@accesspoint:~ $ ping 10.8.0.1
PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.
64 bytes from 10.8.0.1: icmp_seq=1 ttl=64 time=80.1 ms

pi@accesspoint:~ $ ping 10.8.0.2
PING 10.8.0.2 (10.8.0.2) 56(84) bytes of data.
64 bytes from 10.8.0.2: icmp_seq=1 ttl=64 time=0.171 ms

sudo iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

pi@accesspoint:~ $ ping -I 10.8.0.2 10.2.1.145
PING 10.2.1.145 (10.2.1.145) from 10.8.0.2 : 56(84) bytes of data.
64 bytes from 10.2.1.145: icmp_seq=1 ttl=63 time=80.9 ms

pi@accesspoint:~ $ ping -I 10.24.11.15 10.2.1.145
(0 received, 100% packet loss)

Added Route :

pi@accesspoint:~ $ sudo iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
pi@accesspoint:~ $ sudo sudo iptables -A FORWARD -i tun0 -o br0 -j ACCEPT
pi@accesspoint:~ $ sudo iptables -A FORWARD -i br0 -o tun0 -j ACCEPT

pi@accesspoint:~ $ ping 10.2.1.145
PING 10.2.1.145 (10.2.1.145) 56(84) bytes of data.
64 bytes from 10.2.1.145: icmp_seq=1 ttl=63 time=82.5 ms

pi@accesspoint:~ $ ping -I 10.24.11.15 10.2.1.145
PING 10.2.1.145 (10.2.1.145) from 10.24.11.15 : 56(84) bytes of data.
64 bytes from 10.2.1.145: icmp_seq=1 ttl=63 time=82.5 ms

pi@accesspoint:~ $ sudo ip route get 10.2.1.145 from 10.8.0.2 iif br0
RTNETLINK answers: Invalid argument

pi@accesspoint:~ $ sudo ip route get 10.2.1.145 from 10.8.0.2 iif tun0
RTNETLINK answers: Invalid argument

pi@accesspoint:~ $ sudo ip route get 10.2.1.145 from 10.24.11.15 iif br0
RTNETLINK answers: Invalid argument

pi@accesspoint:~ $ sudo ip route get 10.2.1.145 from 10.24.11.15 iif tun0
RTNETLINK answers: Invalid argument

pi@accesspoint:~ $ sudo ip netconf show dev tun0
ipv4 dev tun0 forwarding on rp_filter off mc_forwarding off proxy_neigh off ignore_routes_with_linkdown off

pi@accesspoint:~ $ sudo ip netconf show dev br0
ipv4 dev br0 forwarding on rp_filter off mc_forwarding off proxy_neigh off ignore_routes_with_linkdown off

I setup another Raspberry Pi (client) and connected to WiFi access point (MyWiFi) I created in above steps.

pi@client:~ $ ifconfig
eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
    ether b8:27:eb:d2:02:8c  txqueuelen 1000  (Ethernet)
    RX packets 0  bytes 0 (0.0 B)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 0  bytes 0 (0.0 B)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
    inet 127.0.0.1  netmask 255.0.0.0
    inet6 ::1  prefixlen 128  scopeid 0x10<host>
    loop  txqueuelen 1000  (Local Loopback)
    RX packets 73  bytes 6692 (6.5 KiB)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 73  bytes 6692 (6.5 KiB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
    inet 10.24.11.201  netmask 255.255.255.0  broadcast 10.24.11.255
    inet6 fe80::561a:a6ae:7d08:1470  prefixlen 64  scopeid 0x20<link>
    ether b8:27:eb:87:57:d9  txqueuelen 1000  (Ethernet)
    RX packets 7277  bytes 792141 (773.5 KiB)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 28592  bytes 3117200 (2.9 MiB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

pi@client:~ $ sudo ip route
default via 10.24.11.1 dev wlan0 src 10.24.11.201 metric 303
10.24.11.0/24 dev wlan0 proto kernel scope link src 10.24.11.201 metric 303

pi@client:~ $ sudo route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.24.11.1      0.0.0.0         UG    303    0        0 wlan0
10.24.11.0      0.0.0.0         255.255.255.0   U     303    0        0 wlan0

Connectivity from client :

pi@client:~ $ ping 10.24.11.15
PING 10.24.11.15 (10.24.11.15) 56(84) bytes of data.
64 bytes from 10.24.11.15: icmp_seq=1 ttl=64 time=2.31 ms

pi@client:~ $ ping 10.2.1.145
PING 10.2.1.145 (10.2.1.145) 56(84) bytes of data
(0 received, 100% packet loss)

pi@client:~ $ ping 10.8.0.2
PING 10.8.0.2 (10.8.0.2) 56(84) bytes of data.
(0 received, 100% packet loss)

Adding Routes on accesspoint :

pi@accesspoint:~ $ sudo ip route add 10.2.0.0/16 via 10.8.0.2 dev tun0 proto static

pi@accesspoint:~ $ sudo ip route
0.0.0.0/1 via 10.8.0.1 dev tun0
default via 10.24.11.1 dev br0 src 10.24.11.15 metric 204
10.2.0.0/16 via 10.8.0.2 dev tun0 proto static
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.2
10.24.11.0/24 dev br0 proto kernel scope link src 10.24.11.15 metric 204
35.166.225.161 via 10.24.11.1 dev br0
128.0.0.0/1 via 10.8.0.1 dev tun0

pi@accesspoint:~ $ sudo route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.8.0.1        128.0.0.0       UG    0      0        0 tun0
0.0.0.0         10.24.11.1      0.0.0.0         UG    204    0        0 br0
10.2.0.0        10.8.0.2        255.255.0.0     UG    0      0        0 tun0
10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0
10.24.11.0      0.0.0.0         255.255.255.0   U     204    0        0 br0
35.166.225.161  10.24.11.1      255.255.255.255 UGH   0      0        0 br0
128.0.0.0       10.8.0.1        128.0.0.0       UG    0      0        0 tun0

Adding Routes on openvpn server in AWS VPC :

ubuntu@openvpn:~$ sudo route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.2.2.1        0.0.0.0         UG    100    0        0 ens5
10.2.2.0        0.0.0.0         255.255.255.0   U     0      0        0 ens5
10.2.2.1        0.0.0.0         255.255.255.255 UH    100    0        0 ens5
10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0

ubuntu@openvpn:~$ sudo ip route add 10.24.11.0/24 via 10.8.0.1 dev tun0 proto static

ubuntu@openvpn:~$ sudo route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.2.2.1        0.0.0.0         UG    100    0        0 ens5
10.2.2.0        0.0.0.0         255.255.255.0   U     0      0        0 ens5
10.2.2.1        0.0.0.0         255.255.255.255 UH    100    0        0 ens5
10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0
10.24.11.0      10.8.0.1        255.255.255.0   UG    0      0        0 tun0

Connectivity from OpenVPN Server to accesspoint :

ubuntu@openvpn:~$ ping 10.8.0.2
PING 10.8.0.2 (10.8.0.2) 56(84) bytes of data.
64 bytes from 10.8.0.2: icmp_seq=1 ttl=64 time=80.0 ms

ubuntu@openvpn:~$ ping 10.24.11.15
PING 10.24.11.15 (10.24.11.15) 56(84) bytes of data.
(0 received, 100% packet loss)

Connectivity for client (following command were running simultaneously) :

pi@client:~ $ ping 10.8.0.2
PING 10.8.0.2 (10.8.0.2) 56(84) bytes of data.
^C
--- 10.8.0.2 ping statistics ---
12 packets transmitted, 0 received, 100% packet loss, time 11416ms

pi@accesspoint:~ $ sudo tcpdump -ni br0 'icmp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:22:23.054146 IP 10.24.11.201 > 10.8.0.2: ICMP echo request, id 2619, seq 1, length 64
11:22:24.084698 IP 10.24.11.201 > 10.8.0.2: ICMP echo request, id 2619, seq 2, length 64
11:22:25.126055 IP 10.24.11.201 > 10.8.0.2: ICMP echo request, id 2619, seq 3, length 64

pi@accesspoint:~ $ sudo tcpdump -ni tun0 'icmp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
^C
(0 packets captured)

And (following command were running simultaneously)

pi@client:~ $ ping 10.2.1.145
PING 10.2.1.145 (10.2.1.145) 56(84) bytes of data.
^C
--- 10.2.1.145 ping statistics ---
17 packets transmitted, 0 received, 100% packet loss, time 16644ms

pi@accesspoint:~ $ sudo tcpdump -ni br0 'icmp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:24:27.609493 IP 10.24.11.201 > 10.2.1.145: ICMP echo request, id 3222, seq 5, length 64
11:24:28.644693 IP 10.24.11.201 > 10.2.1.145: ICMP echo request, id 3222, seq 6, length 64

pi@accesspoint:~ $ sudo tcpdump -ni tun0 'icmp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

I tried to re-do entire set-up in a clean way.

I can't ping AWS VPC IP's from client which is connected to access point MyWiFi, all connectivity works from accesspoint node.

          (Office Network) 10.24.11.1/24                    (AWS VPC) 10.2.0.0/16
+--------------------------------------------+       +----------------------------------+
|                                            |       |                                  |
|                 OpenVPN Client (Pi)        |       |       OpenVPN Server (Ubuntu)    |
|                                            |       |                                  |
|             +--------------------------+   |       |  +--------------------------+    |
|             |                          |   |       |  |                          |    |
|       eth0  |                          |   |tun0   |  |                          |    |
|      <--+-->|                  10.8.0.2|<--|--+----|->|10.8.0.1       10.2.2.101 |ens5|
|             |                          |   |       |  |                          |    |
|         br0 |10.24.11.15               |   |       |  |                          |    |
|             |                          |   |       |  |                          |    |
|             |       wlan0              |   |       |  |                          |    |
|             +--------------------------+   |       |  +--------------------------+    |
|                       ^                    |       |                                  |
|                       |                    |       |                                  |
|     WiFi Client       |                    |       |                                  |
| +------------------+  |                    |       |                  +----------+    |
| |wlan0:10.24.11.201|  |                    |       |                  | Host 1   |    |
| |                  |--+                    |       |                  |          |    |
| +------------------+                       |       |                  |10.2.1.145|    |
+--------------------------------------------+       |                  +----------+    |
                                                     +----------------------------------+

OpenVPN Server route :

ubuntu@openvpn:~$ ip route
default via 10.2.2.1 dev ens5 proto dhcp src 10.2.2.101 metric 100
10.2.2.0/24 dev ens5 proto kernel scope link src 10.2.2.101
10.2.2.1 dev ens5 proto dhcp scope link src 10.2.2.101 metric 100
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1
10.24.11.0/24 via 10.8.0.2 dev tun0 proto static src 10.8.0.1

OpenVPN Client route :

pi@accesspoint:~ $ ip route
default via 10.24.11.1 dev br0 src 10.24.11.15 metric 203
10.2.0.0/16 via 10.8.0.1 dev tun0 proto static src 10.8.0.2
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.2
10.24.11.0/24 dev br0 proto kernel scope link src 10.24.11.15 metric 203
35.176.225.61 via 10.24.11.1 dev br0

WiFi Client route :

pi@client:~ $ ip route
default via 10.24.11.1 dev wlan0 src 10.24.11.201 metric 303
10.2.0.0/16 via 10.24.11.15 dev wlan0 proto static
10.24.11.0/24 dev wlan0 proto kernel scope link src 10.24.11.201 metric 303

Where is the other side of the ethernet cable connected to? Where ended the other side of the VPN tunnel? Is the other side a VPN server or VPN client? — Ingo, Apr 26 '19 at 18:26
Thanks for giving the routing table with `ip route`. It's better readable for me... — Ingo, May 02 '19 at 00:03

Ingo · Accepted Answer · 2019-08-06T21:49:14.567

I don't know something about AWS VPC. But because it seems to be only a routing problem I will use openVPN for reference. For routing it should not be make a big difference. I will try to be as generic as possible.

An issue is that it isn't possible to add a tun interface to a linux bridge. That's exactly what the error message tells you. On openVPN there are specific tap interfaces which are defined for bridge mode. Because you try to use a tun interface and shows the routing table I assume you want to use routing mode.

With this assumptions I see this example:

                           10.8.0.2/24                       ┌──────────┐            10.8.0.1/24
                              /            vpn tunnel        │          │                  \
                          (tun0) ═══════════════════════════════════════════════════════════╗
          wifi   ┌──bridge(br0)───┐   wired            wan   │          │            VPN  (tun0)                 remote
station <.~.~.~> │(wlan0)RPi(eth0)│ <───────> router <─────> │ INTERNET │ <───> (if)Server(eth0) <─────────────> client
       \                 |                   / DHCP-server   │          │       /              \                 /
      (dhcp        br0=10.24.11.15     10.24.11.1/24         └──────────┘  35.166.225.161   10.2.2.101/16   10.2.1.145/16
   from router)

As far as I understand you can:

rpi ~$ ping -I 10.24.11.15 35.166.225.161   # success
rpi ~$ ping -I 10.2.0.2 10.2.0.1            # success
station ~$ ping 10.24.11.15                # success

station ~$ ping 10.2.0.1                    # FAIL

On the RasPi to get packets routed from wlan0 to tun0 there must be ip_forward enabled. Do it by uncommenting #net.ipv4.ip_forward=1 in /etc/sysctl.conf and reboot. Check if it is set with:

rpi ~$ cat /proc/sys/net/ipv4/ip_forward
1
rpi ~$

First I set up an access point with a bridge ⁽¹⁾ and then installed a simple openVPN tunnel ⁽²⁾ so that the installation looks like as shown in the drawing above.

I don't know for what all the routes needed you show but for my setup I have this routing table:

rpi ~$ ip route
default via 10.24.11.1 dev br0 proto dhcp src 10.24.11.15 metric 1024
10.2.0.0/16 via 10.8.0.1 dev tun0 proto static src 10.8.0.2 metric 1024
10.8.0.1 dev tun0 proto kernel scope link src 10.8.0.2
10.24.11.0/24 dev br0 proto kernel scope link src 10.24.11.15
10.24.11.1 dev br0 proto dhcp scope link src 10.24.11.15 metric 1024

Here we have all we need. There is no additional setup necessary.

Because we have a bridge, all devices are on the same broadcast domain (subnet) 10.24.11.0/24. Also the RasPi with interface br0 is a normal member of this subnet. There is no direct connection between the bridge and br0. This implies that the RasPi on ip level is seen anywhere on the subnet. So any station that would like to connect to the vpn remote device must have a route to it via the RasPi. Only it knows how to send packets to the vpn remote device:

station ~$ sudo ip route add 10.2.0.0/16 via 10.24.11.15 dev wlan0 proto static

The routing table on a station will then look like this:

station ~$ ip route
default via 10.24.11.1 dev wlan0 proto dhcp src 10.24.11.201 metric 1024
10.2.0.0/16 via 10.24.11.15 dev wlan0 proto static
10.24.11.0/24 dev wlan0 proto kernel scope link src 10.24.11.201
10.24.11.1 dev wlan0 proto dhcp scope link src 10.24.11.201 metric 1024

Here we see that the RasPi is addressed with its ip address 10.24.11.15. That's a dynamic ip address from a DHCP server but for routing it must be a static one, otherwise routing will break on next change of the ip address. Possible workarounds I will discuss later.

We also have to set a route on the vpn-remote device. It will get ip packets from subnet 10.24.11.0/24 but it does not know where it is and how to send responses. So we have to tell it with a route:

vpn-remote ~$ sudo ip route add 10.24.11.0/24 via 10.8.0.2 dev tun0 proto static

The routing table on vpn-remote will then look like this:

vpn-remote ~$ ip route
default via 10.2.2.101 dev eth0 proto dhcp src 10.2.1.145 metric 1024
10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1
10.2.0.0/16 dev eth0 proto kernel scope link src 10.2.1.145
10.2.2.101 dev eth0 proto dhcp scope link src 10.2.1.145 metric 1024
10.24.11.0/24 via 10.8.0.2 dev tun0 proto static

If you do not have access to vpn-remote I will discuss the workaround later.

Now everything is working as expected. It shows the principle and it should be possible for you to "translate" it to your environment.

Workaround for the vpn-remote device
If you do not have access to vpn-remote to set a route then we can classical fake it with a NAT so it means all packets are coming only from 10.8.0.2, that it knows.

rpi ~$ sudo iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Workaround for the ip address of the RasPi
Anyway, the most simple way is to give br0 a static ip address if possible.

If it's not possible to set a static ip address then I would prefer to make the RasPi a clean router without a bridge. Then you have all possibilities of routing because packets pass the RasPi on ip level (transport layer). You can use sophisticated policy routing and/or NAT if necessary. You can also setup a DHCP server for the access point and give the routes to the stations with it, so you don't have to set them on every station manual.

Another possibility is to use the DNS name instead of the dynamic ip address in the routing rule. But for this you must have a stable dynamic DNS name resolution working.

A vague idea is to use ebtables to filter ethernet packets on the bridge but I haven't done it before and I don't know if a solution is possible with it.

References:
(1) Setting up a Raspberry Pi as an access point - the easy way
(2) Simple openVPN with static keys

@roy Yes and I'm quite sure the problem is the station. But let me give a complete answer. Does the ASCII art shows the correct setup? — Ingo, May 01 '19 at 23:28
@roy With your update I have corrected the ip addresses of the endpoints from the vpn tunnel and the public ip address in the drawing. Does it fit? — Ingo, May 02 '19 at 00:07
Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/93162/discussion-between-roy-and-ingo). — roy, May 02 '19 at 21:11
I am not able to ping 10.24.11.0/24 from VPN server. I do have `10.24.11.0/24 via 10.8.0.2 dev tun0 proto static src 10.8.0.1` in route table. Any idea ? — roy, Aug 02 '19 at 14:30
@roy 10.24.11.0/24 is the address of the subnet and represents the ip address range 10.24.11.1 to 10.24.11.255. It is not a single ip address of any device. You will never get a ping reply from it. — Ingo, Aug 02 '19 at 17:03
@roy Sorry, just seeing that the text does not reflect the drawing because we have heavily changed it in the chat so it may not work. I will update it. Just a moment please. — Ingo, Aug 02 '19 at 17:30
@roy You tried to ping `10.24.11.15` & `10.24.11.201`. From where do you tried? — Ingo, Aug 06 '19 at 21:52
@roy The OpenVPN server has ip address 10.2.2.101, isn't it? Can you ping 10.8.0.2? — Ingo, Aug 08 '19 at 22:28
@roy We have to check with `ip route` on OpenVPN(10.2.2.101) and on RPi(10.24.11.15). — Ingo, Aug 08 '19 at 22:48
@roy Routing tables are looking good as far as I can see with one exception: on OpenVPN Server a route looks like `10.2.2.0/24 dev ens5 proto kernel scope link src 10.2.2.101` but must be `10.2.0.0/16 dev ens5 proto kernel scope link src 10.2.2.101`. Check if ip forwarding is set on OpenVPN Client with: `cat /proc/sys/net/ipv4/ip_forward`, must have 1. — Ingo, Aug 09 '19 at 23:58
`ip_forward` is enabled on OpenVPN Client & Server. Do I need to update route for `10.2.0.0/16` network ? — roy, Aug 12 '19 at 13:14
@roy Yes, you should update the route because 10.2.2.0/24 only covers a small part of the subnet 10.2.0.0./16. — Ingo, Aug 12 '19 at 23:38

score 0 · Answer 2 · answered May 01 '19 at 21:32

I've just read through both of the articles you linked, on doing so I can see that they are operating from wired connection to Wi-Fi connection.

They are designed to set you up with a device that you plug an Ethernet cable into between the public and a device that only has an Ethernet port available. The rPI then connects to the Wi-Fi and provides an internet connection to the wired device.

From your description it appears to me, that your expecting things to work the opposite way, in that you connect to the Wi-Fi on the rPI and traffic is then sent to the network via the Ethernet connection.

If this is indeed the case then you need a tutorial that sets things up to work the opposite to what you have them, and the tutorial you are using is not an appropriate solution for what your trying to do.

If I'm mistaken about what it is you appear to be attempting, then you need to provide more details, such as which interfaces you expect to connect to where, and from which devices.

Raspberry Pi as OpenVPN Access Point

2 Answers2

Linked