Re: site-site vpn setup..

[Rob Townley]

My non IT staff used tinc for years and years on ~20 roaming TabletPCs and
never knew.  I cant get them to copy-n-paste.

Even Microsoft PowerShell 6 builds in a ssh client and _server_ to remotely
manage MS Windows and this what allows Ansible to perform DSC on fleets of
windows and Linux machines.

 I suspect the article is from the GUI only dark ages of Steve Ballmer.

Windows 2012 LOGO’ed network switches are meant to be configured from the
CLI over ssh.


On Thu, Mar 29, 2018 at 11:09 AM Rafael Wolf  wrote:

> Al like any open-source or free sofware you need to put the leg work into
> what you want it to be.
>
> My company is actually creating something using TINC and we believe in
> it.  If successful we'll be giving back to TINC monetarily in a big way to
> make TINC even better so if TINC isn't for you keep an eye on further
> developments in the future.
>
> Thanks,
>
>
> Rafael
>
>
> On Thu, Mar 29, 2018 at 12:03 PM, Tomasz Chmielewski 
> wrote:
>
>> SNMP is mainly used for monitoring, not _server_ automation.
>>
>> Also, it's inherently insecure for anything else - only SNMPv3 offers any
>> kind of encryption, and it's DES - 56 bit only, and you can easily
>> brute-force it on an average computer.
>>
>>
>> If you could provide some serious articles about why is CLI insecure, I'd
>> be interested to read.
>>
>>
>> Tomasz Chmielewski
>> https://lxadm.com
>>
>>
>>
>> On 2018-03-30 00:48, al so wrote:
>>
>>> Just search online why in general that is insecure via CLI vs
>>> programmatic for first class automation..  there is a reason why snmp,
>>> rest, ... exist.
>>>
>>> On Thu, Mar 29, 2018 at 3:50 AM, Tomasz Chmielewski 
>>> wrote:
>>>
>>> You've mentioned security issues in your previous email, but now
 you're hopping to management issues.

 Have you tried Ansible, Chef or Puppet for automation? It works well
 for hundreds of servers, different services and not just one kind of
 VPN.

 Tomasz Chmielewski
 https://lxadm.com

 On 2018-03-29 16:10, al so wrote:
 Programmatic management with first class APIs is preferred for
 larger
 deployments..

 On Mon, Mar 26, 2018 at 12:28 PM, Tomasz Chmielewski
 
 wrote:

 Could you elaborate on why CLI (SSH) managing is insecure?

 Tomasz Chmielewski
 https://lxadm.com

 On 2018-03-27 04:23, al so wrote:
 So, for remote manageability of Tinc, we don't have any SNMP or
 REST
 like programmatic ways?

 If it is going to be CLI only, it is definitely not secure to manage
 and also not very convenient to manage programmatically.

 On Sun, Mar 25, 2018 at 1:44 AM, Guus Sliepen 
 wrote:

 On Sat, Mar 24, 2018 at 02:16:20PM -0700, al so wrote:

 Is there any quickstart guide to setup site-to-site VPN using
 Tinc 1.1

 pre-rel?

>>>
>>> You can find an example of a site-to-site VPN with four sites here:
>>>
>>> http://tinc-vpn.org/documentation/Example-configuration.html [1] [1]
>>> [1]
>>>
>>> Assuming I have two routers at two sites running tinc vpn along
>
   with
>>>
>>> routing feature.
>

>>> If you only have two sites, then just look at the example
>>> configuration
>>> for "Branch A" and "Branch B" in the page I linked, and ignore the
>>> other
>>> two sites.
>>>
>>> Once I setup manually and validate the connection, I want to
>
   automate
>>>
>>> using REST APIs.
>

>>> Tinc does not expose any REST APIs. With tinc 1.1, you can use the
>>> command line tool to automate things though, see:
>>>
>>> http://tinc-vpn.org/documentation-1.1/Controlling-tinc.html [2] [2]
>>> [2]
>>>
>>>
>>>
>>> Links:
>>> --
>>> [1] http://tinc-vpn.org/documentation/Example-configuration.html
>>> [2] http://tinc-vpn.org/documentation-1.1/Controlling-tinc.html
>>>
>> ___
>> tinc mailing list
>> tinc@tinc-vpn.org
>> https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
>>
>
>
>
> --
> Rafael
>
> 765-714-7257
> ___
> tinc mailing list
> tinc@tinc-vpn.org
> https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
>
___
tinc mailing list
tinc@tinc-vpn.org
https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Re: Host not reachable over UDP

[Rob Townley]

Have anything to do with firewall locations, meaning home vs work vs public
vs lockdown.  Probably not it at all.
On Jul 13, 2016 3:22 PM, "Etienne Dechamps"  wrote:

> That's strange. Can you post a detailed log from the affected node (run
> tincd -d5 -D), especially the initialization phase?
>
> On 13 July 2016 at 16:17, Petr Man  wrote:
>
>> Dear all,
>>
>> I have been successfully running for quite some time a tinc 1.1 network
>> in switch mode. I recently added a new node, that refuses to communicate
>> over UDP.
>> Running "tinc info mynode" from a different box returns:
>> Reachability: directly with TCP
>>
>> It appears that tincd is not listening on UDP port 655 on "mynode".
>> Running "ss -nlptu | grep tincd":
>> tcpLISTEN 0  3 *:655   *:*
>> users:(("tincd",pid=10097,fd=6))
>>
>> In the log there is a large number of these messages:
>> Received UDP packet from unknown source 123.321.123.321 port 655
>>
>> I am puzzled how is tincd getting the packets if it is not listening on
>> 655/UDP.
>>
>> When I start netcat on the node on port 655/UDP I can see garbage coming
>> in from the other nodes trying to initiate an UDP connection.
>>
>> Would you have any hints where to start debugging this? All machines are
>> configured the same way and work fine (various linux versions, windows).
>> This particular box is on Ubuntu Xenial kernel 4.3.5.
>>
>> Best,
>> Petr
>>
>> ___
>> tinc mailing list
>> tinc@tinc-vpn.org
>> https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
>>
>>
>
> ___
> tinc mailing list
> tinc@tinc-vpn.org
> https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
>
>
___
tinc mailing list
tinc@tinc-vpn.org
https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Re: tinc 1.1pre4 on Win7x64 --mlock prevents service from starting

[Rob Townley]

On Thu, Jan 24, 2013 at 3:55 AM, Guus Sliepen g...@tinc-vpn.org wrote:
 On Wed, Jan 23, 2013 at 10:03:19PM -0600, Rob Townley wrote:

  What is the problem with the stop and start commands removing/adding the
  service from the registry? That is exactly what tinc 1.0.x does as well.
  You
  can stop/start the service without altering the registry from the service
  control panel, I believe.
 [...]
 i will try the new version this week.  The tinc service would start up and
 i could connect albeit with a great deal of latency.  But when stopped, the
 service would get disabled and then deleted.

 But what is the problem with the service getting deleted? It will get added
 again when you do tincctl start.


Requirement is that remote machines ConnectTo the Server upon bootup
even if a user never logs on.
___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Re: Conflicting Default Values. A trusts B. B trusts EvilNode. Does that mean A trusts EvilNode?

[Rob Townley]

On Thu, Jan 24, 2013 at 4:14 AM, Guus Sliepen g...@tinc-vpn.org wrote:
 On Thu, Jan 24, 2013 at 10:53:18AM +0100, Guus Sliepen wrote:

 There are two kinds of connections. If node A does not have the public key of
 EvilNode, then EvilNode cannot make a meta-connection to A (it cannot 
 ConnectTo
 A). However, UDP packets to/from EvilNode will be allowed, unless you use
 either StrictSubnets or the combination of Forwarding, DirectOnly and
 IndirectData mentioned above.
 [...]
 In the case of EvilNode, the proper way to deny it access to the VPN would be
 for B to remove hosts/EvilNode. [...]

 What I forgot to mention is that EvilNode can only exchange packets with A,
 either directly or forwarded via B, if and only if EvilNode has a working
 meta-connection to B. So once B removes hosts/EvilNode and reloads its
 configuration, it will kill the meta-connection between B and EvilNode, and A
 will then immediately stop accepting packets from EvilNode.

 --
 Met vriendelijke groet / with kind regards,
  Guus Sliepen g...@tinc-vpn.org

 ___
 tinc mailing list
 tinc@tinc-vpn.org
 http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc


In a large network with large number of /hosts/ files on a large
number of not always connected machines, centralized management
provides a way to curtail the effects of a compromised machine
immediately.
___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Re: Conflicting Default Values. A trusts B. B trusts EvilNode. Does that mean A trusts EvilNode?

[Rob Townley]

On Thu, Jan 24, 2013 at 3:53 AM, Guus Sliepen g...@tinc-vpn.org wrote:
 On Wed, Jan 23, 2013 at 09:58:50PM -0600, Rob Townley wrote:

 *You should repeat this for all nodes you ConnectTo, or which ConnectTo
 you. However, remember that you do not need to ConnectTo all nodes in the
 VPN; it is only necessary to create one or a few meta-connections, after
 the connections are made tinc will learn about all the other nodes in the
 VPN, and will automatically make other connections as necessary. *

 The above is from the docs.  Assuming all nodes in router mode.  How does
 this not mean that A trusts B.  B trusts EvilNode.  Does that mean A
 trusts EvilNode? by default?

 Yes. That's a feature.

 If A and EvilNode, have not exchanged public keys directly, they can still
 establish sockets with one another over their TINC IP addresses.
 I know if both node A and EvilNode ConnectTo B, then EvilNode can establish
 internet connections with node A's tinc IP.
 Forwarding=OFF or TunnelServer=YES or IndirectData=NO  are supposed
 to prevent this.

 Neither Forwarding = off nor IndirectData = no will prevent this. The
 TunnelServer = yes option might prevent it because it implies StrictSubnets =
 yes.

 EvilNode can connect and establish a tinc IP connection to A.  I have to
 assume this happens because of Forwarding=internal by default.

 No, the Forwarding option has, in principle, nothing to do with whether A
 trusts EvilNode. You can however use the following combination of options to
 only allow communication with nodes that you have a ConnectTo with:

 Forwarding = off
 DirectOnly = yes
 IndirectData = yes

