Arch Red Route (English)

What about CAs in mobile devices?

2011-09-08T01:39:00.000-07:00

The Diginotar case encouraged finally most operating system and browser vendors to remove the DigiNotar CA from their trusted CAs. In case you are not familiar with the case, I suggest you check the following links where the case has been analysed more carefully:

In addition to the analyses you may also want to see a Black Hat 2011 presentation from:

Moxie Marlinspike about SSL And The Future of Authenticity.

An executive summary of the would be:

One of the generally trusted certificate authorities (DigiNotar) failed to protect its services and was compromised. There now exists DigiNotar signed certificates in the wild free for attackers to use for several online and software update services including companies such as Microsoft, Google and organisations like Mozilla(Firefox). This means that if your operating system or browser certificate stores are not updated, your device is vulnerable to attacks based on these certificates. Attacks can for example install malware on your computer in the form of updates or collect your passwords for various services.

But since most of the operating system and browser vendors already reacted and I have installed updates I am now secure, right?

No you are not. While most of the operating system and browser have removed the CA certificate in question we still have a huge number of devices which may have those CA certificates installed -- the mobile devices. I have not yet received an update for my Android phone (Samsung Google Nexus S) and I think it is pretty much the same for all other mobile phone vendors too, Windows Phones, old and new S40, Symbian, Maemo phones and iPhones included. And it does not even stop to mobile phones, nowadays we have already tablets and all kinds of embedded devices, which may have the operating system included certs installed. Our mobile devices continue to be vulnerable to those leaked certificates and in most cases the users cannot even check or do anything to remove the certificates!

One glimmer of hope is that DigiNotar has not perhaps been in all mobile devices' CA certificate storage, but then again we still have Comodo there and now GlobalSign has stopped signing certificates and is checking their systems for intrusion. Another glimmer of hope is that maybe perhaps now industry will take a closer look at the current certificate authority structure and the system will be improved or fixed for example like Moxie Marlinspike suggests.

Microsoft recommends _not_ to disable IPv6

2011-05-02T23:25:00.000-07:00

In IPv6 seminars you often hear the claim that Microsoft recommends not to disable IPv6. The source for this recommendation is not often presented, but now I did look it up for further reference and discussion with IT departments, which disable IPv6 from their computers.

The Argument against Disabling IPv6

It is unfortunate that some organizations disable IPv6 on their computers running Windows Vista or Windows Server 2008, where it is installed and enabled by default. Many disable IPv6-based on the assumption that they are not running any applications or services that use it. Others might disable it because of a misperception that having both IPv4 and IPv6 enabled effectively doubles their DNS and Web traffic. This is not true.

From Microsoft's perspective, IPv6 is a mandatory part of the Windows operating system and it is enabled and included in standard Windows service and application testing during the operating system development process. Because Windows was designed specifically with IPv6 present, Microsoft does not perform any testing to determine the effects of disabling IPv6. If IPv6 is disabled on Windows Vista, Windows Server 2008, or later versions, some components will not function. Moreover, applications that you might not think are using IPv6—such as Remote Assistance, HomeGroup, DirectAccess, and Windows Mail—could be.

Therefore, Microsoft recommends that you leave IPv6 enabled, even if you do not have an IPv6-enabled network, either native or tunneled. By leaving IPv6 enabled, you do not disable IPv6-only applications and services (for example, HomeGroup in Windows 7 and DirectAccess in Windows 7 and Windows Server 2008 R2 are IPv6-only) and your hosts can take advantage of IPv6-enhanced connectivity.

-- Joseph Davies in Microsoft Technet article: http://technet.microsoft.com/en-us/library/2009.07.cableguy.aspx

Open System Consultants Ltd. and Arch Red Ltd. to enhance Radiator expert services via cooperation agreement

2010-12-08T05:51:00.000-08:00

Open System Consultants, the maker of the "Swiss Army knife of RADIUS Servers" and Finnish Internet architecture expertise company Arch Red have signed a joint agreement to strengthen their cooperation in providing expert services based on OSC's Radiator RADIUS server.

