Advertising a Public IP address

[Keith Whyte]

On 22/05/17 21:02, Guus Sliepen wrote:

> The info command gives the address that is currently selected by the
> local node for communication with NodeB. However, tinc might know more
> than one address. You can do:
>
> tinc -n <netname> dump edges | grep 'to NodeB'
OK, I have a mix of 1.0 and 1.1.. 'NodeB' is  actually running
1.1pre14-63-g3d8a836
I checked that on all the 1.1 nodes, I only have one IP listed. so only
the LAN IP is propagating, for the reasons you state below.
> But you have to make a connection between NodeA and NodeB using their
> public IP addresses, otherwise they themselves will not know they have
> those, and will only tell the other nodes about their local addresses.
OK, so I tried that.
but arrg.. the master NodeA still found NodeB at the router address. so
now 192.168.1.1 is propagating.
Not sure what's going on there, it's a BSC/pf system.. so I guess that
is the way it's doing NAT reflection, it's passing the broadcast probe.
I'm good with netfilter, but tracking this kind of thing down in pf
well.. I have to open some manuals :)

I guess maybe I could prevent that with yet another firewall rule, but
this is getting messy.

The other thing might be to turn off Local Discovery..
I have eight tinc nodes on this LAN, I suppose I have to turn off local
discovery for all off them, otherwise just one will find the local IP
and "poison" the tinc node list?

Would you consider giving the address listed in the host config file
priority for propagation to other tinc daemons?
or maybe this is very much of an outside case? Would appreciate your
opinion.
(I'm not offering a patch at this time,  - I have hardly looked at tinc
source, but might be quite simple, no?)

couple of points:
I am thinking that If I can, I would prefer not to relay everything
through 192.168.1.2 when there's no need. But maybe the performance hit
there is negligable, as there is no crypto happening, is that correct?
192.168.1.2 is just relaying the UDP packets?

I may in the future end up with a LOT of traffic coming through "nodeB",
however actual communication between "nodeA" and "nodeB" would be
minimal, so I don't really mind that using the NAT reflection for that.

Thanks Guus!

k/