Could we have a Paranoid= yes | no  (no)
   Paranoid=yes is an alias that sets other configuration options to make tinc
   behave more like a traditional VPN.  When setting this, it will forcibly
   set all of the following, but not limited to:
   Forwarding = off
   DirectOnly = yes
   IndirectData = yes



 config get IndirectData and config get Forwarding and config get
 TunnelServer all return No matching configuration variables found.  So
 we have to rely on documentation or source code to determine what the
 default values are.  Default configuration parameters are in conflict but
 we have no way with tincctl to know what the actual parameters are for
 verification.

 Hm, it would indeed be nice to have tincctl print the default value if it 
 isn't
 found.

 The default value Forwarding=internal  contradicts both default values
 IndirectData=NO  AND TunnelServer=no, however Forwarding=internal
 WINS allowing EvilNode to connect to A.

 There is no contradiction.

 Is there an option to not allow any other node to connect to your node?  It
 could still ConnectTo Server1, but not allow any incoming connections.

 There are two kinds of connections. If node A does not have the public key of
 EvilNode, then EvilNode cannot make a meta-connection to A (it cannot 
 ConnectTo
 A). However, UDP packets to/from EvilNode will be allowed, unless you use
 either StrictSubnets or the combination of Forwarding, DirectOnly and
 IndirectData mentioned above.

UDP packets ... that would explain a great deal.


 Without somewhat centralized control, it is hard to know who is connecting
 to who, which would be a good reason to have the option to put network keys
 into a DNSSEC server.

 You can dump the graph and visualize it with the following command with tinc 
 1.1:

 tincctl -n netname dump graph | circo -Txlib

 (You can use neato or dot instead of circo for some alternative layouts.) This
 will show you the graph of meta-connections. Besides the drawn lines, all 
 nodes
 can, unless prevented by NATs or firewalls, also exchange UDP packets directly
 with each other.

The graphing features are cool and i like them, but if you want to be
absolutely certain of all nodes that could possibly connect into the
vpn, including those that are powered off, then a centralized node
management system.  Vain attempt to prevent one of the programmers
from sending his public key to China to outsource his own work.

 In the case of EvilNode, the proper way to deny it access to the VPN would be
 for B to remove hosts/EvilNode.  I agree this is not ideal. However, putting
 the keys in DNSSEC in itself is not an improvement, it merely shifts the
 problem and makes the whole system more complex.

 For tinc 1.1, I will probably add a way to blacklist specific nodes. A long
 term solution will be implemented in tinc 2.0.

 --
 Met vriendelijke groet / with kind regards,
  Guus Sliepen g...@tinc-vpn.org

 ___
 tinc mailing list
 tinc@tinc-vpn.org
 http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc


In addition to wondering aloud if a new configuration option could be
created that may be a set of aliases for existing config options.

TunnelServer = yes|no (no) [experimental]
Would setting TunnelServer=yes on each client do the same as the
paranoid setting above?

The following

Re: tinc 1.1pre4 on Win7x64 --mlock prevents service from starting

[Rob Townley]

On Mon, Jan 14, 2013 at 3:46 PM, Guus Sliepen g...@tinc-vpn.org wrote:

 On Mon, Jan 14, 2013 at 12:15:24PM -0600, Rob Townley wrote:

  i usually import a tincd.reg file with the --debug and --mlock and
  --log parameters.  When tinc.myvpn is started from services.msc or sc
  start tinc.myvpn, the only error is the windows error that tinc could
  not be started.  Nothing in EventLog either.

 Ah ok, I see. It should of course write something into the EventLog.

  The frustrating thing at the moment is that using tincctl.exe stop not
  only stops the service but deletes the service from the registry.  It
  recreates it when tincctl.exe start is called, but it prevents
  production use.  Is there a way to make it so that the service is not
  deleted when stopped?  And when init, it checks if the service exists
  and timeout confirms that you want to overwrite the old service entry?

 What is the problem with the stop and start commands removing/adding the
 service from the registry? That is exactly what tinc 1.0.x does as well.
 You
 can stop/start the service without altering the registry from the service
 control panel, I believe.

 Tincctl init never starts or stops a daemon, so it will also not change an
 existing service entry. The tincctl start command (or invoking tincd
 directly)
 will also never overwrite an existing entry.

 --
 Met vriendelijke groet / with kind regards,
  Guus Sliepen g...@tinc-vpn.org

 ___
 tinc mailing list
 tinc@tinc-vpn.org
 http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc


Yes, more logging.

i will try the new version this week.  The tinc service would start up and
i could connect albeit with a great deal of latency.  But when stopped, the
service would get disabled and then deleted.   i look forward to 1.1pre5
this week.
___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Re: LAN discovery issue

[Rob Townley]

If for some reason, MaxTimeout does not work:

A win32 sleep command could also be used.
At cmd.exe, set /?
i believe set or choice can take input but times out after a specified
amount of time.
tinc-up could sleep for 30 seconds or so.


On Sun, Jan 20, 2013 at 9:39 AM, Guus Sliepen g...@tinc-vpn.org wrote:

 On Sat, Jan 19, 2013 at 10:06:20PM +0100, Markus Teufelberger wrote:

   What you can do is add another Address statement to hosts/Alpha on
 Gamma, with
   Gamma's LAN IP address (just like you did with Beta). Make sure it is
 above the
   other Address statement. That way, tinc will first try to connect via
 the LAN
   IP. If that doesn't work, it will try resolving the DynDNS hostname.
 
  Work perfectly on LAN now, BUT I seem now to have that problem the
  other way round:
  It seems to try quite often via the LAN IP and rather forwards the
  packets (even though I did remove the IndirectData stuff from all
  config files) though Alpha when connecting to the VPN from the
  internet from Gamma (who ConnetsTo Alpha) and pinging Beta... Even
  after a minute or so, the -d5 log just contains the following 5 lines:
 
  Sending packet of 74 bytes to Alpha ([WAN-IP] port YYY)
  Received packet of 74 bytes from Alpha ([WAN-IP] port YYY)
  Writing packet of 74 bytes to Windows tap device
  Sending packet of 74 bytes to Beta (192.168.x.x port XXX)
  Packet for Beta (192.168.x.x port XXX) larger than minimum MTU, for
  warding via Alpha
 
  Also in the beginning, there was the following error for some time
  periodically (went away though after half a minute or so):
  Error sending packet to Alpha ([WAN-IP] port YYY): (10014) The s
  ystem detected an invalid pointer address in attempting to use a pointer
 argumen
  t in a call.

 Hm, half a minute corresponds with the maximum time PMTU discovery can
 take. So
 somehow that fails (maybe it is indeed an invalid pointer, although it
 could
 also be something completely different), and that means tinc thinks direct
 communication with Alpha is not possible, so it will indeed forward
 packets via
 another node.

   Contrary to what the manual says, multicast IP traffic is also
 supported in
   router mode, so you don't need to use switch mode for D-LAN.
 
  I receive the following error with -d5 when running D-LAN (D-LAN is
  bound to the tinc interface):
  Cannot route packet from Gamma (MYSELF): unknown IPv4 destination
  address: 10.xx.xx.255

 That's not a multicast address, but a broadcast address. I see in the FAQ
 on
 D-LAN's website that they use 236.13.43.24 as the multicast address. My
 guess
 is that those multicast packets are not being sent to tinc's interface by
 your
 operating system. I have no idea how multicast actually works on Windows.

  My guess is that I somehow need to tell tinc that I am actually trying
  to run a 10.x.x.0/24 network, but on the other hand I only use static
  IPs (10.x.x.x/32) in my config files.

 In this case it might indeed be better to run tinc in switch mode.

  That all aside, I ran into a different issue - from the manual:
  ‘ALRM’
  Forces tinc to try to connect to all uplinks immediately. Usually tinc
  attempts to do this itself, but increases the time it waits between
  the attempts each time it failed, and if tinc didn’t succeed to
  connect to an uplink the first time after it started, it defaults to
  the maximum time of 15 minutes.

 Uhm, that is strange, it should not go to the maximum time immediately...
  I
 cannot reproduce this behaviour myself on Linux, but I'll try it on Windows
 later.

  On a laptop it is (in my case) quite common that connecting to the
  wireless network takes a few seconds after booting - tinc seems to be
  faster and then is on a strike for 15 minutes (there's no way I know
  of to send a signal to a service on Windows). Please make that maximum
  value configurable or make it fail a bit more gracefully (first wait 2
  seconds, then 4, then 8 or whatever you do to increase the wait time)
  instead of going directly to the max. value.

 You can change the maximum time with the MaxTimeout configuration variable.
 Also, tinc 1.1 doesn't rely on signals anymore, you will be able to tell
 tinc
 to immediately try reconnecting using the tincctl program.

  I tried to set up a
  backup program to run after boot - but then the tinc interface doesn't
  come up for 15 minutes after booting, which screws the whole process
  and confuses the hell out of that poor program too... ;-)

 For now just add something like MaxTimeout = 30 to tinc.conf :)

 --
 Met vriendelijke groet / with kind regards,
  Guus Sliepen g...@tinc-vpn.org

 ___
 tinc mailing list
 tinc@tinc-vpn.org
 http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc


___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Re: tinc 1.1pre4 on Win7x64 coughs on #comment in first line of host file

[Rob Townley]

On Mon, Jan 14, 2013 at 4:23 AM, Guus Sliepen g...@tinc-vpn.org wrote:
 On Sun, Jan 13, 2013 at 05:03:28PM -0600, Rob Townley wrote:

 I have the habit of putting the name of the host within the host file
 as a comment usually on the first line.  Helps when files are renamed
 and tracking.  The new version exports  Name = victor and so the old
 comment style is not necessary.  I would think the new version should
 still simply ignore lines that begin with the '#' character.

 For example, a normal host file named victor that also contains the
 following comment line:
 #victor

 tincctl --net=mynet import victor

 fails with Junk at the beginning of the input, ignoring.
 The import hangs and does not seem to work.

 The problem is not the comment at the start of the file, it's that the
