search for: forward_request

...f(strictsubnets) { logger(DEBUG_ALWAYS, LOG_WARNING, "Ignoring unauthorized %s from %s (%s): %s", "ADD_SUBNET", c->name, c->hostname, subnetstr); + /* Disabled forwarding of unauthorized subnets! forward_request(c, request); + */ return true; } This was added because after a few years of operation of the network we had so many no-longer-existing subnet definitions flowing around that each connect created lots of error messages and a ton of useless metadata-traffic...

...logger(DEBUG_ALWAYS, LOG_WARNING, "Ignoring unauthorized > %s from %s (%s): %s", > "ADD_SUBNET", c->name, c->hostname, > subnetstr); > + /* Disabled forwarding of unauthorized subnets! > forward_request(c, request); > + */ > return true; > } > > This was added because after a few years of operation of the network we > had so many no-longer-existing subnet definitions flowing around that > each connect created lots of error messages and a t...

...logger(DEBUG_ALWAYS, LOG_WARNING, "Ignoring unauthorized > %s from %s (%s): %s", > "ADD_SUBNET", c->name, c->hostname, > subnetstr); > + /* Disabled forwarding of unauthorized subnets! > forward_request(c, request); > + */ > return true; > } > > This was added because after a few years of operation of the network we > had so many no-longer-existing subnet definitions flowing around that > each connect created lots of error messages and a t...

TL;DR: a proposal for a new tinc feature that allows nodes to filter ADD_SUBNET messages based on the metaconnection on which they are received, so that nodes can't impersonate each other's VPN Subnets. Similar to StrictSubnets in spirit, but way more flexible. BACKGROUND: THE ISSUE OF TRUST IN A TINC NETWORK In terms of metaconnections (I'm not discussing data tunnels here), one of