[Fork] Asuswrt-Merlin 374.43 LTS releases (Archive)

[trungtoto]

Trung, you should leave the ISP modem and connect Asus router as an assistant wifi router so that
- when the Asus one goes down, you still have wifi from the ISP modem
- when the ISP modem goes down, the ISP technicians can just come and replace their modem without having to touch your Asus one.

Trung, you should leave the ISP modem and connect Asus router as an assistant wifi router so that
- when the Asus one goes down, you still have wifi from the ISP modem
- when the ISP modem goes down, the ISP technicians can just come and replace their modem without having to touch your Asus one.

I will consider this option. Thanks !

 

[MarkyMarkMark]

Okay I will try that

Thanks for all your work.
I've been tinkering with this router for a few years now (refurb really lasted this long, lol).
Went from DDWRT to Tomato now Merlin on various routers.
Keeps my mind exercised.
If you don't use it you'll lose it.

I tried the suggestion of setting inactive to 360 seconds but it did not help.
I think my description was not accurate since I didn't exactly observe the disconnect.

After trying inactive setting, I monitored my VPN client and observed the VPN disconnecting on its own after about 5 minutes after being activated. The client from that point could no longer get a response from the server until the server was restarted. I tried changing the firewall setting "Respond to Ping from Wan" to enabled but that had no effect on the OpenVPN disconnect issue.

My client has this entry in the log:
--Session Invalidated: KEEPALIVE_TIMEOUT

Then it is disconnected and cannot reconnect.

 

[treboR2Robert]

I'm seeing something similar. I posted my details here. I am also using an RT-N66U.

33E7 works for me where as with 34E3, only the first connection is successful. I am also using android, though a different client app from the looks of things (OpenVPN for Android).

Make that 3 people with this problem.

I have enabled and disabled all VPN server settings like HMAC, Respond to DNS etc etc... and exported a new .ovpn each time.

I read somewhere that it may be a DNS problem so I even tried setting "connect to dns automatically" ( under WAN ) back to "yes"
I also turned off "rebind protection", "DNSSEC" and "DNS over TLS"

I "think" I have exhausted all options to try and fix this but nothing seems to work.

