WireGuard tunnel interferes with Tapo cloud app (blocks it)

[AVS]

Hello,

Recently I've discovered that the problem with viewing video from TP-LINK Tapo IP-cameras is related to the WireGuard tunnel: when WireGuard tunnel between ASUS RT-AX88U and another router (Keenetic in my case) is up, then Tapo app (it is the app to control various TP-LINK devices and view IP-cams) on a device in ASUS network (smartphone or tab) cannot open video from remote IP-cameras located in various locations (it continuously tries to start it, understanding that the device is online, but without success).

In order to see video from IP-cams it is sufficient to turn off the WireGuard tunnel, and it is not necessary to turn off the WG server - the impact takes place only when the tunnel is up.

In other words, it looks like WG - when tunnel is up - partially blocks some cloud protocols. I've found out a trick to break through this 'blocking': if I for a second turn off Wi-Fi on smartphone, so that it switches over to mobile data, video starts just in a second, and when I turn on Wi-Fi again, video continues to work.

My assumption that something wrong is with ASUS implementation of WireGuard is based on the info from other users which use WG tunnel in similar scenario but between non-ASUS routers – they do not experience such problems.

Actually, I could not even imagine that there can be any influence of WG on cloud apps (like Tapo app) at all, but it is the case.

Any suggestions on deeper troubleshooting and investigating the root cause of the problem would be appreciated.

Thanks.

 

[ZebMcKayhan]

My assumption that something wrong is with ASUS implementation of WireGuard is based on the info from other users which use WG tunnel in similar scenario but between non-ASUS routers – they do not experience such problems.

There are no blocking going on in Asus Wireguard implementation. But split tunneling could be problematic.

Any suggestions on deeper troubleshooting and investigating the root cause of the problem would be appreciated.

Start by posting your vpndirector rules. And whether or not you are using the dns entry in wireguard client config.

Also state what your purpose is for your vpn connection to the other router. Is it site2site (lan2lan) or to redirect internet data? Or both?

when WireGuard tunnel between ASUS RT-AX88U and another router (Keenetic in my case) is up, then Tapo app (it is the app to control various TP-LINK devices and view IP-cams) on a device in ASUS network (smartphone or tab) cannot open video from remote IP-cameras located in various locations (it continuously tries to start it, understanding that the device is online, but without success).

I don't get it. Are the camera behind wg vpn, or your phone? Or both?

 

[AVS]

Thank you very much for swift reply.

Start by posting your vpndirector rules.

I have not been setting any VPN Director rules.

And whether or not you are using the dns entry in wireguard client config.

No, DNS entry is not specified on client side (which is Keenetic router). However, in ASUS WireGuard settings (VPN Server -> WireGuard -> Advanced) the "Allow DNS" entry is enabled.

Also state what your purpose is for your vpn connection to the other router. Is it site2site (lan2lan) or to redirect internet data? Or both?

It is LAN-to-LAN setup, Internet not redirected through WireGuard.

I don't get it. Are the camera behind wg vpn, or your phone? Or both?

I made a diagram which shows the setup, please kindly see attached. As shown on the diagram, cameras are located in various location, and none of them would open.


Thank you.

 

[ZebMcKayhan]

I made a diagram which shows the setup, please kindly see attached. As shown on the diagram, cameras are located in various location, and none of them would open.

Thanks!

So you have cameras completely off network as well as cameras on adjecent network and none work when you are on asus wifi (phone not via wg) and wg server up and connected? Then if you disconnect wg tunnel (on client or server side) it works for all cameras? Have you actually tested this scenario while still connected to asus wifi?
The reason for asking is just to figure out where the problems lies.

What have you put into Asus server peer AllowedIPs (server)?

Are you running any addons? Any restrictive router option, like AI protect or similar?

 

[AVS]

Thank you very much for your reply!

Then if you disconnect wg tunnel (on client or server side) it works for all cameras?

Yes, exactly - it starts working for all the cameras.

Have you actually tested this scenario while still connected to asus wifi?

Yes, of course, tested several times. Tunnel is up - no video (symbol of connection is spinning), tunnel is down (sufficient to turn it off on either side) - video opens in 1-2 seconds.

