This documentation is to create a VPN service that uses ARRL Logbook of the Word (LoTW) credentials to connect. Instead of requiring the server operator intervention to issue keys etc. Inspired by OH7LZB's 2013 DCC presentation. He setup a simple proof of concept service, but only documented the client end of it.
The purpose of this document is to document both the server and client end of this. I should note that I am implementing it a bit different, as I am not setting up a private CA (simple using the ARRL LoTW CA) and thusly not issuing a server certificate. This greatly simplifies the process for both the client and server. You can read the server configuration details below for further information on that. I have revised OH7LZB's original client documentation below to reflect the difference.
With this info once should be able to set up a service that may be useful to hams who need another public (static) IP or do not have access to the port forwarding to one they are behind. It's pretty common for mobile internet providers (cellular/3G/4G) to not provide a public IP or a method to forward ports. This could be useful for IRLP, EchoLink, AllStar, D-Star, and other ham radio server operators. It could use of the 44net public IP address space. It could provide a publicly routed 44net IP via OpenVPN to licensed amateurs. Or perhaps you are simply setting up a VPN server so that hams can access a remote HF station etc.
Related concepts:
http://authtest.aprs.fi - Web based
authentication demo site (OH7LZB)
https://github.com/hessu/ham-cert-web-demo
- Wed authentication Apache configuration and PHP scripts
W3KD and
W1RFI predict and speculate what ham radio will be like in 25 years (2012
webinar)
Raspberry
Pi Web Based Rig Control
Remote Ham Radio Station Control
Also see ARRL publication "Remote Operating for
Amateur Radio"
LoTW uses a custom file format (.TQ*) to exchange certificates, but after the LoTW certificate process is done and the TrustedQSL software has your certificates, they can be easily copied from TrustedQSL's directories. You'll need four files: the root CA certrificates, your user certificate, an intermediate certificate that was used to sign it, and your private key. The only secret piece of information is the private key - you should not reveal it to anyone at any point, as they could then use services on your behalf, using your callsign.
You will note the TQSL program creates a CALLSIGN.P12 file. A few VPN
clients are starting to support a PCKS12 file. Once such program at the time of
writing this is Secure
Point. If your client supports this you won't need to extract the
ca.crt, client.crt, and client.key files. You can simply import the a .ovpn
client config file and the TQSL CALLSIGN.P12 file.
Windows
Make copies of those files in another directory, and work on those copies in order to avoid breaking the originals.
The user and intermediate certificates need to be concatenated to a single file named client.crt. The user certificate must be first, followed by the intermediate certificate. That can be done by an ascii editor such as Notepad (Wordpad or Word is likely to mess it up in a big way).
The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):
-----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31 0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX 1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo 7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw -----END RSA PRIVATE KEY-----
Copy-paste that block to a separate file named client.key.
The user and intermediate certificates need to be concatenated to a single file named client.crt. The user certificate must be first, followed by the intermediate certificate. That can be done by a single command:
cat ~/.tqsl/certs/user ~/.tqsl/certs/authorities > client.crt
The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):
-----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31 0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX 1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo 7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw -----END RSA PRIVATE KEY-----
Copy-paste that block to a separate file named client.key. If you're going to open up the original private key file in a text editor, it's a good idea to make a backup copy of that file first in case of an accidental corruption of its contents.
The root ca certificate can simple be renamed ca.crt.
If you chose to encrypt your private key with a password (or passphrase) when initially applying for a LoTW certificate and generating the Certificate Request, OpenVPN will ask you for that password when connecting.
To rephrase: When OpenVPN says "Enter Password", the password being asked is the one you picked when you first applied for a LoTW certificate. It's not something the VPN operator knows (or should know). It's not the one you got on a postcard. Only you have ever been aware of that password (hopefully).
Here is steps to install the VPN to Ubuntu 15.10 destop. Install OpenVPN plugin to network manager. Open terminal and type
sudo apt-get install network-manager-open vpn-gnome
Then add VPN-connection information to NetworkManager
Now you can connect to VPN
Log in to Raspberry Pi console. Install openvpn software.
sudo apt-get install openvpn
Create openvpn client configuration file with your favorite editor to /etc/openvpn/client.conf
client dev tun proto udp remote IP-ADDRESS-OF-SERVER 1193 resolv-retry infinite persist-key persist-tun ca ca.crt cert client.crt key client.key comp-lzo verb 3
Extract your client certificate and key as explained above section Extracting the certificate from LoTW. Copy your certificate files ca.crt, client.crt and client.key to /etc/openvpn/ .
Restart openvpn
service openvpn restart
All done.
This assumes installation of openvpn on a Linux platform.
apt-get install openvpn openssl
After the install finishes, you will need the 'easy-rsa'-tool to generate the Diffie Hellman dh1024.pem file It's easiest to copy the example folder and work from there.
cp -R /usr/share/doc/openvpn/examples/easy-rsa /etc/openvpn cd /etc/openvpn/easy-rsa/2.0
In our example server configuration file:
/etc/openvpn/server.conf
port 1194 proto udp dev tun ca ca.crt cert server.crt key server.key dh dh1024.pem server 44.92.21.192 255.255.255.192 ifconfig-pool-persist ipp.txt ;Split tunnel ;push "route 44.0.0.0 255.0.0.0" ;Full tunnel push "redirect-gateway def1" push "dhcp-option DNS 8.8.8.8" client-to-client keepalive 10 120 comp-lzo persist-key persist-tun status openvpn-status.log verb 3
Files explained:
- ca.crt = The latest LotW Root CA cert
certs\root* (no need
to break them apart)
- server.crt = Your personal LotW cert concatenated with the
intermediate that signed it.
certs\user* +
certs\authorities* (if multiple concatenated authorities, you will need to break
them apart and choose one)
| Quote: |
OH7LZB>"I don't think that will work. Your personal LotW cert does not contain "key usage" parameters that would allow it to be used as a server certificate. You should set up a private CA and have it issue a server certificate to be used for the server cert, and the client should use that private CA's certificate as the "ca cert"." NQ1E> Checking for server key usage in OpenVPN is an optional
configuration KB9MWR> Cory is correct. I just followed his steps and the
openvpn server Still a little confused on what OH7LZB is describing. But I
think it |
- dh1024.pem = The Diffie Hellman must be defined/exist.
You build this using the easy rsa tool ./build-dh
*References are to the Windows TQSL program:
C:\Documents and Settings\your-username\Application Data\TrustedQSL\
The best way to use this with 44net IP's would be to coordinate with network operator that can provision BGP routing. If you have a smaller number of VPN clients and don't have those connections you can connect to the central router at UCSD using IPencap. This adds an unnecessary second point of failure, trip time and reduced throughput however.
#!/bin/bash
sysctl -w net.ipv4.ip_forward=1
modprobe ipip
#
Routing bootstrap for the above OpenVPN server
# Simplistic test setup to outside internet via UCSD
#
ifconfig tunl0 up 44.92.21.129 netmask 255.255.255.255
ip route add default dev tunl0 via 169.228.66.251 onlink table 44
ip rule add from 44.92.21.192/26 table 44
#
You'll also need to have entries in the Ampr DNS to achieve world routeable addresses, and obviously a gateway IP defined in the Ampr Portal.
# For a full tunnel: # server.conf: # push "redirect-gateway def1 bypass-dhcp" # push "dhcp-option DNS 8.8.8.8" #To run a full tunnel server you have to modify your NAT. Run these 3 commands as root iptables -I FORWARD -i tun0 -o tunl0 -s 44.92.21.192/25 -m conntrack --ctstate NEW -j ACCEPT iptables -I FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT iptables -t nat -I POSTROUTING -o tunl0 -s 44.92.21.192/25 -j MASQUERADE # tun0: your virtual openVPN networkcard # tunl0: ampr IPIP tunnels (normally eth0 - your normal networkcard) # 44.92.21.192: openVPN network IP block (normally 10.8.0.0)