Hello, I've got an AWS cloud and a local network. I'd like to setup an access from private EC2 instances to local network tinc server. There are two public EC2 instances with tinc server installed, other (private) EC2 nodes do not have tinc. http://imgur.com/tq84crc VPC subnet: 172.22/16 VPN subnet: 21.0.0/24 Source EC2 instance ip: 172.22.0.100 Tinc 1 ip: 172.22.0.101, 21.0.0.1 Tinc 2 ip: 172.22.0.102, 21.0.0.2 Local network tinc (tinc 3): 21.0.0.11 I need to have an access from 172.22.0.100 to 21.0.0.11. 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 One of the possible ways to resolve this issue would be to install tinc to every private EC2 node. Could you please suggest other ways to implement it? Regards, Stan ᐧ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20160916/56920315/attachment.html>
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 -> xxHow 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> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20160916/393ca5f9/attachment.sig>
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/0c62866b/attachment.html>