similar to: Multicast over Tinc

Hi, I have macosx 10.5.8 and Tunnelblick (openvpn) installed before. I have installed tinc using port and got version 1.0.11 (Jun 29 2010 15:10:51) now I have 2 problems: 1) the interface variable from the tinc.conf is not used, instead I have a tun0 interface (or tap0). 2) the tinc-up script seems to be fired too early as I get an error: ifconfig: interface /dev/tap0 does not exist when I run

The documentation is very clear that multicast over tinc does not work in router mode. Why?

Hello, Mike Bentzen has created Cydia packages for tinc. This allows you to easily install tinc on your jailbroken iOS devices (iPhone, iPad and iPod Touch). Packages for both version 1.0.21 and 1.1pre7 are available. His repository is here: http://mike.bentzen.com.au/tinc/ But you can also download them from the tinc website: http://www.tinc-vpn.org/download/ Installation should be

Hello, I have tried for days on end with no success on this, so I thought I would post it here and see if someone can help me at all. *Here's the scenario:* I have 1 PC with a Static IP/Domain (a dyndns.org account - myserver.homeip.net) connected to a router, which in turn is the gateway to the internet. It also has a static local IP (192.168.1.2). I will call this the "server"

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

[This email is either empty or too large to be displayed at this time]

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.

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. Should i turn off PMTUDiscovery or should it be ok to leave on? It takes a very long time to do simple pings (1 second or so), so i wonder what else i can do?

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. Is

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" <etienne at edechamps.fr> 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 <petr

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.

You might want to try with https://github.com/gsliepen/tinc/pull/120 - that said, this bug probably doesn't explain everything because tinc is supposed to log a message from setup_vpn_in_socket() anyway, but there's no such message in your log. In addition, I really don't see any way the "Received UDP packet from unknown source" message could be logged if the UDP socket

i created an ipset and added 8.8.8.8 to it and used the same iptables working all summer long but ?i can still ping 8.8.8.8 and do nslookup queries against it. ipset or iptables is broken. Anybody else rebooted since ipset-6.11-3.el6.i686 was installed and actually tested that IP addresses that are supposed to be blacklisted are actually blocked? ? Filed CentOS bug report 7977

Hi, So I bought a new macbook 2 days ago. I already feel like I'm going to break it somehow. I am kind of surprised that there is no kind of package management system like dpkg being used. Anyway.. Looking at the macosx tinc wiki page on tinc-vpn.org, and it seems to be somewhat incomplete. I have a few questions. I installed the tuntaposx driver and set up the machine to connect to the

Me and my son are running Tinc over 5 nodes, 3 of them got public address and we using them as server. Each node has its own Lan subnet 192.168.0.0/24. Originally we ran network on Openwrt routers with Tinc many years without any problem, but due to limited RAM on routes and change of one router to not Openwrt supported model, we decided to transfer Tinc installation on Raspberry Pi-s in LAN. In

yes, ip_forward was turned on. iptables is defaulted to ACCEPT policy on all the 3 chains. On Sat, May 14, 2016 at 1:24 AM, Guus Sliepen <guus at tinc-vpn.org> wrote: > On Sat, May 14, 2016 at 12:06:51AM +0800, Terry T wrote: > > > I have a Debian 8 64-bit machine set up as a server and apt-got the tinc > > package. I configured tinc as a bridge and everything seems

Hi, I have seen http://www.tinc-vpn.org/pipermail/tinc-devel/2010-October/000473.html and so tried out for myself to see if multicast would work in tinc using routing mode. I'm using tinc 1.0.19. My test involved sending a ping out on 224.1.1.1 (as 224.0.0.0/24 is a special case), and while I could see the traffic reaching the other tinc daemons, it never seemed to go out to the local

Anybody on here successfully get ipset iptables sets to work _after_ a reboot? My question on StackExchange http://unix.stackexchange.com/questions/149536/upon-bootup-all-iptables-are-lost-because-the-kernel-module-ip-set-is-not-loade Some of the things that need to be in place, otherwise iptables does not load: 1.) The kernel module ip_set needs to be loaded. 2.) The "sets" need to be

Hello, I downloaded tinc 1.0.9 from the site and tried to build on Fedora 10 on i386 (and also x86_64). I get, during the configure phase: checking for zlib.h... yes checking for compress2 in -lz... yes checking for lzo1x_1_compress in -llzo2... no checking for lzo1x_1_compress in -llzo... no configure: error: "lzo libraries not found." but: # rpm -qi lzo Name : lzo

http://httpd.apache.org/security/vulnerabilities_20.html states that Apache 2.0.52 is 4 years old and the latest version is 2.0.68. i am no longer a httpd expert, but at least one of the security fixes involves XSS attacks via malformed ftp commands. I also realize that redhat / centos may patch things separately from Apache and that the sysadmin has a great deal to do with how secure things