vtun is a daemon which establishes an IP tunnel through a TCP connection
(among other variants). It can be used for a VPN, in some ways like
IPSec (FreeS/WAN), though keying and crypto are a lot less intricate. (I
hear the IPSec guys sneering.) As part of setting up a connection, a
tun/tap device is allocated at each end, IP addresses are determined,
and each end configures its device with a point-to-point link to the
other end. Routes, if any, are established using the other end's device
IP address as a gateway.
My goal is to set up a server, and multiple clients can connect to it at
once, without individual prearranged addresses being assigned to the
clients. This means that either the daemon has to be hacked and the
protocol augmented to negotiate the endpoint addresses, or everyone has
to share the same pair of IP addresses. It's not a problem if all the
server's tunnel devices have the same address (different from its public
IP address), but it *is* a problem for the clients.
I've been corresponding with <bishop@xxxxxxxxxxxxxx>, one of the
maintainers of vtun. He remembers seeing a SNAT hack which can deal
with the problem, but neither of us can figure out what it is; nor do
repeated searches on Google reveal anything useful. Can any of you
help? More specifically, the server sets up the various connections
like this (as the clients make the connections)
ifconfig tap0 10.0.0.1 pointopoint 10.0.0.2
ifconfig tap1 10.0.0.1 pointopoint 10.0.0.2
ifconfig tap2 10.0.0.1 pointopoint 10.0.0.2
etc...
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Suppose a packet emerges from tap2 with a source address of 10.0.0.2.
It is NATted so its source address is the server's. The replies come
back to the server and are de-mangled so the destination becomes
10.0.0.2, but how can it be told to route them down tap2 rather than
tap0 or tap1? Empirically, it does not make this judgment natively,
picking just one of the taps arbitrarily.
(It's been suggested to run DHCP through the tunnel. But the problem
is, the DHCP client wants to set up a network config and a default route,
not a point-to-point config. Also at the server end, the vtun server
daemon will have finished its job before the client's address is known,
and the DHCP server is not in the business of configuring interfaces.
So again there's no way to set up the point-to-point connection.)
(Another suggestion is to use the client's public IP address on the tun/tap
device. The flies in this ointment are that the clients will often be
behind similarly configured NAT boxes, so the ISP's assigned address is
hard to determine, and 192.168.0.1 will often be assigned to several
clients at once. Also, the server must not use the ISP's assigned address
on the tun/tap device, because then the packets for the enclosing TCP
connection would be sent down the tunnel, ruining everything.)
James F. Carter Voice 310 825 2897 FAX 310 206 6673
UCLA-Mathnet; 6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555
Email: jimc@xxxxxxxxxxxxx http://www.math.ucla.edu/~jimc (q.v. for PGP key)
