<div dir="ltr"><div>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.<br><br>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 :) <br><br></div><div>In the example you linked to, the "office" node exposes the subnet of a physical network (<a href="http://192.168.1.0/24">192.168.1.0/24</a>) 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".<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 11 May 2017 at 04:40, James Hartig <span dir="ltr"><<a href="mailto:james@levenlabs.com" target="_blank">james@levenlabs.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>@Etienne, I understood your explanation about the Subnet being the network *inside* the VPN, but the following the example <a href="https://www.tinc-vpn.org/examples/proxy-arp/" target="_blank">https://www.tinc-vpn.org/<wbr>examples/proxy-arp/</a>, it seems to have:</div><div>Subnet = <a href="http://192.168.1.0/24" target="_blank">192.168.1.0/24</a></div><div>for the office, yet the IP address for the office is 192.168.1.2.</div><div><br></div><div>Is that example no longer valid or am I misunderstanding?</div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Tue, Feb 14, 2017 at 4:01 PM, James Hartig <span dir="ltr"><<a href="mailto:james@levenlabs.com" target="_blank">james@levenlabs.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Tue, Feb 14, 2017 at 3:43 PM, Etienne Dechamps <<a href="mailto:etienne@edechamps.fr" target="_blank">etienne@edechamps.fr</a>> wrote:<br>
> Hang on a second. I've just re-read your original message and I<br>
> believe you are confused about what the "Subnet" option does. Again,<br>
> it deals with addresses *inside* the VPN. In the configuration you<br>
> posted you seem to be using 10.240.0.4 and 10.240.0.5 as internal<br>
> addresses, but then your other statements (and especially your dump<br>
> edges output) seem to indicate that 10.240.0.4 and 10.240.0.5 are<br>
> *also* the physical addresses of the machines on their physical<br>
> network interfaces.<br>
><br>
> That's not going to work: as soon as tinc manages to establish the<br>
> VPN, 10.240.0.4 and 10.240.0.5 become routable on *both* the virtual<br>
> and physical interfaces, resulting in conflicts, and it all goes<br>
> downhill from there. That would completely explain the weird phenomena<br>
> you're reporting. If you make sure to use different IP subnets for VPN<br>
> addresses and physical addresses, your problems should go away.<br>
<br>
</span>That's kind of intentional. I want tinc to be able to receive traffic<br>
destined the local network over the tinc tunnel. I might be doing this<br>
wrong and obviously I'm open to suggestions.<br>
<br>
test_tinc_1 has an internal IP of <a href="http://10.240.0.4/16" rel="noreferrer" target="_blank">10.240.0.4/16</a><br>
test_tinc_1 config is:<br>
<span>Subnet = <a href="http://10.240.0.0/16" rel="noreferrer" target="_blank">10.240.0.0/16</a><br>
Subnet = <a href="http://10.240.0.4/32" rel="noreferrer" target="_blank">10.240.0.4/32</a><br>
Address = 104.154.59.151<br>
<br>
</span>I want other nodes being able to talk to test_tinc_1 to be able to<br>
talk to the network that test_tinc_1 is on. I might not need "Subnet =<br>
<a href="http://10.240.0.0/16" rel="noreferrer" target="_blank">10.240.0.0/16</a>" if I expect all of the nodes in 10.240.x.x to have tinc<br>
installed, right? Will it still forward packets onto the other tinc<br>
instances if I just have "Subnet = <a href="http://10.240.0.4/32" rel="noreferrer" target="_blank">10.240.0.4/32</a>"? I think I need tinc<br>
because otherwise if a server on 10.240.x.x doesn't have tinc, it<br>
won't know how to route the packet back to <a href="http://10.80.0.0/16" rel="noreferrer" target="_blank">10.80.0.0/16</a> ip (see<br>
below). When I create the actual tun0 interface for test_tinc_1, I use<br>
a useless subnet: <a href="http://192.168.0.1/24" rel="noreferrer" target="_blank">192.168.0.1/24</a>.<br>
<br>
Here's how I have it working and how I envisioned it working:<br>
<br>
(keeping the same test_tinc_1 as above)<br>
test_other_1 has an internal IP of <a href="http://10.80.0.2/16" rel="noreferrer" target="_blank">10.80.0.2/16</a><br>
test_other_1 config is:<br>
Subnet = <a href="http://10.80.0.0/16" rel="noreferrer" target="_blank">10.80.0.0/16</a><br>
Subnet = <a href="http://10.80.0.2/16" rel="noreferrer" target="_blank">10.80.0.2/16</a><br>
Address = 128.227.195.201<br>
<br>
test_other_1's tun0 interface has the IP address <a href="http://192.168.0.2/24" rel="noreferrer" target="_blank">192.168.0.2/24</a> and<br>
after it comes up I do:<br>
ip route add <a href="http://10.240.0.0/16" rel="noreferrer" target="_blank">10.240.0.0/16</a> dev tun0<br>
<br>
test_tinc_1's tun0 interface has a similar route for <a href="http://10.80.0.0/16" rel="noreferrer" target="_blank">10.80.0.0/16</a><br>
<br>
When test_other_1 comes up, test_other_1 can talk to 10.240.0.4 and<br>
other 10.240.x.x servers as long as they have tinc installed (and<br>
their tun0 interfaces having 192.168.0.x addresses). If I used<br>
iptables masquerading then I could get it talking to non-tinc servers<br>
in 10.240.x.x, but some of our applications rely on the source IP to<br>
be connectable (like mongo, cassandra, etc) so I can't use<br>
masquerading.<br>
<br>
I'm definitely open and hopeful for a better way of doing this.<br>
Essentially we want to extend the existing networks out to all of our<br>
boxes. So if we have 4 DCs with subnets <a href="http://10.240.0.0/16" rel="noreferrer" target="_blank">10.240.0.0/16</a>, 10.260.0.0/16,<br>
<a href="http://10.80.0.0/16" rel="noreferrer" target="_blank">10.80.0.0/16</a>, <a href="http://10.100.0.0/16" rel="noreferrer" target="_blank">10.100.0.0/16</a>, we want all of the boxes in each of those<br>
DCs to use their internal IPs to talk to any other server's internal<br>
IPs without masquerading. We get this for free with Google Compute for<br>
3 of those subnets but we can't use Google Compute for all of our<br>
servers (developer machines, other non-google regions, etc), so that's<br>
why were looking into tinc. We are currently using openvpn for this<br>
but we want something that is mesh so we can handle something like the<br>
openvpn master server going down.<br>
<div class="m_2824606348813029506HOEnZb"><div class="m_2824606348813029506h5"><br>
> On 14 February 2017 at 20:36, Etienne Dechamps <<a href="mailto:etienne@edechamps.fr" target="_blank">etienne@edechamps.fr</a>> wrote:<br>
>> On 14 February 2017 at 18:59, James Hartig <<a href="mailto:james@levenlabs.com" target="_blank">james@levenlabs.com</a>> wrote:<br>
>>> When you say "and to the local network" what IP does it try to send to<br>
>>> on the local network? The subnet address?<br>
>><br>
>> No. The Subnet option deals with routing *inside* the VPN, not the<br>
>> underlying "real" network.<br>
>><br>
>> In tinc 1.1, the address that local discovery probes are sent to is<br>
>> the local address of the recipient node, as determined by the socket<br>
>> local address of its metaconnection. That's the address shown next to<br>
>> "local" in the dump edges output. In your case the local address is<br>
>> advertised correctly - there is no problem there.<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div class="m_2824606348813029506gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><table style="font-family:"Times New Roman";background:none;border:0px;margin:0px;padding:0px" cellspacing="0" cellpadding="0" border="0"><tbody><tr><td cellspacing="0" cellpadding="0" width="10"> </td></tr><tr><td cellspacing="0" cellpadding="0" width="36" valign="top" height="36"><img src="https://cdn.getadmiral.com/email/james-signature.jpg" width="36" height="36"></td><td cellspacing="0" cellpadding="0" width="10"> </td><td cellspacing="0" cellpadding="0" valign="top"><table style="background:none;border:0px;margin:0px;padding:0px" cellspacing="0" cellpadding="0" border="0"><tbody><tr><td colspan="2" style="color:rgb(66,79,120);font-size:14px;font-weight:bold;font-family:"Source Sans Pro",Helvetica,sans-serif">James Hartig</td></tr><tr><td style="color:rgb(141,150,179);font-size:13px;font-family:"Source Sans Pro",Helvetica,sans-serif" valign="center" height="16">Co-Founder</td></tr><tr><td valign="center" height="16"><a href="tel:3526088859" style="font-family:"Source Sans Pro",Helvetica,sans-serif;color:rgb(141,150,179);font-size:13px;text-decoration:none" target="_blank">(352) 608-8859</a></td></tr><tr><td valign="center" height="16"><a href="mailto:james@getadmiral.com" style="font-family:"Source Sans Pro",Helvetica,sans-serif;color:rgb(141,150,179);font-size:13px" target="_blank">james@getadmiral.com</a></td></tr><tr><td valign="center" height="16"><a href="http://getadmiral.com/" style="font-family:"Source Sans Pro",Helvetica,sans-serif;color:rgb(141,150,179);font-size:13px" target="_blank">getadmiral.com</a></td></tr><tr><td cellspacing="0" cellpadding="0" width="10"> </td></tr><tr><td style="color:rgb(141,150,179);font-size:13px;font-family:"Source Sans Pro",Helvetica,sans-serif" valign="center" height="16">How much are you losing to adblockers? <a href="http://getadmiral.com/" style="color:rgb(141,150,179)" target="_blank">Find out for free with Admiral</a>.</td></tr></tbody></table></td></tr></tbody></table></div></div>
</font></span></div>
</blockquote></div><br></div>