Menu
What's new
By:
Filters Better Search

Clear/delete vpn profile from router?

  • 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!

Rango

Rango

Senior Member
Hello guys. Anyone know how to clear/delete vpn profile from the router?
I don't mind doing it from ssh but don't know how to do that either.

Reason i want to do it cause router says there is routing conflict. I did clear route 192.168.1.1 but that works on cisco only i think as it did not do anything on asus.

If anyone also knows how to clear all routes in asus router as well that would be awesome. Thank you.
 
Client or server?

It's mostly in nvram. Assuming OpenVPN client 1:

Code: 
nvram show | grep vpn_client1

This will give you the list of vpn_client1_xxx variables. You have to unset all of them, one by one.

Code: 
nvram unset vpn_client1_rgw
nvram unset vpn_client1_dns
etc...
nvram commit

Yes, there's a lot of them...
 
Client sir. Is there also way to clear routes without breaking anything.
I'm assuming router will recreated routes automatically on it's own via profile.

My client is showing i'm having route conflict although i don't see any issue with browsing.

Thank you for help.
 
Rango said:
Client sir. Is there also way to clear routes without breaking anything.
I'm assuming router will recreated routes automatically on it's own via profile.

My client is showing i'm having route conflict although i don't see any issue with browsing.

Thank you for help.
Click to expand...

Routes are dynamically created when the client start, they aren't permanent.
 
Should i ignore that message that there is "route conflict" in asus right in vpn profile.
This is not in ssh but right in gui of vpn profile. I can post a screenshot if this is never seen before message.
 
I only run one client at the time but i do switch between 128 and 256 encryption and test like speed and etc. It's same vpn company, just different encryption profile.
I have same error but i never run them at same time.

But only when i imported 2nd ovpn config i got the routing error. It doesn't look like it's affecting anything but routing confilict maybe should not be igonored hence i'm asking. I'm attaching screenshot. Thank you for chiming in and merlin thanks for guidance.
 

Attachments

  • routing-conflict2.PNG
    routing-conflict2.PNG
    329.7 KB · Views: 1,033
Last edited:
Read the content of Syslog for more details.
 
Rango said:
I only run one client at the time but i do switch between 128 and 256 encryption and test like speed and etc. It's same vpn company, just different encryption profile.
I have same error but i never run them at same time.

But only when i imported 2nd ovpn config i got the routing error. It doesn't look like it's affecting anything but routing confilict maybe should not be igonored hence i'm asking. I'm attaching screenshot. Thank you for chiming in and merlin thanks for guidance.
Click to expand...

OK, but in order to 'fix' my 'routing conflict' issues and have Selective Routing between two concurrent VPN Clients (from the same provider HMA) to two different locations

e.g.

VPN1=Hong Kong
VPN2=New York

I manually run this (crude hack) script FixRPDBVPN.sh after starting the second VPN Client

Code: 
#!/bin/sh
Issue_CMDQ(){
      /usr/bin/logger -s -t "($(basename $0))" $$ " " $@
      $@ 2> /dev/null > /dev/null
}
Issue_CMD(){
      /usr/bin/logger -s -t "($(basename $0))" $$ " " $@
      $@
}
/usr/bin/logger -s -t "($(basename $0))" $$ "RPDB multi-VPN Client Patching Started [$@]"

# Fix main - Probably easier to get user to specify route-nopull? but this prevents vpnrouting.sh from creating the RPDB rules :-(
Issue_CMDQ ip route delete 0.0.0.0/1
Issue_CMDQ ip route delete 128.0.0.0/1

