Nighthawk [DD-WRT (Kong)] OpenVPN Client (PIA)

148 posts / 0 new
Last post
kallsop
kallsop's picture
Likewise, be glad to help

Likewise, be glad to help with the R7000 for the next 2 days, then going on vacation for 2 weeks.

Kong
Kong's picture
kamaaina said:

kamaaina said:

Kong said:

kamaaina said: Just configured a 2nd AC56U with PIA as well, latest 24345 build. Let's see if we can collect some data to give Kong some clues on what might cause these freezes. Now, for a plain freshly flashed box, what do I need to enable to collect the right/useful info? It says syslogd disabled but I can't seem to find a check box to turn it on. Wow, seem like I only needed 15 min for it to hang. Just turned VPN off and on again and it's working again. I did not have to restart the router. Where does the keepalive 10 120 go? Tunnel MTU setting (Default: 1400) Tunnel UDP Fragment (Default: Disable) Tunnel UDP MSS-FixEnable Disable Additional Config ??

Well it looks like I can also reproduce it on my test setup. So now I can start digging.

Great. If you want me to change some settings or try anything modified/tweaked/patched, please let me know. This is a second box running in parallel so it does not get anybody screeming when it hangs and can easily be restarted. 

Try the following.:

 

Tunnel MTU setting: 1400

Tunnel UDP Fragment: 1300

Tunnel UDP MSS-Fix: enable

 

In Dougs log I saw these:

 

daemon.err openvpn[1597]: tun packet too large on write (tried=1402,max=1400)

 

So his stalls come from an MTU problem. His default PIA config sets tun-mtu 1500, which might be too large and if you have problems with your isp you will run into the same problems.

Thus try the above, maybe add:

 

keepalive 10 120

 

under Additional Config.

kamaaina
kamaaina's picture
Tried to use the three Tunnel

Tried to use the three Tunnel settings and could not connect. Got an error for the MTU settings, need to do this again to copy/paste the text. I am using their DD-WRT setup on the website otherwise, which might be different from the script Doug is using. https://www.privateinternetaccess.com/pages/client-support/#ddwrt_openvpn

kamaaina
kamaaina's picture
If I disable the two UDP

If I disable the two UDP adjustments the Internet comes back (leaving MTU at 1400).
This is what the OpenVPN status says shortly before the Internet is dead:

Serverlog Clientlog 20140617 15:08:50 I OpenVPN 2.3.4 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Jun 13 2014
20140617 15:08:50 I library versions: OpenSSL 1.0.1h 5 Jun 2014 LZO 2.06
20140617 15:08:50 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:16
20140617 15:08:50 W WARNING: file '/tmp/password.txt' is group or others accessible
20140617 15:08:50 W NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
20140617 15:08:50 W WARNING: normally if you use --mssfix and/or --fragment you should also set --tun-mtu 1500 (currently it is 1400)
20140617 15:08:50 Socket Buffers: R=[180224->131072] S=[180224->131072]
20140617 15:08:50 I UDPv4 link local: [undef]
20140617 15:08:50 I UDPv4 link remote: [AF_INET]198.24.140.66:1194
20140617 15:08:50 TLS: Initial packet from [AF_INET]198.24.140.66:1194 sid=
20140617 15:08:50 W WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
20140617 15:08:50 VERIFY OK: depth=1 C=US ST=OH L=Columbus O=Private Internet Access CN=Private Internet Access CA emailAddress=secure@privateinternetaccess.com
20140617 15:08:50 Validating certificate key usage

Whenever I turn the fragment on it kills the connection. I tried this with MTU 1500 as well.

Kong
Kong's picture
Hmmm if you remove the mssfix

Hmmm if you remove the mssfix and empty fragement and just change tun-mtu to 1500 like it was in older builds, does that get you anywhere.

Kong
Kong's picture
Also what you can check if

Also what you can check if this rule makes a difference, add to commands:

iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

and press ave firewall. You can check with iptables -vnL after some time if any packages math that rule e.g.:

0 0 TCPMSS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU

in my case it is zero

kamaaina
kamaaina's picture
"Plain" VPN connection with

"Plain" VPN connection with MTU 1500 works (no UDP settings). I also played with the three MTU settings again (on/off), it seems it's the Tunnel UDP Fragment entry that kills the connection. If I leave it blank (default: disable) it works, when I enter the 1300 it dies. For the tunnel MTU setting, both 1400 and 1500 seem to work, and for Tunnel UDP MSS-Fix it works with both enabled or disabled. 

