similar to: Fwd: UDP behind a NAT

On Fri, Sep 25, 2015 at 04:51:22PM +0200, Marcus Schopen wrote: > > Maybe the timeout for UDP NAT mappings is a bit short on your Cisco. Try > > adding PingInterval = 30 to the tinc.conf on those clients, perhaps that > > will help. > > Thanks for pushing me into the right direction. I disabled "TCPOnly = > yes" on the host and started with "PingInterval

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

Hi Guus, Am Freitag, den 25.09.2015, 09:36 +0200 schrieb Guus Sliepen: > On Fri, Sep 25, 2015 at 08:41:06AM +0200, Marcus Schopen wrote: > > > I'm running some tinc clients behind a NAT (masquerading, Cisco Router) > > connecting to a host outside on a public IP in a different network. The > > tunnels get unstable every few minutes and I see packet loss when > >

On Fri, Sep 25, 2015 at 08:41:06AM +0200, Marcus Schopen wrote: > I'm running some tinc clients behind a NAT (masquerading, Cisco Router) > connecting to a host outside on a public IP in a different network. The > tunnels get unstable every few minutes and I see packet loss when > pinging the clients on their internal tunnel IPs from the host side. > Before putting the tinc

On Thu, Mar 08, 2001 at 11:51:53AM +0100, Marcel Loesberg wrote: > I'm going to build a VPN and I want to use either Tinc or FreeS/WAN. > I've started building the VPN with FreeS/WAN and I find things are getting > rather complicated. > I looks like Tinc is much easier to configure but in the FAQ and in what I've > seen of the documentation so far there is no mention of

On Mon, Nov 13, 2000 at 03:19:16PM -0500, Steve Horne wrote: > First, please forgive me if the answer to my question is accessible somewhere That's all right. > I want to set up a vpn between a computer with a standard IP address (HOME), > and one hidden behind a firewall, without an externally accessible IP address > (WORK). I can reach HOME from WORK via TCP/IP but not the

I'm stuck behind a corporate NAT that I obviously have absolutely no control over. The nice thing is that the firewall rules, AFAIK, are very nice. I've had tinc running before from behind nazi firewalls with no NAT. Been fiddling with tinc for many hours, but have been SOL. The local machine is the client (has ConnectTo in the conf), and remote is the server (has Listen in the conf).

Hello again :) Thank you all for your reply's. Below are the config files of the 3 hosts. I use  tinc in router mode. I do not have a kernel mode config lines anywhere so tinc must be using the default settings here. I added the ipaddressx to subnets on hostc and this works. Traffic to that ip is now routed via hostc. But since this ipaddressx address changes often I need to resolve it

Well this has had me stumped for days now. For months I've been using tinc in TCPOnly because I always received the unknown host error when using UDP. On Monday, i set the flag IndirectData = yes in my host files, and removed the TCPOnly line. Initially, everything worked great. My throughput increased from 600KB/sec to 2MB/sec between the sites. However, I also did some testing with

Hi, I'm running some tinc clients behind a NAT (masquerading, Cisco Router) connecting to a host outside on a public IP in a different network. The tunnels get unstable every few minutes and I see packet loss when pinging the clients on their internal tunnel IPs from the host side. Before putting the tinc clients behind the NAT they were running on public IPs too (clients and host in

On 11 April 2018 at 11:30, Hans de Groot <hansg at dandy.nl> wrote: > Hello again :) > > Thank you all for your reply's. Below are the config files of the 3 hosts. > I use tinc in router mode. I do not have a kernel mode config lines > anywhere so tinc must be using the default settings here. > > I added the ipaddressx to subnets on hostc and this works. Traffic

Hi all, Has there been any progress made on using UDP, but being a NAT? To avoid the Received UDP packet from unknown source 1.2.3.4 messages? I'm using TCP as a workaround for now. Thanks. David -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20140424/6114ed74/attachment.html>

Guus, or anyone that will help ... Okay.. I've been running tinc for a few months now, and Its been working pretty well with my machine. Attempts to install it on others WinXP Pro, WinXP Home, and WinNT boxes have been spotty at best, with some installations working perfectly, and some not working at all. My latest issue is this. My windows 2000 machine can connect perfectly to our external

On Sun, May 10, 2015 at 08:16:54PM -0400, Darik Horn wrote: > > LZ4 is supposed > > to be a very fast compression algorithm, especially when it comes to > > decompression. I did a quick benchmark with zlib, LZO and LZ4. Now, > > there are many benchmarks you can find online, but most of them deal > > with compressing large files. Tinc on the other hand has to

Hi, I've been struggling for almost a week now, but I can't get the following setup to work. At home I have class A network: 10.0.0.0/16 with a masquerading gateway 10.0.0.1 running tinc. At work (http://www.eastsite.nl) we have a 192.168.0.0/24 network. The gateway is called 'ed' I've set up tinc on 'gateway' and everything is working fine from

With pleasure we announce the release of tinc version 1.1pre16. Here is a summary of the changes in tinc 1.1pre16: * Fixed building with support for UML sockets. * Documentation updates and spelling fixes. * Support for MSS clamping of IP-in-IP packets. * Fixed parsing of the -b flag. * Added the ability to set a firemall mark on sockets on Linux. * Minor improvements to the build system.

With pleasure we announce the release of tinc version 1.1pre16. Here is a summary of the changes in tinc 1.1pre16: * Fixed building with support for UML sockets. * Documentation updates and spelling fixes. * Support for MSS clamping of IP-in-IP packets. * Fixed parsing of the -b flag. * Added the ability to set a firemall mark on sockets on Linux. * Minor improvements to the build system.

With pleasure we announce the release of tinc versions 1.0.33. Here is a summary of the changes in tinc 1.0.33: * Allow compilation from a build directory. * Source code cleanups. * Fix some options specified on the command line not surviving a HUP signal. * Handle tun/tap device returning EPERM or EBUSY. * Disable PMTUDiscovery when TCPOnly is used. * Support the --runstatedir option of

With pleasure we announce the release of tinc versions 1.0.33. Here is a summary of the changes in tinc 1.0.33: * Allow compilation from a build directory. * Source code cleanups. * Fix some options specified on the command line not surviving a HUP signal. * Handle tun/tap device returning EPERM or EBUSY. * Disable PMTUDiscovery when TCPOnly is used. * Support the --runstatedir option of

Thanks Guss, some comments and questions: If you make the yellow nodes ConnectTo all other nodes, and not have > AutoConnect = yes, and the other nodes just have AutoConnect = yes but > no ConnectTo's, then you will get the desired graph. The reason this approach is not desirable is because it fails at automation. It requires us to add a new line of AutoConnect = <new node that