gmane.network.tinc.user

RE: Install Tinc in iPhone / iPad.

Ramses II — 2013-05-17T18:34:56

Hi everyone,

Sorry, i want apologize because I had an error  in the host file, I had a wrong value in the subnet parameter. When I put the correct value in subnet, it works well.

Although not entirely correct, it works well when connect with the iPhone by WiFi but if i try to connect by 3G, it not works.

Can be it by a problem with the tunemu?

From the console, i can ping to the remote Tinc server but in his log not appear nothing about the iPhone connection.

Another thing: Guus, why don't you put the compiled packages by Mike in the "http://www.tinc-vpn.org" web?


Regards,

Ramsés


_______________________________________________
tinc mailing list
tinc< at >tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Re: DTLS

Guus Sliepen — 2013-05-17T14:56:59


Yes, if possible. If it is blocked somehow, tinc will fall back to TCP.


No.


I have not, but maybe others on the list have. 0MQ should work without problems
over tinc.

DTLS

Laurent Alebarde — 2013-05-17T11:19:35

Hi all,

I am looking for a secured communication between web clients and my 
servers. tinc looks great. I understand it uses UDP for data. But does 
it use DTLS (newbbie question) ?

As someone tryed to use 0MQ with it ?

Cheers,

Laurent.

Re: Routing control within one tinc network

Lee Essen — 2013-05-16T03:31:54

Hi Guus,

On 15 May 2013, at 20:09, Guus Sliepen <guus-NnCthlHDAqpg9hUCZPvPmw< at >public.gmane.org> wrote:


