What's new

Asus RT-AC88U VPN Client Glitch

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

NightAss

New Around Here
Asus RT-AC88U VPN Client Glitch

using merlin 380.68 and the build before it

LhPsNOR.png


I setup a VPN to send my traffic to USA for netflix as you may have guessed but my server PC on IP 192.168.1.10 would sometimes use the same VPN with out me adding it to the list and to get my server PC back to my real IP I would need to restart the router or press apply on the vpn client settings page but a few hrs later it would do it again and I cant figger out why as the IP of my server is 192.168.1.10 and that never changes

any ideas?
 
When the Selective VPN routing is working correctly, check the RPDB table; issue:
Code:
ip rule

0: from all lookup local
10nnn from 192.168.1.20 lookup ovpnc1
10nnn from 192.168.1.17 lookup ovpnc1
<snip>

Assuming you are using VPN Client 1 you should see the two (intended) ovpnc1 entries you entered into the VPN Selective Routing table.

When the server 192.168.1.10 suddenly appears to be routed via the VPN then reissue the command and see if there is now an 'extra' entry for the server.
Code:
ip rule

0: from all lookup local
xxxx from 192.168.1.10 lookup ovpnc1

If there is now a spurious entry for the server, then rather than reboot, simply delete the rogue server entry.

But before deleting the RPDB rule manually (or pressing apply on the VPN GUI interface) check if there is now a 'corrupted' NVRAM variable e.g. for VPN Client 1:
Code:
nvram get vpn_client1_clientlist
nvram get vpn_client_clientlist

To manually delete the incorrect RPDB rule issue (where xxxx is the priority index shown for the RPDB rule):
Code:
ip rule del prio xxxx

and the server should no longer be routed via the VPN.

If the above worked, then you need to debug how the additional RPDB rule was added.

A start would be to implement some logging diagnostics.

e.g.
A crude method would be to run a cru (cron job) say every 5 mins and simply dump the RPDB table to Syslog
or
use RMerlin's published technique to temporarily substitute '/usr/sbin/ip' with a fake wrapper script e.g. '/tmp/fakeip' which dumps ALL 'ip' requests to Syslog to pinpoint precisely when the rogue RPDB rule addition is executed etc.

This may then give a clue to assist in identifying who/what is randomly requesting the server to be added to the RPDB table.
 
Last edited:

Similar threads

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