At the moment I have 2 network connected in a VPN and I'm planning to extend this. Actual status: Network A has a public IP Network B is behind a provider-scale NAT. Actually I'm using openvpn with a single UDP connection from B to A, and hosts inside Network A can communicate with B. I tried with tinc, and I saw tinc has to go TCP-Only for accomplish this. This is because Tinc can't reutilize incoming UDP connections to reply back - has to set up an outgoing udp connection defined in config (thing that in a NAT-ed environment isn't possible) I saw in git repository that tinc fallbacks to TCP-Only if it can't estabilish a double-UDP connection, that is fine. But shouldn't tinc get the ability to use an inbound tcp connection to answer back the remote host? (maybe setting incoming ip and leaving port blank or something) -- Keiji Costantini
On Tue, Mar 31, 2009 at 7:41 PM, Keiji Costantini <lists at strites.net> wrote:> At the moment I have 2 network connected in a VPN and I'm planning to > extend this. > > Actual status: > Network A has a public IP > Network B is behind a provider-scale NAT. > > Actually I'm using openvpn with a single UDP connection from B to A, and > hosts inside Network A can communicate with B. > > I tried with tinc, and I saw tinc has to go TCP-Only for accomplish > this. This is because Tinc can't reutilize incoming UDP connections to > reply back - has to set up an outgoing udp connection defined in config > (thing that in a NAT-ed environment isn't possible) > > I saw in git repository that tinc fallbacks to TCP-Only if it can't > estabilish a double-UDP connection, that is fine. But shouldn't tinc get > the ability to use an inbound tcp connection to answer back the remote > host? (maybe setting incoming ip and leaving port blank or something) > > -- > Keiji Costantini > > _______________________________________________ > tinc mailing list > tinc at tinc-vpn.org > http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc >It is possible to have end-to-end UDP even when behind NATs if the configuration were moved to dynamic dns with the port # automatically updating a TXT record or some other hub service.
> Actual status: > Network A has a public IP > Network B is behind a provider-scale NAT. > > Actually I'm using openvpn with a single UDP connection from B to A, and > hosts inside Network A can communicate with B. > > I tried with tinc, and I saw tinc has to go TCP-Only for accomplish > this. This is because Tinc can't reutilize incoming UDP connections to > reply back - has to set up an outgoing udp connection defined in config > (thing that in a NAT-ed environment isn't possible)Network A has a public IP, does this mean a server (with tinc) has direct public IP, no NAT? Then UDP should be no problem if you connect from B to A. Only A to B connectiions will work with TCP. Just connect from B to A and all will be fine. ALBI...
On Wed, Apr 01, 2009 at 02:41:43AM +0200, Keiji Costantini wrote:> I saw in git repository that tinc fallbacks to TCP-Only if it can't > estabilish a double-UDP connection, that is fine. But shouldn't tinc get > the ability to use an inbound tcp connection to answer back the remote > host? (maybe setting incoming ip and leaving port blank or something)The problem in tinc is not single connections, it is the full-mesh capability which is hard to get working in a NAT-proof way. The protocol uses the source address + portnumber of UDP packet to determine which node it came from. Simply disregarding the portnumber is not a full solution. I'm trying to rewrite the way tinc handles UDP, but it is pretty invasive. If I have something remotely working I'll commit it. -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus at tinc-vpn.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://www.tinc-vpn.org/pipermail/tinc/attachments/20090401/c61e0755/attachment.pgp
Guus Sliepen escreveu:> [...]The protocol uses the source > address + portnumber of UDP packet to determine which node it came from. Simply > disregarding the portnumber is not a full solution.What about breaking the protocol (with a fallback option) and move this information to the payload instead of relaying on UDP header. This would make easier to make tinc protocol independent in the future. -rsd