Thanks for the response ... unfortunately this option won't work since I don't know the subnet ranges in advance (it's related to the Akamai CDN.)


I'll have a look at switch mode, I hadn't thought of that. 

Thanks,

Lee.

RE: Install Tinc in iPhone / iPad.

Ramses II — 2013-05-15T20:06:24

Hi Mike,

Very thanks by to compile and put it in your web.

I have downloaded it and installed in my iPhone.

It appear that all is correct, but I can't do Ping to the IP Address of my ppp0 interface.

I execute the following command:

/usr/sbin/tincd -d2 --logfile=/var/log/tinc.log

If we see the log, all appear that is correct:

---------------------------------
iPhone4:/ root# cat /var/log/tinc.log
2013-05-15 21:21:25 tinc[31239]: tincd 1.0.21 (May  5 2013 10:47:52) starting, debug level 2
2013-05-15 21:21:25 tinc[31239]: /dev/null is a BSD tunemu device
2013-05-15 21:21:25 tinc[31239]: Executing script tinc-up
2013-05-15 21:21:25 tinc[31239]: Listening on 0.0.0.0 port 655
2013-05-15 21:21:25 tinc[31239]: Listening on :: port 655
2013-05-15 21:21:25 tinc[31239]: Ready
2013-05-15 21:21:25 tinc[31239]: Trying to connect to Central (178.x.x.x port 80)
2013-05-15 21:21:25 tinc[31239]: Connected to Central (178.x.x.x port 80)
2013-05-15 21:21:26 tinc[31239]: Connection with Central (178.x.x.x port 80) activat

Re: Routing control within one tinc network

Guus Sliepen — 2013-05-15T16:09:22


In router mode, a gateway route does nothing, that only has effect on Ethernet
networks. If you want traffic to specific IP addresses go via the normally
unpreferred node, that is easy: just add Subnets for those IP addresses (or
whole ranges if you want) to the host config file of the unpreferred node. You
can have overlapping Subnets, and smaller Subnets always are preferred over
larger ones (just like the Linux routing table works).

If that is not enough, you could run tinc in switch mode, but then you'd have
to use some other tool to handle failover between the two nodes. You can use
host-up/down scripts to change your routing table depending on which one(s) are
online, or run a routing daemon on top of your VPN.

Routing control within one tinc network

Lee Essen — 2013-05-15T15:39:29

Hi,

I have a question around whether there is any way to control tinc routing if you have multiple routes to the same destination.

I have a three node configuration, let's call them:

home -> connects to both other nodes
vps1 -> a VPS, providing connection to the internet
vps2 -> another VPS, also providing a connection to the internet

Both vps nodes provide their own 192.168.x.0 subnet as well as 0.0.0.0/0 to allow any traffic to go that way and out to the internet (via SNAT.)

My original plan was to have different weightings on the 0.0.0.0/0 networks so that I got a preferred vps node, but in the event of a problem it would effectively fail over to the other one. This config all works perfectly ... tinc is absolutely superb!

BUT ... my preferred vps node has a slight issue from a geographic standpoint that means some services don't work as well as they should ... I'd still like it to be the primary since it has a much bigger bandwidth allowance, but I'd like to route specific services over the other v

Re: connectivity issues

Guus Sliepen — 2013-05-12T12:12:24



Try it without "Forwarding = off" in any case.


That reply is generated by tinc and means that it thinks it knows the
192.168.69.3 address, but that the node it belongs to is offline.

[...]

That means MIKEDEV02 is receiving approxmitely 1 packet from VPS01PP and
sending it to the virtual network interface.

[...]


Not necessarily, the "edges" are only the meta connections between the nodes.
To check whether MIKEHOMEPC is reachable, you should give the command:

tinc -n vpn info MIKEHOMEPC

[...]

Hm, that looks like it has a direct connection to MIKEHOMEPC, so it shouldn't
give Destination net unreachable replies.


Look at the output of "tinc -n vpn info MIKEHOMEPC" when pings are not working.
You can also get detailed log output at any time by running "tinc -n vpn log 5".

connectivity issues

Mike Bentzen — 2013-05-12T01:49:24

Hi Guus and List,

Since the CVE-2013-1428 was announced, I followed the recommendation to 
update my windows machines to tinc1.1pre7.
I've had connectivity issues since upgrading. I've done some debugging 
but I can't figure out when or why its happening.

All machines on the network are running Windows 7 or Windows 2008R2 
Enterprise server and tinc 1.1pre7.
I've got one master node, which all machines connect to. Everything is 
running in router mode.
All machines (apart from MIKEIPHONE and MIKEIPAD are connected to the 
network and authenticated)
I've also recently changed the Forwarding variable on the master node 
to: Forwarding = off, but I cannot remember how long ago this was, and 
I'm not sure if this is what is causing the issue.
I don't want VPS01PP to route any VPN traffic, I only want it to be used 
for establishing the connection between other nodes.

Example:

When trying to connect MIKEHOMEPC to MIKEDEV02, i get a destination 
unreachable message.
VPN addresses: MIKEHOMEPC = 192.168.69.5/32,

Re: Changes in Makefile/dependencies between Tine 1.0.16 and 1.0.21?

Guus Sliepen — 2013-05-11T16:01:21


I don't know how Ubuntu handles their LTS releases, but normally you would only
backport the fix for a vulnerability, you don't package a newer upstream
version. In that case, the debdiff posted by Malte S. Stretz in that thread is
what you want to apply to the Ubuntu LTS packages as well:

http://launchpadlibrarian.net/138627199/tinc_1.0.19-2_1.0.19-3.diff.gz

If it's not LTS then just package the latest version of tinc as you would do
any new upstream release.

Changes in Makefile/dependencies between Tine 1.0.16 and 1.0.21?

Rene Bartsch — 2013-05-11T15:08:43

Hi,

currently there is a bug report about CVE-2013-1428 in Ubuntu (
https://bugs.launchpad.net/ubuntu/+source/tinc/+bug/1174763). Are there any
changes in Makefile or dependencies which make it necessary to adjust a
packaging system or does it suffice to adjust version numbers and
source-code url?

Thanx,

Renne

Re: Environment variables in tinc.conf?

Guus Sliepen — 2013-05-11T11:17:50


Yes, with version 1.0.21 or 1.1pre7, you can use environment variables for the
Name option (but not for any other option).

http://www.tinc-vpn.org/documentation/tinc_4.html#index-Name

Environment variables in tinc.conf?

Rene Bartsch — 2013-05-11T11:00:17

Hi,

even with only five nodes one looses track of changed configs and host
files after adding/removing a node or changing the config (e.g. ConnectTo).
It would be great if one can just copy a default tinc.conf to all nodes.
Show-stoppers are the ConnectTo- and Name-options. ConnectTo is be replaced
by Autoconnect, but one still needs to set the Name of a node. Using
environment variables in tinc.conf like $HOSTNAME would simplify matters.

Is it possible to use environment variables in tinc.conf? If not, this is a
feature request to enable enviroment variables in tinc.conf or add a flag
"HOST" to the Name option (Name = HOST) which resolves the hostname as node
name.

Thanx

Renne

Re: ARP resolution not done from one end

Nick Hibma — 2013-05-10T21:01:10


The problem is not the roaming node (with the multiple tunnels), but the central node. I do actually manually do the ping when the tunnel comes up. Second the problem occurs after the MAC address expires, not after tunnel change (the 3G link is not operational at the moment).



There are no firewalls in there doing anything, and certainly not with ARP requests (freebsd ipfw).


I see ping pong's.

Removing statements from the tinc config showed that after removing TunnelServer the ARP requests started coming through.

I don;t quite understand, but it does make some kind of sense.

Nick

Re: ARP resolution not done from one end

Guus Sliepen — 2013-05-10T20:50:08


DirectOnly has nothing to do with that. But TunnelServer (which implies StrictSubnets) does.

Re: ARP resolution not done from one end

Nick Hibma — 2013-05-10T20:42:52

Never mind. The subnet statement is there.

Nick

Re: ARP resolution not done from one end

Nick Hibma — 2013-05-10T20:41:52

Could it be that its because I have DirectOnly in there the roaming node knows where to send the ARP requests because it has a proper Subnet line in the central node's hosts file, but the central node does not have a Subnet statement anywhere for the roaming node?

Nick

Re: ARP resolution not done from one end

Guus Sliepen — 2013-05-10T20:18:47


I don't know, but here are some things:

- ARP requests are not always broadcast, they can be unicast as well. When the
  kernel remembers the MAC address, but the ARP entry is about to expire, it
  will use unicast. Only after a few unicast ARP packets have not elicited a
  response will the kernel fall back to broadcast. (AFAIK, on Linux.)

- Tinc maintains its own table of MAC addresses it has seen on the VPN. They
  are also expired after a while (10 minutes by default, configurable with the
  MACExpire option). If a packet inside the VPN has a destination MAC address
  that is known, tinc will directly send it to the node it thinks the MAC address
  belongs to. If it is not known, the packet is broadcast.

So, if you swap the MAC addresses of the client's virtual interfaces, and you
don't send any packet FROM the client, then tinc will not learn of the new MAC
addresses. If the server still remembers the old MAC addresses, and sends
unicast packets via the wrong link, then the client's kernel will lik

ARP resolution not done from one end

Nick Hibma — 2013-05-10T19:46:43

Folks,

We have a setup where each mobile node connects with 1 or more tinc instances (over different links) to a central node. tinc is running in switch mode. The link is chosen by setting the IP address on the active link's interface, and the central node sees this after the first packet on the link, and moves the MAC address to a different 'ethernet port' (link). This works really well, and keeps webmal sessions alive on a moving ship (VSat -> 3G -> VSat).

We have changed our setup and now the tunnel becomes idle for long periods of time. The problem is that the central node expires it's ARP table entry for the node. tinc is not forwarding ARP requests over the link / links. After doing 1 ping from the mobile node to the central node the ARP entry is there again as that end does forward ARP requests, and things are back to normal. The roaming node seems to initiate ARP resolution, while the central node does not.

Any points as to why the central tinc is not doing / able to do the ARP request?


tinc.con

Re: Iptables rules and internet access problems

Cédric Lemarchand — 2013-05-10T19:22:04

The simpliest way to debug issues like this is to add before your 'DROP' 
a 'LOG' rule :

iptables -A FORWARD -p tcp --dport 80 -i eth0 -o eth1 -j LOG 
--log-prefix 'DROPED '
iptables -A FORWARD -p tcp --dport 80 -i eth0 -o eth1 -j DROP

This way, every packets forwarded from eth0 to eth1 to a tcp port 80 
will add en entry in your syslog.

If your iptables default policy is set to DROP, then just add the LOG 
rule at the end of the table definition, before the final drop. Off 
course, you can do that in INPUT, OUTPUT and FORWARD tables.

http://lmgtfy.com/?q=iptables+log+drop

Cya

Le 10/05/13 17:49, noyfound a écrit :

Iptables rules and internet access problems

noyfound — 2013-05-10T15:49:36

Hello,

I have faced some problems :

1. With iptables running i can't ping my tincvpn server but as i turn it
off i can. i have added all rules mentioned in examples but no success.

2. I want to get internet access on the client which is a win 7 computer
using tincVPN but i gained no success either (i can't use bridges because
server is a VPS using OpenVZ)

so any advice for solving this two problems is really appreciated

*Server :*
OS : centos 6.4 32bit

*tinc.conf :*
Name = server
AddressFamily = ipv4
Interface = tun0

*Client :*
OS : win 7 x64

*tinc.conf :*
Name = client
AddressFamily = ipv4
Interface = mytinc
ConnectTo = server

*Hosts files :*
*Server :*
Address = 69.*.*.*
Subnet = 10.0.0.1/32
== pubkey ==

*Client :*
Subnet = 10.0.0.2/32
== pubkey ==