PROCESS="0"
for LINE in `ip route show | grep "dev tun1" | awk ' {print "ip_route_add_default_via_"$9"_dev_"$3"_table_11"}'`
do

   /usr/bin/logger -s -t "($(basename $0))" $$ $LINE

   PROCESS="1"

   VPNID=`echo $LINE | awk ' FS="_"{print $8}'`;VPNID=${VPNID:4:1}
   MY_VPNTAB="11"$VPNID

   # Fix the current RPDB table 111,112 etc.
   Issue_CMD  ip route flush table $MY_VPNTAB
   #Issue_CMDQ ip route delete 0.0.0.0/1 table $MY_VPNTAB
   #Issue_CMDQ ip route delete 128.0.0.0/1 table $MY_VPNTAB


   # Add the only (default) route
   CMD=`echo $LINE$VPNID | sed 's/_/ /g'`
   /usr/bin/logger -s -t "($(basename $0))" $$ " " $CMD
   $CMD

done

ip route flush cache

#  Testing...
#   e.g. ip rule add from xxx.xxx.xxx.xxx lookup 111 prio 999
#        ...try to access http://geoip.hidemyass.com/ from xxx.xxx.xxx.xxx

#        ip rule del prio 999
#        ip rule add from xxx.xxx.xxx.xxx lookup 112 prio 999
#        ...try to access http://geoip.hidemyass.com/ from xxx.xxx.xxx.xxx
##       ip rule del prio 999


if [ "$PROCESS" == "1" ]; then
   /usr/bin/logger -s -t "($(basename $0))" $$ "RPDB multi-VPN Client Patching completed."
else
   /usr/bin/logger -s -t "($(basename $0))" $$ "RPDB multi-VPN Client Patching Skipped, no VPNs ACTIVE."
fi

@RMerlin vpnrouting.sh creating the second VPN Client instance always seems to cause my Routing conflict.
 
Merlin i run simple configuration with no any type of scripts enabled. I just have two different profiles from same vpn company, one for 128 and one for 256.
I only run one at the time. I also wait 5 seconds before i turn on second one after i turn off first to give router a chance to complete the switch, just to make sure. Reconnect at wan is no for both for now during the testing.

My best guess since i don't do anything too fancy is that when second profile, whatever it is is imported it conflicts or at least it says so that it conflicts with routing stating routing conflict. Here is my log. I deleted my vpn company from profile for security purpose. The log pretty much looks like this in whole as every hour authentication re-valides itself as it's set to every hour. If this isn't enough i can reboot and paste again as i know then it shows more info.
 
Last edited:
Martineau said:
vpnrouting.sh creating the second VPN Client instance always seems to cause my Routing conflict.
Click to expand...
Try this patched vpnrouting.sh

- copy the attached vpnrouting.sh.txt file to /tmp/vpnrouting.sh on the router
- issue the following command on the router
mount -o bind /tmp/vpnrouting.sh /usr/sbin/vpnrouting.sh

Hopefully this will help
 

Attachments

  • vpnrouting.sh.txt
    5.1 KB · Views: 748
john9527 said:
Try this patched vpnrouting.sh

- copy the attached vpnrouting.sh.txt file to /tmp/vpnrouting.sh on the router
- issue the following command on the router
mount -o bind /tmp/vpnrouting.sh /usr/sbin/vpnrouting.sh

Hopefully this will help
Click to expand...

I have been using the following VPN Client directive to quickly override the original vpnrouting.sh (for my tweaks) on a per VPN Client basis;)

Code: 
route-up   "/jffs/scripts/vpnrouting.sh"

rather than use this system-wide technique

Code: 
  mount -o bind /jffs/scripts/vpnrouting.sh /usr/sbin/vpnrouting.sh


OK, your patched version of vpnrouting.sh fixes the passing of args to openvpn-event!, and correctly flushes inappropriate table 254 entries for the first physical VPN Client to be started - usually VPN 1.

