search

gsliepen / tinc

a VPN daemon
http://tinc-vpn.org/
Other
1.93k stars 283 forks source link

Got bad ID from <unknown> #434

Open wellloaded opened 1 year ago

wellloaded commented 1 year ago

tinc[5423] | Got bad ID from <unknown> (192.168.1.2 port 42887): invalid name tinc[5423] | Error while processing ID from <unknown> (192.168.1.2 port 42887)

I get dozens of these messages per hour. In my full mesh tinc VPN this is the only device experiencing this. This device is behind the ISP router and gets a private IP, I have tried port forwarding and DMZ towards the tinc machine (just in case this was an attack) but this makes no different.

192.168.1.1 = ISP router 192.168.1.2 = tinc device (FreshTomato Router)

I have a second machine in the tinc vpn mesh that operates from behind the ISP router and this just works fine I have no logs of sort recorded, so it has to be something with this specific installation.

To me the most confusing part is: 192.168.1.2 port 42887 192.168.1.2 as stated is the tinc device LAN IP address... why port 42887 is handled by the tinc process considering I use the default 655?

Can anyone shed some light on what's going on, and especially why only this device considering the config is aligned to the others?

Thanks

gsliepen commented 6 months ago

Sorry for the very late reply. Port 42887 appears because it is the port the other side is sending from. It still connects to tinc's port 655. Outgoing TCP connections normally get assigned a random source port number by the operating system, so that is normal.

The question is of course, what tries to connect to your tinc daemon? It certainly isn't another tinc daemon, as they would never send an ID message with an invalid name.

Chaots commented 3 months ago

I just encountered the same message, In my case using Openwrt.

The default config seems to hint at setting the wrong Name for the remote endpoint to connect to. for me it was resulting in a local connection to the local instance, After correcting the Name and tinc-host "name" variables the error disappeared.

I am not entirely sure what the actual mistake was, though double checking those and setting them right, things started working and the errors disappeared. It seems to be related to the way openwrt / the likes initialize tinc as a deamon.