Arch Red brings 8 years experience with Radiator, building RADIUS implementations for eduroam(tm) in Finland, its commercial application, the Wireless Tampere community network as well as for traditional Internet and mobile service providers.

The new closer cooperation between Open System Consultants and Arch Red provides new opportunities for both expert services and product development, Arch Red managing Director, Karri Huhtanen says.

Mike McCauley, OSC's managing director welcomes the synergies this new cooperation offers. With Arch Red's application experience, we can together provide the highest quality access solutions and technical support to our mutual customers.

Cloud Computing Business Models

2010-11-17T07:41:00.000-08:00

As a part of my postgraduate studies I attended a TUT seminar course about cloud computing and chose to do my presentation about the cloud computing business models. Obviously this only covers only small part of them, but the presentation gives a general idea about what models are available and on what level of cloud computing solutions (IaaS, PaaS, SaaS etc.).

Cloud Computing Business Models

View more presentations from khuhtanen.

Feel free to comment or ask questions about the presentation and I will try to answer them in the comments.

Arch Red Guest Server v3.0 is coming

2010-09-17T05:05:00.000-07:00

A new version (v3.0.0) of Arch Red's guest management software (Arch Red Guest Server v3.0) is nearing its release. A pre-release demo version (2.9.13) is already installed to our demo site. For more information about the demo and user credentials see:

http://www.archred.com/products/arch-red-guest-server/arch-red-guest-server-demo

Arch Red Blog is now IPv6 enabled

2010-08-24T06:50:00.000-07:00

Yesterday we found out a way to enable IPv6 for our Google hosted services such as our English and Finnish blogs.

It seems that while Google only enables IPv6 on its on services by request of the IPv6 service provider or IPv6 block owner, it is possible to enable IPv6 on those Google hosted services which are offered under your own domain name.

Since Arch Red blogs are under our own domain name service (archred.com and archred.fi), we can allow them to be accessed also with IPv6 with a simple change in DNS by changing CNAME for them to point to ghs46.google.com instead of IPv4-only ghs.google.com.

Heikki changed our DNS already yesterday and you should be now able to read even this blog entry over IPv6.

ICT SHOK Future Internet Testbed Architecture v2.0 published

2010-06-03T00:00:00.000-07:00

Together with CSC, TUT also had a poster about ICT SHOK Future Internet Testbed here at Terena Networking Conference. Earlier we had only few printed copies of the testbed architecture document available, but now the same document is also published in the Internet at address:

http://www.futureinternet.fi/publications/ict-shok-future-internet-testbed-architecture-v20-web-version.pdf

The central idea with our testbed is that instead of building yet another testbed, we will combine existing and new services into a concept, which is supposed to grow and evolve serving various research programs and cooperation both in Finland and abroad.

If you are interested to learn more about our concept, check the architecture specification or contact either me or CSC's Jari Miettinen or Pekka Savola.

Debugging eduroam at TNC2010

2010-06-01T02:23:00.000-07:00

Yesterday Matti was having trouble with Helsinki University user accounts and the eduroam network here at TNC2010. Together with few eduroam guys (Stefan Winter and Miroslav Milinovic) and Heikki Vatiainen from our company we tried to find out why the authentication process did not seem to go through. What made it harder was that for example Radiator does not log enough information about failing authentication process unless it clearly ends in success or failure. Increasing log level to debug levels of course helps and we were able to see that the Helsinki University RADIUS server did send response messages to authentication requests even if the process did not go through.

Other servers in Finland worked fine (I have been able to use eduroam the whole time with my TUT accounts) and only difference we first found was that Helsinki University certificate was bigger than the ones in some of the working organisations. This lead us to suspect RADIUS message fragmentation problems somewhere in between European Top Level RADIUS and Matti's device. We then remembered the one Radiator configuration directive, which we found was missing from Helsinki University RADIUS server configuration.

Adding EAPTLS_MaxFragmentSize 1024 solved this problem so if you are having similar problems with eduroam and your home organisation is running Radiator RADIUS, we suggest checking at least this setting found in Radiator manual:

EAPTLS_MaxFragmentSize

For TLS based EAP types such as TLS, TTLS and PEAP, this optional parameter specifies the maximum size in octets permitted for each TLS message fragment. Defaults to 2048, but many EAP clients, routers and wireless Access Points have limitations that require EAPTLS_MaxFragmentSize to be set as low as 1000 or less. Setting this number too small can result in excessive RADIUS request round trips during EAP TLS authentication, slowing down the authentication process. Setting this number too large can result in failure to complete TLS authentication for some types of clients and devices.

Beer and Food in Vilnius

2010-05-31T07:39:00.000-07:00

Got feedback from conference participants and at least one Finnish tax payer that they want to see more research coverage on beer and food. :) So even if we have been busy attending sessions, debugging eduroam and in various discussions, we have also been able to research the opportunities Vilnius presents for enjoying good beer and food.

Based on the background research done by Stig and Matti, I have managed to map already few places to enjoy good beer and food after heavy conference day. I will try to update this map during conference and all participants are welcome to contribute if they have clarifications or new places to be added.

Beer places in Vilnius, Lithuania

View Beer places in Vilnius, Lithuania in a larger map

Defining the Y Generation

2010-05-31T07:29:00.000-07:00

It is sometimes hard to figure out what is the definition of X generation, Y generation or even millennials. Hannes Lubich's presentation in today's plenary clarified among others what Y generation means and what are the characteristics of this generation.

The interesting thing was that at least I was able to pick up few Y generation characteristics from myself even if I guess I belong more to the previous generation based on my age. Or maybe it is just that I want to find some younger Y generation characteristics in me. :)

Blogging at Terena Networking Conference 2010

2010-05-31T00:33:00.000-07:00

You know that you have done too much Web 2.0 when people invite you to blog about events. This year I am once again participating in Terena Networking Conference and the conference organiser asked if I would interested to blog about the event. Since I am already hanging around here (currently in Juniper's meeting) and taking photos I accepted and here we are, part of Terena Networking Conference 2010 coverage.

To make sure that my time was efficiently used, instead of just watching presentations, blogging and drinking beer :) I am also both invited speaker, paper and poster presenter here, which should keep me busy doing those slides and later by presenting them.
My first presentation is about RadSec/RADIUS based roaming paper and the second invited one is about the Internet bus from Tampere, Netti-Nysse. The poster is about ICT SHOK Future Internet Testbed and I just managed to bring it to conference lobby before coming to this Juniper presentation.

And speaking of presentations, I really have to now upload some placeholders for compatibility testing purposes to the presentation system, so more coverage and even some nice photos about Vilnius will have to wait to the next post. Luckily they have a nice working eduroam Wi-Fi network here complete with both public IPv4 and IPv6 addresses.

What is eduroam and roaming?

2010-04-11T22:28:00.000-07:00

A promotional eduroam video produced by Australia's research and education network (AARnet) explains the concept of eduroam and the benefits of federated roaming:

For you, it is possible to get this technology to your home organisation or even a company by utilising Arch Red products and services to bring your network and users as a part of eduroam or other community networks such as Wireless Tampere (Langaton Tampere).

Building a mobile eduroam access point with RadSec and OpenWRT

2010-04-03T04:15:00.000-07:00

A mobile Wi-Fi access point is a very useful way to both demonstrate and extend existing community network coverage over any third-party broadband connections. The problem usually is how the authentication traffic can be transferred over Internet jungle and secured from eavesdropping and man-in-the-middle attacks. Often this is done by deploying VPN solutions such as OpenVPN, but a new IETF draft, RadSec, makes it possible to achieve same security and functionality without having to rely on the use of VPNs.

Figure 1: the mobile eduroam access point network architecture

It has been in my plans to write this article for a while now, but now finally Easter holidays gave the opportunity to finalise the configuration and some free time to write these configuration instructions. This blog post describes how you can build a mobile eduroam access point by utilising RadSec and a popular open source access point firmware called OpenWRT. The network architecture is presented in the Figure 1 above and the rest of the instructions follow below.

The first thing to do is of course install OpenWRT on your access point. There are several different OpenWRT supported access point models and the installation instruction vary between models and manufacturers. In this case I assume that you have alredy OpenWRT based access point installed and continue from the actual eduroam and RadSec configuration.

The base OpenWRT distribution does not come with all the software we will require so we need a working Internet connection to install some additional packages. The most important of these are the tools for time synchronisation (for certificate validity verification) and radsecproxy for RadSec functionality.

From the OpenWRT command line you can install the needed packages by giving the following commands:

# opkg update
# opkg upgrade
# opkg install radsecproxy
# opkg install ntpclient

I recommend rebooting the access point and verifying the correct time with date command. The default OpenWRT timezone is UTC so the time is likely to be hours off from your local time. You can change the timezone, hostname and remote logging address from /etc/config/system displayed below:

config system
        option hostname mobile-ap
        option timezone UTC
        # remote syslog server, we used the syslog configured to radsec server
        option log_ip 10.10.10.10

The wireless settings for eduroam are configured in /etc/config/wireless. The important thing to notice is that the RADIUS server (radsecproxy) will be run on the OpenWRT access point.

config wifi-device  wl0
        option type     broadcom
        option channel  5 
        option country  FI
        # REMOVE THIS LINE TO ENABLE WIFI:
        # option disabled 1

config wifi-iface
        option device           wl0
        option network          lan
        option mode             ap
        # in case you are already running eduroam in your organisation you might
        # want to consider different ssid to prevent causing denial of service for
        # your users
        option ssid             eduroam

        option encryption       mixed-wpa
        # as we use radsecproxy on localhost for converting RADIUS to RADSEC
        # the RADIUS server is the radsexproxy on localhost
        option server           127.0.0.1
        option port             1812
        option key              RadiusSecretHere
        option nasid            nas.id.here
        option wpa_group_key    600
        option ieee80211d       1

Radsecproxy is an open source implementation of the RadSec protocol. The RadSec protocol is essentially TLS-secured RADIUS over TCP making it more reliable and more secure for setting up connections over unreliable or unsecure networks (such as most Internet connections).

There are however few pre-requirements for configuring RadSec and eduroam:

Home organisation must be part of the national eduroam federation and international confederation to have an access to eduroam infrastructure
a RadSec capable server (either radsecproxy (also on server side) or commercial RadSec capable server such as Radiator)
existing Certificate Authority (CA) for signing certificates for RadSec server and clients

In our company we already had Radiator RADIUS server and own CA configured so making certificates and server configuration was not very difficult. The client side (OpenWRT) configuration was done in the /etc/radsecproxy.conf file.:

listenUDP               127.0.0.1:1812
ListenAccountingUDP     127.0.0.1:1813

# Optional log level. 3 is default, 1 is less, 4 is more
LogLevel                3
#Optional LogDestinatinon, else stderr used for logging
# Logging to file
#LogDestination         file:///tmp/rp.log
# Or logging with Syslog. LOG_DAEMON used if facility not specified
# The supported facilities are LOG_DAEMON, LOG_MAIL, LOG_USER and
# LOG_LOCAL0, ..., LOG_LOCAL7

# Syslog is nice as you can direct it to external host via OpenWRT's
# system configuration
LogDestination          x-syslog:///log_daemon

tls mobile-ap-to-radsec-server {
    # In Arch Red we have multiple levels of CA servers with root CA and server CA
    # so the CACertificateFile is a bundle of root CA and server CA. The server CA
    # is the actual CA certifying both the server and mobile-ap certificates.
    CACertificateFile    /etc/certs/ca-servers-bundle-cert.pem
    CertificateFile     /etc/certs/mobile-ap-cert.pem
    CertificateKeyFile  /etc/certs/mobile-ap-key.pem
    # Optionally enable CRL checking
    # CRLCheck on
    # Optionally specify how long CAs and CRLs are cached, default forever
    # CacheExpiry 3600
}

