OpenVPN Client: Missing routes in Routing Policy alternate routing table

Discussion in 'Tomato Firmware' started by eibgrad, May 15, 2019.

  1. eibgrad

    eibgrad Network Guru Member

    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; and If 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 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).

    root@tomato-lab2:/tmp/home/root# ip route show table main dev tun11  proto kernel  scope link  src dev vlan2  scope link dev br0  proto kernel  scope link  src dev vlan2  proto kernel  scope link  src dev lo  scope link
    default via dev vlan2
    root@tomato-lab2:/tmp/home/root# ip route show table 311
    default via 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 Seems mighty popular too, indicating many ppl are running into this problem.

    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.
    Malakai, rs232 and Jose C like this.
  2. eibgrad

    eibgrad Network Guru Member

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice