<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi,<br>
<br>
PROTO=ICMP TYPE=11 CODE=0 <br>
<br>
<span style="color: rgb(34, 34, 34); font-family: sans-serif;
font-size: 14px; font-style: normal; font-variant-ligatures:
normal; font-variant-caps: normal; font-weight: 400;
letter-spacing: normal; orphans: 2; text-align: start;
text-indent: 0px; text-transform: none; white-space: normal;
widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(248, 249, 250); text-decoration-style:
initial; text-decoration-color: initial; display: inline
!important; float: none;">TTL expired in transit</span><br>
<br>
perhaps a routing loop? <br>
<br>
regards<br>
<br>
Thomas <br>
<br>
<div class="moz-cite-prefix">Am 30.12.17 um 22:47 schrieb Martin
Sand:<br>
</div>
<blockquote cite="mid:f94f553d-df25-0a39-de92-2d4c26cf11ea@gmx.net"
type="cite">Hi Noel
<br>
<br>
Thanks for the advice. I installed tcpdump and wireshark and added
a rule to log ICMP errors.
<br>
This is an excerpt from the log file. I assume this line shows
something is sent to port 80 but I cannot find the corresponding
iptables entry.
<br>
<br>
Dec 30 21:42:11 localhost kernel: [1423944.393321] IN= OUT=eth0
SRC=210.211.212.213 DST=192.168.2.135 LEN=88 TOS=0x00 PREC=0xC0
TTL=64 ID=38805 PROTO=ICMP TYPE=11 CODE=0 [SRC=192.168.2.135
DST=192.168.1.130 LEN=60 TOS=0x00 PREC=0x00 TTL=1 ID=63979 DF
PROTO=TCP SPT=47511 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0 ]
<br>
<br>
Best regards
<br>
Martin
<br>
<br>
<br>
On 28.12.2017 01:43, Noel Kuntze wrote:
<br>
<blockquote type="cite">Hi,
<br>
<br>
Looks like your firewall rules on the hub are broken and cause
the problems or you need to configure an additional CHILD_SA to
tunnel ICMP errors from the hub, because it has no IP in the
local TS.
<br>
Check both those suspicions.
<br>
<br>
Kind regards
<br>
<br>
Noel
<br>
<br>
On 27.12.2017 23:00, Martin Sand wrote:
<br>
<blockquote type="cite">Thanks again Noel.
<br>
<br>
I have executed `traceroute -T --mtu <destination>` and
`mtr -rw <destination>` on machines at both locations.
<br>
I did not do further investigation on the MSS yet since I have
this strange packet loss.
<br>
Based on the route, I assume this happens at the hub which is
in between the two routers?
<br>
Could this be the root cause I need to further investigate?
<br>
<br>
Kind regards
<br>
Martin
<br>
<br>
traceroute -T --mtu pi-frankfurt
<br>
traceroute to pi-frankfurt (192.168.2.135), 30 hops max, 60
byte packets
<br>
1 router-freiburg (192.168.1.1) 0.263 ms 0.179 ms 0.172
ms
<br>
2 * * *
<br>
3 router-frankfurt (192.168.2.1) 41.762 ms 41.182 ms
36.716 ms
<br>
4 pi-frankfurt (192.168.2.135) 36.693 ms 43.629 ms
37.051 ms
<br>
<br>
traceroute -T --mtu pi-freiburg
<br>
traceroute to pi-freiburg (192.168.1.130), 30 hops max, 60
byte packets
<br>
1 router-frankfurt (192.168.2.1) 0.489 ms 0.381 ms 0.287
ms
<br>
2 * * *
<br>
3 router-freiburg (192.168.1.1) 38.368 ms 47.673 ms
35.441 ms
<br>
4 pi-freiburg (192.168.1.130) 39.456 ms 54.566 ms 36.117
ms
<br>
<br>
mtr -rw pi-frankfurt
<br>
Start: 2017-12-27T22:57:40+0100
<br>
HOST: workstation Loss% Snt Last Avg Best
Wrst StDev
<br>
1.|-- router-freiburg 0.0% 10 0.2 0.2 0.2
0.3 0.0
<br>
2.|-- ??? 100.0 10 0.0 0.0
0.0 0.0 0.0
<br>
3.|-- router-frankfurt 0.0% 10 33.3 35.5 32.5
42.0 2.7
<br>
4.|-- pi-frankfurt 0.0% 10 33.5 34.4
32.7 36.7 1.5
<br>
<br>
<br>
On 27.12.2017 21:08, Noel Kuntze wrote:
<br>
<blockquote type="cite">Hi,
<br>
<br>
You can test the convergence speed using `traceroute -T
--mtu <destination>`, but that only gives you the MTU.
You need to manually discover the MSS
<br>
using `traceroute -T -O mss=<mss>
<destination>`.
<br>
<br>
The best way to check if the problem continues is to just
run tcpdump/wireshark and check for ICMP Fragmenation needed
packets and TCP errors or timeouts.
<br>
<br>
Kind regards
<br>
<br>
Noel
<br>
<br>
On 27.12.2017 17:12, Martin Sand wrote:
<br>
<blockquote type="cite">Thanks Noel. Sorry, I had to travel
to the other location (350 km).
<br>
<br>
I adapted the iptable rules. It improved, but I have the
impression it only improved a bit.
<br>
Is there a way to measure MTU discovery time?
<br>
<br>
Kind regards
<br>
Martin
<br>
<br>
<br>
On 14.12.2017 13:51, Noel Kuntze wrote:
<br>
<blockquote type="cite">Hi,
<br>
<br>
<blockquote type="cite">VPN internal http requests to a
web server of another spoke take some time until the
page is rendered.
<br>
I assume this is due to the latency.
<br>
</blockquote>
Nah. It's extremely more likely that the path MTU
discovery takes some time (maybe due to some
missing/wrong firewall rules on some host(s) in your
network topology).
<br>
Try lowering the MTU and MSS of the tunneled traffic[1].
<br>
<br>
Kind regards
<br>
<br>
Noel
<br>
<br>
[1]
<a class="moz-txt-link-freetext" href="https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling#MTUMSS-issues">https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling#MTUMSS-issues</a><br>
<br>
On 14.12.2017 13:41, Martin Sand wrote:
<br>
<blockquote type="cite">Hi all
<br>
<br>
I have a Hub and Spoke setup. Connections are working
perfectly fine.
<br>
Throughput is almost reaching the maximum rate of the
upload channel speed, 10 MBit/s.
<br>
<br>
Unfortunately the latency is not fulfilling my
objectives. I have an average ping time of 39 ms (see
below) when pinging clients on other spokes.
<br>
VPN internal http requests to a web server of another
spoke take some time until the page is rendered.
<br>
I assume this is due to the latency.
<br>
<br>
Is there any chance to improve the latency? Or is the
latency perfectly good?
<br>
<br>
Best regards
<br>
Martin
<br>
<br>
Hub internet address
<br>
64 bytes from vpn.example.com (217.122.5.6):
icmp_seq=1 ttl=57 time=15.2 ms
<br>
<br>
Internal address of Hub
<br>
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
<br>
64 bytes from 192.168.1.1: icmp_seq=1 ttl=62 time=40.4
ms
<br>
<br>
Client on another spoke
<br>
PING 192.168.1.130 (192.168.1.130) 56(84) bytes of
data.
<br>
64 bytes from 192.168.1.130: icmp_seq=1 ttl=61
time=108 ms
<br>
64 bytes from 192.168.1.130: icmp_seq=2 ttl=61
time=41.8 ms
<br>
64 bytes from 192.168.1.130: icmp_seq=3 ttl=61
time=38.0 ms
<br>
64 bytes from 192.168.1.130: icmp_seq=4 ttl=61
time=35.2 ms
<br>
64 bytes from 192.168.1.130: icmp_seq=5 ttl=61
time=36.4 ms
<br>
64 bytes from 192.168.1.130: icmp_seq=6 ttl=61
time=39.1 ms
<br>
64 bytes from 192.168.1.130: icmp_seq=7 ttl=61
time=38.1 ms
<br>
64 bytes from 192.168.1.130: icmp_seq=8 ttl=61
time=41.6 ms
<br>
64 bytes from 192.168.1.130: icmp_seq=9 ttl=61
time=36.0 ms
<br>
64 bytes from 192.168.1.130: icmp_seq=10 ttl=61
time=36.7 ms
<br>
<br>
--- 192.168.1.130 ping statistics ---
<br>
10 packets transmitted, 10 received, 0% packet loss,
time 9013ms
<br>
rtt min/avg/max/mdev = 35.295/45.159/108.281/21.146 ms
<br>
<br>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Thomas Will
Xinux e.K.
Wichernstrasse 18
66482 Zweibruecken
Registergericht
Amtsgericht Zweibruecken
HRA 1518
P: +49 6332 44040
F: +49 6332 899227
M: +49 170 5218548
M: +49 176 97497102
E: <a class="moz-txt-link-abbreviated" href="mailto:thomas.will@xinux.de">thomas.will@xinux.de</a>
W: <a class="moz-txt-link-freetext" href="http://www.xinux.de">http://www.xinux.de</a>
</pre>
</body>
</html>