# configuration for OpenWRT's local RADIUS
client 127.0.0.1 {
        type    udp
        # the secret between OpenWRT nas/hostapd and radsecproxy
        secret  RadiusSecretHere
}

# in the real configuration the IP address of the RadSec server
server 10.10.10.10 {
        type    TLS
        # the RADIUS shared secret between mobile-ap and RadSec server
        secret  SecretBetweenMobileAPandRadServer
        port    2083
        tls     mobile-ap-to-radsec-server
        certificateNameCheck off
        matchCertificateAttribute CN:/^radsecserver\.hostname\.here$/
        retryCount      3
        retryInterval   5
}

# The realm below is equivalent to /.*
realm * {
        # the IP addresses of the RadSec server
        server 10.10.10.10 
        accountingServer 10.10.10.10
}

I copied the necessary (CA and client) certificates manually to a directory /etc/certs I had created on the wireless access point file system. A larger deployment of RadSec access points would of course require either a scalable way to deploy and install client certificates or utilising only one client certificate for all mobile access points. Solving this issue can however be a topic for paper or some future blog post, when actual need arises. I did not yet configure the certificate revokation list (CRL) retrieval, but it is in my plans to document also this aspect.

Right, so now we have the actual configuration pretty much set up and we can start testing. Before running radsecproxy as a service I did a prelimanry testing by running it on OpenWRT console with the following command:

# radsecproxy -c /etc/radsecproxy.conf -d 3 -f

I was now able to check if the radsecproxy was able to connect to the home organisation RADIUS server and thus verify the radsecproxy configuration. After this was verified I enabled the radsecproxy permanently with the following command:

# /etc/init.d/radsecproxy enable

Then I rebooted the access point and verified once again that time was correct, radsecproxy was running as a daemon and wireless settings were correct before proceeding to eduroam authentication tests using my own TUT user account.

Like you have probably guessed, the testing was successful and I was able to now have my own mobile eduroam access point to be deployed wherever I may roam. :) Of the difficulties I ran into while doing this, I think the most difficult was once again setupping and configuring the X.509 certificates properly. The radsecproxy default was to check if the certificate CN contained the IP address mentioned in the server block and I had to check from the documentation how this check could be replaced with hostname check without having to use DNS hostname in the configuration block. The result is documented above there in the radsecproxy configuration.

RadSec as a technology felt very solid and functional for connecting devices and services to eduroam and the radsecproxy open source implementation was so well implemented and documented that I think it could be used as an official open source implementation to join to the eduroam federation with RadSec and this way as a roaming proxy replacing for example FreeRADIUS. Even the current radsecproxy implementation has better functionality set (for example dead realm marking) for eduroam proxy usage than the current FreeRADIUS has.

<commercial>Or then again, you can get a Radiator RADIUS+RADSEC server from us, Open System Consultants or some other reseller.</commercial>

Finding rogue IPv6 routers on Mac OS X

2010-03-15T09:14:00.000-07:00

In one of the larger wireless campus networks there was a problem of an annoying host advertising 6to4 (2002) and fec0 prefixes to a network segment which already had an official IPv6 router. This is the same kind a situation as rogue DHCP server in IPv4 network. All traffic is sent to go through the advertising host and if that can either route or drop the traffic making IPv6 services slow or unusable. There exists few extensions for IPv6 to secure router advertisements and only accept proper ones, but those extensions are rarely implemented in the mobile devices.

So to find the owner of the misbehaving host, one option is to find the IPv4 address from the 6to4 prefix and inform NOC (Network Operations Center) about it. In 6to4 addresses the original IPv4 address is part of the IPv6 address so we can find out the corresponding IPv4 address this way (example IPv6 prefix 2002:c0a8:2a2a::/48):

% printf "%d\n" 0xc0
192
% printf "%d\n" 0xa8
168
% printf "%d\n" 0x2a
42

