Behavior like -R and -L SSH

[Guus Sliepen]

On Mon, Aug 28, 2017 at 10:48:56PM -0400, Rafael Wolf wrote:

> I wanted a TINC tunnel like this, where I have a server on the Internet
> with a public IPv4 address as my TINC server.  Then I can have clients
> connect to it and see each other except that the client at a customer
> site would allow me to route behind it so I could see hosts on site beyond
> my device on premise.
[...]
> Internal Devices <-- Customer Site with a rasperry pi --> Internet -->
> Public Server <-- Laptop, PC, whatever
> 
> Server with public IPv4 address:
[...]
> /etc/tinc/devtun/tinc-up
> 
>   #!/bin/sh
>   ifconfig $INTERFACE 192.168.2.1/29
>   route add -net 192.168.0.0/24 gw 192.168.2.1 dev $INTERFACE

The route statement is correct. However, "gw 192.168.2.1" does not do
anything when tinc is in router mode. You can leave it out.

> /etc/tinc/devtun/hosts/devtun
>   TunnelServer = yes
>   Address = 10.0.10.3
>   Subnet = 192.168.2.1/32
> 
>   -----BEGIN RSA PUBLIC KEY-----
>   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>   -----END RSA PUBLIC KEY-----
> 
>   * Note that I also tried putting in another "Subnet" for the 192.168.0.0
> but it
>     didn't seem to do anything.

You should only put in Subnet statements for those address ranges that
belong to that node itself. It seems like 192.168.0.0/24 is the address
range for the internal devices at the customer site, so this does not
belong to devtun.

> Client config (rasperry pi at the client site):
[...]
> /etc/tinc/tinc-up
> 
>   #!/bin/sh
>   ifconfig $INTERFACE 192.168.2.2/29
>   # This route breaks networking!  Definitely don't use this!
>   # route add -net 192.168.0.0/24 gw 192.168.2.2 dev $INTERFACE

You should indeed not add this route. If 192.168.0.0/24 belongs to the
internal network, then adding a route for 192.168.0.0/24 to the VPN
interface will ensure demo can no longer talk to its internal network.

> /etc/tinc/demo/hosts/demo
> 
>   TunnelServer = yes
>   Address = 67.219.201.3
>   Subnet = 192.168.2.2/32
>   Subnet = 192.168.0.0/24
>   Mode = router
> 
>   -----BEGIN RSA PUBLIC KEY-----
>   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>   -----END RSA PUBLIC KEY-----
[...]
> Got ADD_SUBNET from demo (75.134.104.213 port 54059): 10 3d2ef9c2 demo
> 192.168.2.2/32#10
> Ignoring unauthorized ADD_SUBNET from demo (75.134.104.213 port 54059):
> 192.168.2.2/32#10
[...]
> Both server and client can ping each other.
> 
> So...why would I be getting that "unauthorized subnet" from the demo site?

Because you are using the TunnelServer option, which implicitly also
enables the StrictSubnets option. Try it without TunnelServer = yes.

> Once I iron out the subnet issue how can I "route" from the server or other
> clients connected to the server beyond the client (which is my pi)?

Your configuration looks correct to me, as long as you remove the
TunnelServer option.

> OH and also...when I have the client config files like this on each host:
> 
> server has:
>   devtun <-- what I actually fire up with tincd to "listen"
>   demo
> 
> client has:
>   devtun
>   demo <-- what I actually fire up with tincd to "connect"
> 
> ...does the client really care what the "devtun" config file has in it
> besides the authentication key?

Yes, if you use TunnelServer = yes then it will also use the Subnets
from that file, and will not allow devtun use any other Subnet.
Otherwise, no.

> ...does the server really care what the "demo" config file has in it
> besides the autnetication key?

Yes, it also reads the Subnets because TunnelServer = yes, and it reads
the Address statement so it knows how to connect to demo.

-- 
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: 833 bytes
Desc: not available
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20170829/9ecf2504/attachment.sig>