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
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, 220.127.116.11
> > Tinc 2 ip: 172.22.0.102, 18.104.22.168
> > 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
> > 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
> 22.214.171.124, 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 126.96.36.199
> 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