Appletalk Routing in 2025

As I've continued to play around with retro computing environments, based largely in virtual labs built with various incarnations of Qemu, I've run into some situations where I either needed or wanted to route some native Appletalk servers over IP networks, where Appletalk routers don't exist in between - or, at the very least, the routers don't have Appletalk services enabled, and I am not in control of the routers. It's also possible that I'm trying to contain my ancient computing environments enough that I both don't expose my overall environment to needless risk, and that I keep an InfoSec team happy that my activities are not doing that. So, how is one to overcome the obstacles of Layer 3 segmentation and Appletalk routing in 2025?

Simple: Linux. Okay, of course Linux - that's obvious, let's get more specific.

The biggest item you'll need - running on Linux, of course - is Netatalk. Netatalk is an open source Apple compatibility software suite for Linux, specializing in supporting some of the older Mac technologies, most notably the Apple Filing Protocol (AFP). In fact, version 3.x and 4.x of Netatalk really only support AFP. However, if you go back to the 2.x release, which still has some level of active maintenance on it (git code was updated in October 2024), you'll find it supports quite a wide range of Apple services - beyond AFP, it also supports printing (PAP), time synchronization (timelord), and, the one we're most interested in, Appletalk (atalk). Appletalk was a network protocol similar to Internet Protocol (IP) and IPX/SPX, and included features like network and node addressing that allowed it to inter-connect Apple systems over a wide range of networks, distances, media types, etc.

Several vendors included Appletalk routing in their products, as well. Cisco routers had it built in for years - and may still have the feature present (I haven't been on a Cisco router in a decade or more, so I'm not sure about that). Also, notably, Microsoft Windows NT 4.0 Server had a service that could be installed called "Services for Macintosh," which included, among other things (more on those in a future post), the capability to set up Windows to create Appletalk Zones (the equivalent of IP subnets) and route between them. Ultimately IP won out over the likes of Appletalk (and IPX/SPX, and a few others), but not before many organizations built out rather large Appletalk networks connecting Macintosh as well as other Apple platforms together with this protocol.

My first exposure to Appletalk was in elementary school in the early 1990s. My elementary school had a computer lab that had, first, Apple IIe computers, and then, later, the Macintosh LC computers (with the IIe co-processor card). The network used in both the Apple IIe and Macintosh LC incarnations of the lab was LocalTalk - or, more properly, Farrallon's PhoneNet, the much less expensive version of LocalTalk which used CAT3 (telephone) cable to link the systems together in a bus. A single "server" in the lab provided a central location for storing all of the educational games that were enjoyed by students when we were in the lab. There was also an HP LaserJet printer with an AppleTalk card in it, residing on the same network as the Macintosh LC workstations.

From there I moved to another elementary school, which had the Apple IIe platform (a step backward!), but I don't recall if any networking was used. Probably, if only to connect us to a single central printer. The real changes occurred when I went to middle and high school - the high school I attended was a brand new school, and had received a very large investment in computing. The layout of the school was a "pod" structure, where each pod was a series of classrooms around an outside ring, and the center of the ring was split between a relatively large computer lab (30-50 computers) and teachers' offices. The school opened with four pods, and, thus, four computer labs, three of which contained Intel-based PCs running Windows 95, and the fourth lab full of beautiful teal iMac G3s (including the hockey puck mouse). Each classroom in the school also had a Macintosh computer from the PowerMac/Performa 5000-series line, the beige all-in-one CRT units, for the teachers to use for presentations, attendance, multimedia, etc.

The computers in the school were connected via Ethernet, including the Mac computers, rather than LocalTalk/PhoneNet, but, for the Macintosh computers, Appletalk was still crucial to the networking of those systems, for two reasons: 1) the Macintosh platform did not have a CIFS/SMB client available at this point, so file shares had to be available via AFP, and 2) the AFP client on Mac OS did not support TCP/IP, it only worked over Appletalk.

The school's solution at that time was to enable AppleTalk routing on the school's routers, and to install and use Services for Macintosh on the Windows NT4 domain controllers and file servers to allow Macintosh clients to connect to the Windows NT4 file shares. This made it so that students and teachers could log on to the same file shares from both Windows and Macintosh clients and share files between the platforms.

Getting back to the present, I've attempted to re-create in spirit, if not in scale or actual hardware, the computing environment that existed in my high school, including routing Appletalk traffic between multiple zones. In searching for ways to solve the challenge of routing AppleTalk over non-AppleTalk networks, I first stumbled across something called AURP: Appletalk Update-Based Routing Protocol. Despite the name, which I find either ambiguous or misleading, or maybe both, AURP is more than just a routing protocol, it's actually a way to tunnel Appletalk traffic over IP, set up peers on remote ends of those networks, and create and update Appletalk routing tables across those networks.

Unfortunately, finding software - or, at least, freely-available software - that supports AURP is a bit difficult. Linux does not appear to have support for AURP built-in to the kernel or any of the standard routing tools, and Netatalk makes no mention of supporting the protocol, even in their older atalkd daemon. Maybe there's a programming challenge waiting, there, somewhere, but not just, yet. Beyond that, while Cisco supports the protocol, you either need a couple of physical Cisco routers or you have to be able to download and run one of the Cisco Virtual Router platforms, which requires a purchase and support contract. Novell Internet Access Server (NIAS) appears to have support for AURP; however, IAS is a legacy product, not free, and there are no apparent available downloads for it. It's possible that FreeBSD contains some support for it, although there doesn't seem to be any readily-available documentation, only a few obscure source code files. Finally, I found some references to "Apple IP Gateway" as a piece of software that supports both Appletalk and IP, but I'm having trouble locating the software download for it, and it's unclear, without actually playing around with it, if it will actually provide the AURP functionality to route between Appletalk networks over IP, or if it just provides a way for for Appletalk clients to access resources on IP-connected systems, which is a slightly different challenge.

As I thought about the challenge, though, it occurred to me that I ought to be able to solve this with any type of Layer 2 tunneling configuration, and those are plentiful - there are a wide variety of options out there for creating a Layer 2 over IP, many of which support encryption, as well. I briefly looked at a couple of the better-known VPN software packages - OpenVPN being the best-known option out there, and one I have worked with in the past. The challenge with the likes of OpenVPN and LibreSWAN is really the level of configuration required to get it functional and troubleshoot issues. OpenVPN isn't too bad, the others can be quite tedious. I also stumbled across options like GRE, which is relatively easy to configure and provides fairly simple encapsulation of just about any Layer 2 protocol you'd like within IP. While any of those would have done, and there are a few I might like to explore in more detail simply for the fun of doing something different or perhaps more period-appropriate to the computing environment that I'm trying to simulate, one option came to mind that was relatively simple and something that I deal with on a daily basis: SSH.

Many SSH users are familiar with the capability to do things like port forwarding, X11 forwarding, even UNIX socket forwarding, over SSH connections, but SSH also includes facilities for tunneling arbitrary Layer 2 protocols over SSH. And, what's more, tunneling over SSH adds layers of security (authentication and encryption) that are possible in more complex software configurations (IPsec, SSL VPN, etc.), but with relatively little configuration.

And, guess what? It works! I'm able to successfully create a SSH connection between two systems, either on the same subnet or across the Internet, configure tunneling between them, and then use the tap interface in Linux with atalkd to route Appletalk traffic and see the Mac resources on both ends of the tunnel.

Here are the configuration steps and details:

• router1
• Add a group called "tunnel"

sudo groupadd tunnel

• Add a user called "tunnel" in the group "tunnel"

sudo useradd -g tunnel tunnel

• Assign a temporary password for the "tunnel" user.

sudo passwd tunnel

• Update sshd_config to lock down any users in the "tunnel" group a bit:

Match Group tunnel

        X11Forwarding no

        AllowTcpForwarding no

        PermitTunnel ethernet

        PermitTTY no

• Create the tap interface and assign it to the "tunnel" user

sudo ip tuntap add tap0 mode tap user tunnel

• Configure atalkd to route between the local interface and the tap interface.

ens19 -router -phase 2 -net 103 -addr 103.142 -zone "Local Net 103"

tap0 -router -phase 2 -net 1001 -addr 1001.142 -zone "Virtual WAN"

• router2
• Add a group called "tunnel"

sudo groupadd tunnel

• Add a user called "tunnel" in the group "tunnel"

sudo useradd -g tunnel tunnel

• su to the tunnel account and create an SSH key.

sudo su - tunnel

ssh-keygen -t ed25519 -b 4096

• Install the SSH key to the "tunnel" user on router1.

ssh-copy-id tunnel@router1.domain.tld

• Configure the tap interface and assign it to the "tunnel" user.

sudo ip tuntap add tap0 mode tap user tunnel

• Configure atalkd to route between the local interface and the tap interface.

ens19 -router -phase 2 -net 101 -addr 101.143 -zone "Local Net 101"

tap0 -router -phase 2 -net 1001 -addr 1001.143 -zone "Virtual WAN"

• Start the SSH connection.

ssh -o Tunnel=ethernet -w 0:0 -t tunnel@router1.domain.tld

• Bring up the tap interface.

sudo ip link set tap0 up

• router1
• Bring up the tap interface.

sudo ip link set tap0 up

• Disable password access for the "tunnel" user.

sudo passwd -l tunnel

• Start atalkd

sudo systemctl enable --now atalkd

• router2
• Start atalkd

sudo systemctl enable --now atalkd

Screenshots: