search for: ans_key

...ing keys") This is a great feature as it basically allows peers to do UDP Hole Punching (via MTU probes) even when both are having their source ports rewritten by a NAT, which is extremely useful. However, I have a few questions and concerns about the way it's currently implemented in ANS_KEY messages: - AFAIK, once a key is negotiated using REQ_KEY and ANS_KEY messages, and barring any changes to the graph, it will only be negotiated again <KeyExpire> seconds later, which by default is one hour. This means that the UDP port information is only updated once an hour, which seem...

...stingly, this piece of information could perhaps also be used to kickstart PMTU discovery, using the indirect PMTU as a "hint" to constrain the initial range and thereby making it converge faster on the actual PMTU. Note that the dynamic UDP address information (currently transmitted via ANS_KEY messages) poses similar issues, and therefore these proposals can be applied to UDP address data as well with the same pros and cons. In the end I expect us to adopt the same proposal for both PMTU and address information. Arguably, having a robust dynamic way to transmit fresh UDP address informat...

...c.vpn[2918]: Sending 6 bytes of metadata to tls (81.13.33.158 port 655) May 24 00:20:12 gnome tinc.vpn[2918]: Sending 98 bytes of metadata to tls (81.13.33.158 port 655) May 24 00:20:12 gnome tinc.vpn[2918]: Flushing 115 bytes to tls (81.13.33.158 port 655) May 24 00:20:13 gnome tinc.vpn[2918]: Got ANS_KEY from tls (81.13.33.158 port 655): 16 tls mjt 91 64 0 11 May 24 00:20:13 gnome tinc.vpn[2918]: Got bad ANS_KEY from tls (81.13.33.158 port 655) May 24 00:20:13 gnome tinc.vpn[2918]: Error while processing ANS_KEY from tls (81.13.33.158 port 655) May 24 00:20:13 gnome tinc.vpn[2918]: Closing connect...

