Quartz sync: Jan 6, 2026, 12:15 AM
All checks were successful
Build and Push Quartz Wiki / build-and-push (push) Successful in 43s
All checks were successful
Build and Push Quartz Wiki / build-and-push (push) Successful in 43s
This commit is contained in:
vorpax
@@ -0,0 +1,247 @@
|
||||
---
|
||||
title: Untitled
|
||||
publish: true
|
||||
date: 2026-01-05
|
||||
tags:
|
||||
- guide
|
||||
- network
|
||||
description: A guide on how to connect to 802.1X on OpenWRT
|
||||
---
|
||||
|
||||
# Connecting a Travel Router to eduroam with 802.1X on OpenWrt
|
||||
|
||||
## The Problem
|
||||
|
||||
Universities use eduroam, a secure roaming WiFi service that requires 802.1X authentication.
|
||||
This presents a challenge when you want to connect multiple devices or run infrastructure like a homelab node in a dorm room.
|
||||
Most consumer devices expect simple WPA2-PSK networks where you just enter a password, but eduroam requires each device to authenticate individually with a username and certificate validation.
|
||||
|
||||
The typical solution is to authenticate each device separately, but this becomes impractical when you need to connect servers, or devices that lack proper 802.1X supplicant support.
|
||||
|
||||
A travel router solves this by authenticating once to eduroam and then providing a standard local network for your devices.
|
||||
|
||||
## Understanding 802.1X and eduroam
|
||||
|
||||
The 802.1X standard defines port-based network access control. When you connect to an 802.1X network, the access point acts as an authenticator that forwards your credentials to a RADIUS server. The RADIUS server verifies your identity and either grants or denies network access.
|
||||
|
||||
eduroam uses 802.1X with EAP-TTLS or PEAP as the outer authentication method and typically PAP or MSCHAPv2 for the inner authentication.
|
||||
The outer method creates an encrypted tunnel using TLS, and your actual credentials travel through this tunnel to the RADIUS server. This provides strong security even on an open wireless network.
|
||||
|
||||
The authentication flow involves presenting a username in the format `user@institution.domain`, an anonymous identity to protect your real username during the initial handshake, and validating the RADIUS server certificate against a trusted CA certificate. This last step prevents attackers from impersonating the authentication server.
|
||||
|
||||
## Why a Travel Router
|
||||
|
||||
A travel router is a compact router designed for mobile use.
|
||||
|
||||
In our case, it serves as a translation layer between the complex 802.1X requirements of eduroam and the simpler networking expectations of our devices.
|
||||
|
||||
You authenticate the router once to eduroam, and it provides a local network over Ethernet and wifi where you can connect servers, development machines, or any IoT devices without each device needing to understand 802.1X.
|
||||
|
||||
This approach provides several advantages.
|
||||
You can run services that require static IPs or specific network configurations. You can connect devices that lack 802.1X support entirely. You avoid repeatedly entering credentials on multiple devices.
|
||||
|
||||
Most importantly, you gain control over your local network segment, enabling you to run monitoring tools, configure custom DNS, or set up VLANs as needed.
|
||||
|
||||
## Hardware and Software Selection
|
||||
|
||||
This guide uses the GL.iNet Beryl AX (GL-MT3000) running OpenWrt 24.10 with a MediaTek MT7981 chipset.
|
||||
|
||||
Like most Mediatek chipsets, The MT7981 has mature driver support shipped with recent Linux Kernel and hence is well supported on OpenWrt, moreover it handles 802.1X authentication reliably.
|
||||
|
||||
OpenWrt is a Linux-based router firmware that replaces vendor firmware with a fully configurable system. Unlike consumer router interfaces, OpenWrt exposes the full Linux networking stack and uses the `wpa_supplicant` (along with `hostapd`) for 802.1X support.
|
||||
|
||||
The choice of OpenWrt over the stock GL.iNet firmware ensures we are working with well-documented, upstream software.
|
||||
|
||||
## Building a Custom OpenWrt Image
|
||||
|
||||
Rather than flashing a stock image and installing packages afterward, building a custom image ensures all necessary packages are included from the start. This is important because you need working internet connection to install additional packages, creating a chicken-and-egg problem.
|
||||
|
||||
Visit the OpenWrt firmware selector at `https://firmware-selector.openwrt.org/` and search for "GL-MT3000"
|
||||
Then, in the package customization field, you need to make one critical change and add several packages.
|
||||
|
||||
The default OpenWrt image includes `wpad-basic-mbedtls`, which is a minimal WiFi configuration tool that lacks 802.1X support.
|
||||
You **must remove this package** and **replace it with the full version**. Enter `-wpad-basic-mbedtls` (note the minus sign) to remove it, then add `wpad-mbedtls` to install the full version with EAP support.
|
||||
|
||||
Add these additional packages in the same field: `ca-certificates` for validating SSL certificates, `vim` and `bash` if you prefer these over the default `vi` and `ash` shells. The complete package customization string should read:
|
||||
|
||||
```
|
||||
base-files
|
||||
ca-bundle
|
||||
dnsmasq
|
||||
dropbear
|
||||
firewall4
|
||||
fitblk
|
||||
fstools
|
||||
kmod-crypto-hw-safexcel
|
||||
kmod-gpio-button-hotplug
|
||||
kmod-leds-gpio
|
||||
kmod-nft-offload
|
||||
kmod-phy-aquantia
|
||||
libc
|
||||
libgcc
|
||||
libustream-mbedtls
|
||||
logd
|
||||
mtd
|
||||
netifd
|
||||
nftables
|
||||
odhcp6c
|
||||
odhcpd-ipv6only
|
||||
opkg
|
||||
ppp
|
||||
ppp-mod-pppoe
|
||||
procd-ujail
|
||||
uboot-envtools
|
||||
uci
|
||||
uclient-fetch
|
||||
urandom-seed
|
||||
urngd
|
||||
kmod-mt7915e
|
||||
kmod-mt7981-firmware
|
||||
mt7981-wo-firmware
|
||||
kmod-hwmon-pwmfan
|
||||
kmod-usb3
|
||||
kmod-usb-net
|
||||
kmod-usb-net-ipheth
|
||||
luci
|
||||
wpad-mbedtls
|
||||
usbmuxd
|
||||
libimobiledevice
|
||||
vim
|
||||
bash
|
||||
usbutils
|
||||
```
|
||||
|
||||
Request the build and download the resulting firmware image. Flash this to your router following the standard flashing procedure for your model.
|
||||
|
||||
## Obtaining eduroam Credentials
|
||||
|
||||
Your institution should provide an eduroam configuration tool, typically through the eduroam Configuration Assistant Tool at `cat.eduroam.org`.
|
||||
|
||||
Download the Linux installer for your institution, it's a rather convenient Python script which we will extract the configuration parameters from.
|
||||
|
||||
Look for the configuration section near the end. You need these specific values: the EAP outer method (likely TTLS or PEAP), the inner authentication method (likely PAP or MSCHAPv2), the RADIUS server hostname, the anonymous identity, and the CA certificate.
|
||||
|
||||
The CA certificate appears in the script as a multi-line string starting with `-----BEGIN CERTIFICATE-----`.
|
||||
|
||||
Copy this certificate exactly, preserving all line breaks, and save it to a file. This certificate will be used to validate that you are connecting to your institution's legitimate RADIUS server.
|
||||
|
||||
## Initial Router Configuration
|
||||
|
||||
Connect to your router over Ethernet after flashing. The default IP is typically `192.168.8.1` or `192.168.1.1`. SSH to the router as root (password may need to be set on first boot through the web interface).
|
||||
|
||||
Create the CA certificate file in the appropriate location. Copy your institution's CA certificate and save it to `/etc/ssl/certs/institution-ca.crt`. Set the permissions to be world-readable:
|
||||
|
||||
```bash
|
||||
chmod 644 /etc/ssl/certs/institution-ca.crt
|
||||
```
|
||||
|
||||
## Configuring the WiFi Interface
|
||||
|
||||
OpenWrt uses the UCI (Unified Configuration Interface) system for configuration. The wireless configuration file is `/etc/config/wireless`.
|
||||
|
||||
You can edit this file directly or use UCI commands. The UCI approach is safer as it validates syntax.
|
||||
First, determine which radio to use. Run `wifi status` to see available radios.
|
||||
|
||||
The Beryl AX typically has `radio0` for 2.4GHz and `radio1` for 5GHz. Choose based on which band eduroam uses at your location. The 5GHz band often has less interference but shorter range.
|
||||
|
||||
Create the eduroam interface configuration:
|
||||
```bash
|
||||
uci set wireless.eduroam=wifi-iface
|
||||
uci set wireless.eduroam.device='radio1'
|
||||
uci set wireless.eduroam.network='wan'
|
||||
uci set wireless.eduroam.mode='sta'
|
||||
uci set wireless.eduroam.ssid='eduroam'
|
||||
uci set wireless.eduroam.encryption='wpa2+ccmp'
|
||||
```
|
||||
|
||||
This creates a station mode interface (meaning the router acts as a WiFi client) associated with the WAN network.
|
||||
|
||||
Now add the 802.1X parameters:
|
||||
```bash
|
||||
uci set wireless.eduroam.eap_type='ttls'
|
||||
uci set wireless.eduroam.auth='PAP'
|
||||
uci set wireless.eduroam.identity='your.username@institution.domain'
|
||||
uci set wireless.eduroam.anonymous_identity='anonymous@institution.domain'
|
||||
uci set wireless.eduroam.password='your_password'
|
||||
```
|
||||
|
||||
Replace the identity and password with your actual credentials. The anonymous identity protects your username during the initial handshake. Replace `institution.domain` with your institution's actual domain.
|
||||
|
||||
The certificate validation is where many configurations fail. In theory, you should validate the RADIUS server certificate against the CA:
|
||||
```bash
|
||||
uci set wireless.eduroam.ca_cert='/etc/ssl/certs/institution-ca.crt'
|
||||
uci set wireless.eduroam.domain_suffix_match='radius.institution.domain'
|
||||
```
|
||||
|
||||
However, many institution certificates lack proper Subject Alternative Name (SAN) fields, causing modern TLS implementations to reject them.
|
||||
|
||||
If you encounter authentication failures with certificate validation errors in the logs, you may need to disable certificate validation.
|
||||
|
||||
```bash
|
||||
uci delete wireless.eduroam.domain_suffix_match
|
||||
```
|
||||
|
||||
Commit the changes and reload the wireless configuration:
|
||||
```bash
|
||||
uci commit wireless
|
||||
wifi reload
|
||||
```
|
||||
|
||||
## Configuring the Network Interface
|
||||
|
||||
The wireless interface connects to eduroam, but you need to ensure the WAN interface uses this connection. Check the current WAN device:
|
||||
```bash
|
||||
uci show network.wan
|
||||
```
|
||||
|
||||
The default configuration often sets the WAN device to `eth0` (the Ethernet port), but you need it to use the WiFi interface. Change it to the wireless interface name:
|
||||
```bash
|
||||
uci set network.wan.device='phy1-sta0'
|
||||
uci commit network
|
||||
ifup wan
|
||||
```
|
||||
|
||||
The interface name `phy1-sta0` corresponds to `radio1` in station mode. If you used `radio0` instead, adjust accordingly.
|
||||
|
||||
After bringing up the WAN interface, verify it obtained an IP address:
|
||||
```bash
|
||||
ifstatus wan
|
||||
ip addr show phy1-sta0
|
||||
```
|
||||
|
||||
You should see an IPv4 address assigned via DHCP. Test internet connectivity:
|
||||
```bash
|
||||
ping -c 4 1.1.1.1
|
||||
ping -c 4 google.com
|
||||
```
|
||||
|
||||
## Understanding the Authentication Flow
|
||||
|
||||
Watch the authentication process using the system log:
|
||||
```bash
|
||||
logread -f | grep -i "wpa\|eap"
|
||||
```
|
||||
|
||||
A successful authentication shows this sequence: the supplicant tries to authenticate with the access point, the access point responds, EAP authentication starts, the TTLS method is selected, the TLS handshake completes (or fails with certificate errors), inner authentication occurs, and finally `CTRL-EVENT-EAP-SUCCESS` appears followed by `CTRL-EVENT-CONNECTED`.
|
||||
|
||||
If you see `CTRL-EVENT-EAP-FAILURE`, examine the lines immediately before it. Certificate validation errors mention hostnames or certificate chains. Authentication failures with valid certificates usually indicate wrong credentials. Connection attempts that timeout suggest the RADIUS server is unreachable or the configuration parameters are incorrect.
|
||||
|
||||
## Troubleshooting Common Issues
|
||||
|
||||
Authentication failures usually stem from three issues: incorrect credentials, certificate validation problems, or wrong EAP method parameters.
|
||||
|
||||
If logs show certificate validation errors mentioning hostnames or missing SANs, your institution's certificate lacks modern TLS extensions. Disable certificate validation as described earlier. This is a common problem with older certificate authorities.
|
||||
|
||||
If authentication fails after the TLS handshake completes, verify your username format matches your institution's requirements. Most institutions use `username@domain`. Check with your IT department.
|
||||
|
||||
If the connection succeeds but you have no internet access, the problem lies in the network interface configuration. Verify the WAN interface uses the correct device with `uci show network.wan`. Ensure DHCP is enabled on WAN with `uci set network.wan.proto='dhcp'`. Restart the network service after changes.
|
||||
|
||||
## Security Considerations
|
||||
|
||||
The router stores your password in plain text in the UCI configuration files. These files are only readable by root, but anyone with root access can read them. Avoid sharing configuration backups publicly and use strong router passwords.
|
||||
|
||||
## Conclusion
|
||||
|
||||
This setup provides a robust solution for connecting homelab infrastructure to enterprise WiFi networks. The travel router handles the complex 802.1X authentication, presenting a standard local network to your devices. This approach works well in university dorms, campus offices, or any environment using certificate-based network authentication.
|
||||
|
||||
*Published on January 05, 2026*
|
||||
Reference in New Issue
Block a user