import
 command does not take another argument. It expects the input on stdin.
So, you
 should write instead:

 tincctl --net=mynet import  victor

 Also, the import command only properly works for data generated by the
export
 command. If you feed it a raw host config file, it will not work. I'll
clarify
 the manual and have it print an error message when you add arguments after
 import or export.

 --
 Met vriendelijke groet / with kind regards,
  Guus Sliepen g...@tinc-vpn.org

 ___
 tinc mailing list
 tinc@tinc-vpn.org
 http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc


i thought i tested it both ways, but i probably did not.  i am very pleased
with the ssh examples of exporting and importing.  Slick, but i only have
one node on 1.1pre4.  i had already unix2dos my host files, so not sure
when i will test again.  Will non-root users be able to execute tincctl.exe
import?

It is worth repeating
http://www.tinc-vpn.org/documentation-1.1/tinc_4.html#How-to-configure
*
If you are the owner of bar yourself, and you have SSH access to that
computer, you can also swap the host configuration files using the
following commands:

tincctl -n netname export | ssh bar.example.org tincctl -n netname import
ssh bar.example.org tincctl -n netname export | tincctl -n netname import

*
___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

tinc 1.1pre4 on Win7x64 coughs on #comment in first line of host file

[Rob Townley]

I have the habit of putting the name of the host within the host file
as a comment usually on the first line.  Helps when files are renamed
and tracking.  The new version exports  Name = victor and so the old
comment style is not necessary.  I would think the new version should
still simply ignore lines that begin with the '#' character.

For example, a normal host file named victor that also contains the
following comment line:
#victor

tincctl --net=mynet import victor

fails with Junk at the beginning of the input, ignoring.
The import hangs and does not seem to work.
___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

tinc 1.1pre4 on Win7x64 --mlock prevents service from starting

[Rob Townley]

c:\APPS\TINC\tincd.exe --mlock --net=mynet --config=C:\APPS\tinc\mynet

Without --mlock, the service starts OK.
With --mlock, the service fails to start.
___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

tinc 1.1pre4 on Win7x64 unusually high latency

[Rob Townley]

ping times to ConnectTo machine are often over a second or at least
300 milliseconds.  Hundreds or thousands of times slower than other
nodes from same physical location.
___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

tinc 1.1pre4 Win7x64 import does not recognize Unix EOL

[Rob Townley]

___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Re: Android GUI for tinc

[Rob Townley]

FYI,

AirDroid app allows you to copy files over your LAN using your desktop PC.

Do not remember at the moment if permissions can be changed from AirDroid.
On Nov 30, 2012 6:38 PM, albi a...@life.de wrote:

 Am 01.12.2012 00:18, schrieb Vil Brekin:
  # Use sh to execute all configuration scripts
  ScriptsInterpreter = /system/bin/sh

 Was the same problem.

 I moved tinc folder now to /data/tinc and made /data rx for world. Then
 i changed permissions to 775.
 After some debugging with sshdroid and ssh connection to phone it works
 now fine, even with default gate via tinc vpn.
 Thanks for the help!


 Here the config for all who want to do the same:

 tinc.conf:
 Name = skate
 ConnectTo = vps10
 Device = /dev/tun


 tinc-up:
 #!/system/bin/sh
 ifconfig $INTERFACE 10.11.12.13 netmask 255.255.255.0

 # from here only for default gate via tinc
 ORIGINAL_GATEWAY=`ip route show | grep ^default | cut -d ' ' -f 2-5`
 VPN_GATEWAY=1.2.3.4
 ip route add $VPN_GATEWAY $ORIGINAL_GATEWAY
 ip route add 0.0.0.0/1dev $INTERFACE
 ip route add 128.0.0.0/1  dev $INTERFACE


 Have fun!


 ALBI...

 ___
 tinc mailing list
 tinc@tinc-vpn.org
 http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Re: [olug] TINC

[Rob Townley]

IPsec Pre Shared Key for enterprise wireless is worse than PPTP according
to https://www.cloudcracker.com/blog/2012/07/29/cracking-ms-chap-v2/  .
Make sure IPsec is used with certificates instead.

tinc is an educational project sponsored by a university aiming to grow
awareness of encryption over the public internet.  It does not have a
marketing department.  Criticism is welcome.Think of Schneier *Secrecy
and security aren't the same, even though it may seem that way. Only bad
security relies on secrecy; good security works even if all the details of
it are public.* https://en.wikipedia.org/wiki/Bruce_Schneier#cite_note-20
tinc like much security software can have   'Encryption = 'none', a setup
with no security at all to have a gaming extranet or just plain EOIP.
For mainstream use, security software needs to be secure even when Grandma
installs it.  Hamachi does that but is not as flexible as tinc.

Peter Gutman tore apart many different VPNs in his assessment, but still
ranked tinc the best of those in his comparison.   The only real criticism
he had was that it still used Defense Encryption Standard DES keys just
like a Win2003 based ActiveDirectory would use and MSCHAPv2 for WPA2 uses
till this day.   We are not talking triple DES, just plain DES.  However
tinc didn't use MSCHAP, it uses RSA to establish the session keys.  tinc
also used one of the other AES contenders  BlowFish  since 2000.  BlowFish
has not been broken.   It was not till Win2003R2 that MS upgraded to a
little better arc4 keys.  The fact is there are many MS ActiveDirectory
domains out there that still use DES to this day.  Why? Not only because of
MSCHAPv2 for WPA2 but much more worrisome because even if all your ADS
servers are Win2008R2, they can still run in Win2000 ADS compatibility mode
which would mean DES keys.   DES was broken in the 90's and now the
CloudCracker can break open DES traffic in 24hours.

i have learned much more by using this open source project than other VPNs
- open source or not.



On Tue, Nov 13, 2012 at 6:04 PM, Christopher Cashell topher-o...@zyp.orgwrote:

 On Tue, Nov 13, 2012 at 5:04 PM, Sam Flint harmonicn...@gmail.com wrote:
  Does anyone have experience with tinc vpn?

 It was not looked on particularly favorably in a comparison some years
 ago by well known cryptographer Peter Gutmann:
 http://www.cs.auckland.ac.nz/~pgut001/pubs/linux_vpn.txt

 Admittedly, that review was from 2003.  However, one of the things
 that post discusses in length, and does a great job of illustrating,
 is that security software like VPNs are difficult to get right, and
 very easy to get wrong.

 OpenVPN seems to have emerged as the closest thing to a de facto
 standard for non-IPsec.  Personally, I would stick with either IPsec
 or OpenVPN for any VPN needs unless I had a *really* good reason to
 use something else.

 Personal experience with IPsec and OpenVPN would leave me leaning
 towards OpenVPN for everything that didn't require compatibility with
 non-OpenVPN connections (appliances, routers/firewalls, other
 third-party situations), in which case I'd use IPsec.

  --
  Sam Flint

 --
 Christopher
 ___
 OLUG mailing list
 o...@olug.org
 https://lists.olug.org/mailman/listinfo/olug

___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

client slow or never reconnects to different second address of server.

[Rob Townley]

i have roaming TabletPCs that i would like to connect within the LAN
and outside the firewall.
The server is our main firewall and has two addresses, a 70.168.x.y
public IP and a private 192.168.2.1 both listening at the same high
port number.
The tinc clients connect fine when connecting from home or elsewhere
outside the LAN.
But when behind the firewall on the private LAN, the TabletPCs get a
192.168.2.Y address but still try to use the 70.168.x.y public IP
instead of talking directly to 192.168.2.1.
Is there some setting to increase the aggressiveness of checking for
connecting to the 192.168.2.1 ADDRESS?
What else should i do?
___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Re: Can I use it to FIX my internet connection?

[Rob Townley]

Does anyone have a script for a travelling laptop that will use
numerous dhcp assigned default gateways from numerous locations?

i could script the above, but then when their machine connects at
another coffee shop, the default gateway would be overwritten with the
coffee shop default gateway.

Can /etc/tinc/NETNAME/subnet-up  be used to detect a change in the
default gateway?
___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Re: Weird behaviour between Windows Vista Windows 7 VPN - can anyone help?

[Rob Townley]

 I will try to regenerate the security keys - hopefully that will resolve the
 'Bogus data' message.

Remember to redistribute the hosts files after changing the keys.
___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

tinc vpn interface specific dns under Linux

[Rob Townley]

Window allows one to specify a DNS domain name and DNS server for a
particular interface.
So all DNS queries of your tinc interface are sent to a particular dns server.
For instance windows tinc clients can use a particular dns server on a
private LAN available only to clients inside that NAT or tinc clients.

NetworkManager allows you to specify the same, but the tinc interface
does not show up in NetworkManager.

/usr/share/doc/initscripts*/sysconfig.txt
shows that ifcfg-ethX files allow you to specify particular DNS
servers for that interface
(sorta anyway because the docs say it just gets added to /etc/resolv.conf).
So adding   DNS1=ip of my DNS server available over tinc net to
/etc/sysconfig/network-scripts/ifcfg-eth0
may get me somewhere to this goal.
But how can one add DNS1 to the tinc interface instance or at least
/dev/net/tun?
Can i just create a /etc/sysconfig/network-scripts/ifcfg-tincvpn file
and put the DNS entries in there?
Is there something i can do with tinc-up to set DNS for the tinc interface?


i am not going to add individual hosts to /etc/hosts.

man host.conf and man resolv.conf do not have the answer.

i thought for sure /etc/networks would be the solution, but 'man
networks' says that only class A, B, C networks are supported.  CIDR
notation is not.
___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Re: tinc bridge inner amazon ec2 local segments

[Rob Townley]

Not sure if you got this to work

 Ok, it looks like the tinc-up script worked fine. Can you show me the output 
 of
 route -n on both VPN servers?

What is the subnet of your native interface - 10.0.0.0/8?
While learning, i would change the host file SUBNET mask for host vpn1
to 10.0.101.10/32.
i know that is not what you want, but do host-to-host first, then
host-to-network.


host 1 tinc-up may need:
ip route add 10.0.101.0/24 dev $INTERFACE via 10.0.101.10

host 2 tinc-up may need:
ip route add 10.0.101.0/24 dev $INTERFACE via 10.0.101.12
___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Re: MTU probes fail on reconnect

[Rob Townley]

On Sun, Jan 2, 2011 at 7:49 AM, Guus Sliepen g...@tinc-vpn.org wrote:
 On Sun, Jan 02, 2011 at 07:43:53AM -0600, Rob Townley wrote:

 It would be nice for each tinc node to be forced to log the current PMTU.

 It's in the log output if you send tinc the USR2 signal.

not on windows
___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Re: MTU probes fail on reconnect

[Rob Townley]

It would be nice for each tinc node to be forced to log the current PMTU.
___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Re: PMTUDiscovery vs ClampMSS

[Rob Townley]

Liked the simplification of MSS bytes = MTU bytes +  IP header bytes.

With TSO turned on in hardware (find out by ethtool -k eth0) then
latency skyrocketed.

On 12/18/10, Guus Sliepen g...@tinc-vpn.org wrote:
 On Fri, Dec 17, 2010 at 01:17:22AM -0600, Rob Townley wrote:

 An OpenVPN user on the vyatta.org forums had the problems with
 excessively slow connections.

 He found that either lowering the MTU to about one-third helped:
  router:~# ifconfig vtun0 mtu 516

 Ugh. I cannot recommend setting the MTU so low.

 But also found turning OFF TCP Segmentation Offload (TSO) on the
 server speeded things up just as well.  As i understand it, the word
 segment in this context refers to Maximum Segment Size which is broken
 down to ethernet MTU frame size (usually 1500bytes).

 Almost correct. MSS is the same as MTU, minus the IP header. TSO means that
 if
 you send lots of data through a TCP connection at once, the hardware will
 take
 care of splitting the data up in MSS sized chuncks, and will generate a
 header
 for all of them.

 The problem with these hardware features is that the NIC hardware is often
 slower than your CPU.

 So if you have TSO enabled on your NICs but the tun device doesn't support
 TSO, couldn't that create a problem?

 That should not be a problem. Segmentation is only done once, on the first
 outgoing interface. If the OpenVPN connection was faster with TSO turned
 off,
 then OpenVPN was tunneling over TCP. That is slow in itself.

 --
 Met vriendelijke groet / with kind regards,
  Guus Sliepen g...@tinc-vpn.org

___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Re: PMTUDiscovery and ClampMSS with mixed tincd versions

[Rob Townley]

On Tue, Dec 14, 2010 at 4:40 AM, ZioPRoTo (Saverio Proto)
ziopr...@gmail.com wrote:
 I also understand that the two settings are by default yes if not
 explictly set to no in the config file.

A nice feature would be able to have tincd dump all the configuration
settings for the running process, its host file, and its ConnectTo
host files.
An enterprise nice feature would be to issue a command to the network
and have every node dump all the above configuration parameters and
send them to a central node.
___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Re: PMTUDiscovery vs ClampMSS

[Rob Townley]

On Mon, Dec 13, 2010 at 2:57 PM, Guus Sliepen g...@tinc-vpn.org wrote:
 On Mon, Dec 13, 2010 at 02:06:43PM -0600, Rob Townley wrote:

  Currently, i have nodes with PMTUDiscovery =yes and ClampMSS = yes.

An OpenVPN user on the vyatta.org forums had the problems with
excessively slow connections.

He found that either lowering the MTU to about one-third helped:
 router:~# ifconfig vtun0 mtu 516

But also found turning OFF TCP Segmentation Offload (TSO) on the
server speeded things up just as well.  As i understand it, the word
segment in this context refers to Maximum Segment Size which is broken
down to ethernet MTU frame size (usually 1500bytes).  So if you have
TSO enabled on your NICs but the tun device doesn't support TSO,
couldn't that create a problem?

 ethtool -K eth0 tso off


i have not tested it, but hope to..

echo ethtool -K eth0 tso off  /etc/rc.local


DATA  SEGMENTS   PACKETS   FRAMESBITS
Dont  Send  Paul   For  Beer

Original posting on vyatta.org:
http://vyatta.org/forum/viewtopic.php?t=4419
___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Re: PMTUDiscovery vs ClampMSS

[Rob Townley]

On Mon, Dec 13, 2010 at 2:33 AM, Guus Sliepen g...@tinc-vpn.org wrote:
 On Sun, Dec 12, 2010 at 07:11:30PM -0600, Rob Townley wrote:

 Currently, i have nodes with PMTUDiscovery =yes and ClampMSS = yes.
 When the server does not receive a PMTU request back from one of the
 clients even when the packet size is very small (say 164), then it
 reverts to TCP.

 That means that communication with the client via UDP is not possible.

The log files from the clients indicate the MTU sizes are being sent
back.  i need ethereal or tcpdump or something.
These same machines in the same network going through a different tinc
server will often get sub millisecond response times, but sometimes
get as slow as 1 second of latency for each and every ping.  So i have
a cron job on that tinc server that restarts tinc daemon every hour.
i noticed one difference is that the broadcast address is not set on
the tcp only non-working tinc ip server.


 Should i turn off PMTUDiscovery or should it be ok to leave on?

 You should leave it on. The PMTUDiscovery packets are just regular UDP 
 packets,
 if they fail other UDP packets will not be received either. If you would
 disable PMTUDiscovery, tinc would not fall back to TCP and no communication
 with the client would be possible.

 It takes a very long time to do simple pings (1 second or so), so i
 wonder what else i can do?

 Can you check whether non-VPN traffic from the client to the server is slow as
 well, or maybe if there is a high level of packet loss?

i have 3 public internet IP addresses sitting behind a single cable
modem.  Cable Modem goes to a switch and from the switch to 3 NAT
devices.  One firewall is dedicated to wireless laptops.  The wireless
laptops can ping google.com in 20ms, but will often require 1000ms -
4000ms to ping the tinc server hosted on the vyatta box.  i wonder if
by the time the laptop responds with an acceptable MTU, the server has
already lowered the MTU that it does not read the entire packet.

Need debugging level specifically for MTU / MSS size.  i was too tired
and cold to figure out how to grep for either MSS or MTU or TCP.

One thing i have to say is be careful with netsh command in windows.
On both WinXPSP3 and Win2008R2, the firewall can be turned off as a
matter of domain policy, but firewall deny entries still show in the
c:\windows\pfirewall.log.When windows systems boot up, they
determine if the machine is part of a trusted or untrusted (aka
public) network.  The firewall can be on and off depending on which
trust level it gives to the network.


 --
 Met vriendelijke groet / with kind regards,
     Guus Sliepen g...@tinc-vpn.org

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)

 iEYEARECAAYFAk0F2mAACgkQAxLow12M2nvTPACfdi/peZjMPIXKWugBub7kXcUt
 dhAAnjKALHNgUlNLFvBzUUtlBMdhSqNW
 =kqcv
 -END PGP SIGNATURE-

 ___
 tinc mailing list
 tinc@tinc-vpn.org
 http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc


___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Re: Is there a way to retreive info from tinc?

[Rob Townley]

On Mon, Dec 13, 2010 at 11:04 AM, Guus Sliepen g...@tinc-vpn.org wrote:
 On Mon, Dec 13, 2010 at 02:41:29PM +0100, ZioPRoTo (Saverio Proto) wrote:

  Is there way to request status info from a running tinc daemon?
  Like retreive a list of subnets the tinc network is aware of?
  Or list active nodes etc..

 As far as I know you can send signals to a running tincd to gather
 information about the running tincd process.
 [...]
 maybe some core developer can extend my answer to this question.

 That is correct. Send the USR2 signal and tinc will dump a list of Nodes, 
 Edges
 and Subnets to the syslog. The list of Subnets is similar to a routing table,
 sorted in the same way as the route command prints routes, so the first
 matching Subnet starting from the top will be used to decide which node a
 packet to send to. However, tinc lists all known Subnets, even those from 
 nodes
 who might not be reachable. If a node is not reachable, tinc will skip its
 Subnets when trying to find a match.

 Tinc 1.1 has a command line utility to get a dump of all the Subnets more
 easily. There is also an experimental GUI. It's not released yet, but it works
 and you can get it from the git repository:

 git clone -b 1.1 http://tinc-vpn.org/git/tinc

 or if you don't want to use git and just want a tarball download:

 http://tinc-vpn.org/git/browse?p=tinc;a=snapshot;h=refs/heads/1.1;sf=tgz

 --
 Met vriendelijke groet / with kind regards,
     Guus Sliepen g...@tinc-vpn.org

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)

 iEYEARECAAYFAk0GUgsACgkQAxLow12M2nvkVgCeIcT6tBRpdwhO8TJq0/H2mpSP
 Zo0AnRduIMpb4iGYHY9QGK1C1evHVJ88
 =mE1k
 -END PGP SIGNATURE-

 ___
 tinc mailing list
 tinc@tinc-vpn.org
 http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc



Guus, does the new utility work on windows clients?
If not, is there someway to get that same information on Windows
clients?  As you know, the signalling capability recommended above
does not work on windows.   Is that a limit of mingw?
___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Re: Is there a way to retreive info from tinc?

[Rob Townley]

 (Please trim the quoted part to only that which you are replying to, it 
 reduces
 wear on the scrollbuttons.)

Sorry Guus.  gmail's Show Quoted Text feature helps me forget
reformatting etiquette  will try to remember.
___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

tinc on a vyatta nat firewall

[Rob Townley]

i have tinc 1.0.13 installed on a vyatta firewall.
Latency is very high, anybody have recommendations on how to setup
vyatta to be a tinc node?

