search for: tinc2

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 destina...

...ed 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...

...n each data center on its own class C (Netmask 255.255.0.0) and then the routing commands to allow the local tincd daemon to just send the packets On the self contained example, I planned to run 4 instances of TINC. I could run them in 4 different directories with netnames /tinc1/conf/netname/ /tinc2/conf/netname/ /tinc3/conf/netname/ /tinc4/conf/netname/ Is there a way to run tinc without regard to netnames? /tinc1/tincd --config=/tinc1/conf /tinc2/tincd --config=/tinc2/conf /tinc3/tincd --config=/tinc3/conf /tinc4/tincd --config=/tinc4/conf /tinc1/conf/ /tinc1/conf/hosts /tinc2/conf/ /tin...

On Mon, Dec 08, 2014 at 11:02:24PM -0500, md at rpzdesign.com wrote: > The self contained example is tricky because I created 4 ip-address on > the eth0 device (192.168.1.30/31/32/33) so I could test a 4 node VPN > that lives entirely within a single server. That's quite hard to do, it's far easier to run four instances of tinc on four different ports on the same machine. >

...rks 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...

...two Amazon EC2 instances (micro) running tincd. Each is running dnsmasq to provide a dhcp server for tinc users. Their configuration looks something like this: [tinc1:/etc/tinc/tincnet/tinc.conf] Name = tinc1 AddressFamily = ipv4 Interface = tun0 Mode = switch ConnectTo = tinc1 ConnectTo = tinc2 [tinc1:/etc/tinc/tincnet/hosts/tinc1] Address = 10.100.250.100 Subnet = 172.31.1.1/32 [tinc1:/etc/tinc/tincnet/tinc-up] #!/bin/sh ifconfig $INTERFACE 172.31.1.1 netmask 255.255.0.0 [tinc1:/etc/dnsmasq.d/devnet-dhcp] interface=tun0 bind-interfaces # Dynamic IP range dhcp-range=172.31.1.11...

...ht recvmsg was complex, look at recvmmsg) C) Moving forward, in this case, it looks like I am bottlenecked on my gateway anyway (only eating 36% of cpu at this speed, not showing any substantial delays with SO_TIMESTAMPNS (but I haven't fully checked that) http://snapon.lab.bufferbloat.net/~d/tinc2/native_ipv6.png http://snapon.lab.bufferbloat.net/~d/tinc2/tunneled_classified.png I am a little puzzled as to how well tinc handles out of order packet delivery (the EF,BE,BK(CS1) diffserv queues are handled differently by the shaper on the gateway... and: D) the bottleneck link above is actu...