<div class="gmail_quote">On Tue, Sep 20, 2011 at 11:07 PM, Guus Sliepen <span dir="ltr"><<a href="mailto:guus@tinc-vpn.org">guus@tinc-vpn.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Tue, Sep 20, 2011 at 09:35:13AM +0800, Roger wrote:<br>
<br>
> I'm seeing periodic packet loss with tinc (1.0.16). I have 'ReplayWindow =<br>
> 0' in config, and ping between the hosts is perfect.<br>
<br>
</div>Setting ReplayWindow to zero will disable protection against replayed packets.<br>
If you do not set ReplayWindow, what exactly happens with ping between the<br>
hosts?<br></blockquote><div><br>Thanks for replying. I meant pinging out of the tinc tunnel is perfect, but pinging in the tinc tunnel has packet loss. <br><br>I tried to set 'ReplayWindow' but with no luck -- the packet loss are same. So that ruled out the UDP packets reordering problem which 'ReplayWindow' should fix.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
> I suspect the packets are identified and then dropped by the Great Firewall.<br>
><br>
> My question is: can it be identified by DPI? If yes, how should I improve<br>
> tinc to avoid this?<br>
<br>
</div>In principle tinc packets can be identified, if you have seen the initial<br>
handshake and can associate the UDP packets with it</blockquote><div><br>
</div></div>The initial handshare is described here: <a href="http://tinc-vpn.org/documentation/tinc_6.html#Authentication-protocol">http://tinc-vpn.org/documentation/tinc_6.html#Authentication-protocol</a> . If I change the protocol in the first 2 steps (ID and METAKEY) and replace it with my own version, and use different UDP ports. Maybe it won't be identified.<br>
<br>Roger<br>