[Vtun-Commit] CVS: The file 'vtun/vtund.conf.5' has been modified.

[Bishop <mtbishop>]

The following file was modified in vtun:

Name            Old version     New version     Comment
----            -----------     -----------     -------
vtund.conf.5    1.4.2.1         1.4.2.1.8.1     

The accompanying log:

Initial check-in of Delayed UDP (Nat Hack) feature for working with
unpleasant NATs, submitted by Dragos Vingarzan (rfe2636157)


The diff of the modified file(s):

--- vtund.conf.5	29 Jun 2007 05:26:47 -0000	1.4.2.1
+++ vtund.conf.5	3 Mar 2009 04:15:33 -0000	1.4.2.1.8.1
@@ -145,6 +145,33 @@
 UDP is recommended for \fBether\fR and \fBtun\fR tunnels only.
 This option is ignored by the client.
 
+.IP \fBnat_hack\ \fBclient\fR|\fBserver\fR|\fBno\fR
+side to use nat_hack on.  By default, \fBvtund\fR(8) uses a 'no' setting.
+The side that the NAT hack is enabled on will perform a delayed UDP socket
+connect. Should only be enabled for the side outside of the NAT (typically 
+the server)! Setting 'client' on the server or 'server' on the client is 
+ignored, as to make a single configuration file reusable on both sides.
+
+This is only relevant if you use \fBproto udp\fR. The NAT hack delays
+the UDP socket connect until the first UDP packet is received from the other
+side of the tunnel. The socket is then connected to the actual source port of
+the packet (on the NAT box) and not to the one indicated in the handshake 
+(which is behind NAT and probably unreachable). 
+The first echo request is also disabled on the side with the NAT hack enabled.
+
+Currently the mechanism works only for one side, for a single NAT traversal.
+If you enable it for both sides, both will wait for a first packet and the 
+tunnel will never transport any data.
+
+\fBSecurity warning!\fR Due to the nature of the delayed connection, the tunnel
+can be hijacked in theory by an attacker behind the same NAT, sending the first 
+UDP packet to the server UDP port, before the real client does. If you do not 
+understand the risks, or want to remain as secure as possible behind this kind
+of NAT router, use \fBproto tcp\fR as a NAT traversal solution.
+
+Because of the security issue mentioned above, this option might be disabled
+during compilation (configure --disable-nathack). 
+
 .IP \fBtimeout\ \fIsecounds\fR
 Connect timeout.