Windows Firewall, network discovery

[Etienne Dechamps]

Hi Erik,

On 2 April 2015 at 21:05, Erik Popp <epopp at i2pmail.org> wrote:
> Windows Firewall doesn't know where the center of my VPN is.  This is
> because I intentionally didn't make one.  Thus, my Windows boxes call it
> "Unidentified Network", and assign it to the restrictive settings for public
> networks.
> If I tell Windows that 1 or more of the machines on the VPN is a default
> gateway, it recognizes the network, but only if that machine was up when the
> Windows box connected to the network.  Also, Windows gives me a warning that
> setting multiple default gateways is meant for multiple connections to a
> single network, not separate connections to separate networks.  I currently
> want the VPN to be separate from either physical LAN.

Yes, this is a known issue, and unfortunately this is a Windows
limitation - its NLA (Network Location Awareness) feature is not
designed for virtual peer-to-peer networks at all.

There are only two ways (that I know of) to fix the "Unidentified
network" label (as well as the firewall settings):

- Make sure one node is always up, and then configure that machine as
default gateway, making sure to set appropriate route metrics so that
it will never get priority over your physical network. It seems like
this is not an option for your use case.

- Apply a registry hack to make Windows see the virtual network
adapter as an "endpoint" device. This will fix the firewall settings,
and it will also make the VPN disappear entirely from the network list
(but not the adapter list). This is described at
http://nivot.org/blog/post/2008/09/05/VMWareVMNETAdaptersTriggeringPublicProfileForWindowsFirewall

Here's more discussion about this issue in general:
http://serverfault.com/questions/60794/windows-7-network-connection-with-no-default-gateway-any-way-to-change-the-un

> At my grandparents' house, tinc's local peer discovery doesn't work
> properly.  They don't discover each other on the network unless they can
> both talk to a third machine over the internet, and then they can route
> traffic through each other via the third machine.  If I have 1 or both of
> them ping each other for awhile (a few seconds to several minutes), they'll
> discover each others' local addresses for sending data, but they appear to
> still use their remote peer for the meta connection.  The router which local
> peer discovery has WAN loopback (incorrect term?) enabled, so I can SSH into
> the router using its WAN IP, from inside its LAN.

LocalDiscovery is only about optimizing the path for UDP data packets.
It does not affect metaconnections, though that's an interesting idea
for a feature request.

The main use case for LocalDiscovery is to avoid sending large amounts
of data over the Internet when the two nodes happen to be on the same
LAN; it's not designed to establish new metaconnection edges, and will
not protect against the link between the LAN and the Internet going
down.

You didn't mention which tinc version you're using. If you're making
heavy use of LocalDiscovery, you might want to use 1.1pre11 or later,
as the local discovery process was significantly improved in that
version: https://github.com/gsliepen/tinc/pull/26

By the way, the correct term for what you refer to as "WAN loopback"
is "hairpinning": https://en.wikipedia.org/wiki/Hairpinning

> When the tinc daemon/service is turned on, it breaks LAN gaming on Age of
> Empires III, for that machine.  I suspect that this is a firewall issue.  I
> can't see any games that are being hosted on the LAN.  If I try to connect
> with a direct IP, it seems that messages are getting to 1 of them, but 2-way
> communication doesn't work.

It could indeed be related to the firewall going back to the
restricted profile when the virtual adapter is connected to an
"Unidentified network", as explained above. Here's another
possibility:

On Windows, global broadcast packets (which is probably what's used by
your game to discover lobbies) are by default only sent over one
interface. What might be happening is that the packets are being sent
over the VPN instead of the physical network. There are two solutions
for this:

- Change the adapter priority (in Adapter Settings > Advanced >
Advanced Settings > Adapters and Bindings tab) so that your physical
adapter has higher priority compared to the virtual adapter, ensuring
that broadcast packets get sent on the correct interface.

- Simply install WinIPBroadcast to ensure these packets are sent over
all network adapters, thereby solving the issue once and for all:
https://github.com/dechamps/WinIPBroadcast

Here's more discussion about the broadcast issue in general:
http://serverfault.com/questions/72112/how-to-alter-the-global-broadcast-address-255-255-255-255-behavior-on-windows