Part Four: my Raspberry Pi OpenVPN server
Overview
The concept here is to forward VPN traffic received on the public interface of the Internet router (via incoming TCP port 1194) to the OpenVPN server's interface. The VPN server authenticates the connection, and regulates forwarding traffic to and from various destinations on your private network, based on a defined set of rules. This could include forwarding traffic to your desktop to enable a remote sharing via VNC, RDP, SSH, or other protocol.
Raspberry Pi Configuration
I decided to remove several non-essential packages - specifically the GUI environments - from the newly installed Pidora distribution so as to reduce the server’s attack footprint, and free up resources.
After the operating system was installed, I prepared the system for OpenVPN.
I removed many of the unnecessary packages.
yum groupremove @gnome-desktop @kde-desktop @xfce-desktop @lxde-desktop @cinnamon-desktop @mate-desktop @sugar-desktop @developer-workstation @web-server @basic-x-window @editors @electronic-lab @milkymist @office @sound-and-video @text-internet @admin-tools @system-tools @network-server -yI installed NetworkManager, openvpn, and ntp for time synchronization.
yum install NetworkManager ntp openvpn -yI ran yum to ensure that all of my packages were up-to-date and patched.
yum update -yI enabled IP packet forwarding, so that traffic could be routed from my external clients to the desired hosts via my OpenVPN server.
Edited the file: /etc/sysctl.conf and set the net.ipv4.ip_forward parameter to a value of 1. (net.ipv4.ip_forward = 1)
Triggered sysctl to read the updated file.
sysctl -p /etc/sysctl.conf
OpenVPN Installation and Configuration
- Copied the relevant files from my PKI to the OpenVPN server (see part two in this series on generating a PKI), to the /etc/openvpn/pki/ directory.
- ca.crt (trusted root certificate authority certificate)
- MyOpenVPNServer.crt (server certificate)
- MyOpenVPNServer.key (server private key)
- dh.pem (Diffie-Hellman parameters)
Removed the passphrase from my private key, so that OpenVPN could start up automatically at boot time.
openssl rsa -in /etc/openvpn/pki/MyOpenVPNServer.key -out /etc/openvpn/pki/MyOpenVPNServer.key
Created my server configuration: (/etc/openvpn/server.conf)
# local IP address, port, and protocol for OpenVPN server to listen on and use local 192.168.2.230 port 1194 proto tcp # dev tun is used to created a routed VPN dev tun # my PKI files ca /etc/openvpn/pki/ca.crt cert /etc/openvpn/pki/MyOpenVPNServer.crt key /etc/openvpn/pki/MyOpenVPNServer.key # This file should be kept secret dh /etc/openvpn/pki/dh.pem # server mode server 10.8.0.0 255.255.255.0 ifconfig-pool-persist ipp.txt # optional routes to push to clients push route 192.168.2.0 255.255.255.0 keepalive 10 120 cipher AES-128-CBC # AES comp-lzo # following options enabled for non-Windows servers user nobody group nobody persist-key persist-tun status openvpn-status.log verb 3
In this configuration, my OpenVPN server has an IP address on my local subnet of 192.168.2.230, and will be listening on port 1194 for incoming TCP connections. I am using a routed (non-bridged) VPN, so I needed to ensure that the proper routes were in place, not only on my client, but also on any servers that my client wants to talk to.
When a client connects to my VPN, it receives an IP address on the 10.8.0.0/24 subnet, and the OpenVPN server presents itself as 10.8.0.1. My client does not know how to reach my local subnet (192.168.2.0), therefore I pushed the following routing configuration to my client, so it knew how to handle traffic appropriately:
push route 192.168.2.0 255.255.255.0Basically, this tells my VPN clients that traffic on the 192.168.2.0/24 subnet should be routed through the OpenVPN server; however, the devices on my local subnet know nothing about how to send traffic back to my VPN clients. Therefore, to make ensure that my hosts could route traffic back to the OpenVPN clients, I added a static route on the hosts.
For example, let’s say that my Mac has an IP address of 192.168.2.200 (local subnet), and that my VPN client receives an IP address of 10.8.0.6 (VPN subnet). My VPN knows to route traffic to my Mac, because of the push route command above; however, my Mac does not know how to properly route traffic back.
Using the terminal on my Mac, I ran the following command:
sudo route -n add 10.8.0.0/24 192.168.2.230
This tells my Mac, to route traffic destined for the VPN subnet, to the OpenVPN server (192.168.2.230). More information about creating a static route that will persist through reboots, can be found on the following blog.
Started the openvpn and ntp service, and enabled them to start at boot time.
systemctl start openvpn@server.service systemctl start ntpd systemctl enable openvpn@server.service systemctl enable ntpd systemctl status openvpn@server.service systemctl status ntpd
- Lastly, I configured port-forwarding on my Internet router, to redirect TCP traffic (port 1194) from my public interface, to my OpenVPN server.
That’s about it for now. At this point, I have an OpenVPN server running on my Raspberry Pi, and it’s ready to accept client connections.
Keep on virtualizing!
the DIY home VPN experiment series:
- Introduction.
- Generating a PKI (Public Key Infrastructure) for my OpenVPN.
- My Virtualized OpenVPN Server.
- Deploying OpenVPN using CentOS on a Raspberry Pi.
If you like this article, please share it with others.
No comments:
Post a Comment