Another oldie but goodie. IMO, the OpenVPN client (and server for that matter) have a serious design flaw. And I believe it's because the original developer(s) didn't fully appreciate the importance of the OpenVPN scripting engine to the proper configuration and management of the service. A proper implementation of OpenVPN necessarily requires use of the OpenVPN scripting engine. Without it, the router remains oblivious to certain important events during the connection lifecycle between the OpenVPN client and server. Case and point; soft restarts. As I discussed in my previous posting, Routing Policy creates an alternate routing table that has as its default gateway the VPN, so that specific devices can be routed through it, while others remain routed through the main routing table and over the WAN/ISP. The problem w/ NOT using the OpenVPN scripting engine is that sometimes OpenVPN will trigger what's called a soft restart. This occurs for various reasons (e.g., one side issues a reset for some reason). The net effect is that the connection between the OpenVPN client and server is briefly lost, then re-established. Most users wouldn't even be aware this is happening (but it will show in the syslog). It happens quietly, quickly, and randomly. And when it happens, *all* the routing information relative to the VPN connection is lost and needs to be re-established. The routing system automatically flushes any and all references to the OpenVPN network interfaces before adding them back once the connection is re-established. But since the OpenVPN client isn't listening for the up/down events to be triggered, it's oblivious to what has just happened, and therefore fails to rebuild the alternate routing table! Suddenly and without warning, your OpenVPN client is routing all your previous VPN traffic back over the WAN/ISP. If you happen to have a kill switch, at least that traffic gets blocked. But it will confuse the average user because they will have no idea why the OpenVPN connection has stopped working. In the worst case, as I said, the traffic gets routed back out the WAN/ISP. If you want to see this for yourself, it's pretty simple to reproduce. Configure and connect the OpenVPN client (let's assume #1 for this example) to the OpenVPN server, and then open three (3) separate shells (telnet/ssh) to the router. In the first shell, issue the following command. Code: watch -n5 "ip route show table main; echo; ip route show table 311" This will monitor the relevant routing tables. Let that get well established for a minute or two. You want to see the default route to the VPN appear in table 311 before proceeding. In the second shell, issue the following command. Code: watch "tail -n15 /var/log/messages" This monitors the syslog. Finally, in the third shell, issue the following command. Code: killall -s SIGUSR1 openvpn This forces a soft restart. Watch what happens to the alternate routing table, 311. Eventually it just disappears! And never to return. And if you look at the syslog, you'll see the connection has been lost and re-established. But it gets even worse. Not only is the alternate routing table managed outside OpenVPN's scripting engine, but also the application of firewall rules. What most ppl don't realize is that whenever *any* OpenVPN client is initialized, the router (NOT OpenVPN) reinitializes *all* the firewall rules for *all* the other active OpenVPN clients too! I ran into this problem while developing my own PBR (policy based routing) scripts. I would have one OpenVPN client configured and supplemented w/ my own firewall rules, then start the second OpenVPN client, and it would wipe out all my firewall rules from the first OpenVPN client! Admittedly, these are very tough problems to fix because the real mistake was NOT using the OpenVPN scripting engine to manage the service. And to now correct that mistake would require a major overhaul. I assume that's why Merlin uses the scripting engine w/ his own firmware, despite that firmware being a tomato variant. He recognized the problem and decided to do things properly. I don't see an easy solution here. Like most of the bugs I'm now reporting, this one has been around ever since Routing Policy was introduced by Shibby. And in the early days, I wrote a script to address it. https://pastebin.com/sgNGsjaa Yes, it dates back to 2015! And it's pretty crude. I think I wrote in like 20 mins. And here's the initial identification of this bug way back when. https://www.linksysinfo.org/index.p...uting-policy-empty-routing-table-“111”.71746/ But the fix, as currently written, will only work w/ Shibby tomato and prior tomato variants. FreshTomato now uses a different set of table IDs for its OpenVPN clients (311, 312, an 313). And it has a one more OpenVPN client. So the script needs to be updated (which I'm currently doing). Although the concept behind the fix/hack works (most of the time anyway), it's one crappy solution. It parses the output from ifconfig to find the tunnel's network interface, picks off the IP assigned to the OpenVPN client, and uses that as the VPN's default gateway. But that's not guaranteed to work 100% of the time. The VPN provider *might* require a special gateway for his OpenVPN users. But of course, that's only made available to OpenVPN clients who are using the scripting engine! Anyway, I don't really expect this bug/problem to be fixed, at least not anytime soon. The "problem" is bigger than this one bug. It's more a case of putting ppl on notice regarding the reliability of Routing Policy wrt either Shibby or FreshTomato, and how to deal with it.