Partial network access (ping) on established openvpn

Discussion in 'Tomato Firmware' started by tedly, Mar 15, 2011.

  1. tedly

    tedly Networkin' Nut Member

    I apologize that this is long. But I think the details may have a clue to what is going on. I've been fighting a TomatoUSB OpenVPN issue for just over a week now. I've spent many many hours pouring over the details.

    I built up two e2000 routers using the 1.28 beta code: tomato-E2000-1.28.9054MIPSR2-beta-vpn3.6.bin

    I followed the directions here:

    In the lab, the two VPNs configurations acted just fine. The lab being just over a switch in my internal network. Each had a 192.168.x.x internal address range and were able to completely function. I thought that was it. Tomato has always been excellent quality, no issues ever.

    So, I bring the systems into router production for a couple small offices. They replaced the sole gateway for each network. Router A (vpn server) in the local town comes online and works fine in it's non VPN features. Later that day, the second router (vpn client) arrives on Office B in another city, comes online, connect to router A, all is well. The VPN connects and everything can ping everything. Yay, instant victory!

    The night comes, I add a test/lab TomatoVPN to the mix from a 3rd location. It works just fine. All three network are having a ping fest, pinging away. No settings changed (other than adding the 3rd network to the "Allow Client<->Client" list. I play with the pings/access and eventually disconnect the lab. I'm as happy as an admin can be.

    Come morning, the router A and router B stop allowing pings to the devices behind themselves. For example. Router A can ping Router B (internally) but can ping none of the hosts behind Router B. And likewise in the other direction. But each router can ping the hosts behind itself... for example: Router A can ping all the clients on Network A. And Router B can ping all the hosts on network B. I've seen this problem described time and time again on the forums. But none of the solutions have applied.

    I've toggled NAT on and off, toggled on what networks are in the "Allow Client<->Client" lists, and so many others.

    So, I get a third e2000 router. rebuild it's configuration identical to the server setup on Router A. Bring it into the office, put it online in place of the original Router A.

    Suddenly, all sorts of weirdness starts happening. Now, SOME hosts on each network can be pinged by the remote side. But not all of them. And unfortunately, not the most important one to this office.

    For example. Now (Router B) can ping (LAN printer), (wireless laptop), (network drive), and (wireless iphone), and a few others. But it can't ping the primary server and several other clients. Yet all of these systems can be pinged by the local router A, so I know they have ICMP enabled.

    And the same happens in the opposite order. Router A can ping a few of the hosts on Network B, but not all of them. Again, some of the unpingable hosts are pingable on the local network so I know their ICMP is not disabled.

    I'm pulling what little hair I have out over this. Any help is greatly appreciated.

    VPN Server config pages:

    Page One
    Page Two
    Page Three
    Page Four

    VPN Client config pages:

    Page One
    Page Two
    Page Three
    Page Four

    Only difference to my lab configuration is that the external interface is getting it's IP from PPPoE rather than just a DHCP pull. But I don't see how that would impact a specific section of the network from routing.

    Thanks for any help.
  2. rhester72

    rhester72 Network Guru Member

    Seeing the route tables from each router - along with a diagram of the topology labeled with subnets - would be very helpful.

  3. tedly

    tedly Networkin' Nut Member

    It will take me a little bit to produce the diagram. But here are the route tables.

    (External network address masked with #s)

    VPN Server internal route table:

    Kernel IP routing table
    Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface UH        0 0          0 tun21
    #.#.#.201 UH        0 0          0 ppp0   UG        0 0          0 tun21   UG        0 0          0 tun21   UG        0 0          0 tun21   U         0 0          0 br0       U         0 0          0 lo         #.#.#.201         UG        0 0          0 ppp0
    VPN Client internal route table:

    Kernel IP routing table
    Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
    #.#.#.202 UH        0 0          0 ppp0 UH        0 0          0 tun11   UG        0 0          0 tun11   UG        0 0          0 tun11   U         0 0          0 br0   UG        0 0          0 tun11       U         0 0          0 lo         #.#.#.202         UG        0 0          0 ppp0
  4. tedly

    tedly Networkin' Nut Member

    I'm not sure if you were looking for any more information than this. It's a very simple layout.

    In the end, some hosts on each side can ping some hosts on the other side. But they can't ping all of the hosts like they should. And, sadly, they can't ping the one system they need most of all, and that's the Windows Server.

    Out of desperation I changed the IP on the windows server last night to (from to see if perhaps that would magically route. But it made no difference.

    Its odd to me that the systems that can and can't ping are not grouped together in a segment/subnet of the /24. It's all over the range.

    A side note to the topology, there is a single unmanaged switch on the VPN server side. But even then, some of the pingable hosts are on the extra switch and some of the unpingable hosts are too. So it doesn't seem like that's a factor. By process of elimination (of each networking component) I am fairly sure this is not something physical.
  5. tedly

    tedly Networkin' Nut Member

    For what it's worth, I just set up another VPN service (server 2) on the same router for openvpn desktop client's to use. And thats working fine. When they're logged in there, they can see and access everything. Same TLS authentication and everything, just a higher port.

    They're using TAP rather than TUN of course. So maybe that's why the routing problems aren't showing up there.

    But at least I have a work around for them until the regular routing is figured out.
  6. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    It's likely that the servers you can't contact have a firewall in place that blocks traffic not originating on the local network. If things are working for some of the IPs, there's nothing that should keep it from working on the rest (since your subnet masks all seem okay).

    Also, you could put logging rules in the firewall to see if it's getting through to your LAN (example below for putting in your server firewall script, to log client-originating traffic getting through to your LAN).
    iptables -t nat -A POSTROUTING -s -j LOG --log-prefix "NP "
  7. tedly

    tedly Networkin' Nut Member

    Ah... great idea! I didn't think they would have one for allowing only on-LAN icmp/traffic.

    The only catch to that theory is that it worked for the first 12-18 hours I had it installed on day one. But perhaps they took the one server they were testing and turned on a firewall rule.

    I'll check it when I'm on site tomorrow again.

  8. tedly

    tedly Networkin' Nut Member

    That was the fix. The windows clients I couldn't reach had ICMP and file sharing allowed from only the local network.

    And it turns out that they had been turning the firewall on and off the last week for whatever reason; which explains that it worked during the first day the hardware was in place.

    Everyone is happy.

    Thanks SgtPepper.
  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