Hi Erik, On 2 April 2015 at 21:05, Erik Popp <[email protected]> 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 _______________________________________________ tinc mailing list [email protected] http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
