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 <
> 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 <g...@tinc-vpn.org> wrote:
>> On Fri, Sep 16, 2016 at 02:35:01PM +0300, Stanislav Krasnoyarov wrote:
>> > Tinc 1 ip: 172.22.0.101, 22.214.171.124
>> > Tinc 2 ip: 172.22.0.102, 126.96.36.199
>> > I've setup a VPC route table to route all requests to 21.0.0/24 to tinc
>> > and had configured tinc nodes to use masquerading. It works perfectly
>> > a traffic flows like this:
>> > source -> tinc1 -> tinc3 -> tinc1 -> source
>> > But if tinc3 replies to a different node there is a problem since
>> > no masquerading record for that request
>> > source -> tinc1 -> tinc3 -> tinc2 -> xx
>> How would this happen? If tinc1 masquerades the source address to
>> 188.8.131.52, 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 184.108.40.206
>> without any masquerading. It then also doesn't matter what route the
>> (return) packets use.
>> Met vriendelijke groet / with kind regards,
>> Guus Sliepen <g...@tinc-vpn.org>
>> tinc mailing list
tinc mailing list