thr3ads.net - tinc - Windows Firewall, network discovery [Apr 2015]

If this information is useful, please help other people find it:
Share via:

Erik Popp

2015-Apr-02 20:05 UTC

Windows Firewall, network discovery

<html>
  <head>
    <meta http-equiv="content-type" content="text/html;
charset=UTF-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    I have a simple VPN that consists of:<br>
    <ul>
      <li>1 Xubuntu box</li>
      <li>1 Windows 7 desktop</li>
      <li>1 Windows 8 laptop</li>
    </ul>
    <p>There are a couple of other machines that I had at one time
      added, but they're almost never active.<br>
    </p>
    <p>The Xubuntu box is in my grandparents' home network, the
Windows
      7 desktop at my parents' home, and the laptop is sometimes in one,
      sometimes the other, and sometimes in other networks.<br>
    </p>
    <p>The Xubuntu box and Windows 7 box each have port forwarding set
      up, so that they can ping each other, and I can even do backups
      with rsync through an SMB share (painfully slow due to the
      internet's latency).<br>
    </p>
    <p>To reach them, I use a single DDNS host name for both:<br>
      <tt>nslookup blah.example.com<br>
        server:    192.168.1.1<br>
      </tt></p>
    <p><tt>Non-authoritative answer:<br>
        Name:    blah.example.com<br>
        Address: 1.2.3.4<br>
        Name:    blah.example.com<br>
        Address: 5.6.7.8<br>
      </tt></p>
    <p>I know that the DDNS works because I can ping each router from
      the other network, and I can access the router on one that I've
      set up SSH on.<br>
    </p>
    <p>The VPN operates on layer 2, using the <tt>mode =
switch</tt>
      option, and has the IPv4 address block 192.168.2.0<br>
    </p>
    <p>I don't keep any one machine going all the time, although I
have
      a router that I plan to eventually put tinc on, and that'll be up
      24/7.  Usually, at least 1 of these machines is down.<br>
    </p>
    <p>I have 3 separate problems:<br>
    </p>
    <ol>
      <li>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.<br>
        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.<br>
      </li>
      <li>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.</li>
      <li>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.<br>
      </li>
    </ol>
    <p>tinc.conf on xubuntu box:<br>
    </p>
    <p><tt>Name = gaius<br>
        Device = /dev/net/tun<br>
        LocalDiscovery = yes<br>
        Mode = switch<br>
        ConnectTo = proctor<br>
        ConnectTo = valerian<br>
        ConnectTo = octavian<br>
        ConnectTo = lucius<br>
      </tt></p>
    <p>tinc-up on Xubuntu box:</p>
    <p><tt>#!/bin/bash<br>
        <br>
        ifconfig "$INTERFACE" 192.168.2.2<br>
      </tt></p>
    <p>Host file for Xubuntu box:<br>
    </p>
    <p><tt>#host info for machine "gaius"<br>
        <br>
        #the address/domain that this host can be reached at<br>
        Address = blah.example.com<br>
        <br>
        #to do: pick the strongest cipher available<br>
        Cipher = blowfish<br>
        Digest = sha1<br>
        <br>
        #experiment to find what's the best compression level for
me<br>
        #Compression = 11#"fast lzo"<br>
        <br>
        #I'm not quite sure what this does anymore, so I'm gonna see
        what happens when <br>
        #I disable it<br>
        #IndirectData = yes<br>
        <br>
        #it's a bit confusing, but this is not a subnet mask.<br>
        #instead, it's the address/address range that this machine is
<br>
        #responsible for routing packets to.<br>
        #usually, a tinc daemon is responsible for routing packets only
        <br>
        #to itself, but if you set a subnet that's the same as your
        LAN's <br>
        #address range, it's effectively a proxy to the inside of the
<br>
        #rest of your physical LAN.<br>
        Subnet = 192.168.2.2/32<br>
        <br>
        -----BEGIN RSA PUBLIC KEY-----</tt><br>
    </p>
    <p><tt>*snip</tt><tt>*<br>
      </tt></p>
    <p><tt>-----END RSA PUBLIC KEY-----<br>
      </tt></p>
    <p><br>
      tinc.conf on Windows 7 box:<br>
    </p>
    <p><tt>Name = valerian<br>
        Mode = switch<br>
        <br>
        ConnectTo = gaius<br>
        ConnectTo = proctor<br>
        ConnectTo = octavian<br>
        ConnectTo = lucius<br>
        <br>
        #the network interface that tinc listens on<br>
        Interface = VPN Virtual Network Card<br>
        <br>
        #allows tinc machines on the same LAN to find each <br>
        #other and talk to each other using each others' <br>
        #LAN addresses<br>
        LocalDiscovery = yes<br>
        <br>
        #May help some with latency issues<br>
        ProcessPriority = high<br>
        <br>
        PrivateKeyFile = C:\Program Files
        (x86)\tinc\modulus\rsa_key.priv</tt><br>
    </p>
    <p>host file for Windows 7 box:<br>
    </p>
    <p><tt>#the public address where this machine can be
found<br>
        Address = blah.example.com<br>
        <br>
        #this is the subnet that this machine is the next hop to<br>
        Subnet = 192.168.2.3/32<br>
        Cipher = blowfish<br>
        Digest = sha1<br>
        <br>
        #compression types:<br>
        #0 = off<br>
        #1-9 = zlib, higher number is better compression<br>
        #10-11 = lzo, higher number is better compression<br>
        Compression = 11<br>
        <br>
      </tt><tt>-----BEGIN RSA PUBLIC KEY-----</tt><br>
    </p>
    <p><tt>*snip</tt><tt>*<br>
      </tt></p>
    <p><tt>-----END RSA PUBLIC KEY-----<br>
      </tt></p>
    <p><br>
    </p>
    tinc.conf on Windows 8 laptop:<br>
    <p><tt>#tinc.conf for machine code-named
"proctor"<br>
        Name = proctor<br>
        ConnectTo = gaius<br>
        ConnectTo = valerian<br>
        ConnectTo = octavian<br>
        ConnectTo = lucius<br>
        <br>
        #set this once I discover what the name of the tun/tap device
        will be<br>
        Interface = tinc-vpn<br>
        <br>
        #hopefully, there won't be any conflict between this and the use
        of a tun (layer 3) device<br>
        Mode = switch<br>
        <br>
        #Allows computers running tinc to find each other automatically
        if they're on the same local network<br>
        LocalDiscovery = yes</tt></p>
    <p>host file for Windows 8 laptop:<br>
    </p>
    <p><tt>#host file for machine "proctor"<br>
        #in newer versions of tinc, this line is no longer required.<br>
        #if you omit it in every machine's copy, nobody can find it,
<br>
        #but it might be able to find other machines.<br>
        #if it tries to connect to a machine that it doesn't know the
<br>
        #real address for, any other machine that it does know should <br>
        #introduce the two machines so they can talk directly<br>
        <br>
        #Address = blah.example.com<br>
        <br>
        #turn off security until I get it up and running<br>
        Cipher = blowfish<br>
        Digest = sha1<br>
        <br>
        #experiment with different compression levels to find out what's
        practical<br>
        #Compression = 11#"best lzo"<br>
        <br>
        #a useful dynamic routing feature, I think.  I'm not sure what
        it does anymore<br>
        #IndirectData = yes<br>
        <br>
        #Is this needed?<br>
        Subnet = 192.168.2.1/32</tt><br>
      <tt><br>
        -----BEGIN RSA PUBLIC KEY-----</tt><br>
    </p>
    <p><tt>*snip</tt><tt>*<br>
      </tt></p>
    <p><tt>-----END RSA PUBLIC KEY-----</tt></p>
    <p><br>
    </p>
  </body>
</html>

Etienne Dechamps

2015-Apr-03 10:27 UTC

head link

Windows Firewall, network discovery

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

Apparently Analagous Threads

Search for more maybe matching threads

tinc - Apr 2015 - Windows Firewall, network discovery

Windows Firewall, network discovery

Windows Firewall, network discovery

Apparently Analagous Threads