Jan 20 13:23:40 RT-AC68U daemon.notice openvpn[3470]: /usr/sbin/ip route add 113.29.228.130/32 via xxx.xxx.220.1
Jan 20 13:23:40 RT-AC68U daemon.notice openvpn[3470]: /usr/sbin/ip route add 0.0.0.0/1 via 10.200.4.1
Jan 20 13:23:40 RT-AC68U daemon.notice openvpn[3470]: /usr/sbin/ip route add 128.0.0.0/1 via 10.200.4.1
Jan 20 13:23:40 RT-AC68U daemon.notice openvpn[3470]: add_route_ipv6(): not adding 2000::/3, no IPv6 on if tun11
Jan 20 13:23:40 RT-AC68U user.warn openvpn-routing: Configuring policy rules for client 1
Jan 20 13:23:40 RT-AC68U user.warn openvpn-routing: Creating VPN routing table
Jan 20 13:23:40 RT-AC68U user.warn openvpn-routing: Removing route for 0.0.0.0/1 to tun11 from VPN table
Jan 20 13:23:40 RT-AC68U user.warn openvpn-routing: Removing route for 128.0.0.0/1 to tun11 from VPN table
Jan 20 13:23:40 RT-AC68U user.warn openvpn-routing: Removing route for 0.0.0.0/1 to tun11 from table main
Jan 20 13:23:40 RT-AC68U user.warn openvpn-routing: Removing route for 128.0.0.0/1 to tun11 from table main
Jan 20 13:23:40 RT-AC68U user.warn openvpn-routing: Removing rule 1201 from routing policy
Jan 20 13:23:40 RT-AC68U user.warn openvpn-routing: Added 172.0.0.1 to 0.0.0.0 through VPN to routing policy
Jan 20 13:23:40 RT-AC68U user.warn openvpn-routing: Tunnel re-established, restoring WAN access to clients
Jan 20 13:23:40 RT-AC68U user.warn openvpn-routing: Setting default VPN route via 10.200.4.1
Jan 20 13:23:40 RT-AC68U user.warn openvpn-routing: Completed routing policy configuration for client 1
Jan 20 13:23:40 RT-AC68U user.warn custom script: Running /jffs/scripts/openvpn-event (args: tun11 1500 1541 10.200.5.49 )
Jan 20 13:23:40 RT-AC68U user.warn (openvpn-event): route-up Starting......[tun11 1500 1541 10.200.5.49 ]
Jan 20 13:23:40 RT-AC68U user.warn (openvpn-event): Debug Caller=tun11 1500 1541 10.200.5.49
Jan 20 13:23:40 RT-AC68U user.warn (openvpn-event): VPN_name= , detected for dev=tun11 and Script Type=route-up
Jan 20 13:23:40 RT-AC68U user.warn (openvpn-event): Complete.
Jan 20 13:23:40 RT-AC68U daemon.notice openvpn[3470]: Initialization Sequence Completed

but for the second VPN Client starting, there are no messages indicating that your code amendments are being executed.... o_O

Jan 20 13:24:50 RT-AC68U daemon.notice openvpn[3642]: /usr/sbin/ip route add 192.157.56.146/32 via xxx.xxx.220.1
Jan 20 13:24:50 RT-AC68U daemon.notice openvpn[3642]: /usr/sbin/ip route add 0.0.0.0/1 via 10.200.4.1
Jan 20 13:24:50 RT-AC68U daemon.notice openvpn[3642]: /usr/sbin/ip route add 128.0.0.0/1 via 10.200.4.1
Jan 20 13:24:50 RT-AC68U daemon.notice openvpn[3642]: add_route_ipv6(): not adding 2000::/3, no IPv6 on if tun12
Jan 20 13:24:50 RT-AC68U user.warn openvpn-routing: Configuring policy rules for client 2
Jan 20 13:24:50 RT-AC68U user.warn openvpn-routing: Creating VPN routing table
Jan 20 13:24:50 RT-AC68U user.warn openvpn-routing: Removing rule 1601 from routing policy
Jan 20 13:24:50 RT-AC68U user.warn openvpn-routing: Added 172.0.0.2 to 0.0.0.0 through VPN to routing policy
Jan 20 13:24:50 RT-AC68U user.warn openvpn-routing: Setting default VPN route via 10.200.4.1
Jan 20 13:24:50 RT-AC68U user.warn openvpn-routing: Completed routing policy configuration for client 2
Jan 20 13:24:50 RT-AC68U user.warn custom script: Running /jffs/scripts/openvpn-event (args: tun12 1500 1541 10.200.5.10 )
Jan 20 13:24:50 RT-AC68U user.warn (openvpn-event): route-up Starting......[tun12 1500 1541 10.200.5.10 ]
Jan 20 13:24:50 RT-AC68U user.warn (openvpn-event): Debug Caller=tun12 1500 1541 10.200.5.10
Jan 20 13:24:50 RT-AC68U user.warn (openvpn-event): VPN_name= , detected for dev=tun12 and Script Type=route-up
Jan 20 13:24:50 RT-AC68U user.warn (openvpn-event): Complete.
Jan 20 13:24:50 RT-AC68U daemon.notice openvpn[3642]: Initialization Sequence Completed

