Accessing ip camera through a vpn client

[Guus Sliepen]

On Thu, Dec 15, 2016 at 04:45:14PM +0200, sampsa wrote:

> client name   [ip in eth0]    [ip in tun0]
> 
> gl752 (A)     192.168.1.33    10.0.0.1
> xps13 (B)     192.168.1.55    10.0.0.2
> 
> I also have an ip camera connected to the local network at 192.168.1.21.
[...]
> I'd like to have the camera to have the ip address 10.0.0.21 in the tun0
> interface.

The main issue is then to get gl752 to translate the address of packets
for 10.0.0.21 to 192.168.1.21, and vice versa.  Let's look at a packet
being sent from xps13 to the camera:

src: 10.0.0.2  dst: 10.0.0.21

First, you have to ensure that tinc knows that packets to 10.0.0.21 have
to go to gl752. So add "Subnet = 10.0.0.21" to hosts/gl752 on gl752
itself. Now that the packet arrives at gl752, both the source and
destination address have to be changed! The reason is that the camera is
on a LAN that does not use the 10.0.0.0/24 address range. What you want
is to have the addresses translated so it looks like this:

src: 192.168.1.33  dst: 192.168.1.21

Or in other words, that it looks like the packet came from gl752 and is
being sent to the camera. Now, if the camera sends a packet back, it
will look like this:

src: 192.168.1.21  dst: 192.168.1.33

And now gl752 has to know that this packet is not actually sent to
itself, but that it has to be forwarded back to xps13, so the forwarded
packet has to look like:

src: 10.0.0.21  dst: 10.0.0.2

To do this, two firewall rules have to be added on gl752. The first is a
rule that will translate the destination address 10.0.0.21 to
192.168.1.21:

iptables -A PREROUTING -i tun0 -d 10.0.0.21 -j DNAT --to 192.168.1.21

The second is to masquerade connections to the camera as coming from
gl752 itself:

iptabels -A POSTROUTING -o eth0 -s 10.0.0.0/24 -d 192.168.1.21 -j MASQUERADE

> The camera should be able to stream multicast as well.

That will be even harder. While tinc handles multicast packets, it
treats them as broadcast packets. Also, you need to ensure multicast
packets from the LAN are forwarded to the VPN, and vice versa. I've
never tried to set that up, so I can't help you with that.

> 1) Is there any way to make tinc aware of a device that is accessible
> through the client "xps13", i.e. some sort of "auto-mapping" 192.168.1.21 =>
> 10.0.0.21 (I remember openvpn had something like this..?).

Tinc does not do any mapping itself, so you have to rely on your
kernel's abilities, like described above.

> 2) .. Or should I define "xps13" as being the gateway for "gl752", along the
> lines of:
> 
> https://www.tinc-vpn.org/examples/redirect-gateway/

No, that does not make sense.

> 3) Or is the thing that I am trying to achieve here, better described as
> "bridging", and I should do something along these lines .. ?
> 
> https://www.tinc-vpn.org/examples/bridging/

Bridging could also be a solution, if you can have everything use the
same address range (192.168.1.0/24) without conflicts.

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20161229/e319faae/attachment.sig>