Release Asuswrt-Merlin 386.3 is now available

[wyse]

Hello,
is it possible to switch from 384.18 directly to 386.3 ??

Thanks

(i know about the new 386 codebase it should be necessary to wait until 1 hour after first boot)

 

[L&LD]

Anything is possible.

A full reset is suggested for the best performance, security, and stability afterward though.

Fully Reset Router and Network

Best Practice Update/Setup Router/AiMesh Node(s) 2021

 

[Kingp1n]

Just updated my AX11000 to latest 386.3 fw and all is working flawlessy to include the x3mRouting (option 3) & vpnmgr scripts. My 2 policy rules using PIA VPN were created automatically and no issues after router rebooted from the upgrade!!!. I like the simplicity of VPN Director. Awesome job RMerlin!!! Thanks for this update!!!!

 

[RMerlin]

I think the question is why in routing table there are no routes from VPN server to VPN client. After upgrade firmware, routes came, it's working, but in routing table there are no routes. VPN server pushed through the PUSH parameter. VPN server and clients on RMerlin's firmware 386.3.

Works for me. I have my server push a route for 10.9.0.0, and that route properly gets added to my client's routing table.

 

[Sjekke]

It's possible. 750 Mbps is what I would expect though from any dual-stream 802.11AC client however, so this looks normal to me.

It's a AX client and internal I get 940Mb. On the router the same. But Wan to Wifi slows down ...

 

[Sumsurfguy]

Clean install on a RT-AX3000 earlier today, working well and really like the new VPN Director, many thanks.

 

[gspannu]

@RMerlin - Possible Bug/ Issue in VPN Server settings.

Using the Asus Router as a VPN Server
VPN Server -> IPSec VPN settings.
Setup the Asus Router as a IKEv2 server, no issues in setting up. I have setup my clients as IKEV2 clients and everything connects fine.

I then realised that I needed to change the allocated IP addresses for my clients, so I select
VPN Details -> Advanced Settings
And I changed the IP address range to 192.168.100.x
Hit apply... All saved successfully.

I then reconnect my clients, connection goes through successfully, clients connect - however the new IP address range is not reflected by the clients, they are still on the original range.

Did a bit of digging...

I then checked the ipsec.conf files and it seems that the change of IP address range is only reflected in the ikev1 section. The ikev2 section still reflects the old address range.
I am referring to the line

rightsourceip=

Hope you are able to replicate the issue with the above details...

Router: ASUS RT-AX88U, running version 386.3, no add-ons, no USB, jffs scripts enabled.

@RMerlin
It appears that the line rightsourceip=10.10.10.0/24 is hardcoded for the ikev2 section.
The value of rightsourceip in ikev1 section changes accordingly, but the same value in ikev2 section does not change from 10.10.10.0/24.

Redacted contents of ipsec.conf

conn %default
  keyexchange=ikev1
  authby=secret
  ike=aes256-sha1-modp1024
#Host-to-NET[prof#0]:4>Host-to-Net>null>null>wan>>1>SharedSecretKey>null>null>null>null>null>1>192.168.100>null>1>null>null>0>null>null>null>1>>>eap-md5>1>500>4500>10>1>null>null>null>null><<<<>1


conn Host-to-Net
  keyexchange=ikev1
  left=92.92.92.213
.......
.......
  rightsourceip=192.168.100.0/24
  rightdns=192.168.1.1
.......

#Host-to-NET[prof#1]:4>Host-to-Netv2>null>null>wan>>0>null>null>null>null>null>null>1>10.10.10>null>2>null>null>0>@guru.myddns.me>null>null>0>>>eap-mschapv2>1>500>4500>10>1>null>null>null>null><<<<>1>pubkey>svrCert.pem>always>svrKey.pem>%identity


conn Host-to-Netv2
  keyexchange=ikev2
  left=92.92.92.213
 .......
  leftid=@my.domain.name