The IPv4 address corresponding to 2002:c0a8:2a3a::/48 prefix is thus 192.168.42.42. The IPv4 address is often enough to find the host and its owner, but in large wireless networks the IPv4 addresses may get reassigned so also the time of the problem must be recorded. Then the host and owner can be checked from the DHCP server logs or from the wireless network management system such as Airwave.

There exists also a way to identify the host faster and that is to find out its ethernet mac address. In IPv4 there is ARP, which is used to find out the mac addresses of the corresponding IPv4 addresses. In IPv6 the similar protocol is called Neighbor Discovery Protocol (NDP). The problem was where and how to find this information. In Linux it is possible to use ip utility for this (the addresses in these example are not related to the 6to4 culprit):

% ip -6 neighbor list
fe80::224:36ff:fe9d:c1dc dev br0 lladdr 00:24:36:9d:c1:dc router REACHABLE

It took me for a while to find out what I could use on Mac OS X, but the manual pages hinted that Mac OS X's IPv6 stack conformed to the NetBSD implementation documentation found at:

http://www.netbsd.org/docs/network/ipv6/

The command needed for neighbor discovery protocol control on Mac OS X is called ndp. With this command it is possible to display and manipulate neighbor discovery protocol tables and find out the corresponding ethernet mac addressed for default router IPv6 addresses (listed with netstat -nr):

% netstat -nr
Internet6:
Destination                             Gateway                         Flags      Netif Expire
default                                 fe80::212:3400:9c56:7890%en1    UGc         en1
% ndp -a
Neighbor                        Linklayer Address  Netif Expire    St Flgs Prbs
fe80::212:3400:9c56:7890%en1    0:12:34:56:78:90     en1 23h59m9s  S  R

The more hardcore IPv6 specialists may read the ethernet mac address directly from the link level IPv6 address. The problem is that the link level address may not be always formed from the actual linklayer address so this method is preferable and also a bit more friendlier to user

eduroam(tm) expands in Japan

2010-03-11T00:07:00.000-08:00

RADIUS based authentication roaming federation eduroam(tm) expands in Japan according to Terena's translated news item. The expansion is done in cooperation between the Japanese National Institute of Informatics (NII) and Livedoor, a Japanese provider of commercial WLAN services.

These kind of cooperation announcements give additional validation to Arch Red's vision on utilising eduroam(tm) tried technology to increase community network coverage through roaming instead of building overlapping Wi-Fi networks or trying to form only one dominating one.

Karri Huhtanen presenting at TREX Workshop 2010

2010-02-19T04:04:00.000-08:00

Karri Huhtanen is presenting ICT SHOK Future Internet Testbed, Wireless Tampere and Funet WLAN roaming today on 19th of February at TREX Workshop 2010.

Guest Server 2.8.0 released

2009-11-12T06:25:00.000-08:00

Arch Red Guest Server version 2.8.0 is now available. The version number jump from 2.6.x is an indication of a substantial change: the guest server now handles the time in UTC (Coordinated Universal Time). The user interface stays the same, but the users are now associated with a time zone. This change helps organisations that operate on multiple time zones. For example, the user can be located in Finland while the Guest Server runs in the headquarters in Australia's Adelaide *.

The user associated time zones add to the Guest Server's existing support for internationalization and localization. Global organisations can better serve their customers internally and those who want to run guest sever as a service can now offer their service word wide.

Other changes include enhanced support for multiple languages and easier Guest Server installation. Also included is the previously blogged support for duration for all guest account types.

* The normal time in Finland is UTC+2 while Adelaide in southern central Australia uses UTC +9:30. Both observe daylight savings time, but one has to remember that southern hemisphere switches to DST during the autumn while northern hemisphere changes during the spring, as seen from Finland. The exact time difference between Finland and southern central Australia is left as an excercise for the reader ...

Publications added

2009-09-16T04:57:00.000-07:00

