policy routing failing to route through vpn.

[eibgrad]

OK, so after entering the rule for .183 and immediately running ip rule I get:

:/tmp/home/root# ip rule add from 192.168.50.183 table ovpnc1 prior 10101

:/tmp/home/root# ip rule
0: from all lookup local
10101: from 192.168.50.183 lookup ovpnc1
32766: from all lookup main
32767: from all lookup default

So, thats good news right? However if I go to the GUI and press "Apply" for *any* changes, the rules get erased and it reverts to no rules. We are on to something but I dont think it is anything good.

EDIT: attached log from "apply" No changes were made to anything other than command line rule entry, I checked the rule, it worked, I then went to GUI ( screenshot above) and hit APPLY.

I realize that applying the rules manually *then* restarting the GUI via Apply is NOT going to work since that will reset the rules. What I was suggesting is letting the GUI get connected and configured, waiting a few seconds, then applying the rules. But NOT because I believe this is a long-term solution (or even short-term). That's much too tedious. I merely suggested it as a means to confirm that indeed the problem is the failure of the OpenVPN client to add these same rules (for reasons that are currently NOT known) and not something else we may have overlooked.

IOW, we still need to figure out why these rules are not being applied by the GUI.

 

[ex99125b]

I realize that applying the rules manually *then* restarting the GUI via Apply is NOT going to work since that will reset the rules. What I was suggesting is letting the GUI get connected and configured, waiting a few seconds, then applying the rules. But NOT because I believe this is a long-term solution (or even short-term). That's much too tedious. I merely suggested it as a means to confirm that indeed the problem is the failure of the OpenVPN client to add these same rules (for reasons that are currently NOT known) and not something else we may have overlooked.

IOW, we still need to figure out why these rules are not being applied by the GUI.

I understood your suggestion, followed your instructions, thanks it was a good call.
And yes, CLI sets the rules appropriately and as long as I never press "Apply" *for any reason* after applying the rules via CLI the PBR rules stay intact. So that essentially means that if I intend upon making any configuration changes (to any function of the router) I have to redo my PBR rules via CLI.

EDIT: the text file in my above message is the log from when I press "apply" at any time after succesfully setting PBR rules via CLI--the two events, PBR rule setting and "apply"-- are not connected.

 

[eibgrad]

As long as I never press "Apply" *for any reason* after applying the rules via CLI the PBR rules stay intact.

That's what I would expect. I'm still baffled why those rules are not being applied by the GUI.

P.S. Maybe you should just reset the router to factory defaults and start over. Maybe it got into some weird state for some unknown reason.

 

[ex99125b]

That's what I would expect. I'm still baffled why those rules are not being applied by the GUI.

P.S. Maybe you should just reset the router to factory defaults and start over. Maybe it got into some weird state for some unknown reason.

Thats been my thought. Mostly because the GUI has strange behaviors regarding substituted text...VAN for WAN, TO GO for TUN etc. there are about 10 of them. this tells me something is crashing GUI memory and isnt dynamic, It happened sometime soon after installing my USB stick. I did a factory reset to revert back to zero when I upgraded to an SSD, but the GUI errors persisted through the reset and 3 reboot process. Im at a loss. I can do the reset, but I fear it will be for naught.

EDIT: an interesting GUI artifact: when the list of clients is brought up from the "network map" page, the entry for my (hardwired) roku bounces (1 per second) between YEAR-ETH and ROKU-ETH and the MAC bounces between a single line display and double line display. So the word ROKU is being held somewhere in memory that hasnt been crashed, but there is another address that has gotten overwritten such that YEAR gets substituted. So, yeh...

 

[eibgrad]

Btw, it's a least theoretically possible for *any* of the flash partitions (root, jffs, nvram, etc.) to have gotten corrupted. So if problems persist, it might be prudent to reinstall the firmware as well, and NOT just reset nvram.

 

[ex99125b]

Btw, it's a least theoretically possible for *any* of the flash partitions (root, jffs, nvram, etc.) to have gotten corrupted. So if problems persist, it might be prudent to reinstall the firmware as well, and NOT just reset nvram.

If I didnt know better, It might be the time to jump to 186, but AC66U
(and 40 years of experience)

 

[Martineau]

So, thats good news right? However if I go to the GUI and press "Apply" for *any* changes, the rules get erased and it reverts to no rules. We are on to something but I dont think it is anything good.

The GUI calls /usr/sbin/vpnrouting.sh to manage the RPDB rules and apply the Kill-switch if appropriate.

If the nvram VPN client list doesn't contain the .138 or the rule PRIO is in the reserved range as used by /usr/sbin/vpnrouting.sh then it is indeed lost.

 

[ex99125b]

The GUI calls /usr/sbin/vpnrouting.sh to manage the RPDB rules and apply the Kill-switch if appropriate.

If the nvram VPN client list doesn't contain the .138 then it is indeed lost.

thanks, Im really starting to believe that I have a piece of corrupted static memory that keeps overwriting parts of the GUI on reboot, and therefore that corrupted portion of the GUI keeps bunging stuff. Ill start with a fresh image tomorrow. Because Im on old hardware, Ill stick with 184.19. For the sake of the archives, Ill report back with results.

 

[ex99125b]

Cause:
TL/DR:
MacOS 10.13.6/Mozilla Firefox 85.0.2/"Translate web pages" google translator add-on, ver 7.7
The Google translate add-on corrupts the Merlin 184.19 GUI, and those corruptions get written to Merlin upon "apply" Disabling the add-on stops the corruptions but doesnt fix what its already done. Several restarts were required.

It was a long and arduous debug process, but I started to notice that other web based apps were starting to have corrupted graphic elements.That led to debugging my browser.

Discovering that turning off the add-on or starting in safe mode or changing browsers--like...in my previous attempts at troubleshooting this problem--didnt fix the issues. Only restarting the router several times corrected the issue.

I now have policy based routing working well.

I want to say a big thank you for everyone who took the time to help me out in this thread.

As face-palming obvious as a bad browser is, and as elemental as it is to step one in any debugging scenario, the semi-permanence of the corruption complicated it greatly. Even us grey-beards get punked some times.

Thank you.