What have you put into Asus server peer AllowedIPs (server)?

Allowed IPs (server) on ASUS are 10.6.0.2/32,192.168.2.0/24, allowed IPs (Client) on ASUS are 0.0.0.0/0

Are you running any addons? Any restrictive router option, like AI protect or similar?

No, not using any of that...

BTW, I also have Hikvision cameras, they are not impacted by WG tunnel.

And just in case, maybe it is important (and could have been overlooked in the first message): during months when WG tunnel was permanently up and I was trying to understand the reason (and chasing TP-LINK support etc.) I found a workaround to view video: I had to turn off Wi-Fi on the smartphone for a couple of seconds, so that it switches over to mobile data, and then video starts in a few seconds, and during viewing viedo when I turn on Wi-Fi again and connect to ASUS - video continues to work (normally until next session of the Tapo app, sometimes it could continue to work during, say, half an hour). Same happens with tab (it has no SIM), so if I turned Wi-Fi off and on during attempt to see video, then it often helped to break through this stange "barrier" and receive video.

Thank you.

 

[ZebMcKayhan]

Thank you very much for your reply!


Yes, exactly - it starts working for all the cameras.


Yes, of course, tested several times. Tunnel is up - no video (symbol of connection is spinning), tunnel is down (sufficient to turn it off on either side) - video opens in 1-2 seconds.



Allowed IPs (server) on ASUS are 10.6.0.2/32,192.168.2.0/24, allowed IPs (Client) on ASUS are 0.0.0.0/0


No, not using any of that...

BTW, I also have Hikvision cameras, they are not impacted by WG tunnel.

And just in case, maybe it is important (and could have been overlooked in the first message): during months when WG tunnel was permanently up and I was trying to understand the reason (and chasing TP-LINK support etc.) I found a workaround to view video: I had to turn off Wi-Fi on the smartphone for a couple of seconds, so that it switches over to mobile data, and then video starts in a few seconds, and during viewing viedo when I turn on Wi-Fi again and connect to ASUS - video continues to work (normally until next session of the Tapo app, sometimes it could continue to work during, say, half an hour). Same happens with tab (it has no SIM), so if I turned Wi-Fi off and on during attempt to see video, then it often helped to break through this stange "barrier" and receive video.

Thank you.

This is so weird. If you turn the tunnel off on the client side everything regarding firewall and routes are still there on server side. yet, it starts to work...

What if you remove 192.168.2.0/24 from allowedIPs (server) and restart the server.
This will keep the tunnel but brake lan2lan connectivity. Does it work then?

after the test, reset AllowedIPs again to what it was and restart server to regain lan2lan access.

 

[AVS]

Thanks a lot for your kind feedback and efforts to troubleshoot the problem.

What if you remove 192.168.2.0/24 from allowedIPs (server) and restart the server.
This will keep the tunnel but brake lan2lan connectivity. Does it work then?

Done: removed this address range and restarted the server, ensured that the tunnel is up (and that there is no LAN-to-LAN connectivity). Result - access to cameras is OK. Also waited a few hours to ensure that the result is valid and stable.

Thank you.

 

[ZebMcKayhan]

Thanks a lot for your kind feedback and efforts to troubleshoot the problem.


Done: removed this address range and restarted the server, ensured that the tunnel is up (and that there is no LAN-to-LAN connectivity). Result - access to cameras is OK. Also waited a few hours to ensure that the result is valid and stable.

Thank you.

Alright, so the wireguard tunnel itself is not to blame for this issue. It can be up but the local connection appears to be an issue.
I have no idea how they make this connection but it appears that the video stream is not through the cloud server if there is a local connection between the camera/s and the device viewing.
Assuming the problem doesn't exist if you are locally on the keenetic router. The difference on the asus router is that the cameras are locally connected but not on the same subnet. Some devices are picky about this.

Since you have adjecant ips on your 2 network, what if you change the network size on the asus side to include the other network. Lan tab -> subnet mask, change to 255.255.252.0. This would cover 192.168.0.0 - 192.168.3.255.
That may fix it if your phone is the issue.
If it's still not working, try the same on keenetic router if it's your camera having issues.

