OpenVPN Server - TLS errors

[fastfwd]

OpenVPN Server worked on build 18730, but fails on build 19210 with this pair of error messages (IP addresses replaced by "x.x.x.x"):

Authenticate/Decrypt packet error: packet HMAC authentication failed
TLS Error: incoming packet authentication failed from x.x.x.x:44715

EDIT: This bug report originally stated that Build 19210 sometimes also failed with "TLS Error: cannot locate HMAC in incoming packet from x.x.x.x:63906", but I've since discovered that that error was simply due to a clent misconfiguration while trying to diagnose the other error. My apologies for any trouble that my mistake may have caused.

Comparing files produced by the two builds (I'll attach all these files):

/tmp/openvpn/openvpn.conf: identical except for the expected "dev tap0"/"dev tap2" difference

/tmp/openvpn/route-up.sh: identical except for the expected tap0/tap2 difference and the expected new ebtables commands for DHCP blocking

/tmp/var/log/openvpn: identical from "OpenVPN 2.2.1 mipsel-linux" to "Initialization Sequence Completed", except for build date, tap0/tap2, and three "Sorry, rule doesn't exist" lines from the three "ebtables -D" commands

Client-side conf files haven't changed; I'll attach one of those, too.

[fastfwd]

Build 18730 (Good) - /tmp/openvpn/route-up.sh

[fastfwd]

Build 18730 (Good) - /tmp/openvpn/openvpn.conf

[checho]

excuse me for the dumbest possible question, but is your date and time on the router correct?

[fastfwd]

Build 18730 (Good) - /tmp/var/log/openvpn

[fastfwd]

Build 19210 (Bad) - /tmp/openvpn/route-up.sh

[fastfwd]

Build 19210 (Bad) - /tmp/openvpn/openvpn.conf

[fastfwd]

Build 19210 (Bad) - /tmp/var/log/openvpn

[fastfwd]

Client configuration (works with 18730, fails with 19210)

[fastfwd]

Replying to checho:

excuse me for the dumbest possible question, but is your date and time on the router correct?

Not a dumb question at all. In fact, that was one of the first things I checked when I had crypto errors.

As can be seen from the log files I uploaded (after you posted your question), the router date and time are correct (set via NTP). My client clocks are also set via NTP. My certificates were all signed months ago, so it's not a timezone problem, either.

[fastfwd]

Sash: Excuse me, but why "invalid"? The error is real and repeatable; is there additional info that I can provide?

[Kong]

Probably because:

​http://svn.dd-wrt.com:8000/changeset/19211

[fastfwd]

Well, changeset 19211 didn't fix the problem. It still exists, with identical symptoms, in Build 19215.

19215 fails whether DHCP Blocking (the major change in changeset 19211) is on or off.

What's the protocol here? Do I reopen this bug, or file a new one?

[Sash]

as long as nobody acknowledes this bug its not existing to me. im running ovpn in mips and arm with current nightlies and i dont see any problem.

[basmaf]

Confirm broken openvpn, tls errors as specified by fastfwd Build 19215, Broadcom Linksys E4200

[fastfwd]

Some more info, hope it helps:

1 - I'm also running Build 19215 on an E4200. It's this Kong build:

​http://www.desipro.de/ddwrt/r19215/kingkong-nv60k-broadcom.bin

Kong's build doesn't include any mods that directly affect OpenVPN, but of course it's possible that they break it anyway, so I'd happily try an unmodified build in order to rule out a problem with Kong's mods. Unfortunately, I don't have a build environment set up... So if there's an unmodified 19215-or-later broadcom_K26-nv60k build somewhere, please point me to it.

2 - I've tried drastically simplifying the client.ovpn file that I attached earlier (and, of course, making the corresponding changes in the DD-WRT OpenVPN Server GUI when necessary). One at a time, I made the following changes:

set hash to 'none' set cipher to 'none' remove tls-auth remove remote-cert-tls remove comp-lzo remove fragment/mssfix

When I was done, the configuration didn't do much more than set UDP and TAP, but Build 19215 still failed with TLS errors whenever a client tried to connect. Build 18730, unsurprisingly, succeeded with both the complete configuration and the simplified one.

3 - I turned the verbosity up to 7 on both client and server, but didn't see anything obvious in the logs. And, unfortunately, I didn't save them.

4 - The failure happens with comp-lzo set to either 'adaptive' or 'disabled', and with DHCP Blocking either enabled or disabled, so it doesn't seem to be caused by those recent changes.

5 - Clients I've tried (both work with 18730, both fail with 19215):

Android phone running CM7 with built-in OpenVPN 2.1.4 Win7-64 machine running OpenVPN 2.2.2

[tito]

Replying to Sash:

as long as nobody acknowledes this bug its not existing to me. im running ovpn in mips and arm with current nightlies and i dont see any problem.

I've tried builds 19210 and 19215 on an E3000, neither can connect:

20120506 07:08:29 N TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:lib(20):func(144):reason(134)
20120506 07:08:29 N TLS Error: TLS object -> incoming plaintext read error
20120506 07:08:29 N TLS Error: TLS handshake failed

I'm currently successfully using 18946.

[PetervdM]

i to had this problem with hmac authentication in build r19215. after trying several modifications to my config files, entering a line "auth sha256" in both client and server config files did the trick. it seems the default used sha1 implementation is broken.

[LOM]

Replying to Kong:

Probably because:

​http://svn.dd-wrt.com:8000/changeset/19211

more likely because of r19087

[Sash]

19277

[fastfwd]

Changeset 19277 does not fix the OpenVPN TLS problem. However, the symptoms change.

Build 19215 produced these errors:

Authenticate/Decrypt packet error: packet HMAC authentication failed
TLS Error: incoming packet authentication failed from x.x.x.x:44715

Build 19277 produces these:

TLS_ERROR: BIO read tls_read_plaintext error:error:1408F119:lib(20):func(143):reason(281)
TLS Error: TLS object -> incoming plaintext read error
TLS Error: TLS handshake failed

I'm using this build:

​http://www.desipro.de/ddwrt/r19277/kingkong-nv60k-broadcom.bin

[BrainSlayer]

these private builds do not guarantee a correct build. i dont know if openssl was reconfigured. if not, the patch will not show any effect and produces the same code as before

[Kong]

Just for the record, yes I reconfigured openssl and also made sure openvpn, vpnc are cleaned before compiling. I'm pretty sure this bug will show up in official builds too.

[PetervdM]

Replying to PetervdM: my workaround for openssl by using "auth sha256" is not working anymore in r19277. removing the auth statements from both server and client config files so the orginal config is restored, makes openvpn working again.

[Sash]

loco2M (mips)

Mon May 21 20:22:28 2012 us=795306 UDPv4 link remote: 10.0.0.18:1194
Mon May 21 20:22:28 2012 us=828440 TLS: Initial packet from 10.0.0.18:1194, sid=bae0280b 303a5388
Mon May 21 20:22:29 2012 us=225312 VERIFY OK: depth=1, /C=DE/ST=HE/L=/O=/emailAddress
Mon May 21 20:22:29 2012 us=228476 VERIFY OK: depth=0, /C=DE/ST=HE/L=/O=/OU=Home/CN=/emailAddress=
Mon May 21 20:22:29 2012 us=847822 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon May 21 20:22:29 2012 us=848078 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon May 21 20:22:29 2012 us=848646 NOTE: --mute triggered...

[davem]

r19327 has TLS issues with my E1000 test unit. i cannot find any auth/cipher values which still work. from server (OpenVPN 2.2.2/CentOS 6.2) end with client configured with OpenVPN Client GUI on DD-WRT:

Wed Jun  6 15:35:40 2012 us=421302 1.2.3.4:32768 TLS_ERROR: BIO read tls_read_plaintext error: error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac Wed Jun  6 15:35:40 2012 us=421347 1.2.3.4:32768 TLS Error: TLS object -> incoming plaintext read error Wed Jun  6 15:35:40 2012 us=421361 1.2.3.4:32768 TLS Error: TLS handshake failed Wed Jun  6 15:35:40 2012 us=421489 1.2.3.4:32768 SIGUSR1[soft,tls-error] received, client-instance restarting

attached config of both side and other information.

[dc]

I'm seeing the same behavior as the previous comment -- error messages when the client tries to connect to my E3000 running BS NV60K-Mega Build 19342.

My server starts on 'Wan UP' and uses a config-file (retrieved from /tmp/openvpn/config) which looks like:

dh /tmp/openvpn/dh.pem
ca /tmp/openvpn/ca.crt
key /tmp/openvpn/key.pem
server 192.168.68.0 255.255.255.0
script-security 3
management localhost 5002
dev tun0
proto udp
fast-io
topology subnet
keepalive 10 120
dh /tmp/openvpn/dh.pem
ca /tmp/openvpn/ca.crt
cert /tmp/openvpn/cert.pem
key /tmp/openvpn/key.pem
push "route 192.168.2.0 255.255.255.0"

My client config is also very generic:

client
dev tun
proto udp
remote whatever.it.is 1194
resolv-retry infinite
nobind
ca ca.crt
cert dave.crt
key dave.key
ns-cert-type server
verb 3
mute 20

TLS is not enabled anywhere in the configuration the NVRAM parameters involving TLS are:

openvpncl_tlscip=0
openvpncl_tlsauth=
openvpn_tlscip=0
openvpn_tlsauth=

[jmwhite]

I have a WNR3500L V1 and have the same problem on 19277 (Kong Build). A client would initially be able to begin connecting and then would fail after the VERIFY OK with the server certificate stage with:

20120506 07:08:29 N TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:lib(20):func(144):reason(134)
20120506 07:08:29 N TLS Error: TLS object -> incoming plaintext read error
20120506 07:08:29 N TLS Error: TLS handshake failed

Dropped back to 18730 Kong and all is well in OpenVPN land again. I don't think this is attributed to just Kong builds, but more of a general problem.

[renatopi]

Hi After about 17 days "R(ing) TFM" I could solve this issue and may be we are doing the wrong question.

The right question is: Which tls enciphering modes does the WW-DRT build supports?

Going deeper

In default mode OpenVpn? uses tls AES256-SHA enciphering mode but tls negotiation can be enciphered in several modes. The problem is that OpenVpn? sample config file does not mention a word regarding it and OpenVpn? man page is not explicit about this issue as well.

In other words if you do not explicitly specify which tls enciphering mode both client & server config files will be using, OpenVpn? will be adopting AES256-SHA tls enciphering mode.

Open your desktop and type openvpn --show-tls. OpenVpn? 2.1.0 will be bringing you 19 and OpenVpn? 2.2.1 will be bringing you 44 tls enciphering options!

So, I ask again: Which tls enciphering options does WW-DRT firmware suppots?

I'm using DD-WRT v24-sp2 big Broadcom chipset Cisco E2500. I did a test expliciting the tls cipher mode and and below you can know what worked for me and what did not work for me (of course i did not test all 44 options of OpenVpn? 2.2.1).

Most secure ;tls-cipher DHE-RSA-AES256-SHA #bad ;tls-cipher DHE-DSS-AES256-SHA #bad ;tls-cipher AES256-SHA #bad tls-cipher EDH-RSA-DES-CBC3-SHA #ok ;tls-cipher EDH-DSS-DES-CBC3-SHA #bad ;tls-cipher DES-CBC3-SHA #ok fast ;tls-cipher DHE-RSA-AES128-SHA #bad ;tls-cipher DHE-DSS-AES128-SHA #bad ;tls-cipher AES128-SHA #bad ;tls-cipher RC4-SHA #ok ;tls-cipher RC4-MD5 #ok ;tls-cipher EDH-RSA-DES-CBC-SHA #ok ;tls-cipher EDH-DSS-DES-CBC-SHA #bad ;tls-cipher DES-CBC-SHA #ok ;tls-cipher EXP-EDH-RSA-DES-CBC-SHA #bad ;tls-cipher EXP-EDH-DSS-DES-CBC-SHA #bad ;tls-cipher EXP-DES-CBC-SHA #ok ;tls-cipher EXP-RC2-CBC-MD5 #ok ;tls-cipher EXP-RC4-MD5 #ok Less secure

So what is the solution? We need add in both sides of the openvpn cofig file one of these working lines above.

In time: There is an other issue that GUI does not work for openvpn client and server mode (v24-sp2 big)

At this time I am posting this solution at Wiki page. Please do not hesitate in correct me or improve my solution. Kind regards.. me.

[everflux]

I think the OpenVPN binary is plain broken in current builds (tested with 19519, brainslayer) which prevents connecting to other OpenVPN servers, except TLS is running unencrypted.

Can be verified by running: openvpn --show-tls

Output of current builds: none Using f.e. openwrt whiterussian package of openvpn a list of supported algorithms is returned as expected.

[Sash]

Replying to fastfwd:

OpenVPN Server worked on build 18730, but fails on build 19210 with this pair of error messages (IP addresses replaced by "x.x.x.x"):

Authenticate/Decrypt packet error: packet HMAC authentication failed
TLS Error: incoming packet authentication failed from x.x.x.x:44715

Well, according to the openvpn boards there are at least two possibilities:

1) the key files do not match or are different ==> in that case it should show errors right from the beginning

