Hi bish,
I thought about the security too... maybe including some authentication
info in the echo request/reply would help. Also it wouldn't hurt if the
remote address is also sent in the handshake and only on NAT detection
the NAT hack would be actually used.
Then the first instantiation of the patch, the prototype that I tried to
see if it works or not, was with ifdefs. But I was bothered by the fact
that I needed to keep 2 builds around and try them and see which works.
So the parameter was logically easier to use and I overwrote all the
ifdefs with the nat_hack parameter and kept a single build of vtund.
I was also thinking about the vast majority of the users, which would
just pick vtun pre-compiled from a repository and probably won't ever
know that there is a switch to make it work. So I would be more for
keeping it built-in, but indicating in the man page the risk and that
they should keep using TCP if they don't understand or it is not
acceptable. What do you think? Oh, and I do hate that kind of "security
researcher"...
You are right about the configuration file option and not command line.
I was typically using one vtund server for one vtund client and it did
not occur to me. But what if the client is outside of NAT and the server
inside? Then you would need to enable this delay on the other side. So,
should it be nat_hack=client|server?... In the meantime, here's the -u ;-)
Cheers,
-Dragos
bishop wrote:
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
--
Best Regards,
Dragos Vingarzan
diff -w -a -u vtun-3.0.1_orig/linkfd.c vtun-3.0.1/linkfd.c
--- vtun-3.0.1_orig/linkfd.c 2006-12-11 01:55:06.000000000 -0600
+++ vtun-3.0.1/linkfd.c 2009-02-13 11:10:43.000000000 -0600
@@ -212,6 +212,8 @@
return 0;
}
+ /* because server can't send the first VTUN_ECHO_REQ as it would be probably disconnected */
+ if (!vtun.nat_hack)
proto_write(fd1, buf, VTUN_ECHO_REQ);
maxfd = (fd1 > fd2 ? fd1 : fd2) + 1;
diff -w -a -u vtun-3.0.1_orig/main.c vtun-3.0.1/main.c
--- vtun-3.0.1_orig/main.c 2006-12-11 01:55:06.000000000 -0600
+++ vtun-3.0.1/main.c 2009-02-13 11:10:17.000000000 -0600
@@ -76,6 +76,7 @@
vtun.bind_addr.port = -1;
vtun.svr_type = -1;
vtun.syslog = LOG_DAEMON;
+ vtun.nat_hack = 0;
/* Initialize default host options */
memset(&default_host, 0, sizeof(default_host));
@@ -89,7 +90,7 @@
/* Start logging to syslog and stderr */
openlog("vtund", LOG_PID | LOG_NDELAY | LOG_PERROR, LOG_DAEMON);
- while( (opt=getopt(argc,argv,"misf:P:L:t:np")) != EOF ){
+ while( (opt=getopt(argc,argv,"misNf:P:L:t:np")) != EOF ){
switch(opt){
case 'm':
if (mlockall(MCL_CURRENT | MCL_FUTURE) < 0) {
@@ -102,6 +103,9 @@
case 's':
svr = 1;
break;
+ case 'N':
+ vtun.nat_hack = 1;
+ break;
case 'L':
vtun.svr_addr = strdup(optarg);
break;
diff -w -a -u vtun-3.0.1_orig/netlib.c vtun-3.0.1/netlib.c
--- vtun-3.0.1_orig/netlib.c 2006-12-11 01:55:06.000000000 -0600
+++ vtun-3.0.1/netlib.c 2009-02-13 11:09:08.000000000 -0600
@@ -138,6 +138,8 @@
return addr.sin_addr.s_addr;
}
+extern struct vtun_opts vtun;
+int is_rmt_fd_connected=1;
/*
* Establish UDP session with host connected to fd(socket).
* Returns connected UDP socket or -1 on error.
@@ -190,10 +192,14 @@
}
saddr.sin_port = port;
+ if (vtun.nat_hack)
+ is_rmt_fd_connected=0;
+ else{
if( connect(s,(struct sockaddr *)&saddr,sizeof(saddr)) ){
vtun_syslog(LOG_ERR,"Can't connect socket");
return -1;
}
+ }
host->sopt.rport = htons(port);
/* Close TCP socket and replace with UDP socket */
diff -w -a -u vtun-3.0.1_orig/vtund.8 vtun-3.0.1/vtund.8
--- vtun-3.0.1_orig/vtund.8 2006-12-11 01:55:06.000000000 -0600
+++ vtun-3.0.1/vtund.8 2009-02-13 12:06:49.000000000 -0600
@@ -25,6 +25,9 @@
[
.I -P port
]
+[
+.I -N
+]
.LP
.B vtund
[
@@ -45,6 +48,9 @@
[
.I -n
]
+[
+.I -N
+]
<
.I session
>
@@ -75,6 +81,9 @@
.TP
.I -n
Do not become daemon.
+.TP
+.I -N
+Employ the NAT hack for UDP \- in case you want to transport your tunnel over NAT, but the NAT is assigning another outbound port for the UDP packets as for the TCP ones in the handshake. This hack practically disables the first ECHO\-Request packet and delays the UDP socket connect until a first packet has been received over UDP. Do not use for the end behind NAT, just for the one outside. This is of course unsafe as the tunnel can be easily hi\-jacked at the beginning.
.SS Server mode:
.TP
.I -s
diff -w -a -u vtun-3.0.1_orig/vtun.h vtun-3.0.1/vtun.h
--- vtun-3.0.1_orig/vtun.h 2006-12-11 01:55:06.000000000 -0600
+++ vtun-3.0.1/vtun.h 2009-02-13 11:03:33.000000000 -0600
@@ -206,6 +206,7 @@
struct vtun_addr bind_addr; /* Server should listen on this address */
int svr_type; /* Server mode */
int syslog; /* Facility to log messages to syslog under */
+ int nat_hack;
};
#define VTUN_STAND_ALONE 0
#define VTUN_INETD 1
------------------------------------------------------------------------------
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