I also entered the FW scripts now, and at this time, have MSS-Fix on disabled. I did not enter the keep alive entry yet. The connection is working right now. I will reboot again and then we'll see how long it might stay up. 

I see this in the VPN log now though, even though from a user perspective it looks like I have a steady connection. Not sure what this is. 

20140617 18:20:30 N write UDPv4: Message too long (code=90) 
20140617 18:20:50 N write UDPv4: Message too long (code=90) 
20140617 18:21:10 N write UDPv4: Message too long (code=90) 
20140617 18:21:29 NOTE: --mute triggered... 
20140617 18:23:20 2 variation(s) on previous 3 message(s) suppressed by --mute 
20140617 18:23:20 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16 
20140617 18:23:20 D MANAGEMENT: CMD 'state' 
20140617 18:23:20 MANAGEMENT: Client disconnected 
20140617 18:23:20 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16 
20140617 18:23:20 D MANAGEMENT: CMD 'state' 
20140617 18:23:20 MANAGEMENT: Client disconnected 
20140617 18:23:20 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16 
20140617 18:23:20 D MANAGEMENT: CMD 'state' 
20140617 18:23:20 MANAGEMENT: Client disconnected 
20140617 18:23:20 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16 
20140617 18:23:20 D MANAGEMENT: CMD 'log 500' 

Also found this:
7   404 TCPMSS tcp  --  * *  0.0.0.0/0  0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU

Kong
Kong's picture
 Also found this: 7   404

 Also found this: 7   404 TCPMSS tcp  --  * *  0.0.0.0/0  0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU

OK, that sounds interesting. Because there are only two changes in the last few month regarding mtu and openvpn, this rule and the tun-mtu setting and if it is an MTU problem then usually only a few people are affected and since only a handful people report a problem it would explain things.

kamaaina
kamaaina's picture
That was already after a few

That was already after a few min, say 30 min or so. I don't have access to the box right now but will check again in the morning and see if there is more. It did not freeze the connection yet while I was using it.

kallsop
kallsop's picture
I changed Tunnel MTU Setting

I changed Tunnel MTU Setting to 1500 last night, still have PIA internet this morning. Also have the 'keepalive 10 120' added, might not be needed?

DougRoberson
DougRoberson's picture
Just an FYI, I'm enjoying

Just an FYI, I'm enjoying uptimes in the 3-4 day range now. Currently, I'm at 54 hours.

Kong
Kong's picture
DougRoberson said: Just an

DougRoberson said: Just an FYI, I'm enjoying uptimes in the 3-4 day range now. Currently, I'm at 54 hours.

Did you change anything, if yes, let me know what so we can add the fix.

DougRoberson
DougRoberson's picture
Per your instructions, I

Per your instructions, I changed the TUN-MTU value to 1500. No other changes since then.

DougRoberson
DougRoberson's picture
BTW, right after posting that

BTW, right after posting that, I dropped connection... but it had been 2 and a half days, so not a big deal :)

kamaaina
kamaaina's picture
The router has been up now 5

The router has been up now 5 days 13 hours, seemingly without dropping the VPN connection. The problem is I run it as parallel and only connect occasionally to it to check, so don't really know if up all the time. I am also only connected via cable, wireless turned off. Not sure if this makes a difference. Given the 5 days plus uptime I am tempted to swap it as the main router again to try. With 15+ devices connected 24/7 and world cup streaming we would know about outages quickly ;-)