2) there are errors on the connection from your end to the vpn-server. They suggest using tcp instead of udp, which would correct the errors by retransmitting the packets.

just instalol a working and a non working build an compare/diff the config files and report the differences.

...i personally dont beleave its a config problem...

[fastfwd]

Replying to Sash:

Replying to fastfwd:

OpenVPN Server worked on build 18730, but fails on build 19210 with this pair of error messages (IP addresses replaced by "x.x.x.x"):

Authenticate/Decrypt packet error: packet HMAC authentication failed
TLS Error: incoming packet authentication failed from x.x.x.x:44715

Well, according to the openvpn boards there are at least two possibilities:

1) the key files do not match or are different ==> in that case it should show errors right from the beginning

2) there are errors on the connection from your end to the vpn-server. They suggest using tcp instead of udp, which would correct the errors by retransmitting the packets.

just instalol a working and a non working build an compare/diff the config files and report the differences.

...i personally dont beleave its a config problem...

Thank you for investigating, Sash. Unfortunately, neither of those possibilities seems to be the problem:

1. My config files for the working build (18730) and non-working builds (19210+) are attached to this bug; they're basically identical. I've diffed the key files, too, and they're bit-for-bit identical.

2. If uncorrectable connection errors were to blame, wouldn't all builds fail to work? I've been successfully using build 18730 since March, connecting to it from dozens of locations, and I've never seen the TLS errors that instantly appear when I try to use 19210 or later.

