What's new

Release Asuswrt-Merlin 386.3 is now available

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
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.
 
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.
 
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.
 
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.
 
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:
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.
 
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.
 
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.
 
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.
 
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.
 
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
 
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 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...
 
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.
 
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
 
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.
 
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
 
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

To test the VPNClient killswitch you need to open a SSH session on your router. To do that you need to go to the Administration > System tab after logging in with your browser to the router. Half way down the page under "Service" - Enable SSH for LAN only - do not allow SSH Port Forwarding and choose a non-default port [say 222] and allow password login.

I use MobaXterm on my Windows 10 workstation as a terminal for SSH and several other useful remote tools. Use that or Putty or any other terminal of your choice to login to your Router under SSH terminal using your admin username and password.

At the command prompt you can issue those commands that I pointed out to you.
So if you have configured OpenVPN Client No 1 to route certain Local IP's through a VPN service provider - then with that OVPN1 enabled you would type this command at the Terminal prompt ...

Code:
killall vpnclient1

[Change the 1 to a 2, 3 ,4 or 5 .... depending on which VPNClient you want to test].
Check whether the Local IP's that you had directed through the VPN Tunnel have now lost internet connection - and if so - the killswitch is working as designed. Now to bring the VPN Tunnel back up again issue this command at the terminal prompt ...

Code:
service start_vpnclient1

Now check that the Local IP's that you had directed through the VPN tunnel have had their internet connection restored.

If my explanation above is "overkill" - sorry ... but I have no idea of your skills level ... but do remember all too well when I first joined this forum as a non-coder noob ... first posts are not always easy given the high skill levels of so many members :).

PS - If you are a noob like I was - then if not done already - at that SSH command prompt - type "amtm" and open Pandora's Box to a huge array of awesome add-ons [like those in my signature]. Just follow the prompts and read here if stuck ...
 
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