Connection of different subnets over two OpenWrt routers connected via openvpn

Hi all

My first time posting on the forum, please excuse and advise on any breach of etiquette.

I am having a great deal of difficulty getting a particularly complex (to me) network setup working.

The network devices/structures are as follows:

CLIENT SITE 1 (there can be a number of these sites)
n (say 5+) 'IOT client' devices; must all be dhcp clients; all connected via lan to openwrt router; openwrt router connected to wan via 4G and connected to SERVER SITE via openvpn tunnel as client (tap interface, no network/ip configuration done by openvpn)

CLIENT SITE 2 ... etc, same as CLIENT SITE 1 but in different physical location

SERVER SITE (only one in network)
n (say 5+) 'laptop client' devices, must all be dhcp clients; all connected via wifi to openwrt router; openwrt router connected to wan via VDSL and acts as a openvpn server for CLIENT SITES (tap interface, no network/ip configuration done by openvpn)

What I need to do is configure routing etc so that a 'laptop client' at the SERVER SITE can ping any 'IOT client' at any CLIENT SITE.

All of the 'IOT clients'/'laptop clients' must be dhcp clients [users or installers cannot be expected to add any fixed ip etc network configuration]; openvpn routers at each site can have any custom configuration [openwrt version 19.07+ on routers]

Assume that lan/wifi/4g/openvpn connection (and firewall to allow openvpn through) is all configured and working... so everything is linked just across different interfaces and subnets.

Any suggestions/ideas/recommendations as to how to set this up?

Happy to provide any further information and/or expand on any of the above (where it is not clear).

Thanks in advance.

Stewart

  • Set routes for the subnets on either end
  • Allow thru firewall on both ends

It's straightforward on the web GUI if you're familiar with doing such things. If you need more info, feel free to ask.

The TAP (Ethernet bridge) approach is not recommended as the network gets larger; the VPN channels will become bogged down with broadcast traffic. This is especially an issue with LTE since it is slow and may have a money cost per byte.

However, it is easy to set up. Think of linking dumb APs with Ethernet cables. At each remote site, have a bridge and interface of proto none (Unmanaged) which bridges the tap0 interface to the Ethernet and/or wifi connected to client devices. The server also has a bridge and a DHCP server and forwarding to the Internet. The firewall is not in effect here since these TAP bridges operate at layer 2.

Hi lleachii

Thank you for your prompt reply.

On the firewall side, I treat the lan/wifi/tap(ovpn) interfaces as all being/added to the same 'lan' zone. (Only 4g and VDSL interfaces are wan). This seemed easier than adding additional firewall rules as, so far as I understand, if the interfaces are in the same zone, that will work.

On the routing side, I don't know how to configure this, which is likely where I am stuck. Any suggestions on how to configure/set routes... what these should look like etc.

I am happy doing the configuration via CLI if easier. Once I have a set of working commands, no problem to make those permanent... but I just don't know what routing I actually need as I have very little knowledge in that area. Hints welcome :slight_smile:

The 'IOT devices' on CLIENT SITE(S) are all on a subnet 192.168.8.0/24 (openwrt dhcp server on 192.168.8.1). openvpn client interface (tap0) is not bridged and does not (presently) have an IP assigned, though if it is not bridged and has its own IP, it must be a dhcp client.

The 'laptop devices' on SERVER SITE are all on a subnet of 192.168.1.0/24 (openwrt dhcp server on 192.168.1.1). Again the openvpn server interface (tap0) does not (presently) have an IP assigned, but it can either be bridged or have a static IP assigned to it, depending on advice.

Thanks.

There is no routing in a TAP network. It is all switching. Adding another client site is like plugging another virtual Ethernet cable into the switch that is the VPN bridge at the server.

So you do want each remote site to bridge the TAP interface to its client devices. The TAP interface does not need to hold an IP address though you may want to make it a DHCP client or static IP so that you can log into the remote router over the VPN for administration. The users will not need to do this.

1 Like

If you use a TUN interface for OpenVPN as others pointed out, you just need to add a static route to the other subnet on both ends. This can be easily done in the LuCI GUI: This is for a WireGuard setup where my LAN subnet is 192.168.17.0/24 and the remote subnet is 192.168.177.0/24. On the other box, the corresponding return route is required (192.168.17.0/24).

NB: For WireGuard you could also set the option "Route allowed IPs" which adds the required routes automatically.

Hi mk2, andyboeh

Thanks very much for your comments. I can/will try both TAP/bridged, and TUN, and thanks for setting out the differences .

As there will be a number of CLIENT SITES; how do I get round the issue that each/every client site will have the same remote subnet as the others?

E.g. CLIENT SITE 1 will be on a 192.168.8.0/24 remote subnet and will have a number of 'IOT devices' with IPs in that range assigned by its dhcp server; and CLIENT SITE 2 will be exactly the same remote subnet with devices in the same range.

So with static routing, how do I distinguish between CLIENT SITE 1 and CLIENT SITE 2; or if I use bridging, I'll presumably end up with IP address conflicts/run out of IP addresses if I split the ranges.

Sorry if that does not make sense - I can get my head round understanding static routing or bridging between one client site and one server.

But when I have multiple client sites (and each site serves multiple devices) and I need the 'main' server to be able to talk to every device connected at every client site... that's where I get lost.

Hope that makes some sense.

Thanks again.

Stewart

You'll need to change this if you want to be able to reach all sites from your central site.

Although each site, on its own, will be okay using the same subnet, the problem is that you will have routing ambiguity from the perspective of the central site... it's not unlike trying to deliver a message to a specific person when there are 4 people in the room with the same name. If you only have one tunnel running at a time, this would not present an issue. However, with concurrent tunnels, your router wouldn't that you're trying to reach 192.168.0.4 at site 3 instead of at site 2, as an example.

With TAP:

  • all sites are on the same subnet
  • IP addresses assigned from the server
  • Direct access to any device at layer 2 (MAC address based switching)
  • Broadcast traffic is not isolated

With TUN:

  • all sites must have different subnets
  • IP addresses (within that subnet) assigned locally
  • Traffic is routed to a site based on the subnet IP
  • Routes to other sites pushed from the server
  • Server must be aware of site's LAN IP using client config directory
2 Likes

Also worth adding -- it is mandatory that the device IPs do not overlap in a TAP configuration. While all devices would be on the same subnet, if any devices are using the same addresses, things will break. Especially true of the router, but also the individual hosts on each network.

I don't recall what happens with DHCP traffic over TAP -- Because everything remains on the same broadcast domain and there should only be a single DHCP server per broadcast domain, it may be necessary to have a central DHCP server and thus disable them on the remote sites. This would mean that if the link between the site with the DHCP server is severed, one or more of the sites may not have DHCP servers available leading to potential issues. I believe there are ways to setup failover type scenarios with DHCP, but this begins to get complicated since the DHCP leases table would not be synchronized and upon restoration of the link, there could be overlaps (this can be partially mitigated by ensuring that each site has a non-overlapping pool definition). [note: it is possible that DHCP is not sent over the TAP, and then all that would be necessary would be to avoid overlapping pools].