ChaosVPN

the big picture

What is this all about?

mc.fly will write some stuff about it. In case you have awesome ideas just add them.

A view on the connected nodes inside the ChaosVPN. Refreshed every minute: http://comyn.ainex.net/chaosvpn.png

ChaosVPN 2.0

redesign

The Rebuild of the ChaosVPN became nessesary at some point, as the vermittlung is blackholed. Furthermore we would like to put live back to the ChaosVPN and use it to interconnect the hackerspaces.

So we thought its a good time to redesign stuff. We will climb up to tinc 1.0.10.

software

An unfinshed Howto for Debian systems is available at Debian - users of other systems need to adapt it likewise, more documentation will hopefully follow in the future.

Config builder

Currently we are porting haegars script from perl to c and strip off curl and openssl, so it fits in a OpenWRT box.

OpenWRT Packages

Blogic will build a special OpenWRT package, which is called chaosvpn at the moment and a recent tinc 1.0.10 for that.

See also http://0x1.net/openwrt Packages may be in flux for awhile, if you have trouble with any of the binaries, email cjp.

Debian Packages

Haegar updated (backported) tinc 1.0.11 packages for debian. They are availible at:

• Debian Etch: http://debian.sdinet.de/etch/sdinet/tinc/
• Debian Lenny: http://debian.sdinet.de/lenny/sdinet/tinc/

I will also create Debian packages of the config builder once it is in a usable state.

sources

The source code repository is available at: http://github.com/ryd/chaosvpn

You can download the source with git

git clone git://github.com/ryd/chaosvpn.git

IP Ranges and Participants:

We need to have non colliding ip ranges and therefore we need some coordination of the used ip ranges.

First of all we would like to be compilant to the used ip ranges of freifunk and dn42.

The IP ranges overall are defined in the freifunk wiki ip-net page as root source.

So we use 172.31.0.0/16 for the europeans and 10.100.0.0/13 for the americans. That should leave enough space for everone untill ipv6 is not the future but the present. (Real IPv6 ranges already in use can also be announced on the VPN, but there are no thoughts about private/internal adressing yet.)

However we will not support 192.168.0.0/16 ip ranges as they are used for various other reasons. This rfc1918 ip range will stay as private to use for internal use (and in fact its used in the dn42 for routing uses.)

Question: reverse DNS?
"yes" ;) - but we don't know how to implement them for the VPN yet, delegating it with forward zones in local nameservers does not sound very good to me. --Haegar 00:40, 29 October 2009 (UTC)

Question: Are other ChaosVPN ranges which were already allocated on the Freifunk Wiki also supported (i.e. 10.4.0.0/14 & 10.32.0.0/12)? --Dennis 23:32, 10 November 2009 (UTC)

Procedure: Add your subnet below and drop User:Haegar a message with the infos specified at DebianHowto#6._Mail_haegar.40ccc.de_the_info so he can add you to the official listing.

ip ranges

IP-subnets	Unique Name	Node	Remarks	VPN IP for test pings
172.31.0.0/16	europe range	europe range	europe range
172.31.0.0/23	*reserved*	single hosts	This range may be used for Single-IP-VPN nodes like servers which would participate directly but do not need a subnet.
172.31.2.0/23	*reserved*	subnets	This range may be used for small users which do not want/need a whole /24 - allocate only /29 and /28 from here.
your subnet	your unique name	your url / description	your remarks	vpn ip for ping tests
172.31.16.0/23	ccchh	CCC Hamburg	Chaos Computer Club Hansestadt Hamburg	172.31.17.213
172.31.18.0/23	haegarhome	haegar home
172.31.20.0/23 *planned*		CCC Hamburg	Chaos Computer Club Hansestadt Hamburg Second Range
172.31.22.0/24	haegarvlad	haegar hosted servers / vms
172.31.23.0/24	*reserved*	*reserved*	*reserved*
172.31.24.0/23 *planned*	London Hackspace	http://london.hackspace.org.uk
172.31.26.0/23 *planned*	Leeds Hackspace	http://leeds.hackspace.org.uk
172.31.31.0/24 *requested*	freitagsrunde	http://freitagsrunde.org
172.31.42.0/24	*reserved*	*reserved*	*reserved*
your subnet	your unique name	your url / description	your remarks	vpn ip for ping tests
172.31.51.0/23	ccch	CCC Hannover	Chaos Computer Club Hannover
172.31.99.0/24	hc	User:HC (+4961546039923)	HC's testnode
172.31.100.0/24	datensumpf	http://www.datensumpf.de datensumpf	mc.flys subnet at home
172.31.101.0/24	pesco	User:Pesco	pesco's home/test range
172.31.102.0/24	ryd	User:Jensm	jens's home/test range
172.31.108.0/24	atari	User:Atari	wasteland
172.31.142.0/23	t42home	http://T42.de
172.31.251.0/24	lotho	User:Lotho	lotho at home
172.31.255.0/24	*reserved*	*reserved*	*reserved*
your subnet	your unique name	your url / description	your remarks	vpn ip for ping tests
10.100.0.0/14	us hackerspaces range	us hackerspaces range	us hackerspaces range	us hackerspaces range
10.100.0.0/23	psone	PS:one		10.100.0.2
10.100.2.0/23	ccckc	CCCKC
10.100.4.0/23	noisebridge	Noisebridge
10.100.16.0/24	royksopp	0x1.net	Testing for OpenWrt packages, see http://0x1.net/openwrt for binaries
10.100.68.0/23	ResistorNET	ResistorNET Information	NYC Resistor Hackerspace 397 Bridge Street 5th Flr Brooklyn NY 11201
10.100.100.0/23	hhh	HHH network diagram	former site og HHH: 114 Forrest St Apt 3A / Brooklyn NYC
your subnet	your unique name	your url / description	your remarks	vpn ip for ping tests
10.104.0.0/14	us hackerspaces range - reserved	us hackerspaces range - reserved	us hackerspaces range - reserved	us hackerspaces range - reserved

