LocalDiscovery flip flopping and network design tips

[James Hartig]

@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/20170510/f4b924c0/attachment.html>