Also, as far as I can tell, it is only E4200/E3000/E2500/E1000 users who are seeing these TLS errors. Doesn't that suggest that the problem is specific to the Broadcom builds for those devices? It seems unlikely that all those users -- and ONLY those users -- have misconfigured key files or sudden unexplained connection errors.

I know how frustrating it is to try to debug a problem that you can't duplicate. If I can help in any way by providing more information, please tell me. If it would be helpful for you to have a Cisco/Linksys? Exxxx router, I'd be happy to donate the money for one; just tell me how.

[Kong]

fastfwd, since you have the chance to check both builds, can you attach the output of:

strings /usr/sbin/openvpn

for both builds?

[jackcambridge]

I would just like to say that VPN broke for me when I tried dd-wrt.v24-19519_NEWD-2_K2.6_openvpn_small.bin. Changed to dd-wrt.v24-18777_NEWD-2_K2.6_openvpn_small.bin and it started working again.

I don't know what the problem is in the new version. I tried changing a lot of stuff around, including the tap0/tap2 stuff, but I couldn't get it to work in 19519. My config works fine in 18777 though. I'm using an E1000.

[fastfwd]

From fastfwd - Build 18730 output of "strings /usr/sbin/openvpn"

[fastfwd]

From fastfwd - Build 19545 output of "strings /usr/sbin/openvpn"

