Previous Thread
No joy. OpenVPN Server still fails on Build 19215.
Symptoms are identical to those of builds 19200 and 19210, described here:
http://svn.dd-wrt.com/ticket/2536
Sigh.
http://www.desipro.de/ddwrt/r19215/
Build r19215 +++++++++
Fixed:
openvpn gui fix
limit_pptp fix
May 9, 2012 1:06 AM
May 10, 2012 9:30 AM
Well, sash has (justifiably) closed that ticket, with this comment: "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."
His nightly builds aren't the same as Kong's, of course, so it would be nice to hear from anyone who is successfully (or unsuccessfully) running OpenVPN Server in TLS mode on Kong 19215.
So far, I've had no luck getting it to work, and even with verbosity set to 7, I haven't seen any clear cause for the failure in the logs.
I tried removing as much complexity from the configuration as possible: setting cipher and hash to 'none' and removing the comp-lzo, tls-auth, remote-cert-tls, fragment, and mssfix options. Even with that bare-bones configuration, which didn't do much more than specify TAP and UDP, Kong 19215 failed with TLS Errors whenever a client tried to connect.
After I downgraded to 18730, both my usual configuration and the bare-bones configuration worked perfectly.
May 10, 2012 1:10 PM
Reopened your ticket.
Have the same tls errors.
I'm back @ 18730
@ Kong thanx for creating a kingkong build for the E4200
Could you have a look at the openvpn issues.
May 12, 2012 9:57 PM
Wed May 9 21:59:18 2012 us=934621 Restart pause, 2 second(s)
Wed May 9 21:59:20 2012 us=934800 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Wed May 9 21:59:20 2012 us=935025 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Wed May 9 21:59:20 2012 us=935196 NOTE: --script-security method='system' is deprecated due to the fact that passed parameters will be subject to shell expansion
Wed May 9 21:59:20 2012 us=935415 Re-using SSL/TLS context
Wed May 9 21:59:20 2012 us=935617 LZO compression initialized
Wed May 9 21:59:20 2012 us=936184 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Wed May 9 21:59:20 2012 us=936501 Socket Buffers: R=[114688->131072] S=[114688->131072]
Wed May 9 21:59:20 2012 us=936791 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Wed May 9 21:59:20 2012 us=937154 Local Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Wed May 9 21:59:20 2012 us=937337 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Wed May 9 21:59:20 2012 us=937667 Local Options hash (VER=V4): '41690919'
Wed May 9 21:59:20 2012 us=937992 Expected Remote Options hash (VER=V4): '530fdded'
Wed May 9 21:59:20 2012 us=938232 UDPv4 link local: [undef]
Wed May 9 21:59:20 2012 us=938447 UDPv4 link remote: x.x.x.x:2010
Wed May 9 21:59:21 2012 us=150175 TLS: Initial packet from x.x.x.x:2010, sid=d063b307 cce0b9d7
Wed May 9 21:59:25 2012 us=265056 VERIFY OK: depth=1, /C=CN/ST=SH/L=ShangHai/O=yeax/CN=yeax_CA/emailAddress=admin@ramhost
Wed May 9 21:59:25 2012 us=267694 VERIFY ERROR: depth=0, error=certificate signature failure: /C=CN/ST=SH/L=ShangHai/O=yeax/CN=ramhost/emailAddress=admin@ramhost
Wed May 9 21:59:25 2012 us=268572 TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:lib(20):func(144):reason(134)
Wed May 9 21:59:25 2012 us=268800 TLS Error: TLS object -> incoming plaintext read error
Wed May 9 21:59:25 2012 us=268981 TLS Error: TLS handshake failed
Sun May 13 10:46:33 2012 us=955088 Local Options hash (VER=V4): '41690919'
Sun May 13 10:46:33 2012 us=955429 Expected Remote Options hash (VER=V4): '530fdded'
Sun May 13 10:46:33 2012 us=955669 UDPv4 link local: [undef]
Sun May 13 10:46:33 2012 us=955884 UDPv4 link remote: x.x.x.x:2010
Sun May 13 10:46:34 2012 us=99229 TLS Error: Unroutable control packet received from x.x.x.x:2010 (si=3 op=P_CONTROL_V1)
Sun May 13 10:46:34 2012 us=99766 TLS Error: Unroutable control packet received from x.x.x.x:2010 (si=3 op=P_CONTROL_V1)
Sun May 13 10:46:34 2012 us=274659 TLS Error: Unroutable control packet received from x.x.x.x:2010 (si=3 op=P_ACK_V1)
Sun May 13 10:46:35 2012 us=510599 TLS Error: Unroutable control packet received from x.x.x.x:2010 (si=3 op=P_CONTROL_V1)
Sun May 13 10:46:35 2012 us=511128 TLS Error: Unroutable control packet received from x.x.x.x:2010 (si=3 op=P_CONTROL_V1)
Sun May 13 10:46:35 2012 us=712138 NOTE: --mute triggered...
tried upgrade twice, but I still can not get vpn connection, back to 18730
May 12, 2012 10:36 PM
Debiansid: Thanks for posting; it's nice to know that Basmaf and I aren't the only ones seeing this bug.
Unfortunately, the DD-WRT OpenVPN developer hasn't seen it himself, and he's already expressed an understandable reluctance to work on bugs that haven't been confirmed by multiple users... So if you have a moment, you might bring more attention to the problem by posting your experience with build 19215 as a comment to DD-WRT ticket 2536 ( http://svn.dd-wrt.com/ticket/2536 ).
May 13, 2012 2:40 AM
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
One of the most common problems in setting up OpenVPN is that the two OpenVPN daemons on either side of the connection are unable to establish a TCP or UDP connection with each other.
This is almost a result of:
A perimeter firewall on the server's network is filtering out incoming OpenVPN packets (by default OpenVPN uses UDP or TCP port number 1194).
A software firewall running on the OpenVPN server machine itself is filtering incoming connections on port 1194. Be aware that many OSes will block incoming connections by default, unless configured otherwise.
A NAT gateway on the server's network does not have a port forward rule for TCP/UDP 1194 to the internal address of the OpenVPN server machine.
The OpenVPN client config does not have the correct server address in its config file. The remote directive in the client config file must point to either the server itself or the public IP address of the server network's gateway.
Another possible cause is that the windows firewall is blocking access for the openvpn.exe binary. You may need to whitelist (add it to the "Exceptions" list) it for OpenVPN to work.
May 13, 2012 3:19 AM
Kt_haddock: Thanks, but that error -- "key negotiation failed" -- isn't the one we're seeing with build 19215. And the errors we ARE seeing go away when the router's downgraded to build 18730 with no other changes, which would seem to rule out problems with external firewalls or incorrect client configurations.
May 13, 2012 1:29 PM
updated: May 13, 2012 1:39 PM
I'm seeing the error as well:
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
20120506 07:08:29 TCP/UDP: Closing socket
20120506 07:08:29 I SIGUSR1[soft tls-error] received process restarting
I also added a comment to the trac page.
Member
- member since: 02/28/2010
- rank: 5 of 30050
- 2 articles authored
- 27 forum threads started
- 1110 comments
May 14, 2012 1:54 AM
Kong: Is that possible? I don't know how to connect from the LAN side without causing routing conflicts; I haven't been able to do it even with build 18730.
May 14, 2012 10:59 AM
Same result as Xscape
Connection from lan to server isn't working.
Switched between builds 18730/19215 to double check.
Checked with ubuntu and windows.
Member
- member since: 02/28/2010
- rank: 5 of 30050
- 2 articles authored
- 27 forum threads started
- 1110 comments
May 15, 2012 2:35 PM
updated: May 15, 2012 2:39 PM
See:
http://svn.dd-wrt.com:8000/ticket/2536#comment:10
http://svn.dd-wrt.com:8000/ticket/2535#comment:1
May 15, 2012 5:58 PM
updated: May 15, 2012 5:58 PM
Kong said: See: http://svn.dd-wrt.com:8000/ticket/2536#comment:10 http://svn.dd-wrt.com:8000/ticket/2535#comment:1
Maybe I'm missing something, but I don't understand what ticket 2535 has to do with this problem. My VPN provider uses SHA1, and my client is configured to use SHA1 on r19215; I cannot establish a conenection.
May 16, 2012 1:39 AM
updated: May 16, 2012 2:46 AM
according to the openVPN 2.2 manual sha1 is the default. but with post r18730 builds i have not been able to establish a connection, due to the hmac error of ticket #2536.
after i set the authenticaton protocol to sha256 by entering "auth sha256" in both the server and client config ( i don't use the gui setup ) , i was able to establish a connection again.
it seems that somewhere between r18730 and r19028 the sha1 implementation is broken.
i have commented ticket #2536 too.
May 16, 2012 4:46 AM
Anyone any success using sha256?
My openvpn didn't buzz whether its auth sha256 or auth none
@PetervdM: Did you set the cipher and which build are you using, I'm on king kong 19215 10.3mb.
May 16, 2012 6:09 AM
Wed May 16 17:20:30 2012 us=90971 WARNING: No server certificate verification me
thod has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Wed May 16 17:20:30 2012 us=91280 NOTE: the current --script-security setting ma
y allow this configuration to call user-defined scripts
Wed May 16 17:20:30 2012 us=91520 NOTE: --script-security method='system' is dep
recated due to the fact that passed parameters will be subject to shell expansio
n
Wed May 16 17:20:30 2012 us=91828 Re-using SSL/TLS context
Wed May 16 17:20:30 2012 us=92139 LZO compression initialized
Wed May 16 17:20:30 2012 us=92850 Control Channel MTU parms [ L:1570 D:138 EF:38 EB:0 ET:0 EL:0 ]
Wed May 16 17:20:30 2012 us=93240 Socket Buffers: R=[114688->131072] S=[114688->131072]
Wed May 16 17:20:30 2012 us=93679 Data Channel MTU parms [ L:1570 D:1450 EF:70 EB:135 ET:0 EL:0 AF:3/1 ]
Wed May 16 17:20:30 2012 us=94282 Local Options String: 'V4,dev-type tun,link-mtu 1570,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA256,keysize 256,k
ey-method 2,tls-client'
Wed May 16 17:20:30 2012 us=94541 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1570,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA256,key
size 256,key-method 2,tls-server'
Wed May 16 17:20:30 2012 us=95071 Local Options hash (VER=V4): 'fc8ba345'
Wed May 16 17:20:30 2012 us=95573 Expected Remote Options hash (VER=V4): '79a26cd9'
Wed May 16 17:20:30 2012 us=95894 UDPv4 link local: [undef]
Wed May 16 17:20:30 2012 us=96201 UDPv4 link remote: x.x.x.x:2010
Wed May 16 17:20:30 2012 us=296441 TLS: Initial packet from x.x.x.x:2010, sid=75d24941 8f7abb44
Wed May 16 17:20:30 2012 us=381000 TLS: new session incoming connection from x.x.x.x:2010
Wed May 16 17:20:30 2012 us=381218 TLS Error: reading acknowledgement record from packet
Wed May 16 17:20:32 2012 us=356376 TLS Error: reading acknowledgement record from packet
Wed May 16 17:20:36 2012 us=487076 TLS Error: reading acknowledgement record from packet
Wed May 16 17:20:45 2012 us=218063 TLS Error: reading acknowledgement record from packet
Wed May 16 17:21:01 2012 us=191800 TLS Error: reading acknowledgement record from packet
still no lucky, 18730 is good for that.
May 16, 2012 6:15 AM
I was wondering is it possible to install DLNA version and use ipkg openvpn instead of current one, will it work?
May 16, 2012 7:23 AM
Wed May 16 19:32:30 2012 us=504645 [UNDEF] Inactivity timeout (--ping-restart), restarting
Wed May 16 19:32:30 2012 us=505459 TCP/UDP: Closing socket
Wed May 16 19:32:30 2012 us=505802 SIGUSR1[soft,ping-restart] received, process restarting
Wed May 16 19:32:30 2012 us=506068 Restart pause, 2 second(s)
newest error shows me timeout. btw, 19215 as openvpn client. and 19028 is newest working version for me.
May 16, 2012 7:36 AM
updated: May 16, 2012 7:39 AM
@xscape: i'm using kingkong r19215
server.conf:
dev tap0
secret /mnt/OVPN/static.key
comp-lzo
port 8080
proto tcp-server
fast-io
verb 1
daemon
management localhost 5001
mute-replay-warnings
script-security 2
auth sha256
client.conf:
remote xxxxxxx.yyyyyyyyyyy.zzz
port 8080
proto tcp-client
dev tap
secret static.key
comp-lzo yes
verb 4
disable-occ
auth sha256
mute 10
mute-replay-warnings
route-gateway 172.18.1.254
redirect-gateway def1
+ several route statements
routerup.sh:
killall openvpn
openvpn --mktun --dev tap0
brctl addif br0 tap0
ifconfig tap0 hw ether xx:xx:xx:xx:xx:xx
ifconfig tap0 0.0.0.0 promisc up
ln -s /usr/sbin/openvpn /tmp/myvpn
/tmp/myvpn /mnt/OVPN/server.conf
i'm basically using the tutorial openvpn the easy way:
http://www.dd-wrt.com/wiki/index.php/VPN_%28the_easy_way%29_v24%2B
and amended things when that became necessary. 8080/tcp is for bypassing a proxy.
May 16, 2012 8:44 AM
debiansid said: I was wondering is it possible to install DLNA version and use ipkg openvpn instead of current one, will it work?Absolutely! I have run OpenVPN in this way for years using an Optware script to setup the configuration. Just shut off OpenVPN in the GUI, no need to change build unless you need DLNA. You need "OTRW" and external storage though.
May 16, 2012 9:01 AM
REQ: leave USB disabled by default (e.g. after 30/30/30) in future Kong builds.
Some say that leaving USB enabled by default makes an E2000 crash. So, by disabling it by default, E2000 users may use Kong nv60k builds without fear or bricking their router.
May 16, 2012 9:55 AM
updated: May 16, 2012 10:08 AM
wabe said:debiansid said: I was wondering is it possible to install DLNA version and use ipkg openvpn instead of current one, will it work?Absolutely! I have run OpenVPN in this way for years using an Optware script to setup the configuration. Just shut off OpenVPN in the GUI, no need to change build unless you need DLNA. You need "OTRW" and external storage though.
I just tried to run openvpn from optware on build 18730 vpn version, but it complained openssl cannot support sha256, so I had to switch back to default openvpn binary.
"Wed May 16 22:57:53 2012 us=577120 Message hash algorithm 'sha256' not found (OpenSSL)
Member
- member since: 02/28/2010
- rank: 5 of 30050
- 2 articles authored
- 27 forum threads started
- 1110 comments
May 16, 2012 3:29 PM
debiansid said:I currently run 18730 kingkong build with this setup, works perfectly. I'm actually posting this message through an OpenVPN connection to my routerwabe said:I just tried to run openvpn from optware on build 18730 vpn version, but it complained openssl cannot support sha256, so I had to switch back to default openvpn binary. "Wed May 16 22:57:53 2012 us=577120 Message hash algorithm 'sha256' not found (OpenSSL)debiansid said: I was wondering is it possible to install DLNA version and use ipkg openvpn instead of current one, will it work?Absolutely! I have run OpenVPN in this way for years using an Optware script to setup the configuration. Just shut off OpenVPN in the GUI, no need to change build unless you need DLNA. You need "OTRW" and external storage though.
Add Your Reply
Sponsored Links
Copyright © 2013
Capable Networks LLC.. All Rights Reserved.
RSS |
Privacy Policy |
Advertise With Us |
Terms of Use |
About Us |
Contact Us |
Site Map
Our Capable Community Network:
DVR playground |
Explore3DTV |
MediaSmart Home |
My Open Router |
DijitCommunity |
Robo Community |
Sansa Community |
TechLore |
TiVo Community
MyOpenRouter.com is not affiliated with NETGEAR®. NETGEAR is a registered trademark of NETGEAR, Inc. in the United States and/or other countries. Other brand names mentioned herein are for identification purposes only and may be trademarks of their respective holder(s). © 2011 NETGEAR, Inc. All rights reserved.
