How to make DVR hooked up to VPN Server GL-AR300M16 be able to seen by DVR in remote location hooked up to VPN Client GL-AR300M16?

I have GL-AR300M16 as VPN Server, another as VPN Client. I want DVR at home hooked to the router that is running VPN server, to be seen by DVR in remote location hooked up to VPN Client router. In current setup they are on separate networks, despite being on same VPN, so can’t see each other.

Because with my set up, they are both connected to the same VPN, but they are hidden from seeing each other because they are on different subnets as they are connected to separate routers.

How do I make it so they are on the same network subnet and can see each other?

Are these Tivos? Tivos discover each other at layer 2. OpenVPN TAP connections will pass layer 2, but OpenVPN TUN connections are only layer 3 and do not.

Once upon a time I did successfully connect two networks with TAP and my Tivos could communicate with each other, but it was such a gigantic pain to maintain TAP i vowed never to do it again. TUN is much more straightforward. I deal with my Tivos now through kmttg and plex.

They aren’t TIVO but they probably work in a similar way. They are Virgin TV 360 boxes which run on a new proprietary firmware. Most Virgin Boxes out thererun TIVO but Virgin are transitioning as many as they can ro their new 360 system.

Just don’t.
This is in general not a good idea. It should be two separated networks. Else you’ll got a lot of unwanted side effects.

What you want to use are routes. Just configure in router B (remote) what IPs or nets are available over router A (home). I don’t know how to add routes exactly with 2 GL.iNet devices, but It should be easy to goggle.

Ok I will give it a go. I’m sure what I am trying to do is simple, but I thought it would be as simple as running the VPN, connecting everything to it and they would all see each other. But there’s a bit more to it.

If you are into networking, in fact it is simple. A little difficult, if you are in a lot of different networking. Sometimes the terms are mixing up.

But I’ll try to generalize:
Client A in Network A with Router A - WAN - Router B with Network B to Client B

