search for: tcponly

Hi there! Today I've tried a FTP connection (me with TCPOnly send file to another no TCPOnly), but the upload bandwidth was about 20 kb/s, while connecting to the other directly (I upload a file to him via FTP) the connection was about 5 times faster... what's wrong? thanks

Hi there! Today I've tried a FTP connection (me with TCPOnly send file to another no TCPOnly), but the upload bandwidth was about 20 kb/s, while connecting to the other directly (I upload a file to him via FTP) the connection was about 5 times faster... what's wrong? thanks

Hi, I've successfully running tinc1.0pre4 between two locations on SuSE Linux 7.1 in a special masquerading Firewall environment, so that I'm using the TCPonly keyword in the host files to get a connection. Otherwise I would get the message 'Received UDP packet on port 655 from unknown source <ipaddress in hex:port>'. After upgrading to 1.0pre5 I'm getting this message again (and the connection is not working), until I've changed the...

...udden, the vpn would not work as a full-mesh. Certain nodes were not contactable. I re-generated my rsa-keys, and checked my configuration. My vpn uses the following in tinc.conf, as I am routing both ipv4 and v6. === name = node1 mode = switch AddressFamily = any PMTU = 1280 PMTUDiscovery = yes TCPonly = no ConnectTo = hub1 ConnectTo = hub2 ConnectTo = hub3 === My VPN has some hosts called by nodex. These nodes are dynamic-ip, and set to contact (connectTo) the hubs when they bring up their tincd. The hubx nodes are fixed-ip, and are connected to each other in a full mesh. With TCPonly = no,...

If the concern is more about the reliability instead of throughput, should I add TCPonly = yes in the host configuration to make the VPN runs on TCP?

...Network and TAP-Win32) 192.168.6.107 mask 255.255.255.0 gw 192.168.6.1<br> change -> mask 255.255.0.0 > Tinc.conf<br> > Name = homeClient<br> > ConnectTo = vpnoffice<br> > Mode=switch<br> Change -> Mode=router Why everybody wants switch??? Add -> TCPonly=yes > vpnoffice: Network Bridge(Local Connection and TAP-Win32) 192.168.2.103 mask 255.255.255.0 gw 192.168.2.2<br> -> mask 255.255.0.0 > Tinc.conf:<br> > Name = vpnoffice<br> > Mode=switch<br> Change -> Mode=router Add -> TCPonly=yes > Host File...

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

The only time I can think off, that you’ll *want* to use TCP, is when UDP doesn’t work through the firewalls/NATting. > On 18 Jun 2017, at 14:53 , Bright Zhao <startryst at gmail.com> wrote: > > If the concern is more about the reliability instead of throughput, should I add TCPonly = yes in the host configuration to make the VPN runs on TCP? The problem with TCP, is that TCP, encapsulated inside a TCP stream, is a recipe for very poor performance, as you could have retransmits, encapsulated in retransmits. But then the questions might be more like: Have you read up about w...

...off, that you’ll *want* to use TCP, is when UDP doesn’t work through the firewalls/NATting. >> >>> On 18 Jun 2017, at 14:53 , Bright Zhao <startryst at gmail.com> wrote: >>> >>> If the concern is more about the reliability instead of throughput, should I add TCPonly = yes in the host configuration to make the VPN runs on TCP? >> >> The problem with TCP, is that TCP, encapsulated inside a TCP stream, is a recipe for very poor performance, as you could have retransmits, encapsulated in retransmits. >> >> But then the questions might be...

Hey, Tinc developers! I'm not sure if anyone else has brought this up, but we've got a rather good reason for using TCP, even though UDP will actually form a working connection. Anyone on Comcast's "small business" service is forced to use an SMC cable modem/router. Its NAT implementation is capable of letting tinc's UDP tunnels work fine, but they limit a single UDP

Guus, [tinc version 1.0.24] Consider the case where you have the following setup client - fw - server The client and server successfully setup a tunnel and UDP communication starts to happen. Then the client shuts up and the server only needs to send data to the client if the remote tool accesses the client?s UI. If the firewall times out the NAT UDP hole, the server has a problem: The UDP

...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 different networks) and the tunnels > > were rock stable without any problems. As a workaround(?) I added > > "TCPOnly = yes" [1] to the host's config file and since then all tunnels > > seem to work stable again, but I can't explain this to me as the NAT > > should handle UDP connections. Any ideas? > > Maybe the timeout for UDP NAT mappings is a bit short on your Cisco. Try > ad...