[fastfwd]

Replying to Kong:

fastfwd, since you have the chance to check both builds, can you attach the output of:

strings /usr/sbin/openvpn

for both builds?

Done. Sorting and diffing shows that large groups of strings apparently related to OpenSSL are present in 18730 but absent in 19545.

[t4ndeta]

Hi,

I've got 2 E4200 units which I wanted to tunnel with OpenVPN. So I flashed them with the latest DD-WRT (19519 from BrainSlayer?) but I couldn't connect successfully. The reason is described in this thread.

So I flashed the 2nd router with 18777 from BrainSlayer? and with this version OpenVPN worked flawlessly.

So, I found a workaround for this problem. I copied the OpenVPN from 18777 to /jffs/opt/sbin on 19519. Then added commands to startup: #------------------------------------- mount -o bind /jffs/opt /opt rm -f /tmp/openvpnserver ln -s /opt/sbin/openvpn /tmp/openvpnserver #-------------------------------------

This proves that the problem is in openvpn compilation.

Here is a copy of openvpn from 18777: ​http://dl.dropbox.com/u/653798/dd-wrt/E4200/openvpn

HTH, T4

[ddwrtchris]

Hi,

i have just seen this ticket.

First of all i have a question:

In the first tickets i see that a SERVER config is used, that has:

--server

that leads to "--tls-server" since server ist a macro.

So if a client, that has --client, which leads to a "--tls-client".

but the (at the very top) configuration of the client, does not show ANY tls-keys configured.

So the behavior that the client (using configuration that has NOTHING regarding tls configured) is not able to connect is right.

If that was possible, it MUST be a very bad bug of the upstream openvpn package that we have been used, and that was just corrected.

Please post me your SERVER and CLIENT config.

[davem]

both broken client configurations posted to this ticket (mine and fastfwd) have both 'client' and 'tls-key' specified.

also, i should note that my client configuration is actually just a copy of what is automatically generated by dd-wrt using openvpncl nvram values.

[fastfwd]

ddwrtchris:

My client config is client.ovpn (the seventh attachment to this bug). The --pkcs12 option in line 26 of that file combines the functions of the --ca, --cert, and --key options.

[ddwrtchris]

Hi,

agreed.

Can you try to set the cipher and tls-cipher on both sides like:

cipher AES-192-CBC
tls-cipher AES256-SHA

[fastfwd]

ddwrtchris: I'm glad that you're interested in fixing this bug, but I'm afraid I can't do what you ask.

I'm currently testing a new build by Kong that's linked against PolarSSL rather than OpenSSL -- it eliminates the problem -- and I'd also be happy to test a new build linked against OpenSSL if you think you've fixed the bug. I just don't have time, though, to take my router out of service and "try this, try that" with an old build (especially when renatopi has already pointed out, in comment 27 above, that --tls-cipher AES256-SHA doesn't work).

I hope you understand.

[davem]

the configurations i posted already have identical tls-cipher and cipher specified on both ends.

[ddwrtchris]

ok. we'll check this with two testrouters.

I had no problems using newer builds as server / client.

Also i would really like to move to polarassl as well, Our first tests longer ago using polarssl with older openvpn versions did not work at all.

Our tests and a solution might take till next week.

[daymz]

Just in case it is useful, I am also experiencing this exact TLS problem and errors running BrainSlayer?-V24-preSP2 SVN 19342 (big) on a Netgear WNDR4000.

I am willing to try debugging this with you but I can not downgrade to 18777.

ddwrtchris -> let me know when you have a new build (next week) that I can test.

[jacgec]

Same issue here. Firmware: dd-wrt.v24-19342_NEWD-2_K2.6_big-nv64k Router: WNDR4000

Server log reports same errors as others have reported:

20120831 03:27:21 N 10.1.10.152:62767 TLS_ERROR: BIO read tls_read_plaintext error: error:1408F119:lib(20):func(143):reason(281) 
20120831 03:27:21 N 10.1.10.152:62767 TLS Error: TLS object -> incoming plaintext read error 
20120831 03:27:21 N 10.1.10.152:62767 TLS Error: TLS handshake failed 
20120831 03:27:21 10.1.10.152:62767 SIGUSR1[soft tls-error] received client-instance restarting

[wetpaint]

