So I upgraded a box to OpenVPN 2.4 yesterday, turns out that it’s not that straight forward an upgrade if you don’t keep your CRL fresh (like most people it seems).

Here explains what’s going on a little bit

So the answer is a bit of hackery inside your easyrsa implementation and regen the CRL

1. Open openssl-1.0.0.cnf in your favourite editor and search for crl_days

default_days = 3650 # how long to certify for
default_crl_days= 30 # how long before next CRL

Change to

default_days = 3650 # how long to certify for
default_crl_days= 3650 # how long before next CRL

2. Open the vars file in your text editor and add the following key to the bottom of your file

export KEY_ALTNAMES=”something”

3. Regenerate your crl

source ./vars
openssl ca -gencrl -out crl.pem -config ./openssl-1.0.0.cnf

4. Move the crl.pem to wherever your old crl was and finally test with “openssl crl -in ./crl.pem -text | grep Update”, check that “Next Update” is a date in the future.

5. Go home for tea and medals as your OpenVPN server should now be working and letting clients connect 🙂

Whilst trying to get my shiny new Android phone setup, I came across a small issue with the voicemail
to email service in Asterisk. Seems Android can’t handle the wav49 codec, so there’s a simple fix to
change the codec in the voicemail.conf

Original – voicemail.conf

; Formats for writing Voicemail.  Note that when using IMAP storage for
; voicemail, only the first format specified will be used.

New – voicemail.conf

; Formats for writing Voicemail.  Note that when using IMAP storage for
; voicemail, only the first format specified will be used.

The only downside is that the new WAV attachments are much larger, however – being able to
listen to them under Android, outweighs that issue.

A customer of mine, recently asked me to look into a problem with his SNOM OpenVPN enabled
handsets, they were working – just had an annoying “VPN:Error” message at the bottom of the
screen, it seems to be that the fix is to declare the device as a tun0, but make sure that
the device type is tap (yes yes I know tap / bridging is not exactly ideal but the customer
wanted it this way).

Anyhow all fixed now and the config is posted below :-

# It's a client config
# The device is called tun0
dev tun0
# However it's a tap device - just happens to be called tun0
dev-type tap
# UDP / Endpoint / Port
proto udp
remote 1194
# Other bits
resolv-retry infinite
# Certificates go here - note the "/openvpn/" this has to be in place.
ca /openvpn/ca.crt
cert /openvpn/voip.crt
key /openvpn/voip-key.key
ns-cert-type server
# turn on compression
# Set log file verbosity.
#verb 5
# Silence repeating messages
key-method 2
ping 10
ping-restart 60

I’ve whipped up a script to backup Edgemax/Vyatta routers and push it to a RCS system, download a copy here


sshpass (Sourceforge page)
bzr here (or something else like CVS/Git)


./ <userid> <passwd> <router IP address> <filename>


Whilst it’s not a great idea to embed SSH passwords in scripts, you could use SSH keys with a bit of jiggery pokery of the script, it’s upto you, personally I only allow access to ssh from the my trusted management platforms and even the above user SSH userid could be restricted to only allow “show configuration”

* Big thanks to [email protected] for allowing me access to his test box for final testing.


My beloved Edgerouter Lite is dead 🙁 It seems that it suffers from a known DDR issue with a
few of the first production models, it’s best diagnosed by connecting to the console port
115200 8N1 with a cisco console cable and rebooting the box.

If it hangs around the “DRAM: 512MB” line (see below) you’re out of luck 🙁

Looking for valid bootloader image....
Jumping to start of image at address 0xbfc80000

U-Boot 1.1.1 (UBNT Build ID: 4493936-g009d77b) (Build time: Sep 20 2012 - 15:48:51)

BIST check passed.
UBNT_E100 r1:2, r2:12, serial #: xxxxxxxxxxxxxxxxxx
Core clock: 500 MHz, DDR clock: 266 MHz (532 Mhz data rate)
DRAM:  512 MB

I’ve got a call into UBNT support to see what the RMA process will be (I’m in the UK and there seems to be some issue getting RMA’s through the distie), so we’ll have to see what happens.


Some days you just need to do a bit of packet mangling and you don’t want to
write loads of DNAT/SNAT statements, so why not just use the NETMAP target

Take this example (The IP addresses have been changed to protect the innocent)

iptables -t nat -A PREROUTING -d -j NETMAP --to
iptables -t nat -A POSTROUTING -d -j NETMAP --to

It allows you to translate entire networks on a 1:1 mapping basis, so
maps to and maps to and so on and so on.


(Oh and the Postrouting line is for the SNAT on the way back btw)

Whilst doing some other work for #dayjob,  I came across this little outfit based out in Israel doing free Class 1 SSL certificates for a year.

Ok I thought what’s the catch (other than it’s about as trustworthy as a man claiming to be secure , but can’t demonstrate it), it seems there isn’t much of a catch :

  1. The T’s & C’s state it has to be for “non-commercial” activity.
  2. It’s only Class 1, funny enough they do Class 2 and EV certs as well – for a cost naturally.
  3. It’s only for a year, but you can just keep renewing it every year.
  4. Errr and that’s about it really.

All in all, it’s worth signing up and using it for test certs and things like that, I tend to use it for test certs for Loadbalancers/Offload SSL box’s, saves explaining to people why you need to purchase certs for a development environment, anyway it’s worth a punt —

Whilst fiddling around with the Edgemax Lite I came across a bit of an issue whilst connecting
it to my main OpenVPN hub server, the fact that it couldn’t do comp-lzo compression.
Whilst I don’t need to do compression, it’s switched on by default in most OpenVPN distributions
and without it, in my case it caused immense pain on the server end and refused to work.

I hunted high and low for the answer on Ubiquiti’s very good forum and googled the issue to the
Nth degree, but because it’s so new I don’t think anyone has come across this issue yet (or at
least documented it anywhere). So what to do – do I turn off comp-lzo on the server or do I
run another another copy of OpenVPN on it just for the Edgemax?

In the end, I had a bit of a brainwave and remembered it’s a Vyatta, so I googled for that instead
and that lead me to the answer which is :

openvpn-option --comp-lzo

Here’s my complete Openvpn vtun statement :
openvpn vtun0 {
mode client
openvpn-option --comp-lzo
protocol udp
remote-port 1194
        tls  {
             ca-cert-file /config/auth/ca.crt
             cert-file /config/auth/cert.crt
             key-file /config/auth/cert.key

And literally that’s all you have to do (well apart from SCP the keys/certs into config/auth) to
get OpenVPN in default UDP flavour working on the box. I haven’t yet tried any other configs
but if the client config works this well I can’t imagine server/site-to-site won’t be too
complicated to get working.