Release Asuswrt-Merlin 386.3 is now available

Status
Not open for further replies.

SomeWhereOverTheRainBow

Part of the Furniture
@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

Code:
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
Code:
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
.......
  [email protected]
.......
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)
 

WET

Regular Contributor
For what it is worth I upgraded both mesh node & router to 386.3. All is well including UPNP (miniDLNA) hanging off of node (RT-AC68U). Broadcast issues I was having with 386.2_6 & 386.3_alpha are gone.
 

Jumpstarter

Senior Member
A few hours after updating the router a remote connection over pptp occured to my router

Code:
Jul 27 09:59:49 RT-AC5300 pptpd[4186]: CTRL: Client 172.58.107.14 control connection started
Jul 27 09:59:49 RT-AC5300 pptpd[4186]: CTRL: Starting call (launching pppd, opening GRE)
Jul 27 09:59:49 RT-AC5300 pptp[4187]: Plugin pptp.so loaded.
Jul 27 09:59:49 RT-AC5300 pptp[4187]: PPTP plugin version 0.8.5 compiled for pppd-2.4.7, linux-..
Jul 27 09:59:49 RT-AC5300 pptp[4187]: pppd 2.4.7 started by admin, uid 0
Jul 27 09:59:49 RT-AC5300 kernel: pptp0: renamed from ppp10
Jul 27 09:59:49 RT-AC5300 pptp[4187]: Using interface pptp0
Jul 27 09:59:49 RT-AC5300 pptp[4187]: Connect: pptp0 <--> pptp (172.58.107.14)
Jul 27 09:59:49 RT-AC5300 kernel: pptp_rcv_check():[BLOG_PPTP_RCV_OOS_GT] current seq_recv is -1
Jul 27 09:59:49 RT-AC5300 pptp[4187]: MPPE 128-bit stateless compression enabled
Jul 27 09:59:52 RT-AC5300 pptp[4187]: Cannot determine ethernet address for proxy ARP
Jul 27 09:59:52 RT-AC5300 pptp[4187]: local  IP address 192.168.1.1
Jul 27 09:59:52 RT-AC5300 pptp[4187]: remote IP address 192.168.10.2
Jul 27 10:00:02 RT-AC5300 pptpd[4186]: CTRL: EOF or bad error reading ctrl packet length.
Jul 27 10:00:02 RT-AC5300 pptpd[4186]: CTRL: couldn't read packet header (exit)
Jul 27 10:00:02 RT-AC5300 pptpd[4186]: CTRL: CTRL read failed
Jul 27 10:00:02 RT-AC5300 pptpd[4186]: CTRL: Reaping child PPP[4187]
Jul 27 10:00:02 RT-AC5300 pptpd[4186]: CTRL: Client pppd TERM sending
Jul 27 10:00:02 RT-AC5300 pptpd[4186]: CTRL: Client pppd finish wait
Jul 27 10:00:02 RT-AC5300 pptp[4187]: Terminating on signal 15
Jul 27 10:00:02 RT-AC5300 pptp[4187]: Connect time 0.2 minutes.
Jul 27 10:00:02 RT-AC5300 pptp[4187]: Sent 3520 bytes, received 4091 bytes.
Jul 27 10:00:02 RT-AC5300 pptp[4187]: MPPE disabled
Jul 27 10:00:02 RT-AC5300 bcrelay[5847]: ignored ENETDOWN from sendto(), a network interface was going down?
Jul 27 10:00:05 RT-AC5300 pptp[4187]: Connection terminated.
Jul 27 10:00:05 RT-AC5300 pptp[4187]: Modem hangup
Jul 27 10:00:05 RT-AC5300 pptp[4187]: Exit.
Jul 27 10:00:05 RT-AC5300 pptpd[4186]: CTRL: Client 172.58.107.14 control connection finished

1627394841508.png


According to the gui, pptp is disabled. Looks like a factory reset may be in order for some.
 

gspannu

Regular Contributor
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)
Any fudge I can apply to any file or some other mechanism; so that I can use my preferred IP address range for ikev2.

Thanks.
 

octopus

Very Senior Member
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?
Check log what happened.
 

maestr0

Occasional Visitor
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.
Upgraded to 386.3. Previously I connected to VPN server with 10.8.6.0 and added "route 192.168.6.0 255.255.255.0" for additional subnet. Now only the route for 10.8.6.0 is in the routing table. No way to connect to 192.186.6.0 as there is no route for that.

Update: have 2 VPN clients (to 10.8.5.0/192.168.5.0 and 10.8.6.0/192.168.6.0). Routes are only created for 10.8.5.0 and 10.8.6.0. Subnet 192.168.5.0 is reachable as this is the client with the lowest number (client1). 192.168.6.0 is not reachable. When I stop client1, I can reach 192.168.6.0 as that is than the client with the lowest active client.

Doesn't make a difference if I push the route from the VPN server or add it to the config on the VPN client side.
 
Last edited:

maestr0

Occasional Visitor
Upgraded to 386.3. Previously I connected to VPN server with 10.8.6.0 and added "route 192.168.6.0 255.255.255.0" for additional subnet. Now only the route for 10.8.6.0 is in the routing table. No way to connect to 192.186.6.0 as there is no route for that.

Update: have 2 VPN clients (to 10.8.5.0/192.168.5.0 and 10.8.6.0/192.168.6.0). Routes are only created for 10.8.5.0 and 10.8.6.0. Subnet 192.168.5.0 is reachable as this is the client with the lowest number (client1). 192.168.6.0 is not reachable. When I stop client1, I can reach 192.168.6.0 as that is than the client with the lowest active client.