I poked holes in the firewall and set up nat translation, but i wonder
if there is a much better way?
Someway to use gre?
___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Re: MINGW Help

[Rob Townley]

On Sun, Dec 5, 2010 at 3:48 PM, Sabbiolina sabbiol...@gmail.com wrote:
 Problem with openssl:

 I followed the tutorial, with installing a debian netinstall.



 dhcppc1:~/mingw/openssl-0.9.8g# mingw make
 making all in crypto...
 make[1]: Entering directory `/root/mingw/openssl-0.9.8g/crypto'
 ( echo #ifndef MK1MF_BUILD; \
     echo '  /* auto-generated by crypto/Makefile for crypto/cversion.c
 */'; \
     echo '  #define CFLAGS gcc -DOPENSSL_THREADS  -DDSO_WIN32
 -mno-cygwin -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486 -Wall
 -D_WIN32_WINNT=0x333 -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2
 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM'; \
     echo '  #define PLATFORM mingw'; \
     echo   #define DATE \`LC_ALL=C LC_TIME=C date`\; \
     echo '#endif' ) buildinf.h
 gcc -I. -I.. -I../include -DOPENSSL_THREADS  -DDSO_WIN32 -mno-cygwin
 -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486 -Wall -D_WIN32_WINNT=0x333
 -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM
 -DRMD160_ASM -DAES_ASM   -c -o cryptlib.o cryptlib.c
 cc1: error: unrecognized command line option -mno-cygwin
 make[1]: *** [cryptlib.o] Error 1
 make[1]: Leaving directory `/root/mingw/openssl-0.9.8g/crypto'
 make: *** [build_crypto] Error 1
 dhcppc1:~/mingw/openssl-0.9.8g#


 I saw in the tutorial:

 cd $HOME/mingw/openssl-0.9.8k


 but on disk:

 /root/mingw/openssl-0.9.8g


 It could be the problem?



 ___
 tinc mailing list
 tinc@tinc-vpn.org
 http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc



From Feb 12, there was a posting about setting up on Ubuntu.  i used
Fedora, so don't know how much this helps:
sudo apt-get build-dep tinc

openssl-0.9.8g is over 3 years old.  k is over a year old.  i would
get OpenSSL 0.9.8q directly from openssl.org
___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Re: What is a minimum MTU?

[Rob Townley]

On Wed, Oct 13, 2010 at 10:25 AM, Guus Sliepen g...@tinc-vpn.org wrote:
 On Tue, Oct 12, 2010 at 05:44:47PM -0500, Rob Townley wrote:

 I know MTU is Maximum Transmission Unit, but what is a minimum
 Maximum Transmission Unit?
 Shows up in tinc.log as Packet for PC5 (ip.x.y.z port 655) larger
 than minimum MTU, forwarding via TCP.

 Tinc tries to discover the actual MTU of the path between two nodes by sending
 probe packets of various sizes.  It can detect a lower bound and upper bound
 for the true MTU. The lower bound (minimum MTU) is the biggest probe that has
 been succesfully sent and received back, the upper bound (maximum MTU) is
 decreased whenever a RFC compliant router sends an ICMP Packet Too Big message
 in response to a probe that is larger than the true MTU.

i am not sure i understand, i would have thought there is minimum
packet size as there is a minimum ethernet size.

 Tinc will only send UDP packets that are smaller than the minimum MTU to the
 destination, because there is no guarantee that larger packets will arrive.
 When the packet is bigger than the maximum MTU, it will either send its own
 ICMP Packet Too Big messages, or fragment the packet (only for IPv4 packets
 without DF bit set). For packets that are within the minimum and maximum MTU,
 it will forward packets via TCP.
Again, this just seems backwards, i will have to research more.


 If UDP communication is not possible, no probes will succeed, so the minimum
 MTU will be 0 and the maximum MTU will be 1514 by default, and all packets are
 thus forwarded via TCP, as it should.

 Tinc keeps sending probes after the real MTU has been determined (by default
 once a minute) to check whether UDP communication is still possible.

 Ping times between tinc nodes are outrageously slow at times ...
 greater than 1 second.

Sometimes, it is even 5 seconds.  This may have come across as too
negative.  i think tinc is cool and enjoy it, i am frustrated i have
not figured it out yet.


 I understand. It could be that temporary disruptions of the network that 
 caused
 the MTU probes to fail, resulting in tinc falling back to TCP.  It should
 normally try to reestablish UDP connections after an hour.

Is there some way to ask tinc to reestablish UDP connections much more
frequently?
The Tablets (including wireless card) may go into a low power mode on
battery, but the network itself is never down.



 I do not know why it would be so slow. But others have experienced such
 behaviour in the past as well. In any case, could you run tincd -n netname
 -kUSR2 on the tinc server and send me the results?

Attached are too files, one is when it seems normal.  The other is
probably when the multisecond echo requests occur.


BUGS-Jitter.log
Description: Binary data


BUGS-Jitter-pmtu.log
Description: Binary data
___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Re: What is a minimum MTU?

[Rob Townley]

On Wed, Oct 13, 2010 at 2:21 PM, Rob Townley rob.town...@gmail.com wrote:
 On Wed, Oct 13, 2010 at 10:25 AM, Guus Sliepen g...@tinc-vpn.org wrote:
 On Tue, Oct 12, 2010 at 05:44:47PM -0500, Rob Townley wrote:

 I know MTU is Maximum Transmission Unit, but what is a minimum
 Maximum Transmission Unit?
 Shows up in tinc.log as Packet for PC5 (ip.x.y.z port 655) larger
 than minimum MTU, forwarding via TCP.

 Tinc tries to discover the actual MTU of the path between two nodes by 
 sending
 probe packets of various sizes.  It can detect a lower bound and upper bound
 for the true MTU. The lower bound (minimum MTU) is the biggest probe that has
 been succesfully sent and received back, the upper bound (maximum MTU) is
 decreased whenever a RFC compliant router sends an ICMP Packet Too Big 
 message
 in response to a probe that is larger than the true MTU.

So maximum MTU is the theoretical maximum packet size which may not
include all headers needed along the route.
The following terminology could substitute for minimum MTU:
  - true MTU
  - empirical MTU
  - actual MTU
  - known MTU
  - tested MTU



 Tinc will only send UDP packets that are smaller than the minimum MTU to the
 destination, because there is no guarantee that larger packets will arrive.

Makes perfect sense.



 If UDP communication is not possible, no probes will succeed, so the minimum
 MTU will be 0 and the maximum MTU will be 1514 by default, and all packets 
 are
 thus forwarded via TCP, as it should.
i notice MYSELF (the Linux sever) has a minimum MTU of 0 at times and
will watch for
a corresponding increase in latency.  Not sure why it would change,
but it does.


 Tinc keeps sending probes after the real MTU has been determined (by default
 once a minute) to check whether UDP communication is still possible.

If those are the PING PONG probes, i do not see them once a minute.
What setting is determines the 1 minute interval?



 the MTU probes to fail, resulting in tinc falling back to TCP.  It should
 normally try to reestablish UDP connections after an hour.

 Is there some way to ask tinc to reestablish UDP connections much more
 frequently?
 The Tablets (including wireless card) may go into a low power mode on
 battery, but the network itself is never down.


Guus, after printing out your email and reading while on walk outside
in beautiful weather here in Omaha, NE, i realized it made perfect
sense and that you wrote it extremely well.  Thank You.
___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

What is a minimum MTU?

[Rob Townley]

I know MTU is Maximum Transmission Unit, but what is a minimum
Maximum Transmission Unit?
Shows up in tinc.log as Packet for PC5 (ip.x.y.z port 655) larger
than minimum MTU, forwarding via TCP.

Ping times between tinc nodes are outrageously slow at times ...
greater than 1 second.
Othertimes, the same link will be 1ms.  For entire weekends, i could
ping from all 3 laptops out the wireless router into a switch into
another NAT to the Linux tinc server to an inside node without a
dropped packet and always under 5ms.  Then for no apparent reason, it
becomes slow - extremely slow and windows takes forever to logon and
frustrations rise.


Here is the log contents during a simple ping (when in Debug 5)
usually associated (not 100%) with very long echo times about 1 second
for what essentially is a LAN.
Receiving packet of 62 bytes (tun mode)
Sending packet of 90 bytes (tun mode)
Packet for PC5 (ip.x.y.z port 655) larger than minimum MTU, forwarding via TCP


tinc 1.13 on windows clients to tinc 1.13 on Linux server behind a NAT.

So essentially the Tablets require (at times) more than 20x the time
for an echo request to a local LAN node than to www.google.com.
Google is 40ms, the local node is 800ms - 5000ms.
___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Re: Tinc performance on a Dir-300

[Rob Townley]

On Tue, Sep 21, 2010 at 7:49 AM, Clemens John clemens-j...@gmx.de wrote:
 Am Dienstag 21 September 2010, 13:51:26 schrieb ZioPRoTo (Saverio Proto):

 this will cause new TCP connections to use segments that fit your interface
 MTU.

I have had this problem too!  Can you do the same for UDP connections?
___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Re: Tinc performance on a Dir-300

[Rob Townley]

On Mon, Sep 20, 2010 at 11:27 AM, Guus Sliepen g...@tinc-vpn.org wrote:
 On Mon, Sep 20, 2010 at 04:37:03PM +0200, Clemens John wrote:

 we are using Tinc in our Freifunk Network in Oldenburg for internode
 connections over the internet. So Tinc is running on OpenWrt 10.03 on Dlink
 Dir-300 Routers.
 We all have enough internet bandwith (1,6 MB/sec and more) but we only get a
 maximum speed of ~350KB/sec between two tinc nodes because then tinc uses 99%
 of the cpu.

 Is it possible to get more Speed with tinc on this machines? I think we have
 compression and encryption already turned off so what is using the cpu?
 [...]
 If there is no way to get more speed, do you know another VPN-Solution which
 is better concerning speed? We dont need security because the network is
 completely open, but we need speed.

 Are you sure you have 1.6 MB/sec both upstream and downstream?

 You can try other VPN software, such as OpenVPN or perhaps VDE, and see if
 those are faster.  Maybe you can also try profiling tinc (either with
 valgrind's callgrind tool, or compile tinc with -pg in both CFLAGS and LDFLAGS
 so you can use gprof) to see where the bottleneck is.

 However, the Dir-300 has a MIPS processor running at 182 MHz with only 16 kB
 instruction and 16 kB data cache. That means it is not very fast, especially
 not if a packet has to go all the way to userspace to be processed by tinc and
 back.

 --
 Met vriendelijke groet / with kind regards,
     Guus Sliepen g...@tinc-vpn.org

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)

 iEYEARECAAYFAkyXi2AACgkQAxLow12M2nsYMgCeKWMubZfL1xpJrpaNEe0DKihi
 RLcAoIkxbuk0JU2SADcZ5uRNdUyvpuEI
 =3Owl
 -END PGP SIGNATURE-

 ___
 tinc mailing list
 tinc@tinc-vpn.org
 http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc




Have you tried nice?  On a full PC platform running Fedora 13 our
gateway tinc node does much much better with nice.  Even though there
were plenty of unused CPU cycles,  changing /etc/init.d/tincd by
prepending 'nice -n 20' to tincd --net=YourNetName
made performance much more consistent.  Otherwise, ping times would
range from 2milliseconds to 4000milliseconds.
___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

tinc on Vyatta?

[Rob Townley]

http://www.vyatta.org/getting-started/package-repository

indicates that vyatta can handle debian packages.
Anybody tried tinc on vyatta using prebuilt packages?  Version?

Better to somehow compile from source?
___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

[OT] mssql clients connect intermittently

[Rob Townley]

Most likely this is offtopic, hence the OT in the subject.   But i am
completely drained by this.

WinXP tinc Tablets connect wirelessly through a Linux tinc node to
network drive letters on a win2003 server just fine.

That same Win2003 server provides mssql.  The Tablets can connect and
other times they cannot.  All the while, the drive letter is mapped.

All tinc nodes are in router mode.  The winxp tablets have been
verified to receive Group Policy via the tinc network.

Licensing issue bc the mac addresses may appear the same? There is a
mssql Temporary UUID oxymoronic code that is different.

Has anyone seen problems like this before?

Again, sorry if this is too offtopic. Ethereal crashed too many times
to get an answer.
___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

tinc confused on remote nodes behind NAT?

[Rob Townley]

Something tells me this was covered recently, but i didn't find it again in
gmail.   The nodes see each other but if i have something misconfigured that
is decreasing my speed.

All my nodes are behind NATs.
i have a remote node that connects to a central node via port forwarding
from public port  to hp821 running on port 655.

remoteNode   public ip 1.2.3.4:    hp821:655

There are other nodes behind the central NAT that could be making outgoing
connections on port 655.

From the log below, the MTU port is different than the real port.  hp821
seems to be seen on multiple ports, but i wonder if it is being confused
with other nodes behind the same NAT.

# cat /usr/local/etc/tinc/eceonet/hosts/hp821
Address = 1.2.3.4 
Address = 192.168.2.228 655
#Port = 

Subnet = 5.5.5.228/32
.
.
.
some lines from tinc.log:
tincd 1.0.12 (Feb 11 2010 13:26:31)
Got PONG from hp821 (1.2.3.4 port ): 9
Sending MTU probe length 1315 to hp821 (1.2.3.4 port 655)
Sending MTU probe length 1315 to hp821 (1.2.3.4 port 655)
Sending MTU probe length 1315 to hp821 (1.2.3.4 port 655)
Got MTU probe length 1315 from hp821 (1.2.3.4 port 655)
Got MTU probe length 1315 from hp821 (1.2.3.4 port 655)
Got MTU probe length 1315 from hp821 (1.2.3.4 port 655)
Sending PING to hp821 (1.2.3.4 port ): 8
Sending 2 bytes of metadata to hp821 (1.2.3.4 port )
Flushing 2 bytes to hp821 (1.2.3.4 port )
Got PONG from hp821 (1.2.3.4 port ): 9
Sending MTU probe length 1315 to hp821 (1.2.3.4 port 655)
Sending MTU probe length 1315 to hp821 (1.2.3.4 port 655)
Sending MTU probe length 1315 to hp821 (1.2.3.4 port 655)
___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Re: No connection between nodes on same LAN

[Rob Townley]

On Sun, May 9, 2010 at 10:12 AM, Eric Estabrooks e...@urbanrage.com wrote:
 On 05/09/10 07:09, Daniel Schall wrote:
 Thanks for the diagram  -  what did you use to create it?

 The diagram was made using Microsoft Visio 2007.

 First, what version of tinc are you using on your nodes  -  is it 1.0.13?

 I am using tinc 1.013, the pre-compiled version from the website. All the
 nodes are running windows.

 A third option that might work is when doing PMTU discovery after
 exchanging
 session keys between Node1 and Node2 (via their meta connections with
 Node3 of
 course), that they also send some MTU probes to the broadcast address. The
 receiving node will update the known address of the peer when it receives
 a
 valid UDP packet, whereever it came from.

 I think the third option is easiest to implement, I don't know if it will
 work
 though. I'm a little busy this month so if you or someone else wants to
 try to
 implement it, please go ahead :)

 I am curious to implement it, but I am also rather busy.
 Currently, I am studying the sources to evaluate, what to implement:
 a) a broadcast discovery algorithm to find all nodes in the same network
 segment OR
 b) making each node send its endpoints to all other nodes to let them choose
 what endpoint they want to contact the node


 I'd guess you'll have to go with option a.  Because even though their
 ips may appear to put them on the same lan, it's not a guarantee that
 they are and you might have one or more nodes that have them same
 internal ip but are at different locations.


 Eric


 ___
 tinc mailing list
 tinc@tinc-vpn.org
 http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc



My bad, i guess i must have had extra ConnectTo statements in my
infrastructure.  I know i was getting optimal speeds and bandwidth but
not sure what i am getting now because when i ping another node, it
says it is taking as long 4 seconds, but hundreds of those multi
second echo requests are repeating.  Looks like the same ping sequence
number repeats many times.

Wouldn't IPv6 help solve this with all its link-local / site-local /
and global addresses.  Maybe that is the reason Microsoft is doing
something so similar to tinc (called Direct Access) but it requires
IPv6 (not to mention new Win2008R2 servers and Win7 workstations).
Just a thought, i havenot toyed with those crazy long addresses yet.
http://tinc-vpn.org/examples/ipv6-network/

p.s. anyone remember the open source Linux / java analogues to Visio?
Is it Dia?  Oh yes, it is Dia and the link is in the example url
above.
___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Re: No connection between nodes on same LAN

[Rob Townley]

On Sun, May 9, 2010 at 7:09 AM, Daniel Schall daniel-sch...@web.de wrote:
 Thanks for the diagram  -  what did you use to create it?

 The diagram was made using Microsoft Visio 2007.

 First, what version of tinc are you using on your nodes  -  is it 1.0.13?

 I am using tinc 1.013, the pre-compiled version from the website. All the
 nodes are running windows.

 A third option that might work is when doing PMTU discovery after
 exchanging
 session keys between Node1 and Node2 (via their meta connections with
 Node3 of
 course), that they also send some MTU probes to the broadcast address. The
 receiving node will update the known address of the peer when it receives
 a
 valid UDP packet, whereever it came from.

 I think the third option is easiest to implement, I don't know if it will
 work
 though. I'm a little busy this month so if you or someone else wants to
 try to
 implement it, please go ahead :)

 I am curious to implement it, but I am also rather busy.
 Currently, I am studying the sources to evaluate, what to implement:
 a) a broadcast discovery algorithm to find all nodes in the same network
 segment OR
 b) making each node send its endpoints to all other nodes to let them choose
 what endpoint they want to contact the node


 In the meantime, I've found out why the nodes do not communicate over their
 public NAT-addresses in some circumstances.
 It's the router that blocks UDP packets from other sources than the one the
 connection was originally established, especially packets from behind the
 router that get passed to a port at its public interface.
 That will also prevent other nodes to contact the ones behind the router,
 since the packets they send come from other endpoints than the one the
 internal node connected to in the first place.

i don't know if totally understand what you are saying but disabling
loopback on the router or disabling wireless-to-wireless connections
would be detrimental.

Even with loopback disabled, dynamic dns storing the external port
numbers would still be useful.



 Best

 Daniel

 ___
 tinc mailing list
 tinc@tinc-vpn.org
 http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Re: No connection between nodes on same LAN

[Rob Townley]

On Thu, May 6, 2010 at 8:47 AM, Daniel Schall daniel-sch...@web.de wrote:
 Hi all,



 I am currently deploying tinc as an alternative to OpenVPN.

 My setup includes a lot of nodes and some of them are sitting together
 behind the same router on the same network segment.

 (E.g. connected to the same switch.)



 I noticed, that those nodes do never talk directly to each other via their
 private ip-addresses, but instead use the NATed address they got from the
 router.

 Furthermore, some talk only over a third node, that sits outside the LAN.



 Example 



 Router1   :

 Public IP  1.1.1.1



 Local LAN behind said router

     Subnet     192.168.0.x/24



 Tinc-VPN :

     Subnet 172.25.3.0/24





 Node1

     Behind Router1

     NAT-UDP    1.1.1.1:1001

     LAN-IP 192.168.0.101

     Tinc-IP  172.25.3.101



 Node2

     Behind Router1

     NAT-UDP    1.1.1.1:1002

     LAN-IP 192.168.0.102

     Tinc-IP  172.25.3.102



 Node3

     Public IP  2.2.2.2

     Tinc-IP  172.25.3.1



 Node1 connects to Node3.

 Node2 connects to Node3.

 Both nodes can ping Node3’s tinc-ip.



 But both nodes (1  2) do not get a direct connection, they only talk via
 Node3.

 So pinging Node2 from Node1 results in a packet from Node1 to Node3 and from
 Node3 to Node2’s NATed UDP-Port at the router.

 Sometimes, It results in a “direct” packet from Node1 to Node2’s public
 UDP-Port.



 It seems to me as if tinc is unable to see, that Node1 and Node2 are sitting
 “right next to each other”, and is only considering the publicly visible UDP
 port to send data to.





 Can anyone confirm this, or do I have some misunderstanding regarding tinc?



 Additional information:

 Every Node has every other node’s public key. The host configuration is
 always the same:

 Port  = 1655

 IndirectData  = no

I assume you tried IndirectData both ways and it did not help.  Not
sure which way it should be but i would think you would need other
tinc deamons to make a direct connection to you even if they are not
in the ConnectTo list.


 PMTUDiscovery  = yes

 Compression    = 10



 Only Node3 has a Address set. This node acts kinda like a “server”, where
 all other nodes connect to.

 I plan to add more “server-like” nodes in the near future that provide a
 fixed address.



 The config file looks like this:

 Name   = NodeX

 ConnectTo = Node3 (this line is of course missing on Node3)

 Device     = {.. Windows UUID.. }

 DeviceType    = tap

 Mode   = switch



 Node adresses are assigned using a DHCP server on Node3.

Are you saying your tinc addresses are already received via DHCP?  i
am interested, please explain.






 I’d be happy hearing from you guys.





 Best regards



 Daniel Schall



 ___
 tinc mailing list
 tinc@tinc-vpn.org
 http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc


___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Use glpi-project plugin to manage tinc keys...

[Rob Townley]

Anyone found a way to use glpi-project.org, ocsinventory-ng.org, or
FusionInventory.org to manage tinc keys?  These LinMacWin projects are
used to manage an enterprise of machines.  So all the machine info is
already there and  a plugin or api call could be used to handle tinc
specifics.   GLPI can store files pertaining to a particular machine.
The drawback would be that tinc would have to be modified to lookup
keys from glpi.  Alternatively, use an ocs tinc installation package
to pull down keys for a particular group and push a key back to the
repository upon creation by tinc.
___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Fwd: Use glpi-project plugin to manage tinc keys...

[Rob Townley]

Comments at bottom:

- Forwarded message --
From: Guus Sliepen g...@tinc-vpn.org
Date: Wed, Apr 21, 2010 at 2:17 PM
Subject: Re: Use glpi-project plugin to manage tinc keys...
To: tinc@tinc-vpn.org


On Wed, Apr 21, 2010 at 08:12:49AM -0500, Rob Townley wrote:

 Anyone found a way to use glpi-project.org, ocsinventory-ng.org, or
 FusionInventory.org to manage tinc keys?

I hope you mean only the public keys? I have not heard about these projects
before today.

 These LinMacWin projects are used to manage an enterprise of machines.  So
 all the machine info is already there and  a plugin or api call could be used
 to handle tinc specifics. GLPI can store files pertaining to a particular
 machine.  The drawback would be that tinc would have to be modified to lookup
 keys from glpi.  Alternatively, use an ocs tinc installation package to pull
 down keys for a particular group and push a key back to the repository upon
 creation by tinc.

Someone who works with such projects would have to write such an installer.
Alternatively, have a look at ChaosVPN, which is a wrapper around tinc which
pulls keys and config files from a central repository:

https://wiki.hamburg.ccc.de/index.php/ChaosVPN

--
Met vriendelijke groet / with kind regards,
    Guus Sliepen g...@tinc-vpn.org

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkvPTzwACgkQAxLow12M2nvrqACfYncLhJYRJV24GneoWsEbrHF6
NVUAn1UkBoxBXqSQ5HDPfp+iG/84cX6R
=M0X4
-END PGP SIGNATURE-

___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc


Yes, Guus, private keys should never leave a machine.  This would be a
repository for public keys, dynamic port numbers and dynamic
addresses.  Network grouping is sorta already done.  The specific
architecture mode could be kept in this inventory as well, but the 3
main management items are the public key, dynamic port number, and
dynamic ip address.   Key management being the priority.

i had not heard of ChaosVPN.  i will look at that right now.  i would
think the dynamic dns route would still be the ideal way, but other
ways may not need any development.

One use for ocsinventory-ng / fusion / glpi would be to have a fleet
of disparate machines scattered across the internet that you maintain
for your family or business.  tinc would provide a way to push
packages to its virtual ips in a more secure manner.  Nobody has to
login to a vpn.  AV monitoring.  Patch revision for Adobe Flash and
Adobe Reader 


signature.asc
Description: PGP signature
___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Re: multiple addresses and multiple ports in Switch mode

[Rob Townley]

On Sat, Feb 13, 2010 at 4:09 AM, Guus Sliepen g...@tinc-vpn.org wrote:

 On Fri, Feb 12, 2010 at 12:49:52PM -0600, Rob Townley wrote:

  this node doesnt have two nics, the public address is for those
  connecting from the public side of the NAT.  As far as that tinc node
  knows, it is using 655.  i will look elsewhwere for the connection
  problem. dynamic dns of port number could help tinc get better meta
  knowledge about itself.

 Hm, what kind of NAT? If you have a Linux box with netfilter, then if tinc
 behind that NAT makes an outgoing connection first, it will probably keep
 655
 as the source port.


There would be multiple outgoing tinc nodes behind a NAT, only one could be
655.  Dynamic port numbers make me feel more secure.



  What was the name of the dns library you recommended?  Does it work
  with dnsmasq?

 I do not remember recommending a DNS library... Maybe I mentioned
 dyndns.org?


it was a programming library.  It definitely wasn't dyndns.org because i
have been using that for over a decade.



  Do you use gdb debugger?

 Yes, it's an invaluable tool.


Great.  I hope to attempt  to run some of tinc through gdb.




 --
 Met vriendelijke groet / with kind regards,
 Guus Sliepen g...@tinc-vpn.org

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)

 iEYEARECAAYFAkt2elEACgkQAxLow12M2nv8KACfd9hYRxnpTWraUlSeYfC6rtQg
 i00AmgOn0gpB0bovt86hhKHZaojljraw
 =dul/
 -END PGP SIGNATURE-

 ___
 tinc mailing list
 tinc@tinc-vpn.org
 http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc


___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

multiple addresses and multiple ports in Switch mode

[Rob Townley]

i have a switched and bridged tincd node with two addresses, each with a
different port.
Address =  37.70.156.168   28655
Address =  192.168.2.228   655

i was having trouble reliably connecting to it / thru it and noticed that a
log from a remote tincd node indicated it may have mixed up the ports.
It doesn't appear to use the 28655 port that would be needed for remote
access.  Before i changed to switch mode, the remote tincd nodes would have
28655 associated with the external ip address.


1265921476 tinc.vpn[5734]: Received packet of 92 bytes from hp821
(37.70.156.168 port 655)
1265921476 tinc.vpn[5734]: Broadcasting packet of 92 bytes from hp821
(37.70.156.168 port 655)
1265921476 tinc.vpn[5734]: Got unauthenticated packet from hp821
(37.70.156.168 port 655)
1265921476 tinc.vpn[5734]: Received packet of 60 bytes from hp821
(37.70.156.168 port 655)
1265921476 tinc.vpn[5734]: Broadcasting packet of 60 bytes from hp821
(37.70.156.168 port 655)
1265921476 tinc.vpn[5734]: Got unauthenticated packet from hp821
(37.70.156.168 port 655)
1265921476 tinc.vpn[5734]: Received packet of 92 bytes from hp821
(37.70.156.168 port 655)
___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Re: multiple addresses and multiple ports in Switch mode

[Rob Townley]

On Thu, Feb 11, 2010 at 3:06 PM, Rob Townley rob.town...@gmail.com wrote:

 i have a switched and bridged tincd node with two addresses, each with a
 different port.
 Address =  37.70.156.168   28655
 Address =  192.168.2.228   655

 i was having trouble reliably connecting to it / thru it and noticed that a
 log from a remote tincd node indicated it may have mixed up the ports.
 It doesn't appear to use the 28655 port that would be needed for remote
 access.  Before i changed to switch mode, the remote tincd nodes would have
 28655 associated with the external ip address.


 1265921476 tinc.vpn[5734]: Received packet of 92 bytes from hp821
 (37.70.156.168 port 655)
 1265921476 tinc.vpn[5734]: Broadcasting packet of 92 bytes from hp821
 (37.70.156.168 port 655)
 1265921476 tinc.vpn[5734]: Got unauthenticated packet from hp821
 (37.70.156.168 port 655)
 1265921476 tinc.vpn[5734]: Received packet of 60 bytes from hp821
 (37.70.156.168 port 655)
 1265921476 tinc.vpn[5734]: Broadcasting packet of 60 bytes from hp821
 (37.70.156.168 port 655)
 1265921476 tinc.vpn[5734]: Got unauthenticated packet from hp821
 (37.70.156.168 port 655)
 1265921476 tinc.vpn[5734]: Received packet of 92 bytes from hp821
 (37.70.156.168 port 655)



When i try to ping a remote host behind hp821:

1095 tinc.vpn[1807]: Read packet of 42 bytes from Linux tun/tap device (tap
mode)
1095 tinc.vpn[1807]: Broadcasting packet of 42 bytes from ec239dict (MYSELF)
1095 tinc.vpn[1807]: Sending packet of 42 bytes to hp821 (37.70.156.168 port
655)
1096 tinc.vpn[1807]: Read packet of 42 bytes from Linux tun/tap device (tap
mode)
1096 tinc.vpn[1807]: Broadcasting packet of 42 bytes from ec239dict (MYSELF)
1096 tinc.vpn[1807]: Sending packet of 42 bytes to hp821 (37.70.156.168 port
655)
1097 tinc.vpn[1807]: Read packet of 42 bytes from Linux tun/tap device (tap
mode)
___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Re: Configuration of hosts

[Rob Townley]

going from memory bc on my phone.

u had posted a 10./24 which is 255.255.255.0.

The debug level parameter is wrong.

  try -D5

  not -D d5

5 will be too much info so u will want a lower number.



On 1/27/10, Anon anon4...@gmail.com wrote:
 Yes, my netmask was 255.255.0.0.

 With respect to the all traffic comment, using the (horrible)
 Windows firewall does not allow
 interface by interface configuration.  So, if I allow all traffic on
 that interface, I open it up
 to all traffic on all interfaces.  At least that is the way it is in
 XPProSp3.  So, I left my
 firewall in place (which allows traffic on selected ports only, one of
 which is 655).

 I could have sworn that after my last configuration edits I stopped
 and restarted the service, but
 I guess not, because when I rebooted both machines this morning, the
 configuration shown below
 worked just fine without any modifications.

 I ran debug command line, and I guess I don't have something set
 properly, because nothing
 much shows up in the console window.  First, the console window starts with:

 C:\Program Files\tinctincd -n ivpn -D d5
 tincd 1.0.11 (Nov  1 2009 17:03:44) starting, debug level 0
 Tap reader running
 {5227-012D-4x53-8725-588x3x4174x8} (vpn) is a Windows tap device
 Ready

 At that point, the console is frozen (I can't enter any commands in
 that window), which is
 exactly what I expect.

 When I open another console window and tracert or ping to the other
 machine, it works and there
 is nothing that shows up in this console (no debug messages).  This is
 true whether MachineA is
 accessing MachineB or the other way around.  This is true whether
 access is via ping, tracert or
 a Windows program such as VNC (which works swimmingly I might add).

 The only thing that showed up on that console was the following:

 Bogus data received from unknown (192.168.1.8 port 2943)
 Old connection_t for unknown (192.168.1.8 port 2943) status 0010 still lin
 gering, deleting...

 I have no idea what would have generated that message.

 In any event, thank you for the prompt response.  As is my habit, I'm
 closing the loop by writing
 this message so that somebody else who reviews this thread will know
 of its resolution.

 

 On Tue, Jan 26, 2010 at 07:44:43PM -0800, Anon wrote:

* Anyway, I have tincd running as a service on two windows machines on the
 ** same lan.  I'm trying to establish a connection between those two
 ** computers on the vpn ip's (10.20.30.1 and 10.20.40.1).  I have confirmed
 ** that port 655 is open because each machine can ping the other on the LAN
 ** ip address (192.168.1.x) and telnet 192.168.1.x 655 works on both
 ** machines (x=4 on one machine and 8 on the other) (it responds with 0
 ** MachineB 17 on MachineA and 0 MachineA 17 on MachineB.
 **
 ** ipconfig /all confirms that each computer can see itself on the
 10.20.x.1
 ** addresses.
 **
 ** MachineA
 **
 ** Address = 192.168.1.4
 ** Subnet = 10.20.30.0/24
 **
 ** MachineB
 **
 ** Address = 192.168.1.8
 ** Subnet = 10.20.40.0/24
 *
 The netmask of the VPN interface should be 255.255.0.0. Is this the case?
 If
 you have a fireall on the Windows machines, make sure it allows all traffic
 on
 the VPN interface.  You can also start tinc with the options -d5 -D, this
 will
 not start it as a service but run in the console. You can then see what
 happens
 when you try tracert or anything else via the VPN.

 --
 Met vriendelijke groet / with kind regards,
  Guus Sliepen guus at tinc-vpn.org
 http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Re: single host with two different ports

[Rob Townley]

On Wed, Dec 23, 2009 at 1:10 PM, Guus Sliepen g...@tinc-vpn.org wrote:
 On Tue, Dec 22, 2009 at 04:54:59PM +0100, Guus Sliepen wrote:

  How does one specify two different ports in the same host file?  When
  lapops are hardwired versus when mobile on a totally different lan.
 
  address0 71.17.72.27
  address1 192.168.2.27
  port0 22755
  port1 655

 That's unfortunately not supported by tinc (yet).

 But now it is! The latest revision from git allows you to put this in a host
 config file:

 Address = 71.17.72.27 22755
 Address = 192.168.2.27 655

 Symbolic names will also work of course, Address = example.org https will
 connect to 192.0.32.10 port 443.


Great work GUUS!!!

 As for support for SRV records: unfortunately there is no easy way to do it,
 this will probably require an external library (libruli seems a candidate), 
 but
 this may bring in its own dependencies and porting issues.

 There also seem to be problems with DNS servers that drop requests for SRV
 records, which causes queries to take a long time to time out.  So one 
 wouldn't
 want to enable this by default, unless we do asynchronous DNS lookups, which
 requires substantial changes to tinc.

 So, I'll not add SRV support in tinc 1.0.x. Support for KEY records will
 probably share the same problems as for SRV records. Of course, if someone 
 else
 wants to work on it I'll be happy to merge workable patches.

i was hoping to start on it but i messed up my dev machine when trying
to make cross compiling via mingw work.  The example directions on the
website are pretty clear, but i still messed it up.   But i guess i
need to set up the machine to get the latest git repo so that i can
have multiple ports per host file.

Since the person installing tinc would also be the bind / pdns
installer, then i don't see SRV lookups as much of a problem.  It
would be a tinc net only dns server.

Thanks You Guus






 --
 Met vriendelijke groet / with kind regards,
     Guus Sliepen g...@tinc-vpn.org

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)

 iEYEARECAAYFAksyaxUACgkQAxLow12M2nsXGACeKqzdnQsmnQqmenG0Jc5cxQRr
 OaAAoJJ1525vAQ6dHamaWZmJ/vVd2F8j
 =khTw
 -END PGP SIGNATURE-

 ___
 tinc mailing list
 tinc@tinc-vpn.org
 http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc


___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Re: NSS vs OpenSSL

[Rob Townley]

On Mon, Oct 5, 2009 at 3:47 PM, Guus Sliepen g...@tinc-vpn.org wrote:
 On Mon, Oct 05, 2009 at 03:22:09PM -0500, Rob Townley wrote:

 Since Fedora is pushing NSS SSL instead of OpenSSL, has someone tested
 tinc-vpn against NSS?  As i recall, a single machine can not have
 OpenSSL and mod_nss installed at the same time anymore.  So if you
 have apache running, you _may_ have problems running tinc?  The nss
 api is supposed to mostly similar to openssl api, but there are some
 things openssl supports and somethings nss supports.

 Perhaps mod_nss conflicts with mod_ssl, but I cannot believe it would conflict
 with the OpenSSL libraries themselves.

 --
 Met vriendelijke groet / with kind regards,
     Guus Sliepen g...@tinc-vpn.org

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)

 iEYEARECAAYFAkrKW3IACgkQAxLow12M2nuXKACcC05ZcjV6Pw99HlUL9fPnZSry
 wFYAnAr0jRaND6UjVNOqofyqzjJmgIMX
 =0usf
 -END PGP SIGNATURE-

 ___
 tinc mailing list
 tinc@tinc-vpn.org
 http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc



Maybe it was more of a yum / rpm packaging dependency problem than
strict library incompatibility problem.  i haven't found where i read
the exact problem i was thinking of.  Regardless, the movement is away
from openssl to nss.

A fc developer Tomas Mraz says that OpenSSL needs redesign and another
even goes as far as to say that even the OpenSSL developers want
everyone to use nss instead.
http://www.linux-archive.org/fedora-development/227882-heads-up-openssl-0-9-8j-rawhide.html

Redhat's OpenSSH moved to nss / fipscheck.  fips=Federal Info
Processing Standard.

Here is a problem with OpenSwan on upgrade from fc10 to FC11:
http://forums.fedoraforum.org/showthread.php?t=224391
___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Re: UDP and NAT

[Rob Townley]

On Tue, Mar 31, 2009 at 7:41 PM, Keiji Costantini li...@strites.net wrote:
 At the moment I have 2 network connected in a VPN and I'm planning to
 extend this.

 Actual status:
 Network A has a public IP
 Network B is behind a provider-scale NAT.

 Actually I'm using openvpn with a single UDP connection from B to A, and
 hosts inside Network A can communicate with B.

 I tried with tinc, and I saw tinc has to go TCP-Only for accomplish
 this. This is because Tinc can't reutilize incoming UDP connections to
 reply back - has to set up an outgoing udp connection defined in config
 (thing that in a NAT-ed environment isn't possible)

 I saw in git repository that tinc fallbacks to TCP-Only if it can't
 estabilish a double-UDP connection, that is fine. But shouldn't tinc get
 the ability to use an inbound tcp connection to answer back the remote
 host? (maybe setting incoming ip and leaving port blank or something)

 --
 Keiji Costantini

 ___
 tinc mailing list
 tinc@tinc-vpn.org
 http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc


It is possible to have end-to-end UDP even when behind NATs if the
configuration were moved to dynamic dns with the port # automatically
updating a TXT record or some other hub service.
___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Re: Tinc over 3g problems?

[Rob Townley]

2009/3/26 Guus Sliepen g...@tinc-vpn.org:
 Unfortunately you have at least two NATs in the way which prevents you from
 switching to UDP, which is the only real solution to the problem.
Why do two NATs prevent UDP?
___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Windows CE / Windows Mobile 6 /

[Rob Townley]

googling site:tinc-vpn.org wince results in nothing.  Has there been
any attempt to port it to wince based devices?
___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

Re: Tinc 2.0

[Rob Townley]

Maybe I am missing something, but since each host already has a public
 private key, then why is a 3rd party needed currently?

But it is difficult to replicate the public host file to  each
machine.  That is why I would welcome a modified myDns or modified
djbdns that holds the public key for each dynamically updated
hostname.  Hamachi must use a special DNS server to accomplish this.



On 3/6/09, Albi Rebmann a...@life.de wrote:
 For tinc 2.0 certificate based authorisation will be used that allows
 clients to authenticate each other without the need for a third party to
 be online.

 Are there news about tinc 2.0?
 Release date ;)


 ALBI...


 ___
 tinc mailing list
 tinc@tinc-vpn.org
 http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

___
tinc mailing list
tinc@tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc