
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi, All</div><div class=""><br class=""></div><div class="">Here is the case: </div><div class=""><br class=""></div><div class="">A, B, C, D all configured with "IndirectData = yes”, so connection only happens when there’s a “ConnectTo” in tinc.conf.</div><div class="">Arrow indicate the “ConnectTo” direction</div><div class=""><br class=""></div><div class="">Everything works fine earlier as below:</div><div class=""><br class=""></div><div class="">1. A connect to C, D connect to C</div><div class="">2. C is the transit node where only forward traffic between A and C</div><div class="">3. D advertise 0.0.0.0/0#2</div><div class="">4. A can access internet from D through C, no problem at all</div><div class=""><br class=""></div><div class="">What I did yesterday:</div><div class="">5. A connect to B</div><div class="">6. B advertise 0.0.0.0/0#1</div><div class=""><br class=""></div><div class="">Then I thought the traffic will go through B directly if B is reachable, but when B is down, traffic will fallback to D(through C), but interestingly, when the step 5 and 6 are done, I found the traffic seems goes to B though C(not directly), which is not under my earlier expectation.</div><div class=""><br class=""></div><div class="">Then I remove the “ConnectTo = B” statement from A, but interestingly, at this time, the traffic still goes to B through C. From what I know from tinc, if the “ConnectTo” is removed, and IndirectData = yes every where, this shouldn’t happen. And from the tcp connection perspective on A at this moment, it indeed only connect to C, no connection to B at all.</div><div class=""><br class=""></div><div class="">Then I investigate further, I found the advertised route from B still exist on C, where it shows something like below:</div><div class=""><br class=""></div><div class=""><i class="">2017-06-01T09:00:29.558712+08:00 C tincd: 0.0.0.0/0#1 owner B <b class="">(That’s the reason, why C received the packet from A forward to B even A is not connected to B, in this case I have to stop the tinc daemon on B in order to make traffic goes back to D)</b></i></div><div class=""><br class=""></div><div class="">After tincd -n myvpn -kWINCH on A/C/D, then all the old unreachable info is gone.</div><div class=""><br class=""></div><div class="">So questions here:</div><div class=""><br class=""></div><div class="">1. Why in the my case, the traffic will go A>C>B path even A is not connect to B?</div><div class="">2. Why the unreachable info and the related advertised subnet info still exist in C even the A remove the ConnectTo statement to B(all IndirectData = yes)? Should I run a crontab to WINCH all the outdated connection regularly to avoid this? Sounds not that way…looking for advice.<br class=""><br class=""></div><div class=""><br class=""></div><img apple-inline="yes" id="F9AE75C3-A641-4BBA-B76A-49137F11B3DF" src="cid:FC5D30DC-C405-408B-97E3-590386FF6DB3" class=""></body></html>