I have no problems connecting to the VPN on the 1st attempt, no matter what server settings are selected.
But as soon as i disconnect from the VPN i can not reconnect until I restart the VPN server on the router ( I do this just by clicking "apply" in the "VPN Details" tab.

Glad its not just me, hopefully someone here has a easy solution for us.

EDIT: i am also using the latest version of "OpenVPN Connect" from the play store.

 

[john9527]

@MarkyMarkMark @treboR2Robert
Well, I can't recreate it....
- left the client connected and idle for 30 min and stayed connected
- disconnected/reconnected 3X without problems

A couple of general things to check.....
- make sure your client isn't setting a custom keepalive setting. A mismatch between client and server can cause connection problems/disconnects
- if you are also using a VPN client, make sure you don't have a port conflict between the client and server
- if you are using port 443 for the server, make sure you changed the default AICloud port to something else (AICloud grabs 443 even if you aren't using it)c

 

[treboR2Robert]

@MarkyMarkMark @treboR2Robert
Well, I can't recreate it....
- left the client connected and idle for 30 min and stayed connected
- disconnected/reconnected 3X without problems

A couple of general things to check.....
- make sure your client isn't setting a custom keepalive setting. A mismatch between client and server can cause connection problems/disconnects
- if you are also using a VPN client, make sure you don't have a port conflict between the client and server
- if you are using port 443 for the server, make sure you changed the default AICloud port to something else (AICloud grabs 443 even if you aren't using it)c

Strange
If i check the "VPN Status" tab once connected it shows my phone as connected.
I only stay connected for 10 seconds or so and then disconnect.
Within another 20 secs or so and a page refresh my phone disappears from the "VPN Status" tab so it seems as if it disconnected ok.
Yet I try to reconnect my phone and nothing.

I tried the standard port 1194 aswell as others i created off the top of my head.

The ports i was trying were five digit port numbers so no conflicts from anything standard and ive checked my port forward rules too.

 

[treboR2Robert]

I noticed in another post you recommended doing something with the jffs partition.

I have this formatted and set to disabled.

It isn't needed for openvpn is it ?

I came straight from DD-WRT to your 34E3 fork using the asus firmware recovery tool.

If i ssh into the router where do i find openvpn settings ? So far setting it up I have used nothing but the gui.

Thanks

 

[john9527]

Strange

That almost sounds as if it may be 'power saving' related and it's leaving the openvpn client in a bad state. Is there a way to disable some of the power saving options on the phone?

 

[john9527]

It isn't needed for openvpn is it ?

On this fork it's not needed unless you use the command line options to try and move the certs to jffs.

 

[treboR2Robert]

I have the OpenVPN app put in the "unmonitored apps" under power saving settings and there are no other power saving features enabled.
I am using a stock samsung galaxy s6 running android 7.0

You said yours is working ok, could you post your "vpn details" tab settings and also your WAN dns settings ?
Obviously leave out any private settings.

And what app are you using ?

I will try the exact same settings as you.

Cheers

 

[Deleted member 27741]

Hey- dumb question of the day from me. I am seeing no "block page" when cleanbrowsing dns filter (using DoT) blocks something. I am assuming that cleanbrowsing does have a block page so...
Is there a way to show the block page? I would prefer that to a dns error page, since there is not in fact a dns error. If cleanbrowsing does not have a block page ignore this question or ridicule my ignorance. Your choice.

 

[treboR2Robert]

Ok so i just found out there are 2 official openvpn apps for android.

Openvpn connect which is very basic

And

Openvpn for android which is a bit more advanced.

I was using connect before so i thought id try openvpn for android.

This behaves the same way but with a couple of differences.

As its connecting it shows you a log and there are 2 lines that dont look good but it connects fine.

04:17 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this

04:17 GDG: SIOCGIFHWADDR(lo) failed

At disconnect it shows

04:22 Sorry, deleting routes on Android is not possible. The VpnService API allows routes to be set on connect only.

Then when i try to reconnect it says

04:25 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

04:25 TLS Error: TLS handshake failed

04:25 SIGUSR1[soft,tls-error] received, process restarting

 

[bbunge]

Hey- dumb question of the day from me. I am seeing no "block page" when cleanbrowsing dns filter (using DoT) blocks something. I am assuming that cleanbrowsing does have a block page so...
Is there a way to show the block page? I would prefer that to a dns error page, since there is not in fact a dns error. If cleanbrowsing does not have a block page ignore this question or ridicule my ignorance. Your choice.

If you want to know if Cleanbrowsing has a block page ask them. Their tech support responded quickly to my questions. Unfortunately I had too many complaints from the home crew of can not connect to their favorite web sites using DoT with this firmware so I went back to stock Asus yesterday. Initially thought it was my ISP blocking things. Had used Cleanbrowsing, Quad9 and Cloidflare. Cloudflare was a bit better but...

Sent from my P01M using Tapatalk

 

[keeka]

Ok so i just found out there are 2 official openvpn apps for android.

Openvpn connect which is very basic

And

Openvpn for android which is a bit more advanced.

I was using connect before so i thought id try openvpn for android.

This behaves the same way but with a couple of differences.

As its connecting it shows you a log and there are 2 lines that dont look good but it connects fine.

04:17 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this

04:17 GDG: SIOCGIFHWADDR(lo) failed

At disconnect it shows

04:22 Sorry, deleting routes on Android is not possible. The VpnService API allows routes to be set on connect only.

Then when i try to reconnect it says

04:25 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

04:25 TLS Error: TLS handshake failed

04:25 SIGUSR1[soft,tls-error] received, process restarting

You do not need jffs for the default openvpn server setup. The autogenerated ca, cert and key are saved to nvram.
I'm using the other android vpn client that you mention so logs are different. But I think my unsuccessful (2nd) connection attempt stops around the same point as indicated in your client log.
Could you try the previous firmware (33E7)? OpenVPN server worked reliably for me on that version. This might then point to some change in 34E3?
I believe you're safe to downgrade via the web GUI and since you are not using jffs, you shouldn't need to do anything else. I have gone back and forth between these two firmware a couple of times recently with no ill efects. Other than this vpn connect issue that is ;-)

 

[john9527]

Could you try the previous firmware (33E7)? OpenVPN server worked reliably for me on that version. This might then point to some change in 34E3?

I've went commit-by-commit through the differences between 33E7 and 34E3 and can't see anything that would remotely interact with the OpenVPN server (unless you are using DoT and pushing the DNS server to the OpenVPN clients - which is what I am doing).

I've been testing using the built in NetworkManager OpenVPN interface in Linux Mint 17.3 without any problems.
The only Android I have available is a generic tablet running Android 4.4.2 I'll try and find time today to load the VPN client there.

 

[keeka]

I've went commit-by-commit through the differences between 33E7 and 34E3 and can't see anything that would remotely interact with the OpenVPN server (unless you are using DoT and pushing the DNS server to the OpenVPN clients - which is what I am doing).

Thanks john9527. I'd been leaning towards it being something amiss with my RT-N66U. I've recently experienced filesystem corruption with an otherwise reliable thumbdrive. I disabled entware and removed the thumbdrive whilst I tried to resolve the VPN. Then I saw the other two users' report a similar issue with same hardware. It would be good to get confirmation what firmware those two are using and, if it's 34E3, what they see with the previous firmware.
I made no changes to my DNS settings so AIUI I am not using the new DoT features.

 

[Deleted member 27741]

According to my imperfect testing it looks like block pages only come up when websites are blocked through DNS-based filtering from the parental control tab of the firmware. I don't see block pages when I use something like adguard or cleanbrowsing either through "normal" dns or DoT dns. I do like to see the block page so that I know it was blocked by the dns service and not a failed dns lookup. If it is possible to get block pages working with DoT that would be awesome, if anyone knows how let me know.

 

[treboR2Robert]

Thanks john9527. I'd been leaning towards it being something amiss with my RT-N66U. I've recently experienced filesystem corruption with an otherwise reliable thumbdrive. I disabled entware and removed the thumbdrive whilst I tried to resolve the VPN. Then I saw the other two users' report a similar issue with same hardware. It would be good to get confirmation what firmware those two are using and, if it's 34E3, what they see with the previous firmware.
I made no changes to my DNS settings so AIUI I am not using the new DoT features.

So I just rolled back the N66 firmware to 33E7 and.....

It worked straight away.

Disconnected then 10 seconds later it reconnected instantly.

It reconnects straight away with both "OpenVPN connect" and also "OpenVPN for android"

I do however still get the following lines when connecting

04:17 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this

04:17 GDG: SIOCGIFHWADDR(lo) failed

And I also still get this line when disconnecting

04:22 Sorry, deleting routes on Android is not possible. The VpnService API allows routes to be set on connect only.

But after disconnecting I have no trouble reconnecting.

So I'm guessing something must have changed from 33E7 to 34E3

I am now torn between having DNS over TLS or a working VPN

 

[HowIFix]

@john9527 I have these 4 questions:

01. VPN Client traffic bypass Traditional QoS?

02. In DoT CleanBrowsing/Cloudflare, if I have DNSSEC enabled in Strict mode and restart the router, the internet work? (Because you are using dnsmasq v2.80)

03. You will wait for the stable version 2.80 of dnsmasq, for you to release the next update like @RMerlin? (for me it is a wise decision or maybe not)

Some recent development took a lot of time to complete, plus I'm giving both Asus and the dnsmasq author a larger potential merge window in case they came up with new firmware / a final dnsmasq release. That window will be closed once I move into beta, unless a final dnsmasq comes out with no major changes to it.

04. You add these security fix that releases sometimes in the latest version of ASUS Official firmware? (or is it not necessary?)

ASUS RT-AC68U Firmware version 3.0.0.4.384.32738 (2018/08/15)
Security fixes.
- Fixed Reflected XSS vulnerability.
- Fixed CSRF vulnerability.
- Fixed command injection vulnerability.
- Fixed stack buffer overflow vulnerability.


ASUS RT-AC68U Firmware version 3.0.0.4.384.20942 (2018/05/21)
Security fixes.
- Fixed XSS vulnerability. Thanks to Yonghui Han of Fortinet's FortiGuard Labs.
- Fixed CVE-2018-8877, CVE-2018-8878, CVE-2018-8879
- Fixed plain text password vulnerability in lighttpd.


ASUS RT-AC68U Firmware version 3.0.0.4.384.20624 (2018/03/27)
Security fixed.
-Fixed information disclosure vulnerability. Thanks to Haitan Xiang and Fand Wang.
-Fixed CVE-2018-8826 remote code execution vulnerability. Thanks to Chris Wood.
-Fixed AiCloud 2.0 Reflected XSS Vulnerability. Thanks to Guy Arazi and Niv Levi contribution.


ASUS RT-AC68U Firmware version 3.0.0.4.384.20287 (2018/01/26)
Security fixed.
- Fixed Smart Sync Stored XSS vulnerabilities. Thanks fo Guy Arazi's contribution.
- Fixed CVE-2018-5721 Stack-based buffer overflow


ASUS RT-AC68U Firmware version 3.0.0.4.384.10007 (2018/01/02)
Security fixed.
- Fixed KRACK vulnerability
- Fixed XSS vulnerability. Thanks for Joaquim's contribution.
- Fixed LAN RCE vulnerability. An independent security researcher has reported this vulnerability to Beyond Security’s SecuriTeam Secure Disclosure program
- Fixed remote code execution vulnerability. Thanks to David Maciejak of Fortinet's FortiGuard Labs


ASUS RT-AC68U Firmware version 3.0.0.4.382.18547 (2017/11/10)
Security fixed.
- Fixed KRACK vulnerability
- Fixed CVE-2017-14491: DNS - 2 byte heap based overflow
- Fixed CVE-2017-14492: DHCP - heap based overflow
- Fixed CVE-2017-14493: DHCP - stack based overflow
- Fixed CVE-2017-14494: DHCP - info leak
- Fixed CVE-2017-14495: DNS - OOM DoS
- Fixed CVE-2017-14496: DNS - DoS Integer underflow
- Fixed CVE-2017-13704 : Bug collision
- Fixed predictable session tokens, logged user IP validation, Logged-in information disclosure (special thanks for Blazej Adamczyk contribution)
- Fixed web GUI authorization vulnerabilities.
- Fixed AiCloud XSS vulnerabilities


ASUS RT-AC68U Firmware version 3.0.0.4.380.7743 (2017/06/16)
Security fixed.
- Fixed CVE-2017-8828 (XSS vulnerability special for Yair Amit’s https://www.linkedin.com/in/yairamit/ contribution)
- Fixed CVE-2017-5892 (JSONP Information Disclosure)
- Fixed CVE-2017-7494 (Samba remote code execution vulnerability)
- Improved brute-force protection for SSH, Telnet connection.


ASUS RT-AC68U Firmware version 3.0.0.4.380.7378 (2017/03/31)
Security fixed.
- Fixed CVE-2017-5891.
- Fixed CVE-2017-5892.
- Fixed CVE-2017-6547.
- Fixed CVE-2017-6549.
- Fixed CVE-2017-6548.
- Added log message for brute force attack.


ASUS RT-AC68U Firmware version 3.0.0.4.380.4164 (2016/12/13)
Security related.
- Updated OpenSSL library to 1.0.2j to fix security issues.
- Updated Dropbear SSH to 2016.74 to fixe security issues.
- Fixed a security vulnerability regarding XSS.
- Fixed a security vulnerability regarding CSRF.
- Added protection for Brute-force attack.


ASUS RT-AC68U Firmware version 3.0.0.4.380.3831 (2016/07/08)
Security Fixed.
- Fixed XSS issue in WDS page. Special thanks for Jamie's contribution.
- Fixed LPR buffer overflow issue. Special thanks for GeekPwn contribution.
- Remoted DHCP information disclosure.


ETC.

 

[MarkyMarkMark]

Thanks john9527. I'd been leaning towards it being something amiss with my RT-N66U. I've recently experienced filesystem corruption with an otherwise reliable thumbdrive. I disabled entware and removed the thumbdrive whilst I tried to resolve the VPN. Then I saw the other two users' report a similar issue with same hardware. It would be good to get confirmation what firmware those two are using and, if it's 34E3, what they see with the previous firmware.
I made no changes to my DNS settings so AIUI I am not using the new DoT features.

I am using 34E3 on my RT-N66R.
The only other thing I have running on it is Diversion ad blocker.

I did however notice the GUI in System Logs / Port Forwarding is bugged.

I'm using an android 8.0 Galaxy S9 running both OpenVPN clients Connect/For Android.

Maybe I will try and downgrade my FW.

 

[treboR2Robert]

I just tried the latest test version 35T3 and it has the same VPN reconnect problem as 34E3.

33E7 works fine