Menu
App Armor: Adaptive SD-WAN Tunnels for Session Continuity
App Armor applies application-aware traffic policies to a peered SD-WAN tunnel. After the endpoints, routes and policies are configured, it monitors WAN conditions and adapts packet-level path decisions as those conditions change.
Flow identification
Application classification identifies the traffic that should use a particular policy. Confirm the classification and routing for the applications in your deployment.
Adaptive overlay tunnelling
The configured application profile determines how the tunnel handles the traffic. Voice, live video and bulk data have different capacity, delay and loss requirements.
Path monitoring and QoS
Path telemetry includes latency, loss, jitter and available capacity. Adaptive path selection and appropriately sized QoS reservations help the configured traffic respond to WAN changes.
Session continuity deployment guide
Configure adaptive tunnels for real application traffic
Use a peered tunnel and application-aware policies to help calls and business sessions adapt to WAN changes. Treat endpoint reachability, routes and remaining capacity as part of the deployment.
Protected application traffic through a peered tunnel
- ApplicationsPhones, meetings or business traffic
- Client routerClassify and route the flows
- WAN pathsWired, cellular or satellite
- Relay / serverMatching tunnel and return routes
- DestinationPBX, application service or remote LAN
Load balancing, bonding and session continuity
| Configuration | Role | Continuity conditions |
|---|---|---|
| Standalone load balancing | Selects WAN paths for separate sessions. | A direct session uses the selected WAN addressing. A WAN change can require the application to reconnect. |
| Peered bonding | Carries packets from a session across eligible WAN paths to a relay. | Continuity depends on the configured tunnel, stable endpoint/routing, usable surviving capacity and relay availability. |
| App Armor / VoIP Armor policy | Applies application-specific path handling and QoS to selected tunnel traffic. | Both client and server must classify/route the relevant flows. Confirm the profile and software/service options for the supported firmware. |
With an appropriately configured cloud IP or server endpoint, the remote application can continue to see the tunnel’s egress addressing while individual access links change. Traffic outside that tunnel follows its own WAN/NAT path.
Configure the application path
- Choose the endpoints. Use a supported Mushroom client and the cloud service or a customer-hosted Mushroom server/relay. Confirm the tunnel type, server licence and application profile with support.
- Bring the tunnel up. Apply the configuration for the supported firmware and confirm the server address, credentials and required network reachability. The linked older guides may show different menus.
- Route the application flows. Configure the client’s application/destination rules and the server’s return routes. For capture-all deployments, follow the complete firmware-specific instructions rather than assuming tunnel status alone proves traffic capture.
- Classify both directions. For SIP phone services, include SIP signalling and RTP media. Conferencing applications may use different control and media flows; verify their actual policy rather than treating every meeting as SIP.
- Apply QoS reservations and shapers. Size the policy for the codec, simultaneous calls or streams, and the usable capacity of the WAN mix. Confirm the policy at each endpoint.
- Check the path and IP behaviour. Verify that the intended flows use the tunnel, that replies return correctly, and that the application sees the expected egress addressing.
Test continuity and adaptive behaviour
- Start with the exact hardware, firmware, tunnel/profile, relay, codec or application, and QoS settings recorded.
- Run a long-lived application session while monitoring each WAN and the tunnel. Observe the application at the remote end, not just the router status.
- In a test setup, disconnect one link during the session, then introduce loss, changing capacity or higher delay on a path. Check for reconnection, media gaps and usable remaining capacity.
- Add competing bulk traffic to verify the voice/video QoS policy. Record latency, jitter, packet loss, application interruptions and the duration of each trial.
- Test full WAN loss and relay unavailability so the expected failure and recovery behaviour is understood.
Adaptive algorithms respond to path changes. They cannot preserve communication through a total loss of usable connectivity, an unavailable endpoint or insufficient capacity for the application. Tunnel security and encryption are configuration choices that should be confirmed for the deployment.
Is ordinary WAN failover enough to keep a call connected?
Failover can restore a path for new or restarted sessions. A direct session may need to reconnect if its path or public addressing changes. For tunnel-based continuity, verify the application routing, endpoint addressing, relay and remaining WAN capacity.
Does an “up” App Armor tunnel protect all traffic automatically?
The selected traffic must be routed and classified into the tunnel. Confirm the return path and QoS policy as well. Use the firmware-specific configuration references and monitor the actual application flows.