but sadly table 112 is still being populated with incorrect table 254 derived routes.

i.e. after starting VPN client 1

Code: 
admin@RT-AC68U:/tmp/home/root# ip route

xxx.xxx.xxx.1 dev vlan2  scope link
113.29.228.130 via xxx.xxx.220.1 dev vlan2
10.8.0.0/24 dev tun21  proto kernel  scope link  src 10.8.0.1
10.88.8.0/24 dev br0  proto kernel  scope link  src 10.88.8.1
xxx.xxx.220.0/22 dev vlan2  proto kernel  scope link  src xxx.xxx.221.47
10.200.4.0/22 dev tun11  proto kernel  scope link  src 10.200.5.49
127.0.0.0/8 dev lo  scope link
default via xxx.xxx.220.1 dev vlan2

admin@RT-AC68U:/tmp/home/root# ip route show table 111

xxx.xxx.xxx.1 dev vlan2  scope link
192.157.56.146 via xxx.xxx.220.1 dev vlan2
10.8.0.0/24 dev tun21  proto kernel  scope link  src 10.8.0.1
10.88.8.0/24 dev br0  proto kernel  scope link  src 10.88.8.1
xxx.xxx.220.0/22 dev vlan2  proto kernel  scope link  src xxx.xxx.221.47
10.200.4.0/22 dev tun11  proto kernel  scope link  src 10.200.5.49
127.0.0.0/8 dev lo  scope link
default via 10.200.4.1 dev tun11


and after starting VPN client 2, both tables are 'corrupt'

Code: 
admin@RT-AC68U:/tmp/home/root# ip route

xxx.xxx.xxx.1 dev vlan2  scope link
192.157.56.146 via xxx.xxx.220.1 dev vlan2
113.29.228.130 via xxx.xxx.220.1 dev vlan2
10.8.0.0/24 dev tun21  proto kernel  scope link  src 10.8.0.1
10.88.8.0/24 dev br0  proto kernel  scope link  src 10.88.8.1
xxx.xxx.220.0/22 dev vlan2  proto kernel  scope link  src xxx.xxx.221.47
10.200.4.0/22 dev tun11  proto kernel  scope link  src 10.200.5.49
10.200.4.0/22 dev tun12  proto kernel  scope link  src 10.200.5.10
127.0.0.0/8 dev lo  scope link
0.0.0.0/1 via 10.200.4.1 dev tun11
128.0.0.0/1 via 10.200.4.1 dev tun11
default via xxx.xxx.220.1 dev vlan2

admin@RT-AC68U:/tmp/home/root# ip route show table 112