It seems I don't have any of the MTU issues now that it is set to 1500. Here is the filter command output after 5 days:
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
18744 2352K ACCEPT 0 -- tun1 * 0.0.0.0/0 0.0.0.0/0
15M 21G ACCEPT 0 -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT udp -- vlan2 * 0.0.0.0/0 0.0.0.0/0 udp spt:67 dpt:68
0 0 DROP udp -- vlan2 * 0.0.0.0/0 0.0.0.0/0 udp dpt:520
0 0 DROP udp -- br0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:520
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:520
0 0 DROP icmp -- vlan2 * 0.0.0.0/0 0.0.0.0/0
3833 123K DROP 2 -- * * 0.0.0.0/0 0.0.0.0/0
1 79 ACCEPT 0 -- lo * 0.0.0.0/0 0.0.0.0/0 state NEW
18574 1700K ACCEPT 0 -- br0 * 0.0.0.0/0 0.0.0.0/0 state NEW
1371 376K DROP 0 -- * * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
5211K 663M ACCEPT 0 -- * tun1 0.0.0.0/0 0.0.0.0/0
15M 20G ACCEPT 0 -- tun1 * 0.0.0.0/0 0.0.0.0/0
0 0 TCPMSS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
0 0 ACCEPT 0 -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT 47 -- * vlan2 192.168.10.0/24 0.0.0.0/0
0 0 ACCEPT tcp -- * vlan2 192.168.10.0/24 0.0.0.0/0 tcp dpt:1723
0 0 lan2wan 0 -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT 0 -- br0 br0 0.0.0.0/0 0.0.0.0/0
0 0 TRIGGER 0 -- vlan2 br0 0.0.0.0/0 0.0.0.0/0 TRIGGER type:in match:0 relate:0
0 0 trigger_out 0 -- br0 * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT 0 -- br0 * 0.0.0.0/0 0.0.0.0/0 state NEW
0 0 DROP 0 -- * * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 5362K packets, 1042M bytes)
pkts bytes target prot opt in out source destination
Chain advgrp_1 (0 references)
pkts bytes target prot opt in out source destination
Chain advgrp_10 (0 references)
pkts bytes target prot opt in out source destination
Chain advgrp_2 (0 references)
pkts bytes target prot opt in out source destination
Chain advgrp_3 (0 references)
pkts bytes target prot opt in out source destination
Chain advgrp_4 (0 references)
pkts bytes target prot opt in out source destination
Chain advgrp_5 (0 references)
pkts bytes target prot opt in out source destination
Chain advgrp_6 (0 references)
pkts bytes target prot opt in out source destination
Chain advgrp_7 (0 references)
pkts bytes target prot opt in out source destination
Chain advgrp_8 (0 references)
pkts bytes target prot opt in out source destination
Chain advgrp_9 (0 references)
pkts bytes target prot opt in out source destination
Chain grp_1 (0 references)
pkts bytes target prot opt in out source destination
Chain grp_10 (0 references)
pkts bytes target prot opt in out source destination
Chain grp_2 (0 references)
pkts bytes target prot opt in out source destination
Chain grp_3 (0 references)
pkts bytes target prot opt in out source destination
Chain grp_4 (0 references)
pkts bytes target prot opt in out source destination
Chain grp_5 (0 references)
pkts bytes target prot opt in out source destination
Chain grp_6 (0 references)
pkts bytes target prot opt in out source destination
Chain grp_7 (0 references)
pkts bytes target prot opt in out source destination
Chain grp_8 (0 references)
pkts bytes target prot opt in out source destination
Chain grp_9 (0 references)
pkts bytes target prot opt in out source destination
Chain lan2wan (1 references)
pkts bytes target prot opt in out source destination
Chain logaccept (0 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT 0 -- * * 0.0.0.0/0 0.0.0.0/0
Chain logdrop (0 references)
pkts bytes target prot opt in out source destination
0 0 DROP 0 -- * * 0.0.0.0/0 0.0.0.0/0
Chain logreject (0 references)
pkts bytes target prot opt in out source destination
0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with tcp-reset
Chain trigger_out (1 references)
pkts bytes target prot opt in out source destination

Startup

linuxloon
linuxloon's picture
I just recently bought a

I just recently bought a R7000 just to run DD-WRT and to connect to PIA via OpenVPN. I used this guide to set it up. Nice little router and thanks kong for all the work you do with DD-WRT, great combo.

http://www.myopenrouter.com/article/46341/How-to-Set-Up-a-VPN-On-NETGEAR...

I added some policy based routing, similer to kallsop config earlier in the thread, so the lower IP's on my local network, like my SIP phone won't be in the VPN but most clients will be.

the VPN is working well, though after reading this thread I an going to be checking a lot closer to see if it is exposing my real IP by dropping / reconnecting in the background.

I am having two issues.

If I enable QoS ( for my SIP phone ) it drop's the VPN. All the clients not on the VPN work but VPN clients will stop working or just not be on the VPN but work.  I do have the firewall / IP table commands in place and have not looked up what the commands actually do but no matter what I try with the QoS it drops the VPN as soon as QoS is enabled.

iptables -N VPN
iptables -F VPN
iptables -I INPUT -i tun0 -j VPN
iptables -I FORWARD -i tun0 -j VPN
iptables -A VPN -i tun0 -o br0 -j ACCEPT
iptables -I POSTROUTING -t nat -o tun0 -j RETURN

anyone able to get QoS and OpenVPN to work togther ?

2nd issue. When I try to enable port forwading for my web server the commands seem to be accepted but what it displayes is just a blank field. That is, I put the info in and when it displays it, everything is blank just one more empty line. I can add a screen shot if that's not clear. I have tried port fowarding, port range forwerding and port triggering .. same thing for all.

I was going to say I am running the most current version but I see kong has just put up a new version as I was writting this post.

 

Sky1111
Sky1111's picture
linuxloon said: I just

linuxloon said: I just recently bought a R7000 just to run DD-WRT and to connect to PIA via OpenVPN. I used this guide to set it up. Nice little router and thanks kong for all the work you do with DD-WRT, great combo. http://www.myopenrouter.com/article/46341/How-to-Set-Up-a-VPN-On-NETGEAR... I added some policy based routing, similer to kallsop config earlier in the thread, so the lower IP's on my local network, like my SIP phone won't be in the VPN but most clients will be. the VPN is working well, though after reading this thread I an going to be checking a lot closer to see if it is exposing my real IP by dropping / reconnecting in the background. I am having two issues. If I enable QoS ( for my SIP phone ) it drop's the VPN. All the clients not on the VPN work but VPN clients will stop working or just not be on the VPN but work.  I do have the firewall / IP table commands in place and have not looked up what the commands actually do but no matter what I try with the QoS it drops the VPN as soon as QoS is enabled. iptables -N VPN iptables -F VPN iptables -I INPUT -i tun0 -j VPN iptables -I FORWARD -i tun0 -j VPN iptables -A VPN -i tun0 -o br0 -j ACCEPT iptables -I POSTROUTING -t nat -o tun0 -j RETURN anyone able to get QoS and OpenVPN to work togther ? 2nd issue. When I try to enable port forwading for my web server the commands seem to be accepted but what it displayes is just a blank field. That is, I put the info in and when it displays it, everything is blank just one more empty line. I can add a screen shot if that's not clear. I have tried port fowarding, port range forwerding and port triggering .. same thing for all. I was going to say I am running the most current version but I see kong has just put up a new version as I was writting this post.

Yes, I am itching to try 24500 tonight as well...

linuxloon
linuxloon's picture
I'm on build 24500 and no

I'm on build 24500 and no issues so far but also no fix's for the 2 issues. enabling QoS still drops the VPN.

I tried with both the ipchains commands in place and removed, no affect on the QoS killing the VPN but is connects fine w/o them in place so I will leave them off for now. To soon to know if it affects stability of the VPN.

question - should a 30-30-30 reset be done when going from one firmware version to another ?

I did do one after fist putting DD-WRT on the router.

 

Kong
Kong's picture
linuxloon said: I'm on build

linuxloon said: I'm on build 24500 and no issues so far but also no fix's for the 2 issues. enabling QoS still drops the VPN. I tried with both the ipchains commands in place and removed, no affect on the QoS killing the VPN but is connects fine w/o them in place so I will leave them off for now. To soon to know if it affects stability of the VPN. question - should a 30-30-30 reset be done when going from one firmware version to another ? I did do one after fist putting DD-WRT on the router.

I'm going to forward this to the guy who normally does the dd-wrt vpn development, maybe he knows why.

kamaaina
kamaaina's picture
@Kong: Thanks for the update.

@Kong: Thanks for the update.

OK, have my R7000 back on WW-DRT w/ 24500. PIA connected. I used the default info from the PIA website again. Let's see how it goes.

kamaaina
kamaaina's picture
Kong said:

Kong said:

linuxloon said: I'm on build 24500 and no issues so far but also no fix's for the 2 issues. enabling QoS still drops the VPN. I tried with both the ipchains commands in place and removed, no affect on the QoS killing the VPN but is connects fine w/o them in place so I will leave them off for now. To soon to know if it affects stability of the VPN. question - should a 30-30-30 reset be done when going from one firmware version to another ? I did do one after fist putting DD-WRT on the router.

I'm going to forward this to the guy who normally does the dd-wrt vpn development, maybe he knows why.

Wow, this is indeed funky. I can confirm this happens to me as well with the freshly installed version. QoS enabled/disabled is like an on/off switch for the VPN client.

linuxloon
linuxloon's picture
Went back to 24345_OLD ( old

Went back to 24345_OLD ( old wireless drivers ) because of issues with client drops on wireless. Not sure if it's an issue with the client or the router but wireless works great on 24345 so I will stick with it for now. The radio on the router was not resetting but the client would drop under heavy use. Client was on 2.4 radio w/broadcom chipset. tried a number of different wireless settings on the router but results were all similar. Fine under low to moderate use but client will drop/reconnect under heavy use.

Also, I was seeing a lot of error's on the openvpn connection, though it was working fine, I would not have seen the errors if I wasn�??t sending the router log to a syslog server. What I was seeing over and over, though again vpn was working fine and passing traffic.

openvpn[1851]: tun packet too large on write (tried=1430,max=1400)
openvpn[1851]: Authenticate/Decrypt packet error: packet HMAC authentication failed

I have changed the MTU to 1500 and openvpn is working fine W/O packet to large error.

I'm testing the connection ever min against a remote server to see if connection ever drop's and exposes the local IP, been up about 24 hours and stable so far.

agaricus
agaricus's picture
I too am having issues with

I too am having issues with OpenVPN and the WAN connection going out. I suffer all the same symptoms. After about 8-24hours the WAN connection just cuts off. It still has a WAN IP lease and I can still connect to the router just fine. A reboot is required to get things back to normal.

I am using VyprVPN. I use the settings given by VyprVPN. For the record I tried Shibby's Tomato firmware and it also experienced the exact same thing. I am using build 24710M. VyprVPN's sets tun-mtu to 1500 by default so I do not think it is that.

Also, turning off the VPN client does not bring the Internet connection back. I enabled syslog and hopefully I can catch exactly what happened next time (if it is logged).

toemahtoer7k
toemahtoer7k's picture
I too am having issues with

I too am having issues with OpenVPN and the WAN connection going out. I suffer all the same symptoms. After about 8-24hours the WAN connection just cuts off. It still has a WAN IP lease and I can still connect to the router just fine. A reboot is required to get things back to normal.

I am using VyprVPN. I use the settings given by VyprVPN. For the record I tried Shibby's Tomato firmware and it also experienced the exact same thing. I am using build 24710M. VyprVPN's sets tun-mtu to 1500 by default so I do not think it is that.

Also, turning off the VPN client does not bring the Internet connection back. I enabled syslog and hopefully I can catch exactly what happened next time (if it is logged).

linuxloon
linuxloon's picture
Could not resist trying the

Could not resist trying the new 24710M code when I saw there was a fix for the QoS issue.

Good news is the QoS seems to be working. I have not tested to verify it's truly working as QoS but it can now be enabled while the VPN is up. Thanks Kong.

I am stress testing the wireless now. Similar idea to what backhack23 suggested with wget but all local.

only been up for a day but so far the router and VPN have been stable.

toemahtoer7k
toemahtoer7k's picture
BackHack23, very informative.

BackHack23, very informative. I have my MTU set at 1500 as default and as suggested by VyprVPN. I'm not seeing any errors related to MTU. Should I still attempt to change it to the values you suggested?

linuxloon, do you mind sharing what your router settings for your VPN are?

tommi7
tommi7's picture
just to let you know. i had

just to let you know. i had some trouble with the speed of pia openvpn client (vyprvpn and airvpn were the same) on R7000 and r6300v2. openvpn speed maxed out at 8-9Mbit up and down. wheras speed without vpn was 30-40Mbit. tried different builds of ddwrt and tomato. tcp was faster in download (up to 30 Mbit). but slower in upload (2-3Mbit) but who knows, maybe pia is the limiting factor over tcp.
my solution was to up:
sndbuf 180224
rcvbuf 180224
in additional config and speed went up to 37Mbit over udp 1194.
just to let you know.
might be that this is only my personal problem as my connection is a little bit special as beeing quiete fast 100/50Mbit (1-30ms pings) within brasil. but a little bit unstable when connecting to us (100-200ms) and european servers (200-300ms pings) and a lot of hops.
oh and thank you for the all the work thats put in ddwrt and the forum. just installed ddwrt for the first time 2 weeks ago and i'm really enjoying it.

toemahtoer7k
toemahtoer7k's picture
Just wanted to add that VPN

Just wanted to add that VPN was not the issue. It was the instability with the latest Kong builds with the new drivers. I downgraded to build 24345M and the issue went away. Apparently there are wifi issues with the newer builds that cause the router to reboot.

slidermike
slidermike's picture
Some r7000 users (myself

Some R7000 users (myself included) have random reboots with the newer wireless driver vs the old wireless driver.
Kong and Brainslayer are aware of it. Supposedly netgear has a newer driver that corrects it but we have to wait until BS gets a copy that he can share with the dd-wrt team.
All this is discussed in the dd-wrt forums.
Over there it is discussed quite a bit and we believe there are a couple of common things that might trigger the reboot.
Certain apple devices & access the wireless at its fringe range seem to be 2 of the biggest trigger points based on the amount of user feedback but it isnt certain.
kong cannot replicate it since he does not have any apple devices. There have been a few users saying they see the issue and dont have any apples but thats a smaller # of reported users.

kbp
kbp's picture
Well I have both an i5s and a

Well I have both an i5s and a 2013 MBP and have yet to see a reboot with the latest 24800 build. Granted its not been out long -

Pages