....... 
 rightsourceip=10.10.10.0/24
 rightdns=192.168.1.1

 

[Jakem]

This release is fantastic. Everything works better then expected. Gotta love VPN Director because it makes everything so much easier.
Thanks Merlin, great software that is actually worth paying for and I intend to do just that.
One question. How do I test the kill switch. I now know turning off the vpn client also turns off the kill switch so that I still have access to wan. Previous version when turning off vpn client activated the kill switch and prevented internet access.
I just want to make sure if the tunnel goes down the kill switch will block internet access.
Thank You

 

[kernol]

This release is fantastic. Everything works better then expected. Gotta love VPN Director because it makes everything so much easier.
Thanks Merlin, great software that is actually worth paying for and I intend to do just that.
One question. How do I test the kill switch. I now know turning off the vpn client also turns off the kill switch so that I still have access to wan. Previous version when turning off vpn client activated the kill switch and prevented internet access.
I just want to make sure if the tunnel goes down the kill switch will block internet access.
Thank You

Already answered in this thread - use search function .
Here's the answer ...

 

[joomlafab]

Dirty upgrade from 386.2_6 on AX3000 (same firmware than AX58U) went smooth. Everything looks OK.

Thanks Rmerlin !

 

[timevacuum]

Resolving Overlapping VPN Routing Rules
edit 21/07/27: moved to new thread here

 

[eugenezh]

Upgrade from 386.2_6 to 386.3 on AC86U went ok, however my VPN routing setup is not working anymore.

In my scenario I have a list of hostnames. I need to route all traffic to these hosts via a openvpn tunnel tun11. All the rest traffic should be routed normally via wan.
I was not able to use the "Policy Routing" feature on 386.2_6 firmware, since it only allows to specify ip addresses or subnets. Instead I had "Force Internet traffic through tunnel" in my openvpn client configuration set to "No" and used custom "openvpn-event" script to read the list of hosts, resolve their IPs and add routes to resolved IPs via tun11. Another script set to be run periodically did ip resolution for the hosts from the list and checked if traffic was routed to resolved IPs via tun11. If that was not the case for some "freshly resolved" IP address, the script corrected routes to match the IP changes.
That was a pretty simple but effective setup and it worked for me perfectly.
After upgrade to 386.3 all my scripts are run as expected, routes are added correctly, but all traffic continues to go via wan. "ip route get <dest-ip>" returns the route via wan, despite the routing table contains the route for the <dest-ip> via the tun11.

I read in the changelog: "Rewrote OpenVPN routing handling. The firmware will now handle route creation itself rather than letting the openvpn client create/remove routes." and suspect this is the reason. Could anyone please advice if my setup is possible with the new firmware at all? Is it possible to adapt my scripts to these changes in routing handling?
So far I had to revert back to 386.2_6 and routing is working for me again.

Thanks in advance for any insights.

 

[modestyB]

The Wifi-radar does not work for me. User error?

 

[Hazel]

The Wifi-radar does not work for me. User error?

Most likely. Did you press

on the 'Configure' page before returning to the WiFi Radar Home page and wait a few seconds before it populated the graphs?

 

[Marvin Gage]

So does this firmware have AiMesh 2.0?

 

[Db Major]

@RMerlin I’ll have to check this, but it’s always worked up until 386.3.
The server is an RT-AC68U running Merlin 386.3 just as the RT-AX88U is.

@RMerlin
When I use OpenVPN to connect from my phone to the RT-AC68U, I can access the 68’s subnet and configure page however, when I connect to it using my RT-AX88U’s VPN client with the exact same config file, it doesn’t allow access to the subnet.
Do I need to do something in the client config to see the 68’s subnet that I wouldn’t have needed to do before?

I also connect to an RT-AC86U that’s running 386.2_6 from the X88U and I can access the 86U’s subnet, so I’m not 100% sure it’s the client config?
Thanks for your help.

 

