Hi All,
I've been playing around with TINC and like what I've seen so far.
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. I do this with -R and -L port redirects in SSH BUT
I need friendlier URL's and host names. With ssh I always have to do
localhost:xxxxx instead of x.x.x.x (IP) or http(s)://hostname or whatever
else I want to connect to like RDP servers, etc.
Internal Devices <-- Customer Site with a rasperry pi --> Internet -->
Public Server <-- Laptop, PC, whatever
Here is my config (I don't have a "Laptop , PC , whatever" config
yet):
Server with public IPv4 address:
/etc/tinc/tinc.conf
Name = devtun
AddressFamily = ipv4
Interface = tuu0
Mode = router
/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
/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.
Command: tincd -n devtun -d5 -D
tincd 1.0.26 (Jul 5 2015 23:17:54) starting, debug level 5
/dev/net/tun is a Linux tun/tap device (tun mode)
Executing script tinc-up
Listening on 0.0.0.0 port 655
Ready
Client config (rasperry pi at the client site):
/etc/tinc/tinc.conf
Name = demo
AddressFamily = ipv4
Interface = tuu0
ConnectTo = devtun
Mode = router
/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
/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-----
Command: tincd -n demo -d5 -D
Server logs of interest:
Sending ADD_SUBNET to demo (75.134.104.213 port 54059): 10 1b9f2ab0 devtun
192.168.2.1/32#10
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
Got ADD_SUBNET from demo (75.134.104.213 port 54059): 10 79c41aff demo
192.168.0.0/24#10
Ignoring unauthorized ADD_SUBNET from demo (75.134.104.213 port 54059):
192.168.0.0/24#10
Both server and client can ping each other.
So...why would I be getting that "unauthorized subnet" from the demo
site?
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)?
I have played about with various route adds but nothing seems to work and
get me PAST the pi.
I've tried paying with adding the routes but something isn't right.
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?
...does the server really care what the "demo" config file has in it
besides the autnetication key?
I'm a bit confused besides the KEY if the client really cares what's in
that file since it's not "called"
by the daemon.
Thanks for any insight and help!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20170828/db15043f/attachment.html>
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 $INTERFACEThe 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 $INTERFACEYou 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>