Fwd: Configure HA VPN using tinc at AWS

Stanislav Krasnoyarov stanislav.krasnoyarov at gmail.com
Fri Sep 16 16:13:00 CEST 2016


Ok, I've found it, it's still masquerading. In case of "source -> tinc1 ->
tinc3 -> tinc2 -> xx" tinc2 did masquerade response packet. I think I just
have to exclude 172.31.0.0/16 subnet from masquerading.

It is still unclear though if there's a way for tinc to reply to the same
node it had received an incoming packet from.

On Fri, Sep 16, 2016 at 4:55 PM, Stanislav Krasnoyarov <
stanislav.krasnoyarov at gmail.com> wrote:

> Actually I was wrong on masquerading. I've set it up the other way to
> masquerade packets from tinc3 to the internet via tinc1/tinc2.
>
> Subnet = 172.31.0.0/16 is there for both tinc1 and tinc2 as well as route
> for tinc3. I can reach any private instance from tinc3.
>
> > the return packet from tinc3 should end up back at tinc1, not tinc2.
> I suspect tinc doesn't reply to the same node, but uses generic rules to
> resolve destination.
>
> Anyway since masquerading is off the table then any route should work
> fine. Let me run a few more tcpdumps.
>
> On Fri, Sep 16, 2016 at 4:15 PM, Guus Sliepen <guus at tinc-vpn.org> wrote:
>
>> On Fri, Sep 16, 2016 at 02:35:01PM +0300, Stanislav Krasnoyarov wrote:
>>
>> > Tinc 1 ip: 172.22.0.101, 21.0.0.1
>> > Tinc 2 ip: 172.22.0.102, 21.0.0.2
>> >
>> > I've setup a VPC route table to route all requests to 21.0.0/24 to tinc
>> 1
>> > and had configured tinc nodes to use masquerading. It works perfectly
>> when
>> > a traffic flows like this:
>> >
>> > source -> tinc1 -> tinc3 -> tinc1 -> source
>> >
>> > But if tinc3 replies to a different node there is a problem since
>> there's
>> > no masquerading record for that request
>> >
>> > source -> tinc1 -> tinc3 -> tinc2 -> xx
>>
>> How would this happen? If tinc1 masquerades the source address to
>> 21.0.0.1, then the return packet from tinc3 should end up back at tinc1,
>> not tinc2.
>>
>> In your scenario, you might not need masquerading: just add Subnet =
>> 172.31.0.0/16 to hosts/tinc1 and hosts/tinc2, and the following line to
>> the tinc-up file of the tinc daemon on the LAN:
>>
>> ip route add 172.31.0.0/16 dev $INTERFACE
>>
>> This should allow traffic between your EC2 instances and 21.0.0.11
>> without any masquerading. It then also doesn't matter what route the
>> (return) packets use.
>>
>> --
>> Met vriendelijke groet / with kind regards,
>>      Guus Sliepen <guus at tinc-vpn.org>
>>
>> _______________________________________________
>> tinc mailing list
>> tinc at tinc-vpn.org
>> https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
>>
>>
>>

ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20160916/7b72fabf/attachment-0001.html>


More information about the tinc mailing list