Assume the following topology:
A <--> B <--> C
(A and C are behind firewalls and can only establish direct TCP connection with B)
If I set TCPOnly = yes for node C, B will drop packets sent from A to C, while all other situations work properly (B to C, C to B, and even C to A)
If I leave TCPOnly = no, even though only TCP connections are available (as UDP packets will be dropped by firewalls), everything works as expected.
After some digging, I found that TCPOnly enabled nodes will never have the validkey status flag set, and packets indirectly targeting C are dropped by B from here: https://github.com/gsliepen/tinc/commit/2c9126ab604fce80d9acd1bbdb485eae50aefcad
If I revert the commit everything works again, but I'm not sure if it's the correct way to fix the problem, or there's something wrong elsewhere resulting in validkey unset.
Assume the following topology: A <--> B <--> C (A and C are behind firewalls and can only establish direct TCP connection with B)
If I set TCPOnly = yes for node C, B will drop packets sent from A to C, while all other situations work properly (B to C, C to B, and even C to A) If I leave TCPOnly = no, even though only TCP connections are available (as UDP packets will be dropped by firewalls), everything works as expected.
After some digging, I found that TCPOnly enabled nodes will never have the
validkeystatus flag set, and packets indirectly targeting C are dropped by B from here: https://github.com/gsliepen/tinc/commit/2c9126ab604fce80d9acd1bbdb485eae50aefcad If I revert the commit everything works again, but I'm not sure if it's the correct way to fix the problem, or there's something wrong elsewhere resulting invalidkeyunset.