Last option would be to block the cameras from accessing the tunnel. Some firewall rule on either keenetic side, or asus side.

 

[AVS]

Thank you so much.

Since you have adjecant ips on your 2 network, what if you change the network size on the asus side to include the other network. Lan tab -> subnet mask, change to 255.255.252.0. This would cover 192.168.0.0 - 192.168.3.255.

Will do.

Also, FYI: I have static routes on both routers, on ASUS side (LAN->Route) it is:

Network/Host IP: 192.168.2.0 Netmask: 255.255.255.0 Gateway: 192.168.1.1 Metric: 1 Interface: VPN​

Shall I keep it as it is?

If it's still not working, try the same on keenetic router if it's your camera having issues.

Last option would be to block the cameras from accessing the tunnel. Some firewall rule on either keenetic side, or asus side.

Thanks, OK, will do. But it would mean that we shall assume that if there is such an issue with cameras on Keenetic network, it somehow impacts cameras which are not on ASUS or Keenetic networks.

Thanks a lot once again, your help is very much appreciated.

 

[ZebMcKayhan]

Also, FYI: I have static routes on both routers, on ASUS side (LAN->Route) it is:

Network/Host IP: 192.168.2.0 Netmask: 255.255.255.0 Gateway: 192.168.1.1 Metric: 1 Interface: VPN
Shall I keep it as it is?

If you want, but on asus side it's not needed. AllowedIPs (server) will push this route when wg starts anyway.

But it would mean that we shall assume that if there is such an issue with cameras on Keenetic network, it somehow impacts cameras which are not on ASUS or Keenetic networks.

As I said, I have no idea how these cameras communicate. Perhaps they form a network of their own. I'm only trying to conclude the results of your testing.

It would be interesting to know the results from your testing.

 

[AVS]

It would be interesting to know the results from your testing.

THANK YOU SO MUCH - experiment successful! Having changed the mask to 255.255.252.0 I waited for around 12 hours before posting this message and checking cameras from time to time - all the cameras open fine. (However, I still do not completely understand why )))

Thank you very much once again - you attention to the problem and your help are very much appreciated.

 

[ZebMcKayhan]

However, I still do not completely understand why

Me neither. But glad it worked!

But, what I do know is that even though Wireguard connects your 2 networks together its not exactly the same as actually being connected to the same network.

Multicast for example does not work across network, which is why some functions not always work transparently (which is why shares are not adverticed and pop up by themselves for example).

Another issue is that even though access are allowed in the router across the networks, some devices (like phones et.c) have their own firewall that does not grant access to ips outside network range. Devices which does this properly uses network mask to determine the size of the network to grant access. Other devices may hardcode this to the last numbers in the ip.

As this worked for you I would assume the problem was actually on the device you used to view the camera blocking adjecent network access. So, turns out, nothing to do with Wireguard but more to do with the connection of 2 routed networks together.

Why this borked all cameras? perhaps only tp-link knows the answer to that one.

 

[AVS]

As this worked for you I would assume the problem was actually on the device you used to view the camera blocking adjecent network access.

But this is strange in any case, because TP-LINK says that cameras always connect to the phone via Tapo cloud, the only exception is when a phone sees that it is connected to Wi-Fi network with the same SSID as cameras and thus considers that as the same local network and switches to the local connection type instead of cloud. But in my case cameras' SSID is different...

Why this borked all cameras? perhaps only tp-link knows the answer to that one.

Indeed )))

Thank you very much!

 

[ZebMcKayhan]

TP-LINK says that cameras always connect to the phone via Tapo cloud, the only exception is when a phone sees that it is connected to Wi-Fi network with the same SSID as cameras and thus considers that as the same local network and switches to the local connection type instead of cloud. But in my case cameras' SSID is different...

then this is obviously not true. more likely the phone tries to talk to the camera via local ip which is probably successful since the camera does not have the same firewall restriction. as this is successful the camera will then try to stream the video locally which is then blocked by your phone firewall due to it's from another network.