LocalDiscovery flip flopping and network design tips

Thu May 11 21:01:20 CEST 2017

These two networks can be the same, i.e. the VPN can be an extension of
your local network, sharing the same subnet. That's one the many ways
things can be set up. The same result can be achieved through other ways
(e.g. Ethernet-level bridging). This does not contradict my earlier
statement: a subnet can be *both* inside *and* outside the VPN, depending
on the scenario.

The Subnet configuration option indicates the subnets that you want tinc to
route towards your node. tinc doesn't care whether these subnets are also
part of a physical network or not; it just uses it to route packets inside
the VPN, once they leave the VPN tinc's job is done. Technically you can
put anything you want in your Subnet options; it all depends on what
behavior you want to achieve in the end. Depending on your goal, use case
and other constraints, you can end up with a very standard configuration
(e.g. VPN has a dedicated subnet, each node as a single address, no
inter-subnet routing) to highly configurations involving bridges, NATs and
complicated routing rules. There's no single answer to these questions.
Tools like tinc are highly flexible, and that's a good thing :)

In the example you linked to, the "office" node exposes the subnet of a
physical network (192.168.1.0/24) through tinc, so that when "roadwarrior"
sends packets to that subnet, tinc will route them towards the "office"
node, which will then forward it over the physical network (assuming it's
properly configured to do so at the OS level - again, after packets leave
the VPN it's not tinc's responsibility anymore). In the other direction,
"roadwarrior" is set up with a single address (192.168.1.123) and at the OS
routing table level the "office" node is configured to treat that address
specially, so that it knows that packets going to that address should be
sent to the virtual network interface managed by tinc (instead of the
physical network), which will then use its own internal routing systems
(configured by the Subnet options) to send the packet to "roadwarrior".

On 11 May 2017 at 04:40, James Hartig <james at levenlabs.com> wrote:

> @Etienne, I understood your explanation about the Subnet being the network
> *inside* the VPN, but the following the example https://www.tinc-vpn.org/
> examples/proxy-arp/, it seems to have:
> Subnet = 192.168.1.0/24
> for the office, yet the IP address for the office is 192.168.1.2.
>
> Is that example no longer valid or am I misunderstanding?
>
> On Tue, Feb 14, 2017 at 4:01 PM, James Hartig <james at levenlabs.com> wrote:
>
>> On Tue, Feb 14, 2017 at 3:43 PM, Etienne Dechamps <etienne at edechamps.fr>
>> wrote:
>> > Hang on a second. I've just re-read your original message and I
>> > believe you are confused about what the "Subnet" option does. Again,
>> > it deals with addresses *inside* the VPN. In the configuration you
>> > posted you seem to be using 10.240.0.4 and 10.240.0.5 as internal
>> > addresses, but then your other statements (and especially your dump
>> > edges output) seem to indicate that 10.240.0.4 and 10.240.0.5 are
>> > *also* the physical addresses of the machines on their physical
>> > network interfaces.
>> >
>> > That's not going to work: as soon as tinc manages to establish the
>> > VPN, 10.240.0.4 and 10.240.0.5 become routable on *both* the virtual
>> > and physical interfaces, resulting in conflicts, and it all goes
>> > downhill from there. That would completely explain the weird phenomena
>> > you're reporting. If you make sure to use different IP subnets for VPN
>> > addresses and physical addresses, your problems should go away.
>>
>> That's kind of intentional. I want tinc to be able to receive traffic
>> destined the local network over the tinc tunnel. I might be doing this
>> wrong and obviously I'm open to suggestions.
>>
>> test_tinc_1 has an internal IP of 10.240.0.4/16
>> test_tinc_1 config is:
>> Subnet = 10.240.0.0/16
>> Subnet = 10.240.0.4/32
>> Address = 104.154.59.151
>>
>> I want other nodes being able to talk to test_tinc_1 to be able to
>> talk to the network that test_tinc_1 is on. I might not need "Subnet =
>> 10.240.0.0/16" if I expect all of the nodes in 10.240.x.x to have tinc
>> installed, right? Will it still forward packets onto the other tinc
>> instances if I just have "Subnet = 10.240.0.4/32"? I think I need tinc
>> because otherwise if a server on 10.240.x.x doesn't have tinc, it
>> won't know how to route the packet back to 10.80.0.0/16 ip (see
>> below). When I create the actual tun0 interface for test_tinc_1, I use
>> a useless subnet: 192.168.0.1/24.
>>
>> Here's how I have it working and how I envisioned it working:
>>
>> (keeping the same test_tinc_1 as above)
>> test_other_1 has an internal IP of 10.80.0.2/16
>> test_other_1 config is:
>> Subnet = 10.80.0.0/16
>> Subnet = 10.80.0.2/16
>> Address = 128.227.195.201
>>
>> test_other_1's tun0 interface has the IP address 192.168.0.2/24 and
>> after it comes up I do:
>> ip route add 10.240.0.0/16 dev tun0
>>
>> test_tinc_1's tun0 interface has a similar route for 10.80.0.0/16
>>
>> When test_other_1 comes up, test_other_1 can talk to 10.240.0.4 and
>> other 10.240.x.x servers as long as they have tinc installed (and
>> their tun0 interfaces having 192.168.0.x addresses). If I used
>> iptables masquerading then I could get it talking to non-tinc servers
>> in 10.240.x.x, but some of our applications rely on the source IP to
>> be connectable (like mongo, cassandra, etc) so I can't use
>> masquerading.
>>
>> I'm definitely open and hopeful for a better way of doing this.
>> Essentially we want to extend the existing networks out to all of our
>> boxes. So if we have 4 DCs with subnets 10.240.0.0/16, 10.260.0.0/16,
>> 10.80.0.0/16, 10.100.0.0/16, we want all of the boxes in each of those
>> DCs to use their internal IPs to talk to any other server's internal
>> IPs without masquerading. We get this for free with Google Compute for
>> 3 of those subnets but we can't use Google Compute for all of our
>> servers (developer machines, other non-google regions, etc), so that's
>> why were looking into tinc. We are currently using openvpn for this
>> but we want something that is mesh so we can handle something like the
>> openvpn master server going down.
>>
>> > On 14 February 2017 at 20:36, Etienne Dechamps <etienne at edechamps.fr>
>> wrote:
>> >> On 14 February 2017 at 18:59, James Hartig <james at levenlabs.com>
>> wrote:
>> >>> When you say "and to the local network" what IP does it try to send to
>> >>> on the local network? The subnet address?
>> >>
>> >> No. The Subnet option deals with routing *inside* the VPN, not the
>> >> underlying "real" network.
>> >>
>> >> In tinc 1.1, the address that local discovery probes are sent to is
>> >> the local address of the recipient node, as determined by the socket
>> >> local address of its metaconnection. That's the address shown next to
>> >> "local" in the dump edges output. In your case the local address is
>> >> advertised correctly - there is no problem there.
>>
>
>
>
> --
>
>
> James Hartig
> Co-Founder
> (352) 608-8859 <3526088859>
> james at getadmiral.com
> getadmiral.com
>
> How much are you losing to adblockers? Find out for free with Admiral
> <http://getadmiral.com/>.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20170511/aa2eb310/attachment.html>