FYI, I have exactly the same issues Brainslayer DD-WRT v24-sp2 big - build 19519 on an Asus RT-N16

[sorcer]

I can confirm this issue with both 19519 vpn build and 18777 vpn build (E4200 V1). Downgraded to 18777, in hope for it to fix the tls-issue, same error is replicated in both versions. I'm gonna watch this thread incase somebody got a fix :) Thanks guys, keep up the good work!

[ralftopas]

Hi to everyone,

i have the same issues... Aktually i'm using the following setup:

Server = E4200, DD-WRT v24-sp2 (03/19/12) big (SVN revision 18774) Client 1 = E2000, DD-WRT v24-sp2 (03/19/12) big (SVN revision 18774) Client 2 = E900, DD-WRT v24-sp2 (06/08/12) big (SVN revision 19342)

Server <-> Client 1 VPN works just fine and stable. Server <-> Client 2 VPN wont establish a connection. Same Error: TLS_ERROR: BIO read tls_read_plaintext error: error:1408F119:lib(20):func(143):reason(281) TLS Error: TLS object -> incoming plaintext read error TLS Error: TLS handshake failed SIGUSR1[soft tls-error] received client-instance restarting

Client 1 and 2 have exactly the same settings in config. Only difference is the firmware version. The E900 is supporte from build 18946 or greater (http://www.dd-wrt.com/wiki/index.php/Linksys_E900)

so i guess the problem is, like said bevore, in the builds from a certain svn...

[sorcer]

Replying to ralftopas: Reading this, I will try to downgrade my E4200 V1 once more, going with 18774 that seams to work for you.

[ralftopas]

@sorcer: yes, i hope this will fix your problem. plz, give me a note if this worked out for you...

[sorcer]

Replying to ralftopas:

@sorcer: yes, i hope this will fix your problem. plz, give me a note if this worked out for you...

Sun Sep  9 13:54:09 2012 us=336929 MANAGEMENT: >STATE:1347191649,WAIT,,,
WWWWWSun Sep  9 13:55:09 2012 us=454801 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Sep  9 13:55:09 2012 us=454941 TLS Error: TLS handshake failed
Sun Sep  9 13:55:09 2012 us=455248 TCP/UDP: Closing socket
Sun Sep  9 13:55:09 2012 us=455388 SIGUSR1[soft,tls-error] received

I would say it works…kinda the same as it did before, tried both with tunnelblick (os x) and openvpn on a debian box, same error :/ Even saw a thread were they had to cut 'n paste the certs, just to be sure there is no extra keys in the code+they said it "worked better" from IE7 which is probably also bull, however I'm back to were I've started. Certs were generated on an ubuntubox as suggested.

[ralftopas]

To avoid cert-Problems i generated new certs too. Certs for client1 and client2 I Used both certs with my E2000. Both certs worked perfectly with my server, none of them worked on my E900. So i guess certs are ok. Verifikation in the Log is always OK. I Used Firefox 15 for configuration and copy&paste...

I will send my E900 back and buy another E2000. Then install 18774 and use an identical backup from my Old E2000. Hope to get rid of this...

Don't have the Time to wait for bugfixes :-(

[sorcer]

Oh well, still stuck, not really moving forward. Here comes some output if somebody is able to diagnose this any further.

---

tail -f /var/log/openvpn
Sun Sep  9 21:58:01 2012 TUN/TAP device tap0 opened
Sun Sep  9 21:58:01 2012 TUN/TAP TX queue length set to 100
/tmp/.rc_firewall: line 2: ptables: not found
/tmp/.rc_firewall: line 2: ptables: not found
Sun Sep  9 21:58:04 2012 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Sun Sep  9 21:58:04 2012 UDPv4 link local (bound): [undef]:1194
Sun Sep  9 21:58:04 2012 UDPv4 link remote: [undef]
Sun Sep  9 21:58:04 2012 MULTI: multi_init called, r=256 v=256
Sun Sep  9 21:58:04 2012 IFCONFIG POOL: base=10.20.30.20 size=11
Sun Sep  9 21:58:04 2012 Initialization Sequence Completed
Sun Sep  9 21:58:51 2012 MULTI: multi_create_instance called
Sun Sep  9 21:58:51 2012 10.20.30.102:57891 Re-using SSL/TLS context
Sun Sep  9 21:58:51 2012 10.20.30.102:57891 LZO compression initialized
Sun Sep  9 21:58:51 2012 10.20.30.102:57891 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Sun Sep  9 21:58:51 2012 10.20.30.102:57891 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Sun Sep  9 21:58:51 2012 10.20.30.102:57891 Local Options hash (VER=V4): 'f7df56b8'
Sun Sep  9 21:58:51 2012 10.20.30.102:57891 Expected Remote Options hash (VER=V4): 'd79ca330'
Sun Sep  9 21:58:51 2012 10.20.30.102:57891 TLS: Initial packet from 10.20.30.102:57891, sid=9f2def35 408729c4
Sun Sep  9 21:59:51 2012 10.20.30.102:57891 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Sep  9 21:59:51 2012 10.20.30.102:57891 TLS Error: TLS handshake failed
Sun Sep  9 21:59:51 2012 10.20.30.102:57891 SIGUSR1[soft,tls-error] received, client-instance restarting

everything starts fine, more or less; certs are loading as the should which is what I'm interested in.

—— server config:

mode server proto udp port 1194 dev tap0 server-bridge 10.20.30.1 255.255.255.0 10.20.30.20 10.20.30.30 keepalive 15 60 daemon verb 3 client-to-client dh /tmp/openvpn/dh.pem ca /tmp/openvpn/ca.crt cert /tmp/openvpn/cert.pem key /tmp/openvpn/key.pem management localhost 5001

—— Tunnelblick client conf (certs have been removed in this paste) client dev tap proto udp remote x.x.x.x 1194 nobind mute-replay-warnings cipher BF-CBC comp-lzo pull verb 5 <ca> </ca> <cert> </cert> <key> </key>

—— Both client-server confirms tls-error, I'm not sure were to go from here :/

cheers!

[realdreams]

DD-WRT v24-sp2 (07/20/12) std - build 19519 ASUS RT-N13U B1

OpenVPN TLS_ERROR: BIO read tls_read_plaintext error: error:1408F119:lib(20):func(143):reason(281)

I can launch the exact same config with openvpn on optware and it works just fine. The same config also works on build 17027.

Tue Sep 11 09:44:59 2012 us=764094 MULTI: multi_create_instance called
Tue Sep 11 09:44:59 2012 us=764511 192.168.3.150:57073 Re-using SSL/TLS context
Tue Sep 11 09:44:59 2012 us=764733 192.168.3.150:57073 LZO compression initialized                           
Tue Sep 11 09:44:59 2012 us=765626 192.168.3.150:57073 Control Channel MTU parms [ L:1558 D:166 EF:66 EB:0 ET:0 EL:0 ]
Tue Sep 11 09:44:59 2012 us=765914 192.168.3.150:57073 Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Sep 11 09:44:59 2012 us=766456 192.168.3.150:57073 Local Options String: 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 0,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-server'
Tue Sep 11 09:44:59 2012 us=766647 192.168.3.150:57073 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 1,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-client'
Tue Sep 11 09:44:59 2012 us=767009 192.168.3.150:57073 Local Options hash (VER=V4): '162b04de'               
Tue Sep 11 09:44:59 2012 us=767359 192.168.3.150:57073 Expected Remote Options hash (VER=V4): '9e7066d2'     
RTue Sep 11 09:44:59 2012 us=767854 192.168.3.150:57073 TLS: Initial packet from 192.168.3.150:57073, sid=fe519695 74b6bf96
WRRWRWRWWWWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRRRRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRTue Sep 11 09:45:02 2012 us=686984 192.168.3.150:57073 VERIFY OK: depth=1,                   
Tue Sep 11 09:45:02 2012 us=713276 192.168.3.150:57073 VERIFY OK: depth=0,                       
WRWRWRWRWRWRWRWRWRTue Sep 11 09:45:03 2012 us=568135 192.168.3.150:57073 TLS_ERROR: BIO read tls_read_plaintext error: error:1408F119:lib(20):func(143):reason(281)                          
Tue Sep 11 09:45:03 2012 us=568398 192.168.3.150:57073 TLS Error: TLS object -> incoming plaintext read error
Tue Sep 11 09:45:03 2012 us=568602 192.168.3.150:57073 TLS Error: TLS handshake failed                       
Tue Sep 11 09:45:03 2012 us=570124 192.168.3.150:57073 SIGUSR1[soft,tls-error] received, client-instance restarting

[Sash]

i see this also on RALINK RT305x

DD-WRT v24-sp2 std (c) 2012 NewMedia?-NET GmbH Release: 09/12/12 (SVN revision: 19925)

TLS_ERROR: BIO read tls_read_plaintext error: error:1408F119:lib(20):func(143):reason(281)
TLS Error: TLS object -> incoming plaintext read error
TLS Error: TLS handshake failed
SIGUSR1[soft,tls-error] received, client-instance restarting

[BrainSlayer]

simply kernel config problem (CONFIG_EPOLL missing). should be fixed now

[sorcer]

Stupid question, but how do I obtain this fix? :) Thanks guys, I'm just puzzled most of the time.

