[Release 384/NG] Asuswrt-Merlin 384.4 is now available

[XIII]

I don't think Asus's IPSEC implementation redirects Internet traffic, it's only configured for remote LAN access.

Upgraded from 384.4_1 to 384.4_2 and tried to access https://192.168.1.1:8443 and https://router.asus.com:8443. Even those don't open when using IPSec over cellular...

 

[skeal]

@RMerlin running 384.4_2 on a AC3100 and a AC68U. Uptime is 25hrs now and all is well.

 

[natzakaria]

Upgraded from 384.4_1 to 384.4_2 and tried to access https://192.168.1.1:8443 and https://router.asus.com:8443. Even those don't open when using IPSec over cellular...

Tested it on 5300 and working just fine

 

[RMerlin]

Upgraded from 384.4_1 to 384.4_2 and tried to access https://192.168.1.1:8443 and https://router.asus.com:8443. Even those don't open when using IPSec over cellular...

Port 8443 is for the WAN side. While over a VPN tunnel, it should be port 443 since you're within the LAN.

 

[RMerlin]

384.4_1 test builds have been uploaded to https://asuswrt.lostrealm.ca/test-builds, addressing two security issues related to the webui. I'll provide more details once I officially push 384.4_2 out in the coming days. In the mean time I'd advise people to upgrade, and to validate that there are no odd issues with their webui with this test build.

Both security issues were tied to the web server. One is known to be exploitable without the need to authenticate with the web server. The other issue is a potential buffer overrun that I found - no idea if it was possible to exploit it or not. That fix also resolved a potential web server crash within that same function.

Asus has already fixed that first issue in 384_20379, but since the bug was within closed source code, I wasn't aware of its existence until someone reported the newly found issue last week. The RT-AC88U, RT-AC3100 and RT-AC5300 were using 384_20379 binary blobs, so they were already secured with 384.4. After being warned of the issue, I had to figure out a way to protect the closed source code that contained the vulnerability. That workaround was implemented in 384.4_2, protecting all supported models now.

 

[JSinFCVA]

Have you tried to change your SSID names?

Indeed I have. First thing I tried was to perform a factory reset (even initialize), and set up all new SSIDs as if I was setting up new networks "out of the box". When I can afford some downtime, I'm going to try the ASUS 384 code and see if it makes any difference. If it works, I'll try flashing to the Merlin 384.4 again. I don't mind setting up everything from scratch since my "minimal" requirement is 2 SSIDs (one each for 2.4 and 5.0 GHz). and a DHCP setup with 4 devices having assigned IP addresses. You can't get much simpler than that. But nothing I do after the flash upgrade to 384.4 gives me 2 working radios.

 

[JSinFCVA]

AC86U upgrade to 384.4.2 from 384.4, no client listed in the network map and client status. the client count is 0.

I always see this too under 384.4, but thats the least of my issues. Works fine under 384.3

 

[Odkrys]

I don't think Asus's IPSEC implementation redirects Internet traffic, it's only configured for remote LAN access.

Asus ipsec works for lan and internet both.

My LG phone is working weirdly.
wifi + ipsec = internet ok, web gui access ok
lte + ipsec = internet ok, ping to 192.168.50.1 ok, but web gui access fail !

Samsung Galaxy is all fine !

When remotely logging into the router I have no internet connectivity via IPSec VPN, but it does work via OpenVPN.

Try other brand's cell phone. I don't have apple products so I can't test for ios.

 

[XIII]

Port 8443 is for the WAN side. While over a VPN tunnel, it should be port 443 since you're within the LAN.

If I remember correctly I set it to 8443 myself, to have 443 for OpenVPN.

 

[XIII]

Asus ipsec works for lan and internet both.

Try other brand's cell phone. I don't have apple products so I can't test for ios.

I thought it did (with 384.3?).

Any other iOS owners that can test?

 

[Odkrys]

I thought it did (with 384.3?).

Any other iOS owners that can test?

check " ipsec statusall " in console.

 

[Milan]

AC3200, upgraded to 384.4_2 and everything looks good. Thanks!

same here, no issues till now

 

[AndreiV]

AC3200 flashed and working 100% (as usual) .

 

[joro_abv]

AC56U Updated two days ago. Looking good for now.

 

[seth_space]

Read this one and check for the manufacturer of your hardware..
https://www.snbforums.com/threads/ac-3200-384-4-update-wifi-connectivity-issue.45547/

 

