Need help setting up VPN client on second Tomato router

Discussion in 'Networking Issues' started by MaxMax, Apr 16, 2019.

  1. MaxMax

    MaxMax New Member Member

    Hello everyone, I'm sorry if this question was already answered somewhere else but I was not able to find answer.

    Task:
    Setup a Tomato router as second WiFi access point using a OpenVPN tunnel for the wireless clients connected via this access point. On LAN, the devices connected to the first router must be reachable from the devices connected to second router.

    Current setup:
    Router A from ISP providing internet connection gateway.
    Router B Linksys E2500 with latest Tomato firmware

    Connection A-B: LAN to LAN Ethernet
    Router A IP: 192.168.2.1 with DHCP server for the IP range 2-199

    Router B (Tomato):
    WAN disabled
    LAN br0 at 192.168.2.200 (DHCP off)
    Gateway 192.168.2.1 (Router A) and same for DNS
    Wireless eth1/eth2 properly configured and working
    OpenVPN configured and connected

    In the above situation I have the second router perfectly working as an additional access point but the wireless clients connected via this second router get routed via the gateway (router A) and therefore no VPN tunneling.

    If I check my public IP address from the router (either via SSH or using the Tools) THIS goes trough VPN instead.

    The following is my routing table

    Code:
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    82.102.21.75    192.168.2.1     255.255.255.255 UGH   0      0        0 br0
    10.8.3.0        *               255.255.255.0   U     0      0        0 tun11
    192.168.2.0     *               255.255.255.0   U     0      0        0 br0
    127.0.0.0       *               255.0.0.0       U     0      0        0 lo
    default         10.8.3.1        128.0.0.0       UG    0      0        0 tun11
    128.0.0.0       10.8.3.1        128.0.0.0       UG    0      0        0 tun11
    default         192.168.2.1     0.0.0.0         UG    0      0        0 br0

    The only solution I found, so far is to connect the A-B routers as LAN-WAN and assign to the second router another subnet (e.g. 192.168.1.0/24) with gateway on router A. This indeed works, but makes impossible to communicate devices connected to the different subnets.

    Can someone kindly point me a solution if it exists?

    Thanks in advance.
     
  2. eibgrad

    eibgrad Network Guru Member

    The problem, of course, is that in a LAN to LAN configuration, your desired VPN clients are NOT using that AP as their default gateway, so the fact the AP is configured w/ the VPN is of consequence only to that AP. It's no different than if you configured your VPN on some PC, and expected the rest of the network to magically use it. That's only going to happen if you *force* those clients to use the AP as their gateway, and NOT the primary router. And you can do that in a number of ways.

    1. Configure DHCP on the primary router to return the AP's IP as the default gateway for those specific clients. Of course, this assumes your primary router allows you to make such changes. But that's usually problematic if the primary router is using OEM firmware.

    2. Statically configure the individual clients you want to use the VPN w/ the AP as their gateway. IOW, go into the Windows networking applet and manually configure it as needed. Here again, this may not always be possible. Some network appliances and IOT devices may insist on using DHCP.

    3. Implement PBR (policy based routing) on the primary router, and route those clients that need to use the VPN from the default gateway of that primary router, and over to the AP. Once again, using OEM firmware on the primary router usually makes this problematic.

    In most cases, option #2 ends up being the only viable option.

    That's why configuring a VPN in a LAN to LAN network can often be difficult, esp. when you don't have full control of and access to all of your devices. And that's why many ppl end using the WAN to LAN configuration; it forces the VPN clients to use the tomato router as their default gateway, rather than the primary router. But as you noted, that causes its own problems, like network discovery, which can't cross ethernet boundaries.
     
  3. MaxMax

    MaxMax New Member Member

    First of all thanks for the detailed answer.

    Everything makes more sense now that I read your explanation. Your explanation about having a VPN set on a PC in the network also makes sense, but in this case I find hard to believe there is no way to tell the access point to route the eth1/eth2 wifi to the br0.

    Anyway, as you correctly guess, the option 2 seems the only viable option and I'm trying to setup this even if this doesn't exactly fit my needs.

    The access point is set up as a gateway, LAN to LAN, no DHCP. Works.

    I set my TCP manually for IP, net mask, gateway set to the access point IP.
    VPN is up, but still I don't get it on my client which connects using the standard way.
    What could be wrong here? I also tried to set as DNS my access point and disable IPv6, but with no avail.
    Any suggestion?

    Thanks again.
     
  4. eibgrad

    eibgrad Network Guru Member

    By default, all your wifi network interfaces are assigned to the default bridge (br0), along w/ the LAN ports (usually assigned to vlan1). So there is no such thing as routing from those wifi network interfaces to br0. For that to happen, you would have to *remove* those wireless network interfaces from the br0 bridge, so they stood alone. So using the default configuration of the router, the only routing that typical takes place is between br0 (wireless and wired) and the WAN.

    Now you decide to convert that router into just an AP. And you do that by disabling the WAN, disabling its DHCP server, assigning it a LAN ip on the same network as the primary router, along w/ a netmask, gateway, DNS server(s), etc. Just like any other device behind the primary router. The wireless and wired network interfaces are *still* bridged to br0. And if those were the only changes you made to that AP, then it would be essentially nothing more than a wireless switch. Anything that connects to the AP, wired or wireless, is simply bridged to the primary network.

    Up to this point, no wired or wireless device has been told to use that AP as its gateway.

    Although it may not be obvious, that AP is *still* capable of routing. But since there are usually no other network interfaces on that AP to which it can route (the WAN is disabled), and although you could reconfigure a device on the primary network to use that AP as its gateway, it serves no useful purpose. It just gets routed back out to the same local network (br0) and up to the primary router.

    So first thing I would check is to NOT enable the VPN, and just verify that any device using the AP as its gateway can at least gain access out the WAN.

    If that works, then enable the VPN. That will add a new network interface (tun11) and change the default gateway on the AP from the primary router to the VPN. Now those devices using the AP as their default gateway will be routed over the VPN.

    It's just as simple as that. But sometimes ppl make mistakes w/ the VPN.

    Do you even know the VPN is actually working?

    What does the syslog show? You should be able to ping an IP (e.g., 8.8.4.4) from a shell (telnet/ssh) on the AP and see the replies. And perhaps use traceroute to see if it uses the VPN.

    Sometimes DNS isn't configured correctly on the AP. So using an explicit IP to ping will work, but not by name.

    Did you remember to NAT the VPN's tunnel? Without NAT, devices on the primary network will NOT be able to access the VPN, even if the VPN is active and working perfectly.
     
  5. MaxMax

    MaxMax New Member Member

    I'm sorry, I did not provide enough details.

    works, I can access internet, ping, trace route, etc. both from the AP via SSH or as a client connected to it.

    after some tries I was able to make it work. Seems like the problem was on the VPN connection. However I had not to change the default gateway on the AP from the primary router to the VPN as you suggested. Using the AP as gateway in the device seems enough.

    Now this setup seems to work, though the VPN connection is sometimes bad, and this was the reason why I initially looked to build separate wifi networks to easily switch from VPN to standard ISP connection.

    Back to your first answer, and specifically the option 1 or 3, I'm thinking to use the ISP router as modem only (it allow this) and get another router with TomatoUSB.
    In this case do you think there will be a way to route VPN or ISP depending on the AP?

    Thanks for the help and the valuable information.
     
  6. eibgrad

    eibgrad Network Guru Member

    Maybe you just misunderstood me. I wasn't suggesting that YOU change the default gateway from the primary router to the VPN. What I was saying is that when you connect to a commercial OpenVPN provider, *they* tell the OpenVPN client to change the default gateway to the VPN. IOW, it happens automatically. That's why I wanted you to turn off the VPN, just to prove that using the AP w/o the VPN still gave you internet access. And once you enabled the VPN, the OpenVPN client would (at the instruction of the OpenVPN server) change the default gateway to the VPN. And w/ the same client using the AP as its gateway, it should now use the VPN. No other changes required.

    If you're asking whether by using third-party firmware on the primary router, you'll be able to configure individual clients to either use the ISP or the VPN as their default gateway w/o having to configure the individual devices as you are doing now, then the answer is yes.

    One way is to configure DHCP on the primary router (which is now using tomato) so that different clients are returned different gateway IPs, either the tomato router itself, or the AP.

    Another (and probably better) option is to NOT use the AP for the VPN at all. Instead, run the VPN on the primary router and use PBR (policy based routing) to determine which source IPs use the WAN/ISP vs. the VPN. IOW, the fact you have tomato running on the primary router makes the need for running the VPN on the AP unnecessary. That's not to say you can't do it that way, but that wouldn't be most ppl's first choice. When the VPN is hosted on the primary router, it just makes things easier when it comes to managing access to the WAN/ISP vs. VPN.
     
  7. MaxMax

    MaxMax New Member Member

    Not exactly this, sorry.
    I try to be more precise: sometimes I need to connect to VPN to workaround some geolocating service. This would happen from a couple of devices, but not as the default internet connection. The VPN is not always the fastest...

    So basically (and this was my initial idea) I'd like to have a wifi access point like I have now, named for example "ISP-Connection" and a second wifi access point named for example "VPN-Connection".
    That way I could switch from VPN to ISP simply changing the wifi AP to which I connect.

    Do you think this would be possible?
     
  8. eibgrad

    eibgrad Network Guru Member

    Yes, it's possible. If you daisy chain the VPN router behind the ISP router, WAN to LAN respectively, then anyone who connects to the VPN router is (assuming the VPN is active) routed over the VPN, whether wired or wireless.

    Ppl do this all the time, and for the reasons you've stated. It's convenient. It lets the user decided if and when they want to use the ISP or VPN.

    However, the downside is that clients of the VPN router are necessarily on a different local network (e.g., 192.168.2.x) than clients of the ISP router (e.g., 192.168.1.x). So things like network discovery won't work across the WAN of the VPN router. Also, unless you drop the firewall on the VPN router, and add a static route to the ISP router that tells it how to find the 192.168.2.x network, devices on the 192.168.1.x network won't be able be able to initiate connections to devices on the 192.168.2.x network.

    Whether any of those negatives are an issue is up to you. In some cases, it's problematic. For example, if the ISP router doesn't support static routes (not uncommon). That's why having full control of only *some* of your networking devices can itself be problematic.
     
  9. MaxMax

    MaxMax New Member Member

    This is indeed a big issue for me. I stated that on my first post I already found this way, but can't give up on network discovery.

    I'm still talking about use the ISP router as a modem only and having instead my own router(s). In this case I should have full control.
    Still you confirm me it would not be possible to have different access points routed to ISP or VPN and keep them on the same local subnet to have network discovery?

    Thanks again for your time.
     
  10. eibgrad

    eibgrad Network Guru Member

    We're sorta going round in circles at this point. Each time we change the config from routed to bridged and back, we find shortcoming, change back to the other config, find shortcomings, go back to the other config, etc.

    To recap ...

    In a routed config (the default), both sides of the WAN *must* be using different networks. That's a requirement. If it didn't work this way, the client wouldn't know whether to access the target device locally (i.e., on the same ethernet network as itself), OR send it to the router and have it find the target over the WAN. IOW, the fact the target ip is NOT on the local network is what triggers the routing over the WAN. And since the networks are separated by a WAN, and have their own IP and ethernet networks, network discovery doesn't work across that WAN.

    That's just how all this stuff works. And that's why we tell ppl to avoid using multiple networks whenever possible. Network discovery not working across the WAN usually ends up being a problem.

    All that said, there are some ppl who have successfully used Avahi (acting as a replicator) to transport network discovery across network boundaries. But that requires the installation of additional firmware (e.g., Entware), the avahi packages, and proper configuration of the replicator. A challenge in itself, esp. for networking newbs. Whether you want to try heading down that road to get around the network discovery problem is up to you. But it's the only option I know of for a routed configuration. And I haven't used it myself. I'm only aware of it.

    Short of that, you're left w/ the bridged configuration. That keeps everything on the same local network, network discovery works fine, etc. But you now lose the convenience of having users pick the ISP or VPN based on their choice of wifi. All you can really do is manage the client's default gateway to get the same effect, and that's not nearly as convenient as letting the client itself decide based simply on the choice of wifi SSID. It becomes more of an administrator task than an end-user task.

    There is no perfect answer. As often happens w/ networking, you end up making compromises to get the effect you want. And it's why I nor anyone else can tell you what's the best choice. It all depends on what YOU can live with.
     
  11. MaxMax

    MaxMax New Member Member

    It seems to me you very well outlined the facts and the possible options.
    For now I have a working solution, even if not exactly what I wanted to achieve. But it works.

    About the Avahi (aka Zeroconf/Bonjour/Rendezvous), being me working primarily on Mac it's a well known technology and considering is an open standard I wonder why this is not included by default in Tomato. This would solve a ton of problems.
    I guess (hope) someone else tried this already but in any case I might try to venture into compiling/installing it, just for the fun of experimenting.

    Finally, I wish to thank you again for your time and efforts to clarify me how thing works and to provide solutions.
     
  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