[sorcer]

Replying to BrainSlayer:

simply kernel config problem (CONFIG_EPOLL missing). should be fixed now

Can you please point me in any direction on how to get this fix? Thank you!

[Taubin]

I don't see a newer build since this was changed to "fixed" how do I get this working? Thanks

[davem]

problem remains as of r19963. server side:

Tue Sep 18 05:51:25 2012 us=407211 1.2.3.4:1055 TLS_ERROR: BIO read tls_read_plaintext error: error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac
Tue Sep 18 05:51:25 2012 us=407233 1.2.3.4:1055 TLS Error: TLS object -> incoming plaintext read error
Tue Sep 18 05:51:25 2012 us=407243 1.2.3.4:1055 TLS Error: TLS handshake failed

[dx2003]

Very similar issue on the 19519 version. The OpenVPN server doesn't process the client connections....

[mlerley]

I had exactly the same problem as sorcer -- started with 19519, downgraded to 18774 and got the new error. Trying to connect a Linksys E3000 with a Linksys E3200. 3200 configured as server is running 17201 mega and I can connect to it perfectly from an ubuntu box. I downgraded the E3000 to the same version (17201 openvpn nv60k) and now they are working perfectly.

[rogermac]

Crediting renatopi, above, I believe I have narrowed down the bug. I'm running DD-WRT as an OpenVPN client, hooked-up to an Open-VPN bulletproof server on Mac OSX hosting not less than 15 connections at a time.

