Hi Roderick, well, in the first place I tried to keep it small. I am working on openimscore.org and there we deal with SIP/RTP and getting it over NAT, but we always have one side outside of the NAT. There this hack, of discovering the pinhole seems to work kind of always, as I did not get any complaints about situations that it doesn't.
Then I am not really a NAT specialist. If both sides are behind NAT, certainly some complicated solution with using a 3rd party anchor would work, but in my mind these would be quite complicated to get working, without a public VTUN relay or something, which of course does not sound that nice. Then if it is too complicated, is it worth it? But as I said, I am not a NAT specialist, so I can't even name the type of NAT which maps (srcIP,srcPort,proto,dstIP,dstPort) to each association, other than "nasty" :-p. You can take the patch and use it wherever you like. Anyway, wasn't me inventing the NAT pinholes ;-) . Cheers, -Dragos Roderick Groesbeek wrote: > Hi Dragos, > > Great work! > 1/2 year ago I played with OpenWRT, HSPA and Vtun. > > Because of VTUN not supporting UDP nasty Nat's, we ended up building our > own custom solution. Which we currently use... > > But this was definitely something on my wishlist for Vtun. > It seems like a small patch, maybe it should also been taken in on the > OpenWRT patch repository? > > > > P.s. > Would it be an option to let both parties try to punch UDP holes to each > other, communicating the results over the TCP? [STUN/ICE] > This would omit special NAT hack configuration, would penetrate more > NAT's, maybe also double/triple nat's then. > -- > Vriendelijke Groet, > > Roderick > -- > TRIPLE IT > straat://Pettemerstraat 12A > postcode://1823 CW > plaats://Alkmaar > tel://+31(0)72-5129516 > fax://+31(0)72-5129520 > http://www.triple-it.nl "Laat uw Net Werken!" > > > -----Original Message----- > From: Dragos Vingarzan [mailto:dragos.vingar...@gmail.com] > Sent: Friday, February 13, 2009 7:40 PM > To: vtun-devel@lists.sourceforge.net > Subject: [Vtun-devel] Patch for overcoming NAT with UDP tunnels > > Hi all, > > first of all, thanx for the nice vtun! > > Then I have a patch. I was using vtun over some UMTS connection and then > > I hit a nasty NAT. Worked fine over TCP, of course, but the issue was > that the UDP stream was mapped by the NAT box to a different port. And I > > really wanted to keep the UDP encapsulation (most of my packets would be > > RTP and I do have packet-loss). > > So vtun does the handshake but the the UDP socket is mapped to another > port on the NAT as the one that the client behind NAT indicated in the > handshake. The UDP connect happens with the parameters as the source of > the TCP packets and the indicated port in the handshake, which means > that the actual NATed UDP packets are dropped. > > The idea, which seems to work, was to delay the connect until the first > packet is received and then use the real UDP from address. This of > course would not work if applied on both sides, so I added an extra > parameter ("-N" NAT hack) and a couple of global variables to > orchestrate the delayed connect of the UDP socket. I also disabled the > first Echo Request as there would be no destination port to send to > (this however could be worked around by using sendto() instead of > write()). > > Well, I hacked this quickly, so probably many things are not kosher with > > the line of the project, but it should be enough to get the idea. > > I am looking forward for feedback, even if you would completely reject > the patch. > > Cheers, > -Dragos > > -- Best Regards, Dragos Vingarzan ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ VTun-devel mailing list VTun-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/vtun-devel
