I'm using Tinc 1.1pre14 and I'm trying to connect a node that is behind a firewall that blocks all non-standard ports. I set up a rule in the server to redirect port 25 (that is not used in the server right now) to port 655, both in tcp and udp protocols, and set up the port 25 in the server host configuration file. The client can reach the server, but after the initial sync and key exchange using TCP using port 25, it tries to make UDP connections to port 655 instead of 25. The tunnel is never built and I cannot reach the client. I remember to have the same setup using tinc 1.0.x and it was working fine, but I'm unable to test it now. Is there a chance that tinc ignores the specified port and uses de default 655 port for UDP connections? Thanks! -- *Ing. Guillermo Bisheimer* *B&S Sistemas de Control y Equipamientos* Av. de los Constituyentes 1172 (E3116CIX) Crespo, Entre Ríos Tel/Fax: (0343) 407-8990 (Nuevo número) Cel: (0343) 154679052 WEB: www.bys-control.com.ar e-mail: gbisheimer at bys-control.com.ar skype: guillermo.bisheimer -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20161229/4316968a/attachment.html>
I believe the reason why you're experiencing this problem is because tinc does not use the connection TCP port to determine which port to send UDP packets to. Instead, it uses the port that is *advertised* by the other node. https://github.com/gsliepen/tinc/blob/06b820133285f83f7e1a839cccbed13358b84081/src/protocol_auth.c#L886 That means that if node A is configured with UDP port 655, that's the UDP port it will advertise to node B when it connects and that's what node B will use, even if node B used a different TCP port to establish the metaconnection. I'm not sure why you didn't encounter this problem in tinc 1.0 - at first glance the code seems identical in that respect. On 29 December 2016 at 20:46, Guillermo Bisheimer < gbisheimer at bys-control.com.ar> wrote:> I'm using Tinc 1.1pre14 and I'm trying to connect a node that is behind a > firewall that blocks all non-standard ports. > > I set up a rule in the server to redirect port 25 (that is not used in the > server right now) to port 655, both in tcp and udp protocols, and set up > the port 25 in the server host configuration file. > > The client can reach the server, but after the initial sync and key > exchange using TCP using port 25, it tries to make UDP connections to port > 655 instead of 25. The tunnel is never built and I cannot reach the client. > > I remember to have the same setup using tinc 1.0.x and it was working > fine, but I'm unable to test it now. Is there a chance that tinc ignores > the specified port and uses de default 655 port for UDP connections? > > Thanks! > -- > > *Ing. Guillermo Bisheimer* > > *B&S Sistemas de Control y Equipamientos* > > Av. de los Constituyentes 1172 > > (E3116CIX) Crespo, Entre Ríos > > Tel/Fax: (0343) 407-8990 (Nuevo número) > > Cel: (0343) 154679052 > > WEB: www.bys-control.com.ar > > e-mail: gbisheimer at bys-control.com.ar > > skype: guillermo.bisheimer > > _______________________________________________ > tinc mailing list > tinc at tinc-vpn.org > https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20161230/39ceb422/attachment.html>
Thanks for the clarification. I think the difference between 1.0 and 1.1 was that the UDP tunnel was never built, but tinc allowed TCP only communications anyway. In this case, the tunnel is not working unless I open up the UDP port. I thought that if a UDP connection cannot be made, then tinc falls back to TCP only connection, but may be I need to set that in tinc.conf. El vie., 30 dic. 2016 a las 7:39, Etienne Dechamps (<etienne at edechamps.fr>) escribió:> I believe the reason why you're experiencing this problem is because tinc > does not use the connection TCP port to determine which port to send UDP > packets to. Instead, it uses the port that is *advertised* by the other > node. > > > https://github.com/gsliepen/tinc/blob/06b820133285f83f7e1a839cccbed13358b84081/src/protocol_auth.c#L886 > > That means that if node A is configured with UDP port 655, that's the UDP > port it will advertise to node B when it connects and that's what node B > will use, even if node B used a different TCP port to establish the > metaconnection. > > I'm not sure why you didn't encounter this problem in tinc 1.0 - at first > glance the code seems identical in that respect. > > On 29 December 2016 at 20:46, Guillermo Bisheimer < > gbisheimer at bys-control.com.ar> wrote: > > I'm using Tinc 1.1pre14 and I'm trying to connect a node that is behind a > firewall that blocks all non-standard ports. > > I set up a rule in the server to redirect port 25 (that is not used in the > server right now) to port 655, both in tcp and udp protocols, and set up > the port 25 in the server host configuration file. > > The client can reach the server, but after the initial sync and key > exchange using TCP using port 25, it tries to make UDP connections to port > 655 instead of 25. The tunnel is never built and I cannot reach the client. > > I remember to have the same setup using tinc 1.0.x and it was working > fine, but I'm unable to test it now. Is there a chance that tinc ignores > the specified port and uses de default 655 port for UDP connections? > > Thanks! > -- > > *Ing. Guillermo Bisheimer* > > *B&S Sistemas de Control y Equipamientos* > > Av. de los Constituyentes 1172 > > (E3116CIX) Crespo, Entre Ríos > > Tel/Fax: (0343) 407-8990 (Nuevo número) > > Cel: (0343) 154679052 > > WEB: www.bys-control.com.ar > > e-mail: gbisheimer at bys-control.com.ar > > skype: guillermo.bisheimer > > _______________________________________________ > tinc mailing list > tinc at tinc-vpn.org > https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc > > > --*Ing. Guillermo Bisheimer* *B&S Sistemas de Control y Equipamientos* Av. de los Constituyentes 1172 (E3116CIX) Crespo, Entre Ríos Tel/Fax: (0343) 407-8990 (Nuevo número) Cel: (0343) 154679052 WEB: www.bys-control.com.ar e-mail: gbisheimer at bys-control.com.ar skype: guillermo.bisheimer -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20161230/f8dd82f2/attachment.html>
On Fri, Dec 30, 2016 at 11:38:51AM +0100, Etienne Dechamps wrote:> I believe the reason why you're experiencing this problem is because tinc > does not use the connection TCP port to determine which port to send UDP > packets to. Instead, it uses the port that is *advertised* by the other > node.That's correct, at least for the initial PMTU probes. If it receives packets from a peer with a different UDP source port, it will switch to that one instead. But, to announce a different UDP port than what tinc is actually listening on, you can use the following trick in tinc.conf: Port = 25 ListenAddress = * 655 -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus at tinc-vpn.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20161230/1a8067e5/attachment.sig>
Maybe Matching Threads
- [Announcement] Tinc versions 1.0.32 and 1.1pre15 released
- [Announcement] Tinc versions 1.0.32 and 1.1pre15 released
- [Announcement] Tinc versions 1.0.32 and 1.1pre15 released
- [Announcement] Tinc versions 1.0.32 and 1.1pre15 released
- tinc - controlling communication between nodes