Client A with 192.168.8.2 in Network 192.168.8.0/24 with Router 192.168.8.1
Client B with 192.168.9.2 in Network 192.168.9.0/24 with Router 192.168.9.1 (Note Network x.x.9.x instead of x.x.8.x! Need to be changed.

The OpenVPN Router A is 10.8.0.1 and Router B is 10.8.0.2 …

In between is the OpenVPN Magic. So Router A know from Router B and otherwise. But the clients would not see the networks behind.
The Route will define 'If Client A want to reach Client B, it has to go over Router B …

route add 192.168.9.0 mask 255.255.255.0 10.8.0.2 5
route add [from] mask [subnet] [gateway] [metrik]

The gateway needs to be reached from the client A! Should be automatic reachable in OpenVPN. The Router B should know how to deal with the package.
the metric is ‘the cost’ of this connection. Lower values for concurrent path are more likely used. Will be filled automatic, if not set.

As far a s I know the route can be set on the Client A or Router A … Maybe I’m wrong.

If you’d like it more simple: Put all devices in your OpenVPN, than they can talk in network 10.8.0.0/24 … But I don’t think your DVR will support this.

Thank you for your further reply. Yes you have understood what I am trying to do and yes indeed the DVR doesn’t support direct connection to VPN, it has to go via a DHCP router. It doesn’t even support static IP.

I think I found a guide for what I need?

Except this howto is for wireguard, not for OpenVPN, so the configuration could look different. But the basics should be the same.
Or you are switching to the more modern and more performant (maybe more easy) wireguard VPN, as well. So the howto is 100% matching your situation :slight_smile:

1 Like

Haha I am using Wireguard actually, I forgot to mention in my initial post.

  1. Wireguard is layer 3 only, so if the DVRs really depend on being on the same subnet, it won’t help.
  2. The DVR doesn’t need to allow a static IP. All you need to do is reserve an IP address in the DHCP settings for the DVR’s mac address, and it will get the same IP everytime it connects.
  3. Is one of these a mini? How do they connect if they are on the same subnet? That I guess is what you need to replicate.

I don’t know how they connect at the moment. If they are on the same router they see each other straight away. I reckon if I had them hooked to VPN directly (so they would both get VPN addresses of 10.0.0.2 etc.) then they would see each other. But being behind different routers is making them blind to each other, despite being on the same public IP.

Is there a software I can run on a Windows PC or Android Phone to monitor the LAN traffic to figure out how the boxes communicate? I’d like to learn the port numbers they use as well.

The main box is where the recordings are stored. The other box is a mini box that can schedule recordings and watch recordings from the main box.

I think a solution that might work is using the OpenVPN Bridge mode function which would then give the Remote DVR a direct address on the VPN. I played around with that a little but it didn’t work, but perhaps I didn’t do something correctly.

The DVR can’t have a static IP set on its own settings, it is DHCP only, would the OpenVPN Bridge mode give it an IP address automatically?

OpenVPN won’t give IPs, OpenVPN give TUN devices to create a VPN.
A DHCP server will give IPs. And based on the MAC (or hostname or something like given environment temperature) a DHCP service can give the same IP, every time. If the DVR is asking the same DHCP every time.
The DHCP should assign a IP, before the VPN is build.

You need to:

  • Find your DHCP Server for the DVR
  • Configure the DHCP Service (see in manual)
  • Provide a route from the client to the DVR (see comments before)

It is not a good idea to have more than one DHCP per network. The beryl can provide the DHCP for 192.168.8.0/24, while another DHCP will provide the information for the net at WAN (or Wireless or Tethered, or…)

I don’t have any experience with the bridge mode of OpenVPN.

I’ll try and recall what I did with my Tivos.

Location 1, where I guess your main 360 box is located, is configured with DHCP operating and also has a Openvpn server. That server is configured with a TAP configuration. Assume for the moment that the LAN address of this router is 192.168.1.1, and the DHCP server is configured to hand out addresses from .50 to .254.

Location 2, where the mini is located, is configured with an Openvpn client on the router exported from Location 1. The router has DHCP off, but has a LAN address manually assigned that is on the same subnet as Location 1, but in the .2 to .49 range. The Openvpn client is configured to start on boot. Note that the mini, if it is plugged in, won’t get an IP address immediately. Maybe it has flashing lights, or smoke, or something.

Now maybe, when the router at location 2 starts, its openvpn client reaches out and forms the bridge (TAP) to location 1, and the DHCP request emanating from the mini is negotiated with the Location 1 router. In that case, it may also then bonjour with the main 360 box. It may also be that other devices at location 1 will now get IP addresses and send traffic to the internet over the bridge and out your location 1 internet connection. That is as good as you are going to be able to do.

Now the bad news. Even if the mini connects, it could very well be sensitive to latency or speed, and sense that it is not on the same physical network, leading to a disconnect, usually exactly at the best part of what you are watching.

Note also that all level 3 traffic is also going out back and forth over the bridge. Also, whatever the download speed is at location 2, your internet traffic is going to be limited by the upload speed at location 1. If the bridge goes down, all of location 2 goes down and you will have to completely reconfigure things while the family is screaming at you.

To avoid this, I think I might have set this up so location 2 had its own DHCP server running, with location 1 and location 2 having different ranges, and then blocking the DHCP port so those messages didn’t traverse the bridge.

Drove me nuts.

Well that certainly sounds like a handful to sort out. But it’s worth experimenting with when I next have the time. I enjoy all this problem solving in and of itself anyway, it’s fun :slight_smile:

For now I actually do have something working with the current setup.

With the current setup, the Mini Box thinks it’s on the correct ISP. If it’s connected to the wrong ISP, it blocks the box from working until it is connected to the correct ISP. So from the remote location I can use the Mini Box’s TV Catch Up services that work via the internet as on the VPN it’s on the correct ISP. So even if I can’t solve the recordings situation (for now), at least I have somewhat of a victory and usage of features of the Mini Box with this VPN set up.

Not every TV channel and not every TV programme is available via the Catch Up Service, but it’s a good selection. If a channel/programme supports it and I want to watch it live, then I just play it on the Catch Up Service and fast forward all the way.

If I ever get the recording playback method to work via the VPN, then all TV channels become available. Since it would just be a matter of scheduling a recording on the main box at the home location (a function which works in the current set up as it uses the internet rather than LAN I think) and then playing back the recording of the channel I want to watch (which I haven’t managed to get working).

The funny thing is the provider have an internet only version of their box called a StreamBox. This has no recording functionality, but it plays most of the traditional Cable TV channels via the internet without needing a cable connection and has the Catch Up Services as well of course. Only problem is at the moment they don’t provide this box to customers who have Cable TV. But there are rumours it will be an option by the end of the year.

So this StreamBox would be perfect for my scenario. It would just be a matter of sacrificing the remote location’s recording/recording playback (which I haven’t got working anyway) for a wider selection of channels working via the internet. A sacrifice which would be fine by me.