Friday, February 27, 2009

RADIUS accounting with pfSense (and daloRADIUS on a different machine)







Thursday, February 26, 2009

Virtual topology revamped


gw 192.168.1.1
^ real
| LAN
eth0 192.168.1.x
|
+-----------------------------+---------- HOST ------------------------+
| | |
| NAT | +---+
| | | | | = guests
| tap0 192.168.5.1 | +---+
| | |
| +------------QEMU---------+ +---QEMU-or-UML-----+ | tap* = TUN/TAP
| | | | | Debian | |
| | ed0 192.168.5.x | | freeRADIUS | |
| | | | | daloRADIUS | |
| | pfSense (router) | | DansGuardian | |
| +------ | | | | etc. | |
| | | ed1 192.168.3.1 | | 192.168.3.2 | |
| | | | | | | eth0 | |
| | +------------+------------+ +-------------------+ |
| | | | --------+ |
| Layer 3 tap1 tapR | |
| | | / | |
| | ___BRIDGE_________/ Layer 2 |
| | / \ \ | |
| | tapClient_0 tapClient_1 tapClient ... | |
| | | | \ ------+ |
| | +-USER-MODE-LINUX--+ +-USER-MODE-LINUX--+ +--etc..---+ |
| |_ |eth0 192.168.3.x | |eth0 192.168.3.y | | | |
| |eth1 192.168.4.100| |eth1 192.168.4.101| | | |
| +---------+--------+ +------------------+ +----------+ |
| | | |
| tapX11_0 tapX11_1 |
| \ / / |
| X11_bridge_______________/ |
| 192.168.4.1 |
| | |
| X server |
| |
| (X shall work *before* Captive Portal Authentication) |
| |
| (you can assign a 192.168.3.x address to BRIDGE to allow access to |
| the virtual router from the Host (real) machine) |
| |
+----------------------------------------------------------------------+

Everything You Always Wanted to Have In A Network Appliance * But Were Afraid to Ask


Namely:

  • routing
  • vlan
  • vpn
  • proxy
  • content filtering:
    • virus scanner
    • malware
    • children
    • etc.
  • captive portal
  • accounting:
    • billing
    • prepaid vouchers
    • paypal
    • etc.
  • firewall
  • Access point
  • dns
  • dhcp server
  • smart card
  • account details via printer
Needless to say, the end user is supposed to administer all of these functionalities through a web browser.

Definitely a lot of things for a single, embedded device. On the other hand, putting the bare networking (firewall, routing etc.) on a real pc or server — with writable root file system and rotating parts — isn’t a good idea either. So I’m thinking about separating the network layers. Again and not surprisingly.

I’m thinking about a small networking device with pfSense. The embedded captive portal is able to send accounting packets to an external RADIUS server. The RADIUS server, on its turn, is installed on a regular Linux distro which features any other sophisticated or resource-consuming service such as daloRadius, the required MySQL database, content filtering with DansGuardian, a caching proxy, a virus scanner, print and file services.

+--------------+ +---------+ +---------+
| external AP? +--+ pfSense +--+ Debian? |
+--------------+ +---------+ +---------+

An alternative, all-in-one solution for smaller networks is based on OpenWRT. Its web interface is nice and promising (Lua based ;-), but still not comprehensive as pfSense’s one. Indeed, OpenWRT is a very flexible OS, tailored to wireless devices, yet providing a large collection of pre-packaged software. I’d suggest this option if you don’t need web-based vpn configuration or advanced, web-based RADIUS accounting.

(( \---------/ ))
| OpenWRT |
+---------+

Open source “flagship product”?

Discussions on the italian forum revealed that C++ sources of Zeroshell’s web interface are intentionally not released to the public, making cgi-bin/kerbynet a de facto proprietary tool. This is perfectly legal. The executable file just depends upon glibc and stdlibc++/libgcc, which are licensed under LGPL and “GPL with linking exception” respectively. No full GPL at all. Indeed, the rest of the distro has nothing that any other GNU/Linux distribution couldn’t provide in some way. Open sourcing the backend while closing the front-end is a typical enterprisey attitude. Nothing wrong with that, but it sounds odd to advocate Free Software through something called Zero-shell, as long as its free-software part actually requires a shell to be administered.

Thursday, February 19, 2009

Fork me

Spent the last two days searching for Sourceforge, CVS and SVN alternatives. In no particular order — and listing software tools along with project hosting sites — I considered: Launchpad, Bitbucket, GitHub, Gitorious, Savannah, Git, Mercurial, Bazaar.

Currently, the code for this is there.

I love syntax highlighting, permanent links to single lines of code, social networking features, dynamic generation of tarballs, issue tracker integration etc.

Tuesday, February 17, 2009

Virtual testbed for Zeroshell network appliance




Click to enlarge; and please note the CPU model on top-right of the screenshot ;)

I spent a couple of days with virtual machines. I didn’t want to set up a dedicated host for virtualizations and my CPU has no VT extensions. So, KVM, Xen and OpenVZ got excluded. I used QEMU and the Compact Flash image to emulate Zeroshell; and User Mode Linux boxes as clients.

How to connect virtual machines to each other? The most efficient way (common to QEMU and UML, and not requiring additional daemons, libraries, kernel patches etc.) turned out to be a bridge between TUN/TAP interfaces in the host, leaving Layer 3 communication at the guests level. The other solution (UDP Multicast) proved to be much slower — probably because of additional layers of encapsulation.



gw 192.168.1.1
^ real
| LAN
eth0 192.168.1.x
|
+-----------------------------+---------- HOST ------------------------+
| | |
| NAT +---+ |
| | | | = guests |
| tap0 192.168.0.1 +---+ |
| | |
| +------------QEMU-----------+ tap* = TUN/TAP |
| | | | |
| | ETH00 192.168.0.75 | |
| | | | |
| | Zeroshell (NAT + Captive Portal + DHCPd etc.) |
| +------ | | | |
| | | ETH01 192.168.3.1 | |
| | | | | |
| | +------------+--------------+ |
| | | --------+ |
| Layer 3 tap1 | |
| | | | |
| | ___BRIDGE_______ Layer 2 |
| | / \ \ | |
| | tapClient_0 tapClient_1 tapClient_... | |
| | | | \ ------+ |
| | +-USER-MODE-LINUX--+ +-USER-MODE-LINUX--+ +--etc..---+ |
| |_ |eth0 192.168.3.x | |eth0 192.168.3.y | | | |
| |eth1 192.168.4.100| |eth1 192.168.4.101| | | |
| +---------+--------+ +------------------+ +----------+ |
| | | |
| tapX11_0 tapX11_1 |
| \ / / |
| X11_bridge_______________/ |
| 192.168.4.1 |
| | |
| X server |
| |
| (X shall work *before* Captive Portal Authentication) |
| |
+----------------------------------------------------------------------+