This is the first of several postings I will be making regarding bugs in the Shibby and FreshTomato implementations of OpenVPN. These are NOT new bugs. They've literally been around for YEARS. And I've identified many of them in posts from years past. I was hoping they would eventually be addressed by Shibby way back when, but it just never happened. And these bugs have now migrated to FreshTomato. I'm hoping w/ the new crop of developers we might be able to fix at least a few of them. The sheer number of them has made it nearly impossible for me to use (or recommend) the Routing Policy feature for all these many years. I just plain gave up on it and decided to build my own PBR (policy based routing) scripts. But it would sure be nice if tomato users could finally rely on Routing Policy to work correctly and reliably (I'll get to the reliability issue in another bug report). Now to the first bug. When the Routing Policy tab is configured on the OpenVPN client, that results in the creation of an alternate routing table. Packets are then marked in accordance w/ Routing Policy rules such that only certain packets are routed through that table. However, the problem w/ the current implementation is that it only contains a single route; a default gateway that points to the VPN. And that means any local device configured to route through that table only has one routing option; the internet. For example, assume there are two local networks; 192.168.1.0/24 and 192.168.2.0/24. If 192.168.2.0/24 is configured in Routing Policy to use the alternate routing table, it will have internet access, but ONLY internet access. It can't communicate w/ the 192.168.1.0/24 network, or any other local networks. The routes simply don't exist in that routing table. If there are static routes defined in the main/default routing table, those are missing as well. What follows are two dumps; one of the main routing table, the other table 311, after the OpenVPN client (#1) on FreshTomato (2019.2) has gotten connected to the OpenVPN server (route-nopull option is checked). Code: root@tomato-lab2:/tmp/home/root# ip route show table main 10.13.0.29 dev tun11 proto kernel scope link src 10.13.0.30 192.168.61.1 dev vlan2 scope link 192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1 192.168.61.0/24 dev vlan2 proto kernel scope link src 192.168.61.51 127.0.0.0/8 dev lo scope link default via 192.168.61.1 dev vlan2 root@tomato-lab2:/tmp/home/root# ip route show table 311 default via 10.13.0.30 dev tun11 The solution is obvious; copy ALL routes from the main/default table (except default routes) to the alternate routing table, then add the default route that points to the VPN. FWIW, dd-wrt has the same bug (and has had it for just as long as tomato). And I long ago created a fix for it on PasteBin.com. Seems mighty popular too, indicating many ppl are running into this problem. https://pastebin.com/YwnHLqaa I'm working on a similar fix for Shibby and FreshTomato, but again, it would be nice to see this finally corrected in the firmware.