[XIII]

check " ipsec statusall " in console.

Status of IKE charon daemon (weakSwan 5.2.1, Linux 4.1.27, aarch64):
  uptime: 11 hours, since Mar 25 23:30:19 2018
  malloc: sbrk 1462272, mmap 0, used 313840, free 1148432
  worker threads: 3 of 8 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 2
  loaded plugins: charon aes des rc2 sha1 sha2 md4 md5 random nonce x509 revocation constraints acert pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf agent xcbc cmac hmac attr kernel-netlink resolve socket-default stroke updown eap-identity eap-md5 eap-mschapv2 eap-tls eap-peap xauth-generic
Virtual IP pools (size/online/offline):
  10.10.10.0/24: 254/0/1
Listening IP addresses:
  <REDACTED>
  192.168.1.1
  192.168.1.2
  10.8.0.1
Connections:
 Host-to-Net:  <REDACTED>...%any  IKEv1, dpddelay=10s
 Host-to-Net:   local:  [<REDACTED>] uses pre-shared key authentication
 Host-to-Net:   remote: uses pre-shared key authentication
 Host-to-Net:   remote: uses XAuth authentication: any
 Host-to-Net:   child:  0.0.0.0/0 === dynamic TUNNEL, dpdaction=clear
Security Associations (0 up, 0 connecting):
  none

Not sure what I should see here?

 

[Odkrys]

Not sure what I should see here?

connect and see o_o;;

 

[XIII]

connect and see o_o;;

Status of IKE charon daemon (weakSwan 5.2.1, Linux 4.1.27, aarch64):
  uptime: 22 minutes, since Mar 26 11:34:02 2018
  malloc: sbrk 1462272, mmap 0, used 331120, free 1131152
  worker threads: 3 of 8 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 7
  loaded plugins: charon aes des rc2 sha1 sha2 md4 md5 random nonce x509 revocation constraints acert pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf agent xcbc cmac hmac attr kernel-netlink resolve socket-default stroke updown eap-identity eap-md5 eap-mschapv2 eap-tls eap-peap xauth-generic
Virtual IP pools (size/online/offline):
  10.10.10.0/24: 254/1/0
Listening IP addresses:
  <REDACTED>
  192.168.1.1
  192.168.1.2
  10.8.0.1
Connections:
 Host-to-Net:  <REDACTED>...%any  IKEv1, dpddelay=10s
 Host-to-Net:   local:  [<REDACTED>] uses pre-shared key authentication
 Host-to-Net:   remote: uses pre-shared key authentication
 Host-to-Net:   remote: uses XAuth authentication: any
 Host-to-Net:   child:  0.0.0.0/0 === dynamic TUNNEL, dpdaction=clear
Security Associations (1 up, 0 connecting):
 Host-to-Net[1]: ESTABLISHED 4 seconds ago, <REDACTED>[<REDACTED>]...<REDACTED-2>[<REDACTED-3>]
 Host-to-Net[1]: Remote XAuth identity: <REDACTED-6>
 Host-to-Net[1]: IKEv1 SPIs: <REDACTED-4> <REDACTED-5>, pre-shared key reauthentication in 2 hours
 Host-to-Net[1]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
 Host-to-Net{1}:  INSTALLED, TUNNEL, ESP in UDP SPIs: <REDACTED-7> <REDACTED-8>
 Host-to-Net{1}:  AES_CBC_128/HMAC_SHA1_96, 1497 bytes_i, 0 bytes_o, rekeying in 48 minutes
 Host-to-Net{1}:   0.0.0.0/0 === 10.10.10.1/32

Still don't know what I should see here... (but willing to learn!)

 

[nzwayne]

Installed 384.4_2 on two AC86U's without issue. One via an overlay from 384.4_1 the other a full factory reset and manual config setting from alpha firmware of RT-AC86U_384.5_alpha1. All working well.

 

[Sean Nelson]

(AC68U on 384.4)

This had been reported on 384.3 but seems unaddressed in 384.4 --

[1] Parental control -> time schedule is broken. Any device set to have time schedule would frequently (and randomly) show the "internet blocked" page during the allowed time period.
[2] Firewall -> Network service filter is not reliable. Sometimes (not always) blocked ports are still accessible during blocked periods. May be related to [1]; it seems the time checking is faulty.