RFC: Large dynamic CIPE VPN (2nd posting)|
Christian Lademann <cal,AT,zls,DOT,de>|
Sat, 21 Oct 2000 20:18:49 +0200|
I am working on an idea I had and I would like to hear your opinions and
I would like to build a large-scale VPN with possibly some hundered
that all connect to a central site over the internet. The remote boxes
should be unattended and their CIPE-configuration should eventually be
This said, I do not like the idea to configure all the different
Now my idea to solve this:
1. As soon as the remote box (client) wants to communicate to the
central site (server), or as soon as the internet-connection is
the client connects to the server via tcp to a well-known port and
sets up a SSL-connection.
2. The client authenticates itself to the server with a user-id (name,
mac-address, etc) and a passwort (or with a SSL-certificate, etc).
3. The server looks up the clients desired vpn-configuration in its
database and either accepts or rejects the request. Is also
generates a random static key.
4. If the server accepted the request, it writes out a taylored
to a 'well-known' location (.../options/cipe.$user-id.conf ...),
ciped with a new options '-v' with tells ciped to report the
choosen udp-port and cipe-device. The server collects all those
informations together with the pid of the daemon process and
writes it to a statusfile.
If there is still a ciped-process 'hanging around' from the last
connection, it is killed before the new daemon process is started.
5. If the ciped was started successfully, the server can now open the
firewall for udp-traffic between the client (whose ip-address is
known because of the active tcp-connection) and ciped (whose
upd-port is known because of the '-v' - switch).
The server also sets up the necessary routing table entries.
6. All information is reported back to the client that now can create
it's own taylored cipe.conf:
- the ip-address and udp-port of the CIPE-server
- the initial static key
- other information, like routing table entries, etc.
7. If the client wants to cancel the connection, it either just drops
it's internet connection so the server would stumble over some
or it again connects via SSL to the server to tell it goodbye.
Also it stops it's ciped.
8. If the server wants to teer down the communication it just kills the
specific ciped and closes the firewall.
9. If the ip-address of the client changes, it just starts from step 1.
To support more clients than one server-box can handle (or to have some
kind of load-balancing) the server could find look up the least busy
server of the server-farm between step 3. and 4. If it finds another
move eligible to host the connection (or if the client already connected
to another server before) it would act like a proxy between the client
the actual server to host the ciped until the necessary information is
I have already started and coded up quite a lot of the stuff presented
1. to 9. using PERL. It is not quite finished yet but it will be RSN.
It's called "cipic" (CIPE Initial Connector). I will publish it here
as soon as it is worth to take a look at.
Please tell me, what you think. Is my approach possible? Are there
or more secure possibilities?
Christian Lademann <cal,AT,zls,DOT,de>
PS: This is an output of 'ciped-cb -v ...':
CIPE daemon vers 1.4.1 (c) Olaf Titz 1996-2000