similar to: Can Ping But No Web Interface

Try removing all MTU related settings from both sides. Allow tinc to learn on its own. " PMTU = 1436 ClampMSS = yes PMTUDiscovery = yes" in the config, " Address Family = ipv4" is likely not necessary, i would recommend removing it. " Device = /dev/net/tun" should not be used, unless tinc is having issues locating the tun device. however " DeviceType =

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?

> Currently, i have nodes with PMTUDiscovery =yes and ClampMSS = yes. Hello, these features were introduced in 1.0.13 correct ?? I also understand that the two settings are by default "yes" if not explictly set to "no" in the config file. what may happen if I have a network with mixed versions from 1.0.11 and 1.0.13, where the older daemons do not implement that feature

Hi, I´m using Tinc for several years, but I didn´t fix a performance problem. There a about 20 nodes in this network. Master: 10.0.0.12 (dedicated host in a datacenter, debian, 100mBit port) tinc.conf: Name = TincKnoten12 AddressFamily = ipv4 Interface = tun ProcessPriority=high mode = router #DirectOnly = no Compression=0 PMTUDiscovery = yes #IndirectData = yes #ReplayWindow = 64 #ConnectTo

We run tinc in a linux environment in which it sits there waiting for connections from the clients. All clients are configured to only have one ConnectTo which points to this server. We're seeing in the server log that as soon as a client's connection is activated, a whole bunch of "Flushing x bytes to that host would block" is logged and the whole vpn is bogged down and has

Hello, I failed to find any explanation about node statuses in syslog dump. Could you please enlight what these status codes mean and how to interpret these? Sep 19 07:08:26 ip-10-255-1-200 tinc.routers[20543]: 10_254_5_11 at 10.255.5.11 port 58045 options c socket 7 status 01c2 outbuf 157/0/0 Sep 19 07:08:26 ip-10-255-1-200 tinc.routers[20543]: 10_254_3_113 at 10.255.3.113 port 58233 options c

The server has a 1G symmetrical fibre line. It has been speedtested to various local servers to be close to 800-900M. When there is only a single client, there isn't much problem and as soon as the connection is made, the ping time through to tunnel is a respectable 30ms. As soon as a few more clients are connected, ping time degrades to hundreds and sometimes seconds and with dropped packets.

https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=448 laforge@netfilter.org changed: What |Removed |Added ---------------------------------------------------------------------------- Component|ip_conntrack |nf_conntrack ------- Additional Comments From laforge@netfilter.org 2006-02-14 09:05 MET ------- ipv6 conntrack is

Hello, This is not really a shorewall problem. But just wanted to check if this problem rang a bell with any of you. I have a linux router with slackware 9.1, and kernel 2.4.27 Everyting works ok except for access to web sites that use akamai from behind the router. >From the router machine itself I can access those sites without problems. But machines behind nat, take forever to access

Clients: Some sites just show the top area not the full page. Some sites cant be reached at all. I think it 90% may be the MTU/MSS problem. But I already have set the shorewall.conf CLAMPMSS=1400 or CLAMPMSS=Yes, but it doest make things good. I would be mad. Anybody helps me would so appreciated! If you want know more info. to diag my problem, I would be please to.

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

Hello, Since the ipmasq package has been dropped from debian I decided to migrate to shorewall. My setup is pretty simple: [DSL Modem] -eth0- [shorwall/gateway] -eth1- [local network] ipmasq required that I set the MTU on eth0 to 1492. Migrating to shorewall went well, but a small number of web sites would load slow or not at all. Setting the MTU on eth0 to 1492 and setting CLAMPMSS=Yes

Dear all, we have a very strange problem, - we have 3 VPN endpoints - all are in one NETWORK - all daemons come up and connect without any problem and normally we have no problem working through the VPN but in some cases the connection does not work because the traffic leaves the TAP interface on one VPN endpoint but never arrives on the other end, the similarities between the packages seem to

Hi I have a (bizarre) problem with ssh, which someone has suggested may be down to the MSS value being too high. I know that within Shorewall I can clamp the MSS value to the MTU-40 value, but is there a way I can set MSS to a discreet value? I just want to (dis)prove the MSS theory at the moment (I know it isn''t a real fix). Thanks, Keith

Hello, all! I have many questions about tap device architecture. What is a right way to calc mtu on TAP device to avoid fragmentation on real eth device? I suppose TAP MTU = 1500-8(UDP)-20(IP)-18(Ethernet) = 1454. So I'd set 1454 for tap device: "ip link set mtu 1454 dev eth0" I'm not shure about what is the exact size of ethernet frame header, which tap device use in switch

Hi, I have a setup that consist of 2 firewalls connected over dialup and PPP. Each side of the ppp are protected by shorewall. One side of the PPP masquerades everything not addressed to the local network to its eth0 (the net). fw1 <---- ppp (dialup) -----> fw0 <----- NET When making an http request to a site on the Internet from the machine not directly connected to the net (fw1), the

Am 23.06.2020 08:43, schrieb Luca Bertoncello: And another thing, I discovered right now... > Could you suggest me something to restrict the problem? > Currently, I think the problem can be: > > 1) on Asterisk > 2) on my Gateway/Firewall A couple of years ago I added this entry in my firewall: /sbin/iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS

Am 23.06.2020 09:28, schrieb Marek Greško: Hi > if you need clampmss then it is highly probable there is a PMTU > discovery problem. The clampmss does not work for UDP. Is there a way to check if I have this problem? > I probably counted the size incorrectly. So you are able to ping with > size 1464 and not with 1466. How about trying same ping sizes from the > internet towards

I have problems connecting IPSEC VPN clients on the masqueraded network to outside VPN servers. It looks like this: ipsec-user | 192.168.1.10 (DHCP assigned) | | 192.168.1.1 fw-1 (shorewall, Linux 2.6) | 20.20.20.20 (internet) | 30.30.30.30 fw-2 (IPSEC VPN endpoint) | 192.168.100.1 | | 192.168.100.2 server ipsec-user (a road warrior) is supposed to create an IPSEC tunnel to his home

I am running red hat 9 with shorewall 1.4.6b-1, Have noticed http and smtp connections time out to some hosts I have tried to change tcp_ecn value but without results - the problem persist. I am now forced to use ISP smtp server, and ISP http proxy server to reach some sites. The problem does not exist when I was running win200k with winroute. Thanks to Help L.Djebran