Tweet
I recently upgraded openvpn (using Debian), and after dealing with some cipher / tls incompatibility (my config is very old), I ran into " Assertion failed at crypto.c:74 (packet_id_initialized(&opt->packet_id))". I looked in the source and packet_id seems to be for replay protection. My config file (on server and client) had "no-replay" in it, to disable replay protection, because at some point in the distant past replay protection made it difficult to reconnect after suspending my laptop. I deleted the no-replay line and now it works as expected.
I'm writing so that maybe someone else will find this solution to this problem, and perhaps so that the developers can become aware of it? It is obviously a bug to give an assertion failure for a feature that used to work.
A little off topic: I have used openvpn for about 20 years. A big thank you to everyone that has worked on it! I am kind of upset that it is moving towards TLS-only instead of pre-shared secrets. One of my clients has to remain compatible with a remote server that is on a very slow update cycle so that is a timebomb waiting for me. The TLS configuration is much more complicated and much less well-documented.
I'm going to address that right here. This is how I made keys (these commands are cut and pasted from a diverse set of resources, none of them were complete on their own).
Important note: when making a certificate, it is important that you give it a "CN" Certificate Name -- the other fields can apparently be blank but certificate name has to be filled in! Otherwise, I got the dreaded "Unroutable control packet".
To make a certificate authority, a "myname" host key, and a dh file:
Each host needs its own host certificate, signed with the single CA certificate. Only the server needs "dh".
Then in the openvpn conf file:
The client's configuration needs ca / cert / key, but does not need dh.
That's the quick start that I wish I'd had before I started this. Good luck and thank you!
I'm writing so that maybe someone else will find this solution to this problem, and perhaps so that the developers can become aware of it? It is obviously a bug to give an assertion failure for a feature that used to work.
A little off topic: I have used openvpn for about 20 years. A big thank you to everyone that has worked on it! I am kind of upset that it is moving towards TLS-only instead of pre-shared secrets. One of my clients has to remain compatible with a remote server that is on a very slow update cycle so that is a timebomb waiting for me. The TLS configuration is much more complicated and much less well-documented.
I'm going to address that right here. This is how I made keys (these commands are cut and pasted from a diverse set of resources, none of them were complete on their own).
Important note: when making a certificate, it is important that you give it a "CN" Certificate Name -- the other fields can apparently be blank but certificate name has to be filled in! Otherwise, I got the dreaded "Unroutable control packet".
To make a certificate authority, a "myname" host key, and a dh file:
Code:
openssl req -nodes -new -x509 -keyout ca.key -out ca.crt openssl req -nodes -new -keyout myname.key -out myname.csr openssl x509 -req -CA ca.crt -CAkey ca.key -CAcreateserial -out myname.crt -in myname.csr openssl dhparam -out dh2048.pem 2048
Then in the openvpn conf file:
Code:
ca ca.crt cert myname.crt key myname.key dh dh2048.pem
That's the quick start that I wish I'd had before I started this. Good luck and thank you!
Comment