xxx.xxx.220.1 dev vlan2  scope link
192.157.56.146 via xxx.xxx.220.1 dev vlan2
113.29.228.130 via xxx.xxx.220.1 dev vlan2
10.8.0.0/24 dev tun21  proto kernel  scope link  src 10.8.0.1
10.88.8.0/24 dev br0  proto kernel  scope link  src 10.88.8.1
xxx.xxx.220.0/22 dev vlan2  proto kernel  scope link  src xxx.xxx.221.47
10.200.4.0/22 dev tun11  proto kernel  scope link  src 10.200.5.49
127.0.0.0/8 dev lo  scope link
0.0.0.0/1 via 10.200.4.1 dev tun11
128.0.0.0/1 via 10.200.4.1 dev tun11
default via 10.200.4.1 dev tun11

P.S. I should probably now incorporate my FixRPDBVPN.sh code into openvpn-event now you are correctly passing valid args! :D
 
Last edited:
If you think there's an actual bug in the script and you have a fix (not just a patch/workaround), feel free to provide a pull request. I don't feel like doing any troubleshooting on this right now, but I can at least review the pull request at some time.
 
RMerlin said:
If you think there's an actual bug in the script and you have a fix (not just a patch/workaround), feel free to provide a pull request. I don't feel like doing any troubleshooting on this right now, but I can at least review the pull request at some time.
Click to expand...

RMerlin,

Thank you for taking time to comment.

Clearly you have other priorities at this time, consequently investigating this insignificant issue shouldn't even be in your top 10,000 of things-to-worry-about!

@john9527 has kindly found time to investigate, and I'm sure you will agree, it is in capable hands.

Regards,
 
Martineau said:
and after starting VPN client 2, both tables are 'corrupt'
Click to expand...
Did you remove your custom route-up directive? I just double checked, routing one client thru VPN 1 and another through VPN 2 and everthing is correct and working with the replacement vpnrouting (btw...that is the vpnrouting.sh from my fork).
 
john9527 said:
Did you remove your custom route-up directive? I just double checked, routing one client thru VPN 1 and another through VPN 2 and everthing is correct and working with the replacement vpnrouting (btw...that is the vpnrouting.sh from my fork).
Click to expand...

Yes, ;)

NOTE: There is a warning when the route-up directive is detected..

Code: 
Jan 20 11:45:46 RT-AC68U kern.notice rc_service: httpd 482:notify_rc start_vpnclient1
Jan 20 11:45:48 RT-AC68U daemon.warn openvpn[2076]: Multiple --route-up scripts defined.  The previously configured script is overridden.

but I'm 100% sure that your patched vpnrouting.sh was used in my (multiple) tests.
 
Martineau said:
but I'm 100% sure that your patched vpnrouting.sh was used in my (multiple) tests
Click to expand...

Here's my tables from the test.....VPN 1 started first, then VPN 2....

Code: 
admin@AC68P-06650:/tmp/home/root# ip route
192.168.100.1 dev eth0  scope link
70.171.xxx.1 dev eth0  scope link
10.162.1.5 dev tun11  proto kernel  scope link  src 10.162.1.6
198.7.58.147 via 70.171.209.1 dev eth0
98.143.158.178 via 70.171.209.1 dev eth0
10.10.0.185 dev tun12  proto kernel  scope link  src 10.10.0.186
192.168.100.0/24 dev eth0  proto kernel  scope link  src 192.168.100.2
10.8.0.0/24 dev tun21  proto kernel  scope link  src 10.8.0.1
192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.1
70.171.xxx.0/24 dev eth0  proto kernel  scope link  src 70.171.xxx.119
127.0.0.0/8 dev lo  scope link
default via 70.171.xxx.1 dev eth0
 
admin@AC68P-06650:/tmp/home/root# ip route show table 111
192.168.100.1 dev eth0  scope link
70.171.xxx.1 dev eth0  scope link
10.162.1.1 via 10.162.1.5 dev tun11
10.162.1.5 dev tun11  proto kernel  scope link  src 10.162.1.6
98.143.158.178 via 70.171.209.1 dev eth0
192.168.100.0/24 dev eth0  proto kernel  scope link  src 192.168.100.2
192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.1
10.8.0.0/24 dev tun21  proto kernel  scope link  src 10.8.0.1
70.171.xxx.0/24 dev eth0  proto kernel  scope link  src 70.171.xxx.119
127.0.0.0/8 dev lo  scope link
default via 10.162.1.5 dev tun11
 
