Overview

SoftGRE tunnels wireless client traffic from OpenWiFi access points back to the gateway at Layer 2. It is configured in two halves: a Pseudo Interface that terminates the tunnel, and the Tunnel settings on the WLAN that tell the access points where to send it. Most of the difficulty is not in the settings themselves. It is that a wrong configuration saves cleanly, reports no error anywhere, and produces a network that looks like it is working. This article gives the build order and the verification order, and both orders matter.

Type

Procedure and Troubleshooting

Applies To

OpenWiFi access points on a gateway build that includes SoftGRE. Single-node and cluster.

Problem / Question

• A Pseudo Interface saves with no member interfaces selected and it is unclear whether that is valid
• No tunnel interfaces appear on the gateway and it is unclear whether the tunnel is up
• Every client on a tunnelled SSID reports an invalid password
• The SSID is not broadcast at all, with no error to explain why
• A tunnelled VLAN tears down and rebuilds continuously

Prerequisites

The gateway must be on a build that has SoftGRE. It does not exist on 16.384, so nothing can be configured until the upgrade is done.

Access points on 4.2.4-0.011. Assign firmware per access point in batches rather than repointing the profile, and leave each assignment in place afterwards so units do not fall back. Check your default firmware records too: if they still point at 4.1.1, any newly adopted access point lands on the old build.

Solution / Answer

Create the Pseudo Interface

Network >> LAN >> Pseudo Interfaces, Create New:

On member interfaces. The form accepts an empty list and the tunnel still works on a single-node appliance, because the underlay falls back to the parent interface of the VLANs you selected. Select it anyway. The fallback resolves per node, so it is not equivalent on a cluster, and leaving it empty silently skips two prerequisite checks: cluster-node binding, and VLAN hardware filtering.

On VLANs. This is the step that actually matters. List every VLAN clients will land on, not just the WLAN's default. If your RADIUS realm assigns a VLAN, that is the one to carry. The WLAN default is only a fallback and is usually not what clients get.

On Inbound Traffic. This must match the subnet the access points send from, not the client subnet. If it is wrong the tunnel fails silently.

Do not select DPU mode unless a DPU is present. Only one SoftGRE Pseudo Interface is supported per appliance.

Configure the WLAN

Network >> Wireless >> WLANs:

Fast Roaming must be off on any WLAN using per-device keys. Leaving it on disables the key lookup entirely and every client reports an invalid password.

Make sure the WLAN has a zone. Without one the SSID is simply not broadcast, and there is no error anywhere to tell you why.

If your zone has 6 GHz enabled, WPA2 is rejected on that WLAN. 6 GHz requires WPA3 or OWE, and WPA2/WPA3 mixed is not supported on OpenWiFi. Use WPA3 if you hit this.

Apply

Reboot the test access point. Pushing state does not flip a tunnel that is already established.

If Fast Roaming was previously on, forget the network on the client before retesting. A cached credential fails with the identical invalid-password message and looks like the fix did not work.

Verification

Work through these in order. Steps 1 to 3 can all pass on a network whose tunnel is carrying nothing.

1. Do not look for tunnel interfaces on the gateway. SoftGRE terminates in netgraph and creates no gre, tap or bridge device. An empty ifconfig is normal even when everything is working.

2. Confirm the gateway side came up. The ng_sdan module loaded, ng_sdand running, and the log showing the l2ogre app started with a status of ok and your VLAN range.

3. Confirm the client authenticates and lands on the expected VLAN.

4. Confirm the encapsulation at the access point. This is the only real proof:

logread | grep rg_wss_client

Look for encap=softgre with the peer address, and Tunnel Monitor lines showing tunnels, macs and hooks counts with packets moving.

5. Confirm a client gets an address on the tunnelled VLAN.

A client that connects and works is not proof the tunnel is carrying its traffic. Traffic can take the ordinary bridged path while the tunnel carries nothing. Step 4 is what settles it.

Known Issue

Once the tunnel is up, expect churn on VLANs with few clients. When the last client on a VLAN leaves an access point, that VLAN's tunnel is torn down immediately with no grace period, then rebuilt on the next association. Tracked as issue 4349, fix in progress.

Tell: removed from vlan N (0 remaining) followed by tunnel removed vlan=N in the access point log.

It is masked on busy VLANs, where the count never reaches zero, and worst on quiet ones. Adding a second active client to the same access point and VLAN stops the cycling, which is a quick way to confirm you are seeing this and not something else.