Publications have now been added in English and in Finnish. We usually try to keep the content on our web pages similar, but this time please see the both. For example, the comprehensive IPv6 and NAT material is only in Finnish.

The topics include papers, tutorials, white papers and reports on WLANs, user authentication, roaming and other networking issues.

This is a good start and more will be available later.

Products and examples - see things that Arch Red does

2009-09-08T13:30:00.000-07:00

Product summaries page comes from the experience gathered from the presentations and courses we have given. There is always the moment when the topics are put together, so why not look at the products as a whole too? We already had the products listed individually, and now the summary page shows how they relate to each other, how they can be used to build complete systems and the possibilities to use them with products from others.

Besides products, the page has also architecture design examples. Our products are based on the knowledge we have about what works and what are the right building blocks for a successful design. Depending on the needs of the customer we can use our own products or choose something from the other vendors. Like the examples show, we do not always try to build everything from scratch, but take whatever works best for reaching the requirements.

Going on Tour with Netti-Nysse and Wireless Tampere

2009-08-27T09:56:00.000-07:00

Our company does various things. We of course have our products, services and the R&D centered around them, but we have also our hobby projects -- the projects which we do because of their challenges and also because sometimes it is just fun. Tampere City Library's Internet Bus, Netti-Nysse, is one of those projects we are not just doing for money, but because it has its own challenges and it is fun to utilise our expertise to make the concept grow better.

I am currently writing this sitting in the Netti-Nysse's lecture space somewhere near Venice and on route to Ljublana Slovenia. My mission here is to support the Netti-Nysse team in ICT issues such as the handling of the bus's central Linux server and getting Internet connectivity and bandwidth for the bus wherever and however we can. You might think that's an easy task, just add 3G HSPA modems, but the roaming costs of 1.5 EUR/MB do not exactly encourage utilising that kind of connectivity. So mostly it is just WiFi we already are and will be using.

I have also a mission from Wireless Tampere to promote its open cooperative concept of wireless community network to Tampere's partner cities and at the same time I hope I will be able to find new cooperation, contacts, ideas and even roaming agreements between existing city-wide or municipial wireless networks.

Karri Huhtanen (Arch Red Oy)
Internet Roadie

Guest Server 2.6.1 released

2009-08-10T04:38:00.001-07:00

Arch Red Guest Server 2.6.1 has been released. The release includes one feature and many small enhancements. Now when creating guest accounts, the duration for the accounts can be set.

What is duration? For example, a guest account is created so that it is valid until December 31st and has duration of 24 hours. The guest can log in any time before December 31st, and when the first login happens, the account is valid only for the next 24 hours.

Duration could be specified in the previous versions too, but only for anonymous accounts. Now the duration is also available for personal accounts.

See the demo page for more information about WWW and RADIUS demo.

VMware Server - management over ssh

2009-06-04T07:15:00.001-07:00

Both VMware Server versions, 1.0.x and 2.0.x, can be managed over ssh. Advantage of this is the simplicity of firewall rules which only have to allow ssh to enable VMware management - over ssh. Running VMware management over ssh is even more useful with VMware Server 2.0.x, which uses two TCP ports.

VMware Server 1.0.x
ssh -4 -v -L 1902:127.0.0.1:902 vmwareserver1.example.com
[messages resulting from -v option removed]
debug1: Local connections to LOCALHOST:1902 forwarded to remote address 127.0.0.1:902
debug1: Local forwarding listening on 127.0.0.1 port 1902.

ssh -v shows that all connections to local loopback address 127.0.0.1 and TCP port 1902 are forwarded over ssh to the server's loopback address 127.0.0.1 and port 902.

The reason I am using port 1902 at the local end is that in order to use port 902 ssh must run as root.

Connecting to the server with WMware Server Console is done by choosing "Remote host" and entering 127.0.0.1:1902 as "Host name".

VMware Server 2.0.x
ssh -L 1902:localhost:1902 -L 8333:localhost:8333 vmwareserver2.example.com

The difference with 1.0.x is that:

Two ports are forwarded now: also port 8333 is forwarded to the remote server
Local port 1902 as now forwarded to remote port 1902, not to port 902

Remote port 1902 is not the default port on the server. The default port was changed with vmware-config.pl command from 902 to 1902. The port belongs to VMware authd process.

VMware Server 2.0.x uses two ports for management:

Port 8333 is used with web browser for initially contacting the server over https
The number of second port is learned from connection 1, which in this case is 1902

The reason for configuring the authd port as 1902 is ssh. Now when the ssh command is run, there is no need to run it as root, since it does not have to bind to privileged port 902 but port 1902 instead.

If the server has already been configured to use port 902 and reconfiguring is not an easy option, the ssh command can be run e.g., with sudo as root with port set to 902.

In both cases, once the two ports (8333 and 1902 or 902) have been forwarded with ssh, the server can be contacted with the web browser using https://127.0.0.1:8333/

Tricky, isn't it?

IPv6 and Arch Red

2009-05-20T06:28:00.001-07:00

Arch Red is now fully IPv6 connected. Web pages, email and DNS are most visible to everyone but also less used and internal services such as routing, RADIUS and centralized authentication run on IPv6 now. The latest addition was web availability over IPv6, so we can now consider ourselves as IPv6 enabled.

Why now? Is now the time to start using IPv6? From the technical perspective IPv6 is mostly ready. Some applications and services such as VPN could still be more widely available. There is time to fix these problems, but the according to the projections, IPv4 addresses can only be distributed using the current policy for a relatively short time. For Arch Red's people IPv6 is something we have done for years. Since we consider IPv6 as one of our areas of competence, this is the right time for us.

Based on our own experiences, it is of utmost importance to make your services ready before publishing them to others. Publishing usually means adding IPv6 information to DNS or by some other means advertising your IPv6 availability. This advice about readiness is almost a cliche. As the dictionary says: overused and has thus lost its original impact. Even if this is well known, IPv6 services often do not function as well as their IPv4 counterparts.

There are many things that could be said about IPv6 but now is not the time anymore to roll out barely functional IPv6 services. There are already users out there and more and more are using IPv6 each day.

Guest Server 2.6 and demo are here

2009-05-13T05:30:00.000-07:00

Yesterday version 2.6 of Arch Red Guest Server was released. Along the new release, the demo was also updated and upgraded significantly. Besides WWW interface, the RADIUS interface is now available for connecting one's own RADIUS gear to see how the guest accounts work.

The reason for bringing the RADIUS interface available is to have a way to demonstrate what is possible with Radiator. Serving basic authentication protocols, EAP for WPA and WPA2 and returning tags associated with guest accounts is just a small scratch on the surface, but should provide a good starting point. For example, all kinds of possibilities are available when utilising Guest Server's tag support.

Thanks go to Karri for suggesting the RADIUS demo!

Arch Red Guest Server v2.6 getting near completion

2009-04-27T04:29:00.000-07:00

Lately I have been working on the next release of Arch Red Guest Server. Version 2.6 includes new features and enhancements requested by our customers. Some examples are:

Guest account printing to PDF labels (badges, stickers, etc.)
Full internationalization support
A number of user interface enhancements
More configuration possibilities and controls for administrators

PDF label printing is handy when using the Guest Server as an integrated customer registration and access control solution. PDF label size can be variable, they can contain your desired logo and any text you see required, such as reminder about acceptable use policy.

The PDF label printing is also the first application of the new delivery framework, which offers a new interface for printing, mailing or using other methods such as SMS for delivering the account information to guests.

Guest names and event titles can now be any language and be mailed or printed without problems with garbled fonts. It does not matter where your guests come from, be it northern Europe or Japan for example, names and event titles display correctly leading to better customer satisfaction.

The user interface has been enchanced based on customer feedback. The workflow of adding guests is more streamlined and a number of other small enancements have been added.

For administrators the new version offers more configuration options for controlling the guest account creation and enhanced installer.

I will add more information and new demo showing the new version in a couple of days.