OpenVPN/Static Key
From charlesreid1
Contents
Static Key VPN
This is the simplest setup for a VPN configuration for small numbers of users and point-to-point VPN. There are more scalable options for larger OpenVPN networks.
On The Server
Create OpenVPN Server Key
First, generate a key on the OpenVPN server:
$ openvpn --genkey --secret static.key
Now copy that VPN file over a secure medium onto the computer you'll use as the OpenVPN client.
Server Config File
Create a server config file:
$ cat server.ovpn dev tun ifconfig 10.8.0.1 10.8.0.2 secret static.key
This server file creates a device called tun (or tun0, or tun1, etc)
It sets up an IP address of 10.8.0.1, with a peer-to-peer IP address of 10.8.0.2 (that'll be our single client).
Finally, we point it to our static key.
Server Firewall Script
The server firewall script looks like the following:
# Flush iptables -F # allow SSH/HTTP/HTTPS iptables -A INPUT -p tcp --dport 22 -j ACCEPT iptables -A OUTPUT -p tcp --dport 22 -j ACCEPT iptables -A INPUT -p tcp --dport 80 -j ACCEPT iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT iptables -A INPUT -p tcp --dport 443 -j ACCEPT iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT # Set default policies for INPUT, FORWARD and OUTPUT chains iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT # Set access for localhost iptables -A INPUT -i lo -j ACCEPT # Accept packets belonging to established and related connections iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # Allow connections on 1198 for open vpn iptables -A INPUT -p udp --dport 1198 -j ACCEPT iptables -A OUTPUT -p udp --dport 1198 -j ACCEPT # OpenVPN # this line is important! iptables -A INPUT -i eth0 -m state --state NEW -p udp --dport 1194 -j ACCEPT # Allow TUN interface connections to OpenVPN server iptables -A INPUT -i tun+ -j ACCEPT # Allow TUN interface connections to be forwarded through other interfaces iptables -A FORWARD -i tun+ -j ACCEPT iptables -A FORWARD -i tun+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -i eth0 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT # NAT the VPN client traffic to the internet iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE # all out is ok iptables -A OUTPUT -o tun+ -j ACCEPT
The NAT rules allow traffic to get to the larger internet; the iptables rule came from here: https://openvpn.net/index.php/open-source/documentation/howto.html#redirect
(Plus more info here: https://community.openvpn.net/openvpn/wiki/NatHack - it basically means, rewrite any VPN traffic to the OpenVPN server so that it looks like it natively came from the OpenVPN server.)
Then restart the networking service on the OpenVPN server machine:
$ sudo service networking restart
Forward Packets on Server
Make sure you are forwarding packets:
$ echo "1" > /proc/sys/net/ipv4/ip_forward
This will ensure that any packet that the network interface receives is forwarded (specifically, forwarded to our tunnel device).
Start OpenVPN Server
Now start the OpenVPN server daemon on the OpenVPN server:
$ openvpn --config server.conf --daemon
Final Script
$ cat server.sh #!/bin/bash # # ########################## # # Run an OpenVPN server # at charlesreid1.com # # UDP port 1194 # # # ----------------------- # ip forwarding echo "forwarding packets" echo "1" > /proc/sys/net/ipv4/ip_forward # ----------------------- # Start the OpenVPN server echo "starting openvpn server" killall openvpn openvpn --config rojo_server.ovpn # ----------------------- # Firewall rules echo "setting firewall rules" # Flush iptables -F # ------------- # BEGIN # My Firewall Settings # allow SSH/HTTP/HTTPS iptables -A INPUT -p tcp --dport 22 -j ACCEPT iptables -A OUTPUT -p tcp --dport 22 -j ACCEPT iptables -A INPUT -p tcp --dport 80 -j ACCEPT iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT iptables -A INPUT -p tcp --dport 443 -j ACCEPT iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT # Set default policies for INPUT, FORWARD and OUTPUT chains iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT # Set access for localhost iptables -A INPUT -i lo -j ACCEPT # Accept packets belonging to established and related connections iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # Allow connections on 1198 for open vpn iptables -A INPUT -p udp --dport 1198 -j ACCEPT iptables -A OUTPUT -p udp --dport 1198 -j ACCEPT # OpenVPN # this line is important! iptables -A INPUT -i eth0 -m state --state NEW -p udp --dport 1194 -j ACCEPT # Allow TUN interface connections to OpenVPN server iptables -A INPUT -i tun+ -j ACCEPT # Allow TUN interface connections to be forwarded through other interfaces iptables -A FORWARD -i tun+ -j ACCEPT iptables -A FORWARD -i tun+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -i eth0 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT # NAT the VPN client traffic to the internet iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE # all out is ok iptables -A OUTPUT -o tun+ -j ACCEPT echo "done" # ---------------------------- # Reload the firewall rules echo "restart networking services" service networking restart
Client
Client Config File
On the client, create your client config file:
$ cat client.ovpn remote <IP OF OPENVPN SERVER GOES HERE> dev tun ifconfig 10.8.0.2 10.8.0.1 secret rojo_static.key redirect-gateway def1 dhcp-option DNS 10.8.0.1
Here we're specifying the location of our OpenVPN server with the IP address
Then we're specifying a tunnel device with dev tun
Then an IP of 10.8.0.2 with a peer-to-peer connection at 10.8.0.1 with ifconfig
Then the static server key,
then redirect-gatway def1 which replaces the gateway router on our machine, so that all traffic, including DNS, will go through our VPN connection.
Client Firewall Script
The following are the firewall tables used by OpenVPN, broken down to explain them:
Flush the existing rules in the ip tables:
# -------------------------- # Firewall rules iptables -F
Now set default policies for types of packets:
iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT
Accept packets belonging to accepted connections:
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Respond to pings (that's what the 8 means):
iptables -A INPUT -p icmp --icmp-type 8 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -p icmp --icmp-type 0 -m state --state ESTABLISHED,RELATED -j ACCEPT
Open port 1194 for OpenVPN:
iptables -A INPUT -p udp --dport 1194 -j ACCEPT iptables -A OUTPUT -p udp --dport 1194 -j ACCEPT
All outbound packets are OK:
iptables -A OUTPUT -o tun+ -j ACCEPT
Now print the rules:
iptables -L -v
See https://forums.openvpn.net/topic7722.html for other info.
Client Connect
Now we've got the firewall open on the server, and open on the client. We've got the OpenVPN daemon running on the server, and all that's left is the client. Let's connect:
$ openvpn --config client.ovpn
Final Client Script
$ cat server.sh #!/bin/bash # # ########################## # # Run an OpenVPN server # at charlesreid1.com # # UDP port 1194 # # # ----------------------- # ip forwarding echo "forwarding packets" echo "1" > /proc/sys/net/ipv4/ip_forward # ----------------------- # Start the OpenVPN server echo "starting openvpn server" killall openvpn openvpn --config rojo_server.ovpn # ----------------------- # Firewall rules echo "setting firewall rules" # Flush iptables -F # ------------- # BEGIN # My Firewall Settings # allow SSH/HTTP/HTTPS iptables -A INPUT -p tcp --dport 22 -j ACCEPT iptables -A OUTPUT -p tcp --dport 22 -j ACCEPT iptables -A INPUT -p tcp --dport 80 -j ACCEPT iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT iptables -A INPUT -p tcp --dport 443 -j ACCEPT iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT # Set default policies for INPUT, FORWARD and OUTPUT chains iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT # Set access for localhost iptables -A INPUT -i lo -j ACCEPT # Accept packets belonging to established and related connections iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # Allow connections on 1198 for open vpn iptables -A INPUT -p udp --dport 1198 -j ACCEPT iptables -A OUTPUT -p udp --dport 1198 -j ACCEPT # OpenVPN # this line is important! iptables -A INPUT -i eth0 -m state --state NEW -p udp --dport 1194 -j ACCEPT # Allow TUN interface connections to OpenVPN server iptables -A INPUT -i tun+ -j ACCEPT # Allow TUN interface connections to be forwarded through other interfaces iptables -A FORWARD -i tun+ -j ACCEPT iptables -A FORWARD -i tun+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -i eth0 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT # NAT the VPN client traffic to the internet iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE # all out is ok iptables -A OUTPUT -o tun+ -j ACCEPT echo "done" # ---------------------------- # Reload the firewall rules echo "restart networking services" service networking restart
Testing the Static VPN
Wireshark and Ping (Local)
You can test to make sure that 10.8.0.1 and 10.8.0.2 can see each other on the virtual private network by pinging one from the other.
For example, from the client (10.8.0.2), we can run ping, and specify that ping should use our tunnel device:
$ ping -I tun0 10.8.0.1
Now open wireshark and begin a packet capture on the same tun0 interface. You should see the ping and response packets from Wireshark:
Wireshark and Ping (Remote)
Now you can test all of those firewall rules we set for the OpenVPN server, that set rules for forwarding packets from the tunnel to the ethernet and to the internet at large:
$ ping -I tun0 wikipedia.org
Make sure you can see the ping and response in Wireshark:
This ping and response is happening over the OpenVPN tunnel we created, and that tunnel traffic is then being forwarded to the OpenVPN server's network device.
Wireshark and Browser
Now test out that the redirect-gatway directive in our config file is actually redirecting traffic as expected. Here, we visit Yahoo.com from the OpenVPN client, and check out the packet capture of the tunnel device while we do that. We should see all of our traffic passing through the OpenVPN tunnel:
Further up there were several DNS packets for yahoo.com, and we can see all of the packet traffic from Yahoo to the OpenVPN client for loading the page.
Wireshark and SSH
One more test, just to make sure that the redirect-gateway directive really redirects ALL traffic, and not just SOME traffic. Let's SSH to a remote machine, and verify that we can do that. From the OpenVPN client, we run Wireshark. We should see SSH traffic:
Sure enough, there it is! Hooray!
OpenVPN and WhatIsMyIP.com
I spent a long time trying to diagnose why, every time I used Google or WhatIsMyIp or a similar service to check my IP address from the OpenVPN client, it would always give the native IP address of the OpenVPN client, instead of the OpenVPN server's IP address (indicating that for some reason, the traffic to that site was passing through the regular network connection, which should not be allowed by the redirect-gateway directive.)
I could see my virtual IP, 10.8.0.2. I could also see a native IP, for my ethernet connection (which is how I'm connected to the OopenVPN server). My browser was using the VPN tunnel, because when I was browsing the web I would see corresponding HTTP traffic passing through the tun0 tunnel device, and encrypted TCP data passing through the eth0 device.
So what's going on here?
Turns out, OpenVPN doesn't tunnel your IPv6 traffic by default. Because whatismyip.com is capable of using IPv6, the client connects to whatismyip.com via IPv6, "in the clear" - not through the OpenVPN.
IPv6
OpenVPN does not create a tunnel for IPv6 traffic by default.
I ran a quick test to uncover this fact. First, I visited a few websites while sniffing the tunnel device with Wireshark. I saw some traffic, basically what I excpected. But then I did the same thing while sniffing the ethernet device.
I visited Yahoo.com and saw TCP packets going between my local computer's IPv6 address and some other IPv6 address:
When I did a reverse whois with the IPv6 address, it was the site I was visiting - Yahoo.com.
In other words, traffic was passing directly from my computer to the sites I was visiting, via IPv6. Even though it was encrypted, it was not going through OpenVPN.
Server Solution: Enable IPv6 on OpenVPN
https://community.openvpn.net/openvpn/wiki/IPv6
Confusing.
Not clear whether this works for both IPv4 and IPv6, or just IPv6.
Client Solution 1: Disable IPv6 Temporarily
To temporarily disable IPv6:
$ sysctl -w net.ipv6.conf.all.disable_ipv6=1
To temporarily re-enable IPv6:
$ sysctl -w net.ipv6.conf.all.disable_ipv6=0
Note that you should be wary of using this as a temporary solution - as soon as you forget to do it, your VPN session is as good as useless.
Client Solution 2: Disable IPv6 with Sysctl
You can disable IPv6 temporarily using sysctl.
Edit /etc/sysctl.conf and add:
net.ipv6.conf.all.disable_ipv6 = 1
and remove your loopback IPv6 interface by commenting out this line from /etc/hosts (if relevant):
#::1 localhost.localdomain localhost
You will need to reboot.
Client Solution 3: Disable IPv6 in the Kernel
Edit your boot loader line, to include the flag ipv6.disable=1, by editing /etc/default/grub to include the extra portion:
GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1"
You will need to restart the client machine. Now the client machine will not use IPv6, and all IPv4 traffic is routed through OpenVPN.
More Gotchas
DNS Not Responding
One other problem I ran into was, all my web traffic was loading really, really slowly. When I looked at it with Wireshark, I saw that all my DNS lookups were being denied.
Turns out, the DNS servers that my computer was using were automatically being grabbed from my wireless router, and populated on boot. And those DNS servers were coming from my ISP - Comcast - whose DNS servers are specifically for Comcast customers, and not for random arbitrary people.
Soooo, the good news was, my DNS queries were not coming from my native IP address, but were properly being sent through the VPN tunnel. Yay! The problem was, those DNS queries were being sent to Comcast's DNS servers, from the endpoint of the VPN tunnel, which was not using a Comcast ISP. So the DNS queries failed, because of where they were coming from.
The solution? Change my DNS servers to something different, by changing /etc/resolv.conf
If you want DNS servers controlled by The Goog, a large corporation that CLAIMS they don't keep DNS lookups, but probably do, you can add the following to your resolv.conf file:
nameserver 8.8.8.8 nameserver 8.8.8.4
This is a good "test" DNS server, as it is "always on" and can be used from just about anywhere (but not China).
Wikileaks has a great list of more trustworthy sources of DNS lookups: https://wikileaks.org/wiki/Alternative_DNS
Here's OpenDNS:
nameserver 208.67.222.220 nameserver 208.67.222.222
Testing Again
Once you get OpenVPN working, you can verify it is working.
Fire up Wireshark.
If you monitor the tunnel device tun0 you'll be able to see all of the traffic to and from the OpenVPN server in the clear. This will be either TCP, HTTP, or HTTPS traffic, as well as DNS queries. The tunnel device is being encrypted before it is sent out over the ethernet connection, and is decrypted at the other end.
If you monitor the ethernet device eth0 you'll ONLY see encrypted OpenVPN traffic - UDP traffic on port 1194. Traffic passing through the tunnel, which appears in the clear to us when monitoring the tunnel device, is being encrypted before it is sent out over the ethernet device. By the time the packets get to the ethernet device, they're OpenVPN or TCP packets that are being passed back and forth between two and only two machines: the OpenVPN client and the OpenVPN server. No information about the sites visited, the DNS queries sent, the servers used, etc., can be seen by someone sniffing the ethernet connection.
Wireshark Statistics
You can view the protocols of the packets you've listened to by clicking Statistics > Protocol Hierarchy.
Depending on your port configuration, you'll see different things.
Using a stock OpenVPN configuration, and sniffing the ethernet connection eth0, I see lots of OpenVPN UDP traffic on port 1198:
If you use an OpenVPN server connection on a direct port, like port 80, the traffic will show up in Wireshark slightly differently. Instead of being UDP packet traffic on port 1198, which is easily recognized as OpenVPN traffic, the traffic will actually be TCP packets on port 80. In this case, the Wireshark Protocol Hierarchy report will look slightly different:
Take-Home Message
No matter what, at the end of the day, if your OpenVPN connection is working, you should see something like this: two computers, passing a lot of traffic back and forth, in some kind of encrypted protocol. You can run Wireshark on your own ethernet device while generating some web traffic over the VPN, and run a Protocol Hierarchy analysis, or a Conversation analysis, and all of your web traffic should match the description above: TCP protocol, encrypted, and only traveling between your computer and the OpenVPN server. If you see any DNS queries with websites you're visiting, or if you see IPV6 traffic bypassing the OpenVPN and revealing your native IP address to the world, review the steps above, and:
- Turn on
redirect-gateway def1in your OpenVPN client configuration to route ALL of your traffic through OpenVPN - Turn off IPv6 with
sysctl -w net.ipv6.conf.all.disable_ipv6=1to prevent IPv6 bypassing OpenVPN
Static Key Recap
We covered the setup of a static key, single-user OpenVPN server running on a remote machine. We covered the OpenVPN installation process, then covered the firewall rules required to run OpenVPN clients and servers, then covered the OpenVPN configuration options that need to be set.
We then showed how to use Wireshark to debug the OpenVPN tunnel and make sure it works properly.
 |
OpenVPN a tool for creating and connecting to virtual private networks.
Creating a Static Key VPN: OpenVPN/Static Key Configuring Your DNS: DNS
|