Hi Dragos,
I think your patch has definite value, as it can help overcome a
potential problem when traversing firewalls. There is value in keeping
this code in the codebase, so that further development won't prevent you
from using this method to navigate this somewhat broken kind of NAT.
I worry about the occasional 'security researcher' the kind who finds a
copy of vtun, intentionally compiles it and enables all the risky code
possible, and then publishes an assessment of this build as if it were
common or default. Anything risky we put into vtun, I think, should
require a compiler flag to enable. That way we can protect the unwary
and remind others that by default there's no reduction in security.
I think the global variable is mostly okay. There's already various
switches for log level or whatnot.
The way the UDP connection is set up also worries me. I think that's
just a concern over the way it's already being done now, though, and
nothing to do with your patch. I'd feel a lot better if the delayed UDP
start was a per-profile option (like proto or persist) so that if we -D
NAT_HACK in the compilation, we can then say nat_hack=1 in the
vtund.conf and allow just one peer (client) to delay the UDP connection
set-up.
How do you feel about that?
- compile switch to enable the code
- vtund.conf option ; not a command-line option
- diff -u ;-)
What does everyone else think about this patch? Can we quiet the
security gibbons with a compile-time switch? has anyone else run into
this kind of a NAT setup, needed UDP and seen any other workarounds?
- bish
Dragos Vingarzan wrote:
> 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
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> 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
--
People don't know that vi was written for a world that
doesn't exist anymore -- Bill Joy, creator of vi
http://www.theregister.co.uk/2003/09/11/bill_joys_greatest_gift/
------------------------------------------------------------------------------
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