ccchh - Hamburg

• connector: User:Haegar
• url: http://hamburg.ccc.de
• added in Wiki
• subnet: 192.168.16.0/23 - renumbering needed.

T42 - Hamburg

• connector: winni (at) ccc.de
• url: http://T42.de/
• subnets: 10.10.10.0/23 and 10.11.22.0/24 - renumbering needed.

nycresistor - New York

• connector: User:openfly ( matt [at] nycresistor.com )
• url: http://www.nycresistor.com
• network Wiki: http://wiki.nycresistor.com/wiki/ResistorNET

noisebridge - San Francisco

• connector: aestetix
• url: https://www.noisebridge.net
• network setup: https://www.noisebridge.net/wiki/Network
• subnet: 172.30.0.0/22 - renumbering needed due to collision with Freifunk Bornheim

PS:one - Chicago

• connector: tcrown
• url: http://pumpingstationone.org/

Hive76 - Philadelphia

• connector: FarMcKon
• url: http://Hive76.org

ccc hannover

• (in chaosvpn 1.0)
• connector: User:Lotho ( lotho [at] hannover.ccc.de )
• url: http://hannover.ccc.de
• subnet: 10.23.42.0/24 - renumbering needed due to collision with Freifunk Brandenburg.

ccckc

• Kansas City
• connector: User:rixon
• url: http://cowtowncomputercongress.org

hhh

• (in chaosvpn 1.0, at least for a while)
• connector: User:Carton (carton@Ivy.NET)
• node name: lucette
• url: (diagram somewhat outdated) http://web.Ivy.NET/~carton/rant/hhh-network-diagram.pdf

what about:

ccc berlin

• (in chaosvpn 1.0)

ccc cologne

• (in chaosvpn 1.0)

wanted changes

short term

• The config file itself is not validated. We need a signing and validating structure. (.sig)
• clients don't have to authentificate themself - everybody can see the config.
• if admins are lazy and don't rebuild the config file properly we will have old routes in the network that don't dissapear (at least until the tinc is reconfigured and restarted)

long term

tinc does have some problems. That is the reason why we want to replace that in the forseable future. That will be ChaosVPN 3.0

• Participants can fake network ranges my intention or mistake. (control informations inside tinc are not proper authentificated)
• http://www.cs.auckland.ac.nz/~pgut001/pubs/linux_vpn.txt

ChaosVPN 1.0 (historic)

ChaosVPN 1.0 is obsolete, please see above for the next implementation.

TINC SETUP

At the moment the Hamburg ccc Erfa uses TINC together with some dirty perl-scripts, which are used to read the routes and peers.

For this Setup we have howtos for Debian and Gentoo (in german).

Beginninig in 2003

(haegar:) For me the whole setup with Openvpn was to complicated. It would take some time till its done and the scaling problems were forseable.

Therefore i took time today to get a working mini-solution with tinc running real quick.

The bigger issues with ip-submission and database are able to be added later without any big effort.

Most importand design goals were:

• data traffic between participants must not rely on the ccc infrastructure.
• failure of any parts of the infrastructure must not shut down the network completely
• no work needed for participants just because a new participant is joining or a old one quitting.

system requirements

• linux only first
  • tinc is availible for nearly all unix variants and windows, but my perl script is only working on linux so far.
• perl with LWP and https support
• working dyndns hostname that conains the actual router-ip or static ip

Update 2006

Today (2006) i would implement things different than i did before, but when this happens is completely up in the stars. Until there is a better setup we will use the old setup.