...BNET from client1 (2.2.2.2 port 35031) Got ADD_SUBNET from client1 (2.2.2.2 port 35031) Forwarding ADD_SUBNET from client1 (2.2.2.2 port 35031) Got ADD_EDGE from client1 (2.2.2.2 port 35031) Forwarding ADD_EDGE from client1 (2.2.2.2 port 35031) UDP address of client1 set to 2.2.2.2 port 655 Sending ANS_KEY to client1 (2.2.2.2 port 35031) UDP address of client1 set to 2.2.2.2 port 19446 Sending REQ_KEY to client1 (2.2.2.2 port 35031) Sending PACKET to client1 (2.2.2.2 port 35031) Sending PACKET to client1 (2.2.2.2 port 35031) Got ANS_KEY from client1 (2.2.2.2 port 35031) Got ANS_KEY from client1 (2.2....

...nect to this server. I can ping from my computer (laptophenk) to the server and some other computers but not to jeffrey2015. When I set tincd to -D -d4 I get ( I left out a lot of data of course) UDP address of vpnserver set to ...... port 655 UDP address of jeffrey2015 set to ...... port 655 Got ANS_KEY from vpnserver (..... port 655): 16 jeffrey2015 laptophenk F.....E 91 64 4 5 ..... 33487 Using reflexive UDP address from jeffrey2015: .... port 33487 UDP address of jeffrey2015 set to ..... port 33487 Receiving packet failed: (10054) An existing connection was forcibly closed by the remote host. R...

...they don't propagate the connections on the other nodes. However I get a segfault soon after starting on each node that I enable that option. I've build from the latest code and here is a trace of such a run: (this is not from a "major" node, but the effect is the same) Got ANS_KEY from Backbone (164.138.216.106 port 655): 16 Office Lukav_Beast 52201D7CFDC2C7E1FD7871A36E651B7AC24A52B4ED892CD953397F6BA859AB22D5D4CB235B9CF85910B6BDE91A34C85E 427 672 4 0 94.155.19.130 13935 Using reflexive UDP address from Office: 94.155.19.130 port 13935 UDP address of Office set to 94.155.1...

...ll be connected directly to others. A solution could be TLS (signing public keys), but create a PKI is another issue for us. Instead, we have an idea : would it be possible to have a option in tinc.conf like "TrustedNodes=aaa,bbb,ccc" ? With this option : (a) any ADD_EDGE/ADD_SUBNET/ANS_KEY/... will be cancelled if it comes from a non-trusted connection (b) all REQ_KEY will be sent to trusted nodes only. (a) is easy, but we do not know how to manage (b). In net_packet.c and protocol_key.c we see : send_req_key(n->nexthop->connection, myself, n); The question is :...

...ed from client) *** Jun 27 09:06:03 lemon tinc.9[10186]: Got request from 192.168.9.99 (192.168.2.100 ): 160 c0a80901 c0a80963 Jun 27 09:06:03 lemon tinc.9[10186]: Got REQ_KEY origin 192.168.9.99 destination192.168.9.1 from 192.168.9.99 (192.168.2.100) Jun 27 09:06:03 lemon tinc.9[10186]: Sending ANS_KEY to 192.168.9.99 (192.168.2.1 00) Jun 27 09:06:03 lemon tinc.9[10186]: Got request from 192.168.9.99 (192.168.2.100): 161 c0a80901 c0a80963 962093104 2rrsesncmha0uws71o5eugns2 Jun 27 09:06:03 lemon tinc.9[10186]: Got ANS_KEY origin 192.168.9.99 destination 192.168.9.1 from 192.168.9.99 (192.168.2...

...n/tap device (tun mode) Sending packet of 74 bytes to lleuad (84.92.216.214 port 655) No valid key known yet for lleuad (84.92.216.214 port 655), queueing packet Sending REQ_KEY to lleuad (84.92.216.214 port 4227): 15 athos lleuad Sending 16 bytes of metadata to lleuad (84.92.216.214 port 4227) Got ANS_KEY from lleuad (84.92.216.214 port 4227): 16 lleuad athos 14EDE2A2E4C14F97B3CBF94A388C79C420D6096B29D9F1EB 91 64 4 0 Flushing queue for lleuad (84.92.216.214 port 655) Got REQ_KEY from lleuad (84.92.216.214 port 4227): 15 lleuad athos Sending ANS_KEY to lleuad (84.92.216.214 port 4227): 16 athos lleu...

...s from Linux tun/tap device Sending packet of 98 bytes to crux (192.168.192.17 port 655) No valid key known yet for crux (192.168.192.17 port 655), queueing packet Sending REQ_KEY to crux (192.168.192.17 port 32852): 15 helix crux Sending 14 bytes of metadata to crux (192.168.192.17 port 32852) Got ANS_KEY from crux (192.168.192.17 port 32852): 16 ..... Flushing queue for crux (192.168.192.17 port 655) Got REQ_KEY from crux (192.168.192.17 port 32852): 15 crux helix Sending ANS_KEY to crux (192.168.192.17 port 32852): 16 ..... Sending 73 bytes of metadata to crux (192.168.192.17 port 32852) Received...

...eb 19 15:13:11 linux tinc.vpn[2414]: Node A (12.221.73.89) became reachable Feb 19 15:13:11 linux tinc.vpn[2414]: Got ADD_SUBNET from A (12.221.73.89): 10 A 192.168.0.0/24 Feb 19 15:13:22 linux tinc.vpn[2414]: Got REQ_KEY from A (12.221.73.89): 15 A B Feb 19 15:13:22 linux tinc.vpn[2414]: Sending ANS_KEY to A (12.221.73.89): 16 B A B157130AC44115976F7A773719D0DBEC8E2EADD4EF0BA824 91 64 4 Feb 19 15:13:22 linux tinc.vpn[2414]: Sending 68 bytes of metadata to A (12.221.73.89) Feb 19 15:13:22 linux tinc.vpn[2414]: Received UDP packet on port 655 from unknown source cdd4959:517 Feb 19 15:13:45 linux...

...ake things clearer. Regarding keys: - The key used for the metaconnections (routing protocol over TCP) - i.e. the one you configure in your host files - is NOT the same as the key used for UDP data tunnels. - The key for data tunnels is negotiated over the metaconnections, by sending REQ_KEY and ANS_KEY messages over the metagraph (i.e. the graph of metaconnections). So, in your example, B will send a REQ_KEY message to A, which will forward it to C, which will respond with an ANS_KEY message, also forwarded through A. - These "data keys" are generated on-the-fly and are ephemeral, with...

...ections on the other nodes. > > However I get a segfault soon after starting on each node that I enable > that option. > > I've build from the latest code and here is a trace of such a run: (this > is not from a "major" node, but the effect is the same) > > Got ANS_KEY from Backbone (164.138.216.106 port 655): 16 Office > Lukav_Beast > 52201D7CFDC2C7E1FD7871A36E651B7AC24A52B4ED892CD953397F6BA859AB22D5D4CB235B9CF85910B6BDE91A34C85E > 427 672 4 0 94.155.19.130 13935 > Using reflexive UDP address from Office: 94.155.19.130 port 13935 > UDP address of...

...they don't propagate the connections on the other nodes. However I get a segfault soon after starting on each node that I enable that option. I've build from the latest code and here is a trace of such a run: (this is not from a "major" node, but the effect is the same) Got ANS_KEY from Backbone (164.138.216.106 port 655): 16 Office Lukav_Beast 52201D7CFDC2C7E1FD7871A36E651B7AC24A52B4ED892CD953397F6BA859AB22D5D4CB235B9CF85910B6BDE91A34C85E 427 672 4 0 94.155.19.130 13935 Using reflexive UDP address from Office: 94.155.19.130 port 13935 UDP address of Office set to 94.155.1...

...15 bytes of metadata to office (111.111.111.111 port 655) Flushing 15 bytes to office (111.111.111.111 port 655) Read packet of 110 bytes from Windows tap device Cannot route packet from support (MYSELF): unknown IPv4 destination address 192.16 Writing packet of 138 bytes to Windows tap device Got ANS_KEY from office (111.111.111.111 port 655): 16 office support 4994BC3CC7459028949 Flushing queue for office (111.111.111.111 port 655) Receiving packet failed: No such file or directory Read packet of 175 bytes from Windows tap device Cannot route packet from support (MYSELF): unknown IPv4 destination...

...ions on the other nodes. > > However I get a segfault soon after starting on each node that I enable > that option. > > I've build from the latest code and here is a trace of such a run: (this > is not from a "major" node, but the effect is the same) > > Got ANS_KEY from Backbone (164.138.216.106 port 655): 16 Office > Lukav_Beast > 52201D7CFDC2C7E1FD7871A36E651B7AC24A52B4ED892CD953397F6BA859AB22D5D4CB235B9CF85910B6BDE91A34C85E > 427 672 4 0 94.155.19.130 13935 > Using reflexive UDP address from Office: 94.155.19.130 port 13935 > UDP address of...

...ot ADD_EDGE from home (47.20.123.2 port 655): 12 45ee4727 home work 75.99.126.132 655 c 88 Forwarding ADD_EDGE from home (47.20.123.2 port 655): 12 45ee4727 home work 75.99.126.132 655 c 88 UDP address of home set to 47.20.123.2 port 655 UDP address of offsite set to 49.206.123.244 port 655 Sending ANS_KEY to home (47.20.123.2 port 655): 16 work home 77C094ECC557602BFE34B13EBD0C8A52F9C1ACE136242F1FD3858CE8D7AF137456507C6C30D73AC76DB32AEED9F487CE 427 672 4 0 Sending 130 bytes of metadata to home (47.20.123.2 port 655) Got ANS_KEY from home (47.20.123.2 port 655): 16 home work 0873EB66B3E93BB3CDAD33253...

...nect to this server. I can ping from my computer (laptophenk) to the server and some other computers but not to jeffrey2015. When I set tincd to -D -d4 I get ( I left out a lot of data of course) UDP address of vpnserver set to ...... port 655 UDP address of jeffrey2015 set to ...... port 655 Got ANS_KEY from vpnserver (..... port 655): 16 jeffrey2015 laptophenk F.....E 91 64 4 5 ..... 33487 Using reflexive UDP address from jeffrey2015: .... port 33487 UDP address of jeffrey2015 set to ..... port 33487 Receiving packet failed: (10054) An existing connection was forcibly closed by the remote host. R...

...g from my computer (laptophenk) to the server and some other > computers but not to jeffrey2015. When I set tincd to -D -d4 I get > ( I left out a lot of data of course) UDP address of vpnserver set > to ...... port 655 > > UDP address of jeffrey2015 set to ...... port 655 > Got ANS_KEY from vpnserver (..... port 655): 16 jeffrey2015 > laptophenk F.....E 91 64 4 5 ..... 33487 Using reflexive UDP address > from jeffrey2015: .... port 33487 UDP address of jeffrey2015 set > to ..... port 33487 Receiving packet failed: (10054) An existing > connection was forcibly closed b...

Hi all! I still have never managed to fully wrap my head around how UDP data tunnels can be established between nodes. Everytime I think I understand it, I see something that confuses me again Just now I am seeing the following: I have nodes A, B + C A has everybody's keys and host configuration files. B and C only have A's key, and host config with A's public IP address. B and