DD-WRT doesn't have ANY problem with OpenVPN. The problem in the last releases preventing OpenVPN to apparently work is that there is a regression in the libraries encoding SHA-128 and SHA-256, that are - by chance - the default ciphers suggested by DD-WRT web GUI in establishing TLS.

The linked libraries appear to be able to generate a correct TLS HMAC, but are unable to correctly check the returning packet from the server (in my client configuration, I suppose the situation is reversed when acting as a server).

The observed behaviour is in fact:

• DD-WRT OpenVPN Client sends a SH-256 encoded TLS HMAC to the server
• The server successfully checks the HMAC and replies with an encoded packet (it wouldn't be answering if the HMAC was incorrect)
• DD-WRT discards the reply claiming an encoding error.

Thus there are in my opinion two advices to be kept in consideration:

a) For any user willing to use OpenVPN with TLS-auth in the current releases, simply force a cypher not incurring in the problem, as already well documented by renatopi, that I publicly thank for his work. For the client OpenVPN config, this can in example be accomplished by setting TLS-cypher in the gui to "none" and inserting tls-cypher = EDH-RSA-DES-CBC3-SHA in the additional parameters (provided that the server supports this encoding, otherwise use another of the cyphers indicated by renatopi). My system is working smoothly after adopting this workaround, and I expect the same if DD-WRT is used as a Server.

b) For the development team, I suggest to simply check the interface with the SHA-xxx libraries, whatever they are. It seems to be a very minor issue with the DD-WRT implementation.

Thanks everybody

Rogermac

[sorcer]

I still haven't fixed this issue :/

[pfarao]

I can't get this to work either using build 19519 with rogermac's suggestion. Does anybody have a working server config+client config?

[Bronk-S]

Dear all,

As Pfarao said the suggestion from rogermac didnt resolve the issue neither...

Any suggestion ? I have tried another build from fractal 20115 and didn't works presenting the same symptoms...

Many thanks and regards.

[spod]

I've managed to work around this problem by following Rogermacs suggestion to avoid SHA. So I set "tls-cipher MD5" instead of SHA256 in my server config. "DES" works as well. "AES256" on the other side does not work. Someone please let me know how to get a list of supported ciphers. My client config does not have any tls-cipher (line is missing).

All tested on Linksys E3200 using dd-wrt.v24-19519_NEWD-2_K2.6_openvpn-nv60k.bin

Edit: Sorry was a bit too fast with my reply. Heres what I'm currently using and it seems to work so far:

cipher BF-CBC tls-cipher MD5 auth MD5

Both needs to be on client and server side. Be aware that those options are not very secure and just for testing.

[kuruczfarm]

Replying to spod: You can add the following line to your client config file:

tls-cipher <TLS-CIPHER>

where <TLS-CIPHER> is a parameter. To find out which parameter can be used, run the following on your windows machine in ..\openvpn\bin folder:

openvpn --show-tls

For me these are valid: ECDHE-RSA-AES256-SHA ECDHE-ECDSA-AES256-SHA DHE-RSA-AES256-SHA DHE-DSS-AES256-SHA DHE-RSA-CAMELLIA256-SHA DHE-DSS-CAMELLIA256-SHA ECDH-RSA-AES256-SHA ECDH-ECDSA-AES256-SHA AES256-SHA CAMELLIA256-SHA PSK-AES256-CBC-SHA ECDHE-RSA-DES-CBC3-SHA ECDHE-ECDSA-DES-CBC3-SHA EDH-RSA-DES-CBC3-SHA EDH-DSS-DES-CBC3-SHA ECDH-RSA-DES-CBC3-SHA ECDH-ECDSA-DES-CBC3-SHA DES-CBC3-SHA PSK-3DES-EDE-CBC-SHA ECDHE-RSA-AES128-SHA ECDHE-ECDSA-AES128-SHA DHE-RSA-AES128-SHA DHE-DSS-AES128-SHA DHE-RSA-SEED-SHA DHE-DSS-SEED-SHA DHE-RSA-CAMELLIA128-SHA DHE-DSS-CAMELLIA128-SHA ECDH-RSA-AES128-SHA ECDH-ECDSA-AES128-SHA AES128-SHA SEED-SHA CAMELLIA128-SHA IDEA-CBC-SHA PSK-AES128-CBC-SHA ECDHE-RSA-RC4-SHA ECDHE-ECDSA-RC4-SHA ECDH-RSA-RC4-SHA ECDH-ECDSA-RC4-SHA RC4-SHA RC4-MD5 PSK-RC4-SHA EDH-RSA-DES-CBC-SHA EDH-DSS-DES-CBC-SHA DES-CBC-SHA EXP-EDH-RSA-DES-CBC-SHA EXP-EDH-DSS-DES-CBC-SHA EXP-DES-CBC-SHA EXP-RC2-CBC-MD5 EXP-RC4-MD5

