From charlesreid1
The OpenVPN key is composed by hexadecimal characters and divided into four parts. The first part is used as a key to cipher the data, the second for the hash algorithm key. By default the key to cipher and decipher the data are similar, the principle being the same for the Hash algorithm.
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 ServerCreate OpenVPN Server Key
First, generate a key on the OpenVPN server:
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:
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:
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:
Forward Packets on Server
Make sure you are forwarding packets:
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:
Final ScriptClientClient Config File
On the client, create your client config file:
Here we're specifying the location of our OpenVPN server with the IP address
What Is Generate A Static Openvpn Key Code
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:
Now set default policies for types of packets:
Accept packets belonging to accepted connections:
Respond to pings (that's what the 8 means):
Open port 1194 for OpenVPN:
All outbound packets are OK:
Now print the rules:
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:
Final Client ScriptTesting the Static VPNWireshark 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:
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:
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:
What Is Generate A Static Openvpn Key System
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
Confusing.
Not clear whether this works for both IPv4 and IPv6, or just IPv6.
Client Solution 1: Disable IPv6 Temporarily
To temporarily disable IPv6:
To temporarily re-enable IPv6:
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:
and remove your loopback IPv6 interface by commenting out this line from
/etc/hosts (if relevant):
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:
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 GotchasOpenvpn Static Key ConfigDNS 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:
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:
![]() 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:
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.
Retrieved from 'https://charlesreid1.com/w/index.php?title=OpenVPN/Static_Key&oldid=8596'
Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
December 2020
Categories |