Doesn't make a difference if I push the route from the VPN server or add it to the config on the VPN client side.
 

RMerlin

Asuswrt-Merlin dev
Could you please help me to find a way to receive notification when VPN client up/ down while using the Public IP from the VPN Client?
Use an openvpn-event script instead of overriding the existing event handlers - they are used by the firmware to configure the tunnel.
 

RMerlin

Asuswrt-Merlin dev
Any reason why I should put Merlin build on it??
No reason to. Keeping nodes on stock firmware makes it easier to upgrade them, as long they are still compatible with the AiMesh implementation used on the main router.
 

RMerlin

Asuswrt-Merlin dev
t appears that the line rightsourceip=10.10.10.0/24 is hardcoded for the ikev2 section.
That will have to be sorted out by Asus. I don't touch the IPSEC code, sorry.
 

guho

Regular Contributor
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)
I have my IPK2 at 192.168.2.x and I do this by copying a customized /jffs/scripts/ipsec.conf to $CONFIG in /jffs/scripts/ipsec.postconf. You can also use the helper functions to only change the IPK2 address range, but I have a lot of customizations in mine, so for me it is easier to overwrite the entire ipsec.conf.
 

Jakem

New Around Here
Already answered in this thread - use search function ;).
Here's the answer ...
Thanks kernol for your kind reply. I did read how to test for kill switch operation in this thread but I don't know how to use the two rules that were shown. I can do a lot with my two routers, using one as a node in aimesh and running PIA VPN. Learned a lot along the way but I need instructions from someone like you as to how do I use these rules to test for kill switch operation. I figured everything else out by searching, reading and trying it out. Just can't find any more info on this task.
Your help will be greatly appreciated.
Thanks
 

stamzrat10

Occasional Visitor
Dear RMerlin and team, there is a bug in this build, which was also present in the beta versions.

Whenever I change a rule at the VPN Director, be it by enabling or disabling a rule, deleting or adding a rule, somethings gets messed up with Diversion. I think that is changes how the VPN's DNS policy behaves.

So if I am disabling one rule through VPN Director, Diversion just stops blocking. Only a reboot of the router fixes it.
 

gspannu

Regular Contributor
I have my IPK2 at 192.168.2.x and I do this by copying a customized /jffs/scripts/ipsec.conf to $CONFIG in /jffs/scripts/ipsec.postconf. You can also use the helper functions to only change the IPK2 address range, but I have a lot of customizations in mine, so for me it is easier to overwrite the entire ipsec.conf.
Hi,
Can you please explain in a bit more detail as to which files I need to copy/ create in which folders - some sample content of the file would be very helpful.


All I mainly want to achieve is change the default IPSec ikev2 range from 10.10.10.0/24 to 192.168.2.0/24 as specified in the line rightsourceip=

@guho
What additional file(s) do I create where and what do I modify in the existing /etc/ipsec.conf to achieve this? Many thanks...
 

SomeWhereOverTheRainBow

Part of the Furniture
I have my IPK2 at 192.168.2.x and I do this by copying a customized /jffs/scripts/ipsec.conf to $CONFIG in /jffs/scripts/ipsec.postconf. You can also use the helper functions to only change the IPK2 address range, but I have a lot of customizations in mine, so for me it is easier to overwrite the entire ipsec.conf.
that is nice it can be override with custom scripts.
 

gspannu

Regular Contributor
that is nice it can be override with custom scripts.
Yes, great news... waiting for assistance - some details as to how to actually do this?
 

stamzrat10

Occasional Visitor
Dear RMerlin and team, there is a bug in this build, which was also present in the beta versions.

Whenever I change a rule at the VPN Director, be it by enabling or disabling a rule, deleting or adding a rule, somethings gets messed up with Diversion. I think that is changes how the VPN's DNS policy behaves.

So if I am disabling one rule through VPN Director, Diversion just stops blocking. Only a reboot of the router fixes it.
I have done some experiments and this happens especially when disabling a rule and letting a specific device use WAN instead of a VPN tunnel.
Suddenly all the traffic is not tunneled through the DNS of choice, and Diversion stops working.

In the WAN tab (Connect to DNS Server automatically NO, custom DNS) as well as the openvpn client custom configuration (dhcp-option DNS x.x.x.x) I have set the DNS to a specific one. When disabling a rule through VPN director, diversion stops working for ALL OF DEVICES
 

RMerlin

Asuswrt-Merlin dev
Dear RMerlin and team, there is a bug in this build, which was also present in the beta versions.

Whenever I change a rule at the VPN Director, be it by enabling or disabling a rule, deleting or adding a rule, somethings gets messed up with Diversion. I think that is changes how the VPN's DNS policy behaves.

So if I am disabling one rule through VPN Director, Diversion just stops blocking. Only a reboot of the router fixes it.
Contact the Diversion developer on this, I'm not responsible for third party scripts behaviour.
 

SomeWhereOverTheRainBow

Part of the Furniture
I have done some experiments and this happens especially when disabling a rule and letting a specific device use WAN instead of a VPN tunnel.
Suddenly all the traffic is not tunneled through the DNS of choice, and Diversion stops working.

In the WAN tab (Connect to DNS Server automatically NO, custom DNS) as well as the openvpn client custom configuration (dhcp-option DNS x.x.x.x) I have set the DNS to a specific one. When disabling a rule through VPN director, diversion stops working for ALL OF DEVICES
@thelonelycoder
 
Status
Not open for further replies.

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top