admin@AC68P-06650:/tmp/home/root# ip route show table 112
10.10.0.1 via 10.10.0.185 dev tun12
192.168.100.1 dev eth0  scope link
70.171.xxx.1 dev eth0  scope link
10.162.1.5 dev tun11  proto kernel  scope link  src 10.162.1.6
98.143.158.178 via 70.171.209.1 dev eth0
198.7.58.147 via 70.171.209.1 dev eth0
10.10.0.185 dev tun12  proto kernel  scope link  src 10.10.0.186
192.168.100.0/24 dev eth0  proto kernel  scope link  src 192.168.100.2
192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.1
10.8.0.0/24 dev tun21  proto kernel  scope link  src 10.8.0.1
70.171.xxx.0/24 dev eth0  proto kernel  scope link  src 70.171.xxx.119
127.0.0.0/8 dev lo  scope link
default via 10.10.0.185 dev tun12
admin@AC68P-06650:/tmp/home/root# ip rule
 
0:      from all lookup local
1001:   from 192.168.1.1 lookup main
1002:   from 10.8.0.0/24 lookup main
1201:   from 192.168.1.100 lookup 111
1401:   from 192.168.1.1 lookup main
1402:   from 10.8.0.0/24 lookup main
1601:   from 192.168.1.101 lookup 112
32766:  from all lookup main
32767:  from all lookup default

The duplicate rule entries for table main should probably be cleaned up at some point, but won't hurt anything. .100 thru VPN1 and .101 thru VPN2. (10.8.0.0 is my VPN server)
 
john9527 said:
Here's my tables from the test.....VPN 1 started first, then VPN 2....

The duplicate rule entries for table main should probably be cleaned up at some point, but won't hurt anything. .100 thru VPN1 and .101 thru VPN2. (10.8.0.0 is my VPN server)
Click to expand...

Here is my patched version of vpnrouting.sh (with eye-catcher to Syslog!!!) incorporating your patch to pass the appropriate args to openvpn-event.

For me, table 112 is now created correctly (and table 254 is correctly modified) when VPN client 2 is started after VPN Client 1:


Code: 
admin@RT-AC68U:/tmp/home/root# ip route

192.157.56.146 via xxx.xxx.240.1 dev vlan2
113.29.228.130 via xxx.xxx.240.1 dev vlan2
xxx.xxx.240.1 dev vlan2  scope link
10.8.0.0/24 dev tun21  proto kernel  scope link  src 10.8.0.1
10.88.8.0/24 dev br0  proto kernel  scope link  src 10.88.8.1
10.200.4.0/22 dev tun11  proto kernel  scope link  src 10.200.5.49
10.200.4.0/22 dev tun12  proto kernel  scope link  src 10.200.5.10
xxx.xxx.240.0/22 dev vlan2  proto kernel  scope link  src xxx.xxx.240.145
127.0.0.0/8 dev lo  scope link
default via xxx.xxx.240.1 dev vlan2


admin@RT-AC68U:/tmp/home/root# ip route show table 111

192.157.56.146 via xxx.xxx.240.1 dev vlan2
113.29.228.130 via xxx.xxx.240.1 dev vlan2
xxx.xxx.240.1 dev vlan2  scope link
10.8.0.0/24 dev tun21  proto kernel  scope link  src 10.8.0.1
10.88.8.0/24 dev br0  proto kernel  scope link  src 10.88.8.1
10.200.4.0/22 dev tun11  proto kernel  scope link  src 10.200.5.49
xxx.xxx.240.0/22 dev vlan2  proto kernel  scope link  src xxx.xxx.240.145
127.0.0.0/8 dev lo  scope link
default via 10.200.5.49 dev tun11

