Sure; but again assumes a simple subnet configuration. Lots of enterprise customers have multiple subnets with gateways, internal routers etc. They probably won't respect/forward LAN locator beacons. We (Sococo) gave up on that approach, particularly since Enterprise IT guys like to get excited about broadcast UDP wandering around their subnet.

A straightforward approach is, when talking with the 'rendezvous' server, to include in the message your discovered local subnet address(es). Then the server can inform your peer of the entire set of candidate IP addresses you might be available at (NATted address + subnet addresses). P2P connection pinging then works the same way, with the additional constraint that the 1st P2P message must include a unique id to identify the peer. Because non-routable subnet addresses can be re-used (10.x.x.x or 192.168.x.x style). You don't want to try to connect to Alice and discover that XRay has the same subnet address, XRay is available on your subnet, and XRay is also running the same P2P app.

Anyway like I mentioned, its complicated and full of wrinkles.

The article takes up this very idea and dismisses it because it leaks info about private networks.

I guess they dismissed it too soon. None of our enterprise customers have a problem with it. And some demand it - the alternative is to have their P2P traffic travel outside the firewall and back in again, 'hairpinned' through the public router. Talk about a security risk!

And in our product, the sharing is over encrypted links to qualified peers (members of your working group).