See the current ICMPTX project home page.
ProblemYou're sitting in an airport or in a cafe, and people want your money for Internet access. They do allow ICMP traffic, though (i.e., you can ping machines on the Internet). Enters ICMPTX. (If you can't use ping, but you can issue name queries, use NSTX: IP-over-DNS.) There are several resources online to point you in the right direction, most notably Case of a wireless hack by Siim Põder. There is a similar, thoroughly undocument program called itun, a simple icmp tunnel that claims to do the same thing. Also, check out PingTunnel which is not IP-over-ICMP, but rather TCP-over-ICMP and, therefore, less useful.
Keywordsicmptx, ip-over-icmp, firewall piercing, ping, icmp, tunnel, ifconfig, route, tun/tap, tun0.
Solution: icmptxThe tarball below is based on slightly buggy code I found through Siim Põder's page. I modified it ever so slightly, but I deserve no credit at all. Also, if you destroy everything or anything using this program, I am not responsible.
$ wget -O - http://thomer.com/icmptx/icmptx-0.01.tar.gz | tar xvfz - $ cd icmptx-0.01/ $ make
Proxy-side icmptx setupYou'll need a machine connected to the Internet to serve as your proxy. Make sure the proxy's firewall does not block ICMP traffic. If you can't simply ping the machine, icmptx will surely not work. Also, make sure your kernel supports TUN devices.
# ./icmptx -d 10.0.1.1Now verify you have a tun device:
# /sbin/ifconfig tun0 tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 POINTOPOINT NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:10 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)Configure the tun device. Also, ensure the kernel doesn't intercept and reply to pings.
# /sbin/ifconfig tun0 mtu 65536 up 10.0.1.1 netmask 255.255.255.0 # echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
*nat :PREROUTING ACCEPT [6:1596] :POSTROUTING ACCEPT [1:76] :OUTPUT ACCEPT [1:76] -A POSTROUTING -s 10.0.0.0/8 -j MASQUERADE COMMITRestart iptables:
/etc/init.d/iptables restartand enable forwarding:
echo 1 > /proc/sys/net/ipv4/ip_forwardYou can make sure this change (and the modification that disabled echo replies) are permanent by editing /etc/sysctl.conf, and adding:
Client-side icmptx setupThe client's kernel also needs to support TUN devices. Assuming your proxy's IP address is 126.96.36.199, run as root:
# ./icmptx -c 188.8.131.52
# /sbin/ifconfig tun0 mtu 65536 up 10.0.1.2 netmask 255.255.255.0
# /sbin/route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0OK. So "192.168.1.1" is our gateway. Assuming your wireless network device is called "wlan0" (but it might well be "eth1", or whatever), run:
# /sbin/route del default # /sbin/route add -host 184.108.40.206 gw 192.168.1.1 dev wlan0 # /sbin/route add default gw 10.0.1.1 tun0Obviously, 220.127.116.11 should be replaced with your proxy's IP address.
Problem: some connections seem to hangTry increasing the MTU size (that is the number that comes after "mtu" when invoking /sbin/ifconfig). Do this on both the client and the server. Running it with an MTU of 65536 seems to work fine (since, if I recall correctly, that is the maximum IP packet size). If you want to be dead sure that this is not the problem, crank it up.
I managed to get around the *hanging connection* problem and speed up icmptx very much: just open a new console and start ping -f 10.0.1.1 (gateway node) so the client will flood the gateway with icmp requests (which will not be answered).With this I was able to get stable connections and improve the http download speed to 210 kb/s which is the full physical bandwith of my internet connection.
Open problemsNote that I do not maintain the code. Please see the current ICMPTX project home page.
This is the ICMPTX program. This software is most recently available from http://github.com/jakkarth/icmptx ICMPTX is a program that allows a user with root privledges to create a virtual network link between two computers, encapsulating data inside of ICMP packets. -- license -- This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this ICMPTX. If not, see <http://www.gnu.org/licenses/>. -- basic usage instructions -- First, make sure you have the tun module from your 2.6 kernel loaded up or compiled into your kernel on both ends of your tunnel. Second, compile the code on both the client machine and the server you wish to tunnel your traffic between. Third, on the server side, do something like ./icmpx -s 18.104.22.168 & sleep 1 ifconfig tun0 10.0.3.1 netmask 255.255.255.0 Fourth, on the client side, do something like ./icmptx -c 22.214.171.124 & sleep 1 ifconfig tun0 10.0.3.2 netmask 255.255.255.0 Replace 126.96.36.199 with your internet-accessible IP on the server. At this point you should have a simple link between the client and server. On the client, you should be able to ping 10.0.3.1 and get a response. Note that there are several levels of irony involved in receiving the responses. SSH tunneling can be used at this point for secure communication over the channel. Note that there is no encryption capability provided directly by ICMPTX. Once you've confirmed that the tunnel does in fact work, routing should be easily accomplished. The tun interfaces are just like any other ethernet devices on your system and can be used as such, for example: route add -net 192.168.0.0/24 gw 10.0.3.1 executed on the client could add a route to your server's DMZ segment. Access to systems on the 192.168.0.0/24 subnet from the client would then be transparently tunneled through the ICMPTX connection. -- who's to blame for all this? -- ICMPTX has an interesting lineage. The code for the ICMP handling was originally included from the itunnel program. Tun interface handling was included from the VTun project, originally authored by Maxim Krasnyansky. The two were brought together by edi / teso. From there, Siim Põder cleaned up the code and wrote a short article about it, possibly still available at http://www.linuxexposed.com/content/view/153/52/ . That seems to be where Thomer Gil found it, after which he further cleaned it up and presented it at http://thomer.com/icmptx/, which is where I, John Plaxco, came across it.