[Hazel]

So does this firmware have AiMesh 2.0?

According to the changelog it has AiMesh 2.0, since version 386.1, released 30 January 2021. Lots of other useful to be found there, should you have anymore questions.

 

[amplatfus]

@RMerlin
When I use OpenVPN to connect from my phone to the RT-AC68U, I can access the 68’s subnet and configure page however, when I connect to it using my RT-AX88U’s VPN client with the exact same config file, it doesn’t allow access to the subnet.
Do I need to do something in the client config to see the 68’s subnet that I wouldn’t have needed to do before?

I also connect to an RT-AC86U that’s running 386.2_6 from the X88U and I can access the 86U’s subnet, so I’m not 100% sure it’s the client config?
Thanks for your help.

Hi,

Please, do you have active scripts (i.e.: up/ down) actiive on custom configuration?

10q,
amplatfus

 

[Tim Storey]

Did a complete reset on my RT-AC68U. Previous version of my VPN Client worked fine, with this one the VPN does not connect.

I have received help from the VPN provider support but nothing seems to work.

Before the VPN status tab would show connection details and status, including a public IP address as well as a local IP.

After installing the firmware and reinstalling the VPN client, the public IP is described as "unknown".

There are no rules in VPN director, so all traffic is routed through VPN Client 1 when turned on.

Any ideas?

 

[SomeWhereOverTheRainBow]

@RMerlin - Possible Bug/ Issue in VPN Server settings.

Using the Asus Router as a VPN Server
VPN Server -> IPSec VPN settings.
Setup the Asus Router as a IKEv2 server, no issues in setting up. I have setup my clients as IKEV2 clients and everything connects fine.

I then realised that I needed to change the allocated IP addresses for my clients, so I select
VPN Details -> Advanced Settings
And I changed the IP address range to 192.168.100.x
Hit apply... All saved successfully.

I then reconnect my clients, connection goes through successfully, clients connect - however the new IP address range is not reflected by the clients, they are still on the original range.

Did a bit of digging...

I then checked the ipsec.conf files and it seems that the change of IP address range is only reflected in the ikev1 section. The ikev2 section still reflects the old address range.
I am referring to the line

rightsourceip=

Hope you are able to replicate the issue with the above details...

Router: ASUS RT-AX88U, running version 386.3, no add-ons, no USB, jffs scripts enabled.

@RMerlin
It appears that the line rightsourceip=10.10.10.0/24 is hardcoded for the ikev2 section.
The value of rightsourceip in ikev1 section changes accordingly, but the same value in ikev2 section does not change from 10.10.10.0/24.

Redacted contents of ipsec.conf

conn %default
  keyexchange=ikev1
  authby=secret
  ike=aes256-sha1-modp1024
#Host-to-NET[prof#0]:4>Host-to-Net>null>null>wan>>1>SharedSecretKey>null>null>null>null>null>1>192.168.100>null>1>null>null>0>null>null>null>1>>>eap-md5>1>500>4500>10>1>null>null>null>null><<<<>1


conn Host-to-Net
  keyexchange=ikev1
  left=92.92.92.213
.......
.......
  rightsourceip=192.168.100.0/24
  rightdns=192.168.1.1
.......

#Host-to-NET[prof#1]:4>Host-to-Netv2>null>null>wan>>0>null>null>null>null>null>null>1>10.10.10>null>2>null>null>0>@guru.myddns.me>null>null>0>>>eap-mschapv2>1>500>4500>10>1>null>null>null>null><<<<>1>pubkey>svrCert.pem>always>svrKey.pem>%identity


conn Host-to-Netv2
  keyexchange=ikev2
  left=92.92.92.213
.......
  leftid=@my.domain.name
.......
rightsourceip=10.10.10.0/24
rightdns=192.168.1.1

That is because you are only able to adjust the settings for the IPK1, the settings for the IPK2 are set by instant guard which was added by asus(closed source)