admin@RT-AC68U:/tmp/home/root# ip route show table 112

192.157.56.146 via xxx.xxx.240.1 dev vlan2
113.29.228.130 via xxx.xxx.240.1 dev vlan2
xxx.xxx.240.1 dev vlan2  scope link
10.8.0.0/24 dev tun21  proto kernel  scope link  src 10.8.0.1
10.88.8.0/24 dev br0  proto kernel  scope link  src 10.88.8.1
10.200.4.0/22 dev tun11  proto kernel  scope link  src 10.200.5.49
xxx.xxx.240.0/22 dev vlan2  proto kernel  scope link  src xxx.xxx.240.145
127.0.0.0/8 dev lo  scope link
default via 10.200.5.10 dev tun12

Jan 21 11:38:45 RT-AC68U daemon.warn openvpn[7024]: Ignore conflicted routing rule: 113.29.228.130 255.255.255.255

Jan 21 11:38:45 RT-AC68U daemon.notice openvpn[7024]: /usr/sbin/ip route add 0.0.0.0/1 via 10.200.4.1
Jan 21 11:38:45 RT-AC68U daemon.notice openvpn[7024]: /usr/sbin/ip route add 128.0.0.0/1 via 10.200.4.1
Jan 21 11:38:45 RT-AC68U daemon.notice openvpn[7024]: add_route_ipv6(): not adding 2000::/3, no IPv6 on if tun11
Jan 21 11:38:45 RT-AC68U user.warn (vpnrouting.sh): 7135 Patched by John9527/Martineau vpnrouting.sh
Jan 21 11:38:45 RT-AC68U user.warn openvpn-routing: Configuring policy rules for client 1
Jan 21 11:38:45 RT-AC68U user.warn openvpn-routing: Creating VPN routing table
Jan 21 11:38:45 RT-AC68U user.warn openvpn-routing: Removing routes 0.0.0.0/1,128.0.0.0/1 from table main
Jan 21 11:38:46 RT-AC68U user.warn openvpn-routing: Removing rule 1101 from routing policy
Jan 21 11:38:46 RT-AC68U user.warn openvpn-routing: Added 172.0.0.1 to 0.0.0.0 through VPN to routing policy
Jan 21 11:38:46 RT-AC68U user.warn openvpn-routing: Tunnel re-established, restoring WAN access to VPN clients
Jan 21 11:38:46 RT-AC68U user.warn openvpn-routing: Setting default route 10.200.5.49 for table 111
Jan 21 11:38:46 RT-AC68U user.warn openvpn-routing: Completed routing policy configuration
Jan 21 11:38:46 RT-AC68U user.warn custom script: Running /jffs/scripts/openvpn-event (args: tun11 1500 1541 10.200.5.49 )
Jan 21 11:38:46 RT-AC68U user.warn (openvpn-event): route-up Starting......[tun11 1500 1541 10.200.5.49 ]
Jan 21 11:38:46 RT-AC68U daemon.notice openvpn[7024]: Initialization Sequence Completed


Jan 21 11:39:26 RT-AC68U daemon.warn openvpn[7222]: Ignore conflicted routing rule: 192.157.56.146 255.255.255.255

