1pwnat - http://samy.pl/pwnat
2
3pwnat, by Samy Kamkar, is a tool that allows any client
4behind a NAT to communicate with a server behind a
5separate NAT with *no* port forwarding and *no* DMZ
6setup on any routers in order to directly communicate
7with each other.
8
9There is no middle man, no proxy, no 3rd party, no UPnP
10required, no spoofing, no DNS tricks. The server does
11not need to know the client's IP address before connecting.
12
13More importantly, the client can then connect to any
14host or port on any remote host or to a fixed host and
15port decided by the server.
16
17Simply put, this is a proxy server that works behind a NAT,
18even when the client is also behind a NAT.
19
20You can read the paper published in IEEE and presented at
21the IEEE P2P'10 Conference here: http://samy.pl/pwnat/pwnat.pdf
22
23usage: ./pwnat <-s | -c> <args>
24
25 -c client mode
26 <args>: [local ip] <local port> <proxy host> [proxy port (def:2222)] <remote host> <remote port>
27
28 -s server mode
29 <args>: [local ip] [proxy port (def:2222)] [[allowed host]:[allowed port] ...]
30
31 -6 use IPv6
32 -v show debug output (up to 2)
33 -h show this help and exit
34
35
36EXAMPLE:
37
38Server side allowing anyone to proxy:
39 ./pwnat -s
40
41Client wanting to connect to google.com:80:
42 ./pwnat -c 8000 <pwnat.server.com> google.com 80
43
44Then, browse to http://localhost:8000 to visit the google!
45
46
47FAQ
48 Ok, so does this really work?
49 Yes. Try it!
50
51 I'm confused. This can't work.
52 You should be, and it does work.
53
54 But it can't. My NAT blocks incoming packets and so will the other.
55 I know.
56
57 But how?!
58 Great question! I thought you'd never ask.
59 Look below at HOW DOES IT WORK?
60
61 Does this use DNS for anything?
62 No.
63
64 Do I need to setup port forwarding or a DMZ on either end?
65 No.
66
67 Is there some sort of proxy or 3rd party that tunnels information between
68 the two NATs?
69 No. The connection is direct, client to server.
70
71 Will this work behind my corporate NAT and firewall?
72 This will work behind many NATs and firewalls, but not all.
73
74 What uses does this have?
75 This will allow you to tunnel any service that you want to run (http,
76 ssh, quake server, IRC, ftp, etc.) through your NAT, or proxy into
77 other remote servers.
78
79 What if one or both ends aren't behind a NAT?
80 Everything will work just as well. You can use pwnat to tunnel TCP
81 payload over UDP if you wish; no NATs are necessary.
82
83 Does the server have to specify the client host?
84 No! The server doesn't know the client IP address until the client
85 attempts to connect, penetrating the NAT using this unique method.
86
87HOW DOES IT WORK?
88
89 My method of penetrating NATs is two-fold which I will describe below.
90
91 In order for the full tunnel to be established, the client side needs to
92 know the public IP address of the server, and the server needs to learn
93 the public IP address of the client.
94
95 However, in a true client-server model, the server doesn't know the client IP
96 until the client connects, and NATs will normally drop unknown incoming packets.
97 In pwnat, the server also does not need to know the client IP address.
98
99 Here is how the pwnat server learns the IP address of the client:
100 I get around this by having the client "pretend" to be a random hop on
101 the Internet. I'm essentially using the same technology a traceroute uses
102 to detect hops on the Internet, but I'm doing the reverse in order to
103 penetrate the NAT.
104
105 Specifically, when the server starts up, it begins sending fixed ICMP echo
106 request packets to the fixed address 3.3.3.3. We expect that these packets
107 won't be returned.
108
109 Now, 3.3.3.3 is *not* a host we have any access to, nor will we end up spoofing
110 it. Instead, when a client wants to connect, the client (which knows the server
111 IP address) sends an ICMP Time Exceeded packet to the server. The ICMP packet
112 includes the "original" fixed packet that the server was sending to 3.3.3.3.
113
114 Why? Well, we're pretending to be a hop on the Internet, politely telling the
115 server that its original "ICMP echo request" packet couldn't be delivered.
116 Your NAT, being the gapingly open device it is, is nice enough to notice that
117 the packet *inside* the ICMP time exceeded packet matches the packet the server
118 sent out. It then forwards the ICMP time exceeded back to the server behind
119 the NAT, *including* the full IP header from the client, thus allowing the
120 server to know what the client IP address is!
121
122 Server (1.2.3.4): ICMP Echo Request -> 3.3.3.3
123 ...
124 Server (1.2.3.4): ICMP Echo Request -> 3.3.3.3
125 ...
126 Server (1.2.3.4): ICMP Echo Request -> 3.3.3.3
127 ...
128 Client (6.7.8.9): ICMP Time Exceeded (includes ICMP Echo Request to 3.3.3.3) -> 1.2.3.4
129 Server's NAT: Sees server's Echo Request in client's Time Exceeded packet,
130 sends entire packet to server because it matches server's outgoing packet
131
132 Don't believe me? Just traceroute any host behind your NAT. You'll notice
133 incoming packets coming in from random IP addresses your router knows
134 nothing about. Your router knows to send those back to you, rather than another
135 client on your network, based off of the data inside the ICMP time exceeded packet.
136
137 Now, the server has only learned the client IP address. We still have no
138 method to send any additional data. For the full communication, we use the
139 same method used in my previous software, chownat, to penetrate both NATs.
140
141 Example of a client behind a NAT talking to a machine NOT behind a NAT:
142 Machine A -> NAT A -> net -> quake server
143
144 Machine A sends a UDP packet to quake server, opening a "session".
145 NAT A sees this and says:
146 "If any UDP packets come back soon with the same host and port info,
147 I'm routing it to machine A."
148 Quake server sends UDP packets back, hits NAT A, and NAT A seeing the right
149 hosts and ports, sends it to machine A. Machine A and quake server are now
150 able to communicate without any problem.
151
152 Now here is how pwnat works now that client and server know each others IP.
153 Goal is: Machine A (ssh client) -> NAT A -> net -> NAT B -> Machine B (ssh server)
154
155 When you start up the pwnat server on machine B, it slowly fires off
156 UDP packets to machine A. Of course, NAT A is not expecting these so it
157 drops every one of them. Machine B does not stop.
158
159 Once you begin the pwnat client on machine A, it begins sending UDP
160 packets to machine B. Note: pwnat defaults source and destination
161 ports to 2222. Any unprivileged user can set UDP source and dest ports.
162 Normally the UDP packets that machine A is sending to NAT B would get dropped.
163 However, since machine B is sending similar packets OUT, NAT B assumes
164 these are responses and lets them back in. Once machine B sees these packets,
165 it sends handshake packets back to machine A. These packets will not get
166 dropped by NAT A because of the same reason: NAT A sees packets going out, and
167 the packets coming back to the NAT look like responses to the ones going out.
168
169 Finally, both sides are fully communicating over UDP, allowing protocols that
170 run over TCP to tunnel through.
171 Note: There is a keep-alive process on the pwnat server and client that
172 always keeps the UDP "session" active. The packets it sends have a 0 byte
173 payload and are only sent when the client is not sending data out. Otherwise,
174 the fastest it will possibly send the keep-alive packets is one packet every 5
175 seconds. If any other type of data is traveling through the tunnel, no
176 keep-alive packets will be transmitted.
177
178
179
180by Samy Kamkar
181
182pwnat is based off of udptunnel by Daniel Meekins:
183http://code.google.com/p/udptunnel/
184
185
1=============================================================================
2
3 UDPTUNNEL README
4
5 Author: Daniel Meekins
6 Contact: dmeekins - gmail
7
8 Copyright (C) 2009 Daniel Meekins
9
10=============================================================================
11
12This project tunnels TCP data through a UDP tunnel. The executable can act as
13the server or client. The server acts as a proxy for the client, listening
14on a specified UDP port and creating a connection to a TCP server that the
15client specifies. The client listens on a TCP port, acting as the server that
16some TCP client connects to. The client recevies any TCP data on that port
17and sends the data to the udpserver, which sends it to the TCP connection it
18made with the desired TCP server.
19
20
21-----------------------------------------------------------------------------
221.) Building
23
24On *nix systems in Makefile, make sure that the correct value is set for the
25"OS" variable. Then just run 'make'.
26
27On Windows, if using GCC in Cygwin, make sure the "OS" variable is set to
28CYGWIN in Makefile and run 'make'.
29
30If using the VC++ compiler (cl.exe), make sure to be in the "Visual Studio
31Command Prompt", or at least have all the environment variables set correctly,
32then run 'nmake.exe /f Makefile.Win32'. Also make sure the location of
33WS2_32.Lib is specified correctly fo the LIBS variable.
34
35
36-----------------------------------------------------------------------------
372.) Running
38
39usage: ./udptunnel -<s|c> [-6] <args>
40 -c client mode (default)
41 <args>: [local host] <local port> <proxy host> <proxy port>
42 <remote host> <remote port>
43 -s server mode
44 <args>: [host] port [[host]:[port] ...]
45 -6 use IPv6
46 -h show this junks and exit
47
48To run the server:
49 udptunnel -s [-6] [host] port
50where the port is a UDP port to listen for messages from the udpclient and host
51is the address to listen on. Use the -6 option to listen on IPv6 addresses.
52Examples:
53 udpserver -s 4444
54 udpserver -s -6 2001::10:3 4444
55
56To run the client:
57 udptunnel -c [-6] [local host] <local port> <proxy host> <proxy port>
58 <remote host> <remote port>
59local host/port - Host and port for the TCP server to listen on. If the host
60 isn't supplied, it will listen on all available addresses.
61proxy host/port - Host and port that udpserver is listening on.
62remote host/port - Host and port to forward the received TCP data to. The host
63 is relative to the proxy machine (e.g. specifiying 127.0.0.1
64 is the proxy machine itself).
65Use the -6 option to listen and connect using IPv6 addresses.
66
67Example for tunneling ssh data through the tunnel between two computers with IP
68addresses 192.168.1.2 (client) and 192.168.1.1 (server):
69
70 server# ./udptunnel -s 192.168.1.1 4444
71 client# ./udptunnel -c 127.0.0.1 3333 192.168.1.1 4444 127.0.0.1 22
72 client# ssh -p 3333 user@127.0.0.1
73
74Specified destination list:
75After the args in server mode, a list of hosts and ports can be included to
76control who the client tries to connect to. Current this doesn't work with IPv6
77and no names are translated yet, so the destination host used in the client
78must be the same string as that used in the list.
79
80This code has been tested and works on Linux, Solaris 10 x86, and Cygwin (but
81requires the IPv6 extension - http://win6.jp/Cygwin/index.html). Please send
82any bugs or issues to the contact listed above.
83