1

I have a spread-out setup to deal with: 3 off-site buildings with Tomato Firmware-based routers, connecting to another Tomato-based router as a VPN setup. The Server router is also in our private LAN network (as an edge device).

In our main LAN, we have a DHCP server running on a Linux server, offering 192.168.0.0/19 (yes, subnet mask is 255.255.224.0!), with the 192.168.2.x/24 octet being excluded. At each site, each Tomato VPN Client (the routers from now on) are supposed to offer IPs in a certain range to their clients within the 192.168.2.x subnet. SiteA is 192.168.2.2-29 (router is .1), SiteB is 192.168.2.31-50 (router is .30), and SiteC is 192.168.2.52-80 (.51 is the router). The computers can connect to our server with no issue.

What is happening though, is that all of a sudden (when this worked perfectly fine before), I have the router from SiteA offering leases to clients at other sites. Because they are in the same ultimate network (192.168.0.0/19), they can access servers in our LAN, but not the Internet.

As a temporary fix, I could remote in to the computers at SiteB and SiteC, and assign the default gateway to be the routers at each location. This is not a good fix though, as it prevents other staff from visiting the site with their laptops or tablets, and being able to connect right away.

The routers are not compiled with support for ebtables as recommended in a few other threads. The ultimate goal is to have the DHCP servers only offer leases on the LAN side of their own routers.

Router B's VPN Client configuration
enter image description here enter image description here

Router A's VPN Client configuration (The Redirect Internet Traffic was originally disabled; it was enabled above just for testing)
enter image description here enter image description here

9
  • sorry, DHCP uses layer2 broadcasts, so you cannot scope a server in that manner, other than by blocking DHCP requests crossing the VPN. Commented Apr 25, 2016 at 16:53
  • @FrankThomas How could I go about doing that? I have SSH access to each of the routers, if that helps Commented Apr 25, 2016 at 16:54
  • well, I would implement a firewall at each VPN gateway and having it drop all UDP\67-68 traffic it sees crossing from the VPN to locallan and viceversa. It sounds like your routers do not have the firewall modules installed however, so that makes it more difficult. Commented Apr 25, 2016 at 17:28
  • Is are clients at both site B and C receiving IP assignments from site A, or just one of them (B or C)? Is DHCP working at the other site(s), i.e. if manually attempted, does the router hand out IPs? My point is, that maybe the clients are going all the way to site A because their local router didn't respond or denied the request.
    – Dr.Ping
    Commented Apr 25, 2016 at 18:43
  • And, as already mentioned, separating sites by subnet is the correct way, and avoids many headaches
    – Dr.Ping
    Commented Apr 25, 2016 at 18:48

1 Answer 1

2

Your VPN is TAP, assuming that OpenVPN is the underlying tech, then this means you have a layer2 VPN. That means you have things setup as if they were all physically connected to the same switch. If you don't want a layer2 network, don't use TAP.

4
  • Would TUN (the only other option) still allow what I want, where the clients can all see each other through each site? And have Internet access? Commented Apr 25, 2016 at 16:57
  • If you setup your routes properly. A tun network is the better solution, it just is a bit more complicated. The complicating factor, is that I am not sure if you can do it with tomato. I am completely certain that the underlying OpenVPN supports it though. You would also need to change your network a bit, so that the remote sites are on separate subnets.
    – Zoredache
    Commented Apr 25, 2016 at 17:00
  • And I can't change our network scheme for the next few months, unfortunately :-( Commented Apr 25, 2016 at 17:03
  • Ah, you have a challenging problem then. I am not sure what to suggest. DHCP is probably mostly working for you, because DHCP clients will usually just accept the fastest reply, which will usually be from the physically closest DHCP server.
    – Zoredache
    Commented Apr 25, 2016 at 17:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .