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; 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.
     
    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