...ime I can think off, that you’ll *want* to use TCP, is when UDP doesn’t work through the firewalls/NATting. > >> On 18 Jun 2017, at 14:53 , Bright Zhao <startryst at gmail.com> wrote: >> >> If the concern is more about the reliability instead of throughput, should I add TCPonly = yes in the host configuration to make the VPN runs on TCP? > > The problem with TCP, is that TCP, encapsulated inside a TCP stream, is a recipe for very poor performance, as you could have retransmits, encapsulated in retransmits. > > But then the questions might be more like: Have...

Dear I am testing tinc on Windows and found some interesting behavior. I used "TCPOnly" parameter for both end because I wanted to go through NAT. However, by using TCPOnly parameter, the response of PING slowed down significantly. The PING response with UDP is about 4ms, but it bumped up to 2000ms with TCP. I am just curious whether this is caused by using TCP. Regards Masa...

...et a VPN working, but we cant get routing between two tunnels. This is how it looks, all servers (192.168.*.1) are running IP Masquerade to enable the other computers behind them to access the internet. Both elayne and glenn are connecting to melc, and the tunnel between melc and glenn are running TCPOnly because that glenn doesnt have a public IP (it's behind another firewall at his ISP). 192.168.5.* 192.168.1.* 192.168.3.* | | | | | | 192.168.5.1 192.168.1.1 192.168.3.1 glenn ---TCPOnly--- melc -----...

...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 different networks) and the tunnels were rock stable without any problems. As a workaround(?) I added "TCPOnly = yes" [1] to the host's config file and since then all tunnels seem to work stable again, but I can't explain this to me as the NAT should handle UDP connections. Any ideas? Cheers, Marcus [1] http://tinc-vpn.org/documentation/Solving-problems.html

On Tue, Apr 10, 2018 at 03:36:08PM +0200, Hans de Groot wrote: > hosta  <--> hostb  <-->  hostc > > Hosta and hostc are not directly connected via tinc. But both are conncted > via hostb (I called my network tincnet). This works fine I can ssh from > hosta to hostc and vice versa without any problems. > > hostc is in a whitelisted iprange at some service

...et 192.168.230.0 netmask 255.255.255.0 gw 192.168.230.1 ip route add default via 192.168.230.160 dev tincnet table hostc ip rule add from 0.0.0.0/0 fwmark 1 table hostc hosta Address = x.x.x.x Cipher = blowfish Compression = 0 Digest = sha1 IndirectData = Yes Port = 110 Subnet = 192.168.230.21/32 TCPonly = yes -----BEGIN RSA PUBLIC KEY----- -----END RSA PUBLIC KEY----- hostb Address = x.x.x.x Cipher = blowfish Compression = 0 Digest = sha1 IndirectData = Yes Port = 110 Subnet = 192.168.230.1/32 Subnet = 0.0.0.0/0 TCPonly = yes -----BEGIN RSA PUBLIC KEY----- -----END RSA PUBLIC KEY----- ---------...

...and one Windows Vista Notebooks as client and a Windows Small Business Server 2008 as server. On the client-side the config-file looks like this: Interface=Tinc-VPN AddressFamily=ipv4 Mode=switch Name=TincKnoten_PM1860NB PrivateKeyFile=C:/Programme/tinc/ESV/rsa_key.priv ConnectTo=TincKnoten_remote TCPOnly=yes The "tinc-up.bat"-file looks like this: netsh interface ip set address %INTERFACE% static 192.168.19.1 255.255.255.0 The file "TincKnoten_remote" on the client looks like this (without public key): Address=Server's DNS-Name Port=655 Subnet=192.168.19.8/32 Here is the...

...oes something like this: local nat remote a:8080 --->> b:8080=>c:32896 ------>> d:8080 (hopefully that made some sense, tracking the UDP connection here). Does tinc expect to be able to reach the local machine via UDP port 8080? I saw a mention about TCPonly being removed from pre3. Is there an expected date for when it will be active again? On another note, using something like "-ddd" or "-d3" or "-d -d -d" does not cause tinc to log packets. How do I turn on uber-logging? Thanks!! - Tinc: Discussion list about...