Jan 21 11:39:26 RT-AC68U daemon.notice openvpn[7222]: /usr/sbin/ip route add 0.0.0.0/1 via 10.200.4.1
Jan 21 11:39:26 RT-AC68U daemon.notice openvpn[7222]: /usr/sbin/ip route add 128.0.0.0/1 via 10.200.4.1
Jan 21 11:39:26 RT-AC68U daemon.notice openvpn[7222]: add_route_ipv6(): not adding 2000::/3, no IPv6 on if tun12
Jan 21 11:39:26 RT-AC68U user.warn (vpnrouting.sh): 7327 Patched by John9527/Martineau vpnrouting.sh
Jan 21 11:39:26 RT-AC68U user.warn openvpn-routing: Configuring policy rules for client 2
Jan 21 11:39:26 RT-AC68U user.warn openvpn-routing: Creating VPN routing table
Jan 21 11:39:26 RT-AC68U user.warn openvpn-routing: Removing routes 0.0.0.0/1,128.0.0.0/1 from table main
Jan 21 11:39:26 RT-AC68U user.warn openvpn-routing: Setting default route 10.200.5.10 for table 112
Jan 21 11:39:26 RT-AC68U user.warn openvpn-routing: Completed routing policy configuration
Jan 21 11:39:26 RT-AC68U user.warn custom script: Running /jffs/scripts/openvpn-event (args: tun12 1500 1541 10.200.5.10 )
Jan 21 11:39:26 RT-AC68U daemon.notice openvpn[7222]: Initialization Sequence Completed

I believe the non-fatal spurious

Error connecting - IP/Routing conflict

message is simply due to the fact that if either VPN is restarted manually via the GUI, then table 254 still retains the VPN end-point I/P addresses which do not get automatically removed.

i.e. if I manually remove the VPN endpoints

Code: 
ip route del 192.157.56.146
ip route del 113.29.228.130

...( or reboot!) before starting the associated VPN client then the I/P Routing conflict message never appears.

So I suspect that /etc/openvpn/client?/updown.sh should ultimately be modified to remove these routes?
 

Attachments

  • vpnrouting.txt
    5.9 KB · Views: 768
Last edited:
Maybe this is still not working as maybe when i was getting rid of some info from client1 (which i no longer use) when i did apply maybe it was starting the client again hance stating routing conflict if two vpn clients are running at the same time. Although i can't visually see that is running. I'm only speculating here. I noticed that when i restart the router the routing conflict no longer is present, so maybe only when i apply changes which leads me to what i said. This is on 87u router.

FIXED: Applying changes to OpenVPN client page would start the client even if it was disabled/stopped.
 
You must log in or register to reply here.

Similar threads

orudie
RT-AX86U Pro: after router reboot VPN Fusion Wireguard profile stock on connecting and Internet does not work
Replies
0
Views
330
orudie
orudie
E
Wireguard can't access devices behind asus router
Replies
5
Views
299
ZebMcKayhan
Z
eibgrad
OpenVPN Client: mishandled route directives
Replies
7
Views
820
eibgrad
eibgrad
P
Accessing remotly Server While Using VPN on Asus Router with Merlin Firmware
Replies
9
Views
201
eibgrad
eibgrad
DiOnlyThingINoIsThatIDont
The Asus + Merlin + NordVPN router never disconnects from the internet when NordVPN stops working for a moment.
Replies
4
Views
1K
Viktor Jaep
Viktor Jaep
Similar threads
Thread starter Title Forum Replies Date
P Accessing remotly Server While Using VPN on Asus Router with Merlin Firmware Asuswrt-Merlin 9
G Using VPN Director to route only torrent traffic through VPN Asuswrt-Merlin 9
B Unable to establish VPN connection to my PiVPN (ovpn) from my Asus RT-AC86U running Asuswrt-Merlin 386.14 Asuswrt-Merlin 1
T Wireguard Client VPN not using DNS Asuswrt-Merlin 14
S Wireguard VPN doesn't work, buyer beware Asuswrt-Merlin 6
G VPN director configuration for qBittorrent Asuswrt-Merlin 7
J ASUS GT-AXE16000 CPU usage with VPN on lan machine Asuswrt-Merlin 25
I Wireguard VPN client does not autostart after reboot Asuswrt-Merlin 2
Z Sudden VPN client issues with RX-AX82U Asuswrt-Merlin 5
D VPN director issue on RT-AC86U (386.14 Merlin FW) Asuswrt-Merlin 9

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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

Members online

Total: 653 (members: 31, guests: 622)
Top