similar to: Trying to understand "redirect-gateway" option

Am Freitag, den 25.09.2015, 22:45 +0200 schrieb Marcus Schopen: > Hi Guus, > > Am Freitag, den 25.09.2015, 17:46 +0200 schrieb Marcus Schopen: > > Hmmm ... I've tried "LocalDiscovery = yes" > > in /etc/tinc/mytunnel/tinc.conf already, but that didn't help. Config on > > client A is: > > > > --------------- > > Name = clienta >

Hi, Guus I did some test regarding the points you mentioned below, and yes, you’re right, but some of points may need further adjusted: 1. The destination of IPv4 wouldn’t be changed, Yes I agree, that’s the goal and final destination for the communication. But during the path, it may be encapsulated into another packet(tunnel mode), where the outside IP header is the physical address, but the

Hi Guus, Am Freitag, den 25.09.2015, 17:46 +0200 schrieb Marcus Schopen: > Hmmm ... I've tried "LocalDiscovery = yes" > in /etc/tinc/mytunnel/tinc.conf already, but that didn't help. Config on > client A is: > > --------------- > Name = clienta > AddressFamily = ipv4 > Interface = tun0 > ConnectTo = host > PingInterval = 30 > LocalDiscovery =

On Wed, May 03, 2017 at 02:15:36PM +0800, Bright Zhao wrote: > 1. The destination of IPv4 wouldn’t be changed, Yes I agree, that’s the goal and final destination for the communication. But during the path, it may be encapsulated into another packet(tunnel mode), where the outside IP header is the physical address, but the inner destination remain unchanged, and I think Tinc encapsulates into

Hi Guus, Am Freitag, den 25.09.2015, 17:04 +0200 schrieb Guus Sliepen: > Ok, that means by default the UDP NAT timeout on the Cisco is extremely > short. > > > I check the manual of the the Cisco NAT for any TCP/UDP > > timeout settings, but there is no way to modify anything like "keeps > > TCP/UDP connections alive". > > It wouldn't be called

http://bugs.freedesktop.org/show_bug.cgi?id=15377 Summary: unable to watch DoctorWho Product: swfdec Version: unspecified Platform: Other URL: http://www.bbc.co.uk/doctorwho/s4/episodes/?episode=S4_0 1&action=iplayer&pid=b009w049&title=Partners%20In%20Crim

I found the server(1.1.1.1) didn’t receive the MTU probe from client, so I add iptables -A INPUT -p udp —port 443 -j ACCEPT. After this, I see one packet matching on the server side, and the MTU negotiation works, but when I tear down the tinc, and re-establish the tinc connection, the counter of below UDP/443 never increase, and also my other tinc nodes never add this statement on iptables, but

Hi, experts for example, the below case: You can see a lot of back and forth MTU probe packets been exchanged between tinc nodes, but it’s weird that, from the debug log, one line shows "No response to MTU probes from node1”, but it indeed received a lot of MTU probe response, and finally it get the conclusion of "Packet for node1 (1.1.1.1 port 443) larger than minimum MTU”.

Hi, Guus Thanks a lot for your suggestion, actually I did something else as below. But one question here is if I don’t add "/sbin/ifconfig myvpn 10.0.0.1 netmask 255.255.255.0”, it seems the crontab wouldn’t trigger tinc-up, and then the ip addr of myvpn wouldn’t be configured, then it will prompt the error of "Can't write to Linux tun/tap device (tun mode) /dev/net/tun:

Hi, All Due to some routing rotation purpose, I use crontab to add below info: 0 * * * * echo Subnet = 54.169.128.0/17 >> /etc/tinc/myvpn/hosts/aws_sgp 0 * * * * echo Subnet = 54.169.0.0/17 >> /etc/tinc/myvpn/hosts/aws_sgp 1 * * * * /usr/sbin/tincd -n myvpn -k 1 * * * * /usr/sbin/tincd -n myvpn --debug=3 30 * * * * sed -i '/54.169.128.0\/17/d' /etc/tinc/myvpn/hosts/aws_sgp

Hi, Can you help me explain some behaviour please? I've 2 tinc clients that happen to be on the same network and behind the same NAT gateway. They've been working for ages. Without anything changing, they've stopped. They both died, in sequence while I was actively connected to them and using an SSH session. When I check the logs of another tinc node they connect to I see

Hi, Can you help me explain some behaviour please? I've 2 tinc clients that happen to be on the same network and behind the same NAT gateway. They've been working for ages. Without anything changing, they've stopped. They both died, in sequence while I was actively connected to them and using an SSH session. When I check the logs of another tinc node they connect to I see

On Fri, May 26, 2017 at 09:30:44AM +0800, Bright Zhao wrote: > Due to some routing rotation purpose, I use crontab to add below info: > > 0 * * * * echo Subnet = 54.169.128.0/17 >> /etc/tinc/myvpn/hosts/aws_sgp > 0 * * * * echo Subnet = 54.169.0.0/17 >> /etc/tinc/myvpn/hosts/aws_sgp > 1 * * * * /usr/sbin/tincd -n myvpn -k > 1 * * * * /usr/sbin/tincd -n myvpn

Tinc team: I'm creating a vpn for my work laptop and vps and got trapped, here are my config files: on laptop: *tinc.conf Name = envy13 Device = /dev/net/tun ConnectTo = main *hosts/main Address = <my vps ext ip address> Port = 655 Subnet = 10.0.0.1/32 *hosts/envy13 Port = 655 Subnet = 10.0.0.2/32 *tinc-up #!/bin/sh ip link set myvpn up ip addr add 10.0.0.2/32 dev myvpn ip route add

Hello Drake, I am doing the same... Spanish TV to my UK home, and UK TV to my Spanish home, using Kodi and TVHeadend!!It works really well, but find that I need powerful PCs running Kodi/PVR-HTS to prevent buffering. The Tinc VPN does not filter ports - all ports are available at each end. Since you're likely to be behind NAT this is safe. The port numbers 9981 and 9982 are only needed in the

Hello, Since the present tinc documentation is not very clear about this, please explain the following: is it mandatory to include the local IP address classes in the global VPN address class? Namely, please consider the following setup (which works great in practice): 1. A tinc VPN, full mesh, with n nodes (n > 3) 2. tinc runs on the firewall, which is also the default gateway for each

quoted from http://www.tinc-vpn.org/examples/redirect-gateway/ "In fact, one does not have to set the VPN_GATEWAY variable at all. In switch mode, the gateway routes are necessary" i don't get it. it's is too short to understand. is VPN_GATEWAY set by tinc in switch mode? and why is "In switch mode, the gateway routes are necessary" mentioned here suddenly? afaik,

Hallo David, Am Mon, 6 May 2019 16:43:28 +0800 schrieb David Penn <px920906 at gmail.com>: > *tinc.conf > Name = envy13 > Device = /dev/net/tun I think, you do not need to specify "Device". (I never did) > ConnectTo = main > > *hosts/main > Address = <my vps ext ip address> > Port = 655 > Subnet = 10.0.0.1/32 > > *hosts/envy13 >

I have been delighted by tinc. Building a mesh like I need would have been horrible in OpenVPN. tinc makes it easy. I decided to share a workaround for a problem that's been vexing me. Either I'm being dumb (and can do this better with a hint) or this is something others might need. I've been moving a bunch of services from our university to Amazon (EC2). To do this, I bring

Thank you, Parke and Guus. I have now understood and got it working. Because of my beginner belief, I assumed that the tinc vpn end points needed to be on the same network. I have now discovered that the tinc vpn IP end points addresses can be arbitrary, and different! So I have set the end points to be local to the LAN they connect, and added on each tinc server a dev route to ensure