OpenVPN - accessing Reolink IP-Camera fails

Networking
1

Hi!

I’ve got a green network with 192.168.0.0/255.255.0.0 and an OpenVPN network with 10.114.101.0/255.255.255.0 set up.
The latest core version of IPFire is running here.

Accessing the internal LAN from outside works perfectly after a successful established connection from my smartphone with OpenVPN app on Android.

I’m running three IP-cameras from Reolink inside the LAN, no access to WAN allowed for each of them via IPFire firewall rules.

I can access the IP-cameras using Reolink’s own app on smartphone from LAN.

However, when using the mobile network on my Samsung smartphone and an established OpenVPN connection to LAN, Reolink’s app can only access two of the cameras and camera C is failing.

IP-camera A has got IP-address 192.168.13.1 → accessible (wired)
IP-camera B has got IP-address 192.168.13.2 → accessible (wired)
IP-camera C has got IP-address 192.168.13.3 → fails (wireless)

The only difference between them is, camera A + B are connected using a wired connection and camera C is connected, using internal Wifi. No VLAN-ID is involved, though.

All ports from OpenVPN network to green network are open so are all protocols, with a single firewall rule. As far as I know, Reolink’s app uses http or https protocol for accessing the camera or streaming their vid signals.

Hence, it shouldn’t make any difference, why the Reolink app is not capable of accessing camera C when OpenVPN is enabled.

It may be a misconfiguration of the Wifi access-points, because that’s the only known difference.
However, I doubt this a bit since there is no issue in accessing from internal LAN.

IPFire’s firewall policy for outgoing traffic is set to blocked.

So, I believe it maybe a setting within OpenVPN on IPFire side, altough there are not that much options I could have overlooked the most important one.

OTH, disabling the fw policy for outgoing traffic, does not solve this situation either.

Is there anyone with a similar configuration or a tip which settings or steps I could check to get this running?

2

Hi @hellfire.

A crazy idea. If the traffic originates from the OpenVPN range (10.114.101.0), the camera may not know how to reach this range since it is not Green and packets will be lost. You may have to create a SNAT rule so that the IP of the Green interface is added at the beginning of the TCP frame so that it knows how to get there.

It’s an idea.

Saludos.

3

I am at a disadvantage as I don’t use OpenVPN on IPFire yet, but one thing comes to mind. Could it be that the WiFi connection in the camera rejects packets from outside its own subnet? You could possibly test by switching a wired camera to wireless.
I don’t know the OpenVPN firewalling set up, but one thing you could try is to SNAT 10.114.101.0/255.255.255.0 to green0.

BTW, that is a huge amount of address space you’ve reserved for your LAN! It will also give you some problems connecting by VPN from domestic LANs as one basic rule is that the local and remote LAN subnets should not overlap and the odds are high that a domestic LAN is using 192.168.0.0/24 or 192.168.1.0/24. If you connect from one of those subnets, you won’t be able to access the devices on your LAN which are on the same subnet that you are connecting from.

4

I know, however this is by intention. Because I can build “blocks” of IP-addresses, for types of devices, like IP-cameras, printers or servers and blocks for the devices each user owns, like smartphones, tablets or local PCs.

With those “address ranges” I can set up some networks in firewall groups and use them in firewall rules more efficiently instead of adding a rule for each single IP-address.

The IP-addresses are static leases in DHCP driven by their MAC-address. All others, yet unknown, devices get their IP-address from DHCP address pool (green network) that are blocked per default in firewall for all outgoing traffic.

That’s the intention behind the huge address space. So far, I did not encounter any issues, in my home LAN - this is not a company LAN :wink:

Anyway, I will see if the (S)NAT rule as @roberto and you mentioned will solve the OpenVPN issue.

I will get back here after some tests. Thanks so far for the hints!

5

Just rethought about SNAT and what you have said above.

This would not explain why the other reachable cameras work without any issues, right? They are in the same LAN and are accessible within the smartphone app.

I’ve found out, that a can reach the web interface of camera C without any issues, though. This leaves the question, why is streaming impossible.

I will have to investigate more deeper.

6

It could just be the camera firmware blocking streaming to IPs not from the same subnet when using WiFi. Just try the SNAT rule and see if it helps. It takes minutes to test.

7

Just tried without success! But honestly this may be related to a not properly set up FW rule.

I’ve created a new rule with source OpenVPN.
I’ve checked NAT and source NAT with destination the green network.

Additionally, added the green network to section destination and saved the rule and restarted the firewall.

This failed as before, the camera in question is not reachable.

8

Replying myself: I fiddled around with Wifi settings on my Unifi access points and switched the default profile to manual, adjusted some settings and now it works perfectly.

SNAT is not used, just modified Wifi settings. Guess defaults were not fully compatible with this IP camera, although it was accessible from LAN.

Thanks for reading!

9

After some time my solution did not work anymore. No clue why.

So, I decided to create a new FW rule allowing all traffic from OPENVPN to the specific IP-address of the camera.
Now, since then, this runs perfectly well.

I should mention that I had already a rule in place, allowing all traffic from OPENVPN to the green network, which obviously did not work from external.

The camera has an IP-address from the green network, though.