Connected to PPTP VPN, but Public IP Won't Change

Discussion in 'Tomato Firmware' started by threehappypenguins, Apr 25, 2018.

  1. threehappypenguins

    threehappypenguins Networkin' Nut Member

    I'm trying to connect one Tomato router to another Tomato router (each one is in a separate location, with different ISP's). The one running the server is configured correctly, as far as I can tell, and I can easily connect to it using my laptop (Windows). If I check my IP address, it changes to be the public IP address of the Tomato router running the PPTP server.

    I want to make my entire network have the public IP address of the Tomato router running the PPTP server. I followed these directions (except I used the PPTP server's username and password that I set up, obviously), and I still can't get the public IP address of the other Tomato router.

    The only thing I couldn't get was the subnet mask. I tried putting in, but it won't "stick." Meaning, I click save, it saves, and if the page refreshes, it just shows again. I'm not entirely sure what it does, or if it matters.

    I'm for sure connected. The other Tomato router (with the server) shows my router as a client in the list. Also, my "Overview" sections shows that it's connected.

    I read something online about enabling VPN passthrough. I'm not sure if that is my problem or not. I can't find anything in the settings of my Tomato router that shows VPN passthrough. Both routers have Shibby's Tomato.
  2. eibgrad

    eibgrad Network Guru Member

    The information in that link seems to be from a rather old version of tomato. It certainly doesn't look like my own v138, or anything else I've seen in the past few years. And so I don't know if you too are using an older version of tomato. Might make it more difficult to diagnose the problem, esp if a bug was introduced at some point.

    Not sure either why it has a Subnet Mask field. Once you check the "Use DHCP" option, the IP Address, Subnet Mask, and Gateway options typically disappear (those are used for a static WAN config). I suspect it's a GUI error, where it should have been hidden, just like the IP Address and Gateway options. That would also explain why changes are being ignored.

    As far as VPN passthrough, yes, that's a requirement, but afaik, this is enabled by default. I've never even seen such an option on tomato, even w/ the most current builds. There's really no good reason to disable it anyway.

    Does your tomato build also support a separate section for configuring a PPTP client? That's the way it works on dd-wrt (and modern tomato builds). You can config PPTP either over the WAN, or from the PPTP client in its own section (w/ a redirect gateway option). Just wondering if that might be an alternative is something is wrong w/ PPTP over the WAN.

    If you're connected, then presumably the routing table on the PPTP client should show it. And it should show the default gateway changed to the VPN's network interface (e.g., ppp0) and gateway IP. The following dumps might prove helpful.

    ip route
  3. threehappypenguins

    threehappypenguins Networkin' Nut Member

    I have some screenshots, if that helps. I have Tomato Shibby 1.28. It's definitely not old. I think the firmware was uploaded in 2017?

    The first picture is of my settings. You will see the subnet mask shows, despite me putting in and saving it.

    The second picture is of my routing table. Under the red box is the public IP address of the remote Tomato router that I connected to. Under the blue box is the public IP address of my Tomato router. And you can see ppp0 with the IP address that the PPTP VPN assigned (it's internal, not public, so I figured it's okay to display).

    Let me know if this helps any. I can do a dump soon. Have to pick up spouse from work.

    Attached Files:

  4. eibgrad

    eibgrad Network Guru Member

    P.S. In some cases, only a single PPTP client can be supported through the same router, so make sure the PC w/ the PPTP client is NOT running at the same time as the PPTP client on the router itself!
  5. eibgrad

    eibgrad Network Guru Member

    What's the specific version? Check under About. All Shibby versions report 1.28 as a base, but there should be a subversion as well (131, 134, 138, etc.). I want to make sure this isn't a MultiWAN router, which has introduced its fair share of bugs since its introduction (iirc, around v131), esp. since MultiWAN directly affects the WAN configuration. Given how little PPTP is used these days, esp. over the WAN, it wouldn't surprise me if MultiWAN introduced a bug and nobody noticed.

    Best I can tell based on the information available is that the VPN (ppp0) has NOT been made the default gateway. It appears to still be pointing to the WAN (vlan2). In my experience, when using PPTP, if the PPTP client is the default gateway, it's the one w/ the line "default" and a subnet mask of The router will make that change automatically. But as I said, it appears to still be pointing to vlan2.

    What does a trace (perhaps to Google, ) show in terms of pathway when done from the router itself (using the traceroute -n command), and Windows (using the tracert -d command).
  6. threehappypenguins

    threehappypenguins Networkin' Nut Member

    Definitely only one client. I don't have my laptop connected at the same time my router is connected to the remote router.

    My router: Tomato Firmware 1.28.0000 MIPSR2-140 K26 USB Mega-VPN
    Remote router: Tomato Firmware 1.28.0000 MIPSR2-140 K26 Max

    Both routers are definitely MultiWAN. I didn't realize that it tends to have a lot of bugs. I didn't download it for the MultiWAN features, but to have an updated version of Shibby's Tomato.

    Initially, I tried setting up the PPTP Client section under the VPN Tunneling section, but was having the exact same issued (wouldn't get the remote router's public IP), so I gave up on that and went right to trying the WAN section. Not really sure which one I should be using and why it matters, though.

    What if I somehow set things up on Tomato so that only one device will be told to use the VPN? That is really all I want to do, anyway. I don't need my whole network on the VPN. Actually, I just wanted to test things out with my router connecting to the remote router, but ultimately, I was planning on making it the other way around (remote router connecting to my router). But I wanted to fiddle with things on my end first to be sure it works because the remote router is actually my in-laws and I don't want to disrupt their internet while I'm trying to figure things out. They need one of their devices to have my IP address so they can get a free trial of some IPTV (I don't want live TV ever, lol) that I earned by helping with some technical stuff.

    But now this is driving me crazy because what I thought would be a simple task ended up being a complicated one, lol. Thank you for responding, though!!! :)

    Oh, and here is the tracing log from Windows. I'm not sure how to do it from the router.

      1     1 ms    <1 ms    <1 ms
      2    12 ms    14 ms    11 ms
      3    18 ms    11 ms    16 ms
      4    45 ms    12 ms    15 ms
      5    12 ms    11 ms    11 ms
      6    28 ms    28 ms    29 ms
      7    24 ms    28 ms    48 ms
      8    33 ms    33 ms    34 ms
      9    38 ms    37 ms    38 ms
     10    52 ms    76 ms    45 ms
     11    47 ms    47 ms    49 ms
     12     *        *        *     Request timed out.
     13     *        *        *     Request timed out.
     14     *        *        *     Request timed out.
     15     *        *        *     Request timed out.
     16     *        *        *     Request timed out.
     17     *        *        *     Request timed out.
     18     *        *        *     Request timed out.
     19     *        *        *     Request timed out.
     20     *        *        *     Request timed out.
     21    48 ms    44 ms    45 ms
  7. eibgrad

    eibgrad Network Guru Member

    The point of the trace was for you to see if, based on the ip addresses that show up, whether the client was indeed using the WAN (i.e., the ISP's gateway) vs. the VPN gateway. That's harder for me to tell than you since you've masked some of that information. But once you know these IP addresses, it's usually pretty obvious which path it's taking.

    The address in that trace is a private address, which is interesting. Given you indicated previously that PPTP shows an IP of (and I assume that's still the case), it would suggest is from your ISP.

    AFAIK, the only difference between the WAN use of PPTP and using the separate PPTP client under VPN Tunneling is that the former automatically changes the default gateway to the VPN once connected. IOW, it's implied. In the latter case, you have the *option* to change the default gateway to the VPN by checking the "Redirect Internet traffic". I assume you checked that option.
  8. threehappypenguins

    threehappypenguins Networkin' Nut Member

    Yes, I checked "redirect inter traffic" and it still didn't change my public IP. is interesting. What do you mean it's from my ISP? It's not my public IP address, or the public IP address of the remote router.

    What should I do at this point?
  9. eibgrad

    eibgrad Network Guru Member is most likely the immediate upstream local network of your ISP. Eventually you start reaching ip addresses that are closer to your public IP as you move through the trace. If I had to guess, I'd bet your public IP is in the same network as the IP addresses 2-3 more down the trace.

    Regardless, out of curiosity, let's assume everything w/ the PPTP connection is working and manually force the gateway to be changed to the VPN.

    Go to Tools->System Commands and issue the following command to check the current PPTP client IP and network interface.

    ip route
    Assuming it's the same as before, execute the following commands and verify they were added to routing table.

    ip route add via dev ppp0
    ip route add via dev ppp0
    ip route
    This assumes the VPN gateway IP is still, and the PPTP network interface is still ppp0. If not, adjust accordingly. If you still have connectivity, try the trace to again. See if it changes.

    If you lose all connectivity, you can undo the changes w/ the following.

    ip route del via dev ppp0
    ip route del via dev ppp0
    It's all a longshot, but try it anyway. Nothing to lose at this point.

    The other alternative? Use OpenVPN. PPTP is long since been (effectively) deprecated and even when problems/bugs are found, developers are reluctant to spend time fixing them.
  10. eibgrad

    eibgrad Network Guru Member

    P.S. Btw, if you configure the PPTP client under the VPN tunneling section rather than the WAN, make sure you also check the "Create NAT on tunnel" option as well.
  11. threehappypenguins

    threehappypenguins Networkin' Nut Member

    Yeah, I considered OpenVPN, but am more familiar with PPTP.

    But I tried:

    ip route add via dev ppp0
    ip route add via dev ppp0
    ip route
    And it worked! My public IP is now the remote router's public IP!

    Just curious, do you know if there is some way to make one device (either by IP or MAC, preferably MAC address) use the VPN, but all other devices do not?
  12. eibgrad

    eibgrad Network Guru Member

    Still odd that it never changed the default gateway to the VPN. Sure seems like a bug. We shouldn't have had to do it manually.

    In the long run, it doesn't matter anyway since you want to be selective about what's routed over the VPN. And in that case, you need to implement policy based routing. And therefore I recommend using the PPTP client under VPN Tunneling (w/ the "Redirect Internet traffic" option NOT checked), just to make sure that a "fix" to the WAN's use of the PPTP client doesn't suddenly make it the default gateway again for the entire network.

    Implementing policy based routing isn't all that tough. For example, suppose the client you want routed over the VPN is You need to create a secondary routing table, add the VPN as a default gateway, then add an ip rule that tells the routing system to route that particular IP over the secondary routing table. The following would do the job.

    ip route | grep -Ev '^default |^ |^ ' \
      | while read route; do
            ip route add $route table 200
    ip route add default via dev ppp0 table 200
    ip rule add from table 200
    Of course, you would also remove the previous routing changes so the WAN returned to the ISP.

    You can add more ip rule commands for any additional IPs. Since it doesn't work w/ MAC addresses, you'll have to assign static leases to those IPs to make sure the same device(s) is bound to the alternate routing table.

    The tricky part is the timing. You can't apply these changes until the PPTP client is connected. We have to find a way to detect when the PPTP client comes up and add the changes only at that time. You could do something crude, like monitor the routing table for the pptp network interface (e.g., ppp0) from a continuously running process (begun by the init script at startup), then apply the changes.

    while ! ip route | grep ppp0; do sleep 10; done
    sleep 10
    ip route | grep -Ev '^default |^ |^ ' \
      | while read route; do
            ip route add $route table 200
    ip route add default via dev ppp0 table 200
    ip rule add from table 200
    ) &
    It may be possible to improve the situation by coordinating the changes using ip-up/ip-down scripts in Custom Configuration on the PPTP client. I haven't used the PPTP client or server in so long, I'm a bit rusty. It would take some time to see if that was possible. It's just cleaner because you're adding and removing these data structures in synchronization w/ the PPTP client each time it connects and disconnects. But for some ppl, the crude method will suffice.
    Last edited: Apr 27, 2018
  13. Sean B.

    Sean B. LI Guru Member

    I believe /etc/vpn/ip-up would work for that.
  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