[nik-k]

Cipher does not seem to be the problem:

cipher AES-192-CBC tls-cipher AES256-SHA

works well for me.

​http://tomatousb.org/forum/t-551699/openvpn-hmac-authentication-failed-in-bidirectional-mode-tls

Look at the last post...

[gRim]

I eventually managed to make it work for me as well (revision 19519)

Running OpenVPN server on the router with config via GUI

Encryption Cypher - NONE Hash Algorithm - NONE TLS Cipher - NONE

(NO TLS Auth Key)

Plus 3 additional lines in "Additional Config": cipher BF-CBC tls-cipher EDH-RSA-DES-CBC3-SHA auth SHA1

---

I also included the same 3 lines in the client config: tls-cipher EDH-RSA-DES-CBC3-SHA cipher BF-CBC auth SHA1

- Hope this helps someone

[fastfwd]

gRim: Thanks for posting; it's encouraging to see activity on this bug, even if it's not from developers.

Is your OpenVPN client another DD-WRT box? If so, have you verified (via wireshark traces or whatever) that the packets passing between the routers are actually encrypted?

[nik-k]

Leave off the direction parameter in config directive tls-auth /path/to/ta.key (0|1) and it will work.

[fastfwd]

It's the new year, so I'm checking up on old open bugs I've filed. Has any progress been made on this one? Is there any more information I can provide that will help to resolve it?

[kuruczfarm]

What about build 20435?

[pfar]

I'm using the same build. Still can't get it to work though. Do you have full server+firewall+client config?

Replying to gRim:

I eventually managed to make it work for me as well (revision 19519)

Running OpenVPN server on the router with config via GUI

Encryption Cypher - NONE Hash Algorithm - NONE TLS Cipher - NONE

(NO TLS Auth Key)

Plus 3 additional lines in "Additional Config": cipher BF-CBC tls-cipher EDH-RSA-DES-CBC3-SHA auth SHA1

---

I also included the same 3 lines in the client config: tls-cipher EDH-RSA-DES-CBC3-SHA cipher BF-CBC auth SHA1

- Hope this helps someone

[gRim]

@fastfwd: I'm not using router to router VPN. I only use VPN server on DDWRT router and I use a linux server, an android phone and a windows laptop with OpenVPN gui as clients. I use a Bridged VPN so I can use ftp and sharing services more secure without exposing them to the wan and others (WOL, RDP, SSH,etc) I have been meaning to test the encription of the connection, but I couldn't get some spare time for this. I will post the wireshark test results when I have them.

@pfar

this is my client config on the openVPN GUI on my windows station, not all settings are mandatory (ex: it works without redirect-gateway if you don't want your wan traffic redirected through the vpn)

client dev tap0 proto udp remote blabladnsaddressblabla 1194 resolv-retry infinite nobind ca ca.crt cert blablacert.crt key blablakey.key ns-cert-type server tls-cipher EDH-RSA-DES-CBC3-SHA cipher BF-CBC auth SHA1 dhcp-option DNS 192.168.1.1 dhcp-option DNS 8.8.8.8 redirect-gateway

The server config in DDWRT is bellow (in order): (I have no startup commands or firewall cmds (except some for asiablock))

Enable wanup gui bridge disable 192.168.1.200 192.168.1.250 192.168.1.1 255.255.255.0 Disable 1194 udp none none enable none disabled disable enable disable 1500 (blank) "Cert" "Cert" "Cert" "Cert"

and the lines specified below in the additional config: cipher BF-CBC tls-cipher EDH-RSA-DES-CBC3-SHA auth SHA1

Let me know if it worked or if you still have issues please post the log from Status -> OPENVPN

[Leeeeeo]

Workaround described by gRim is working here - DD-WRT v24-sp2 (06/08/12) big (SVN revision 19342) and OpenVPN 2.2.1 Win32-MSVC++. My router is a WNDR4000.

I have a TUN connection since I need to use the new iPhone client.

Unfortunately, when I try to connect through iPhone, I got a new error (TLS_ERROR: BIO read tls_read_plaintext error: error:1408A0C1:lib(20):func(138):reason(193)). It seems that iOS client doesn't support the cipher user in the workaround.

Any other workaround for this issue?

Thanks in advance...

[pfar]

@gRim Thanks for the reply, but I need to use TUN as well as I am using an Android client (Samsung Galaxy SII), so it won't work.

Replying to gRim:

..

@Leeeeeo How did you do your setup as you have TUN?

Replying to Leeeeeo:

..

[fastfwd]

Update: A year later, OpenVPN is still broken on the latest BrainSlayer? build (r21286).

OpenVPN operation was restored on Kong's branch with his r20500 release, so I am using his builds and I am no longer personally affected by the problem. However, I would still be happy to provide any information that the devs desire regarding my configuration, etc., if it might help to fix the problem in the BrainSlayer? builds.