Why Retail Terminals and Branch Stores Need Two Uplinks
A self-service terminal that loses its VPN doesn't just lose connectivity — it loses the ability to take payment.
A vending machine, a self-service kiosk or a small retail branch typically has exactly one wired uplink, and when that uplink fails — a cut cable, an upstream ISP outage, a router reboot — the site goes dark until someone drives out to fix it. For a self-service terminal handling payments and surveillance, that downtime is directly revenue, and for a chain store it's a manual escalation that shouldn't need to happen at all. The fix in both of the industry cases this note draws from is the same instinct with two different shapes: keep a second, independent path always ready, and switch to it automatically the moment the primary path stops answering.
This note covers two real deployments side by side. The first is a self-service terminal gateway with a wired primary uplink and a 4G cellular backup on the same device, switching over automatically via NQA-based link detection. The second is a chain-agency design where the branch stores have no wired uplink at all — they are purely cellular (3G/LTE) — and the emphasis shifts from failover to letting one headquarters gateway serve dozens of small, always-wireless branches through an IPSec policy-template. Both are dual-link or multi-branch VPN patterns; they are not the same problem.
Planning Essentials
Decide these four things before touching the CLI.
Addressing: the wired uplink usually carries a stable private or public address issued by the primary ISP; the cellular uplink carries a dynamic public address from the mobile carrier, so any IKE peer configuration on the cellular side has to tolerate an address that changes between reconnects. Traffic to protect: both cases in this note protect the same data flows — camera/surveillance VLANs and terminal/transaction VLANs — over whichever uplink is currently active, which means the security ACL has to be identical on both tunnels. Crypto suite: the self-service terminal case in this note uses SM3/SM4 national cryptographic algorithms end to end; that choice is independent of the failover mechanism itself and can be swapped for AES/SHA-2 where national crypto isn't mandated. Detection target: the NQA probe that decides whether the wired path is healthy has to test something that is only reachable via the wired path — testing a target reachable from both uplinks defeats the entire mechanism.
Detection and Switchover: NQA plus standby track
The switchover is a track object watching a health probe, not a routing metric race.
The mechanism behind the automatic failover is a Huawei NQA (Network Quality Analysis) test-instance running an ICMP probe over the wired uplink toward a target that's only reachable while the wired path is healthy — typically an address at headquarters. That test-instance is bound to a track object, and the track object is in turn bound to the cellular interface with standby track, which puts the cellular uplink into a standby state whenever the wired probe is healthy, and brings it up the moment the probe fails. Because both uplinks already have their own independent, always-established IPSec tunnel protecting the same ACL-defined traffic, the switchover itself is just an interface-state change — there's no renegotiation of IPSec or waiting for a new tunnel to come up, which is what keeps the interruption short.
-- NQA probe over the wired path -- nqa test-instance admin icmp test-type icmp destination-address ipv4 192.168.100.1 frequency 5 probe-count 3 timeout 1 start now # -- Cellular interface follows the probe via track -- interface Cellular0/0/0 standby track nqa admin icmp
Verification: display standby state on the cellular interface shows STANDBY while the wired probe is healthy, UP the moment the wired path fails, and returns to STANDBY once the wired path recovers.
Configuration Highlights — Self-Service Terminal, Two Independent IPSec Tunnels
One ACL, one set of protected flows, two separately-negotiated tunnels.
Both uplinks protect the same camera and terminal traffic with the same security ACL, but each has its own IKE peer and its own IPSec policy bound to its own interface — the wired GE interface and the cellular interface are never sharing one IPSec policy. This case uses SM3/SM4 national cryptographic algorithms throughout; swap the proposal algorithms for AES/SHA-2 if national crypto isn't a requirement in your deployment.
-- Shared protected-traffic definition -- acl number 3000 rule 5 permit ip source 10.168.11.0 0.0.0.255 destination 192.168.100.0 0.0.0.255 rule 10 permit ip source 10.168.12.0 0.0.0.255 destination 192.168.100.0 0.0.0.255 # ipsec proposal prop1 esp authentication-algorithm sm3 esp encryption-algorithm sm4 # ike proposal 1 encryption-algorithm sm4 dh group14 authentication-algorithm sm3 -- Tunnel 1: wired uplink -- ike peer hq_wired pre-shared-key cipher %^%#AbCd1234%^%# ike-proposal 1 local-address 10.100.2.1 remote-address 202.1.1.1 # ipsec policy wired_policy 10 isakmp security acl 3000 ike-peer hq_wired proposal prop1 # interface GigabitEthernet0/0/4 ip address 10.100.2.1 255.255.255.0 ipsec policy wired_policy -- Tunnel 2: cellular uplink, independent peer and policy -- ike peer hq_cell pre-shared-key cipher %^%#AbCd1234%^%# ike-proposal 1 remote-address 202.1.1.1 # ipsec policy cell_policy 10 isakmp security acl 3000 ike-peer hq_cell proposal prop1 # interface Cellular0/0/0 ipsec policy cell_policy standby track nqa admin icmp
Two Industry Cases, What's Actually Different
One gateway with a backup link is not the same design problem as fifty gateways with no wired link at all.
The self-service terminal case above is a resilience problem: a single gateway has two uplinks, and the goal is to keep the same site connected when its normal path fails. The chain-agency case is a scale problem: a headquarters gateway (AR1220-S) needs to serve dozens of small branch stores (AR101-S, AR121-S, AR207-S depending on store size), each of which is purely cellular — there is no wired uplink to prefer, because there is no wired uplink at all. Instead of one hub configuration per branch, the HQ side runs an ipsec policy-template with aggressive-mode IKE, so any branch that shows up with the right pre-shared key and the right local-name is accepted without headquarters needing a static peer entry per store. Branches identify themselves by name (ike local-name / remote-name) rather than by IP address, because a cellular branch's public address changes on every reconnect. EasyIP NAT on both ends is configured to exclude the IPSec-protected traffic from translation, so the tunnel's own ACL match isn't broken by the NAT rule sitting in front of it.
-- HQ side: one policy-template serves many branches -- acl number 3001 rule 5 permit ip source any destination 192.168.100.0 0.0.0.255 # ipsec proposal prop2 esp authentication-algorithm sha2-256 esp encryption-algorithm aes-256 # ike proposal 2 encryption-algorithm aes-cbc-256 authentication-algorithm sha2-256 dh group14 # ike peer branch_tmpl exchange-mode aggressive pre-shared-key cipher %^%#AbCd1234%^%# ike-proposal 2 local-id-type name local-name hq_hub # ipsec policy-template tmpl1 10 security acl 3001 ike-peer branch_tmpl proposal prop2 # ipsec policy branch_policy 10 isakmp template tmpl1 # interface GigabitEthernet0/0/1 ip address 202.1.1.1 255.255.255.0 ipsec policy branch_policy nat outbound 2000 # acl number 2000 rule 5 deny ip destination 192.168.100.0 0.0.0.255 rule 10 permit ip source any -- Branch side: cellular-only store, name-based identification -- ike peer hq exchange-mode aggressive pre-shared-key cipher %^%#AbCd1234%^%# ike-proposal 2 local-id-type name local-name store001 remote-address 202.1.1.1 # ipsec policy store_policy 10 isakmp security acl 3002 ike-peer hq proposal prop2 # interface Cellular0/0/0 ipsec policy store_policy nat outbound 2001
| Case | Uplinks | IKE mode | Peer identification | Design goal |
|---|---|---|---|---|
| Self-service terminal | Wired primary + 4G backup, one gateway | Main / static peer per uplink | Fixed remote address | Automatic failover, continuous single-site uptime |
| Chain-agency stores | Cellular (3G/LTE) only, many gateways | Aggressive mode + policy-template | Name-based (local-name / remote-name) | Scale one HQ policy to dozens of branches |
How to Confirm It's Actually Working
- Confirm both IPSec tunnels are independently established before testing failover — display ipsec sa should show an active SA on both the wired and the cellular interface at the same time.
- Check the NQA test-instance result directly — display nqa results admin icmp should show consistent probe success while the wired path is healthy.
- Confirm the track binding with display standby state on the cellular interface: STANDBY while wired is healthy.
- Disconnect or shut down the wired uplink and re-check display standby state — it should flip to UP within the configured probe interval, with no interruption to the IPSec SA on the cellular side.
- Restore the wired uplink and confirm the state returns to STANDBY automatically, without manual intervention.
Four Deployment Gotchas
SYMPTOMThe Cellular Backup Never Activates, Even When the Wired Link Is Down
The wired uplink is confirmed dead, but display standby state keeps reporting STANDBY on the cellular interface.
CAUSEThe NQA probe target is reachable by some path other than the specific wired uplink being monitored — for example, a target reachable via a default route that isn't actually tied to that interface — so the probe keeps succeeding even after the intended wired path fails.
FIXPick an NQA destination that is only reachable through the monitored wired interface, and confirm with display nqa results that the probe genuinely fails when that interface is disconnected.
SYMPTOMFailover Happens Instantly, But Traffic Still Drops for Several Seconds
standby track flips the cellular interface up right on schedule, but the site is still unreachable for a noticeable gap afterward.
CAUSEThe cellular tunnel's IPSec SA was never kept independently established — if the cellular IKE peer only starts negotiating after the interface comes up, the site is unreachable for the full IKE/IPSec negotiation time, not just the probe-detection interval.
FIXKeep both tunnels always-on, as in the configuration above — the switchover should be a standby-to-active interface state change, never a fresh IPSec negotiation.
SYMPTOMA New Branch Store's Tunnel Never Comes Up Even With the Correct Pre-Shared Key
The branch's cellular IP is confirmed working and the pre-shared key matches, but the IKE negotiation with headquarters still fails.
CAUSEA policy-template design identifies branches by ike local-name / remote-name in aggressive mode, not by IP address. If the branch's local-name doesn't match what headquarters expects, or the branch is still configured for main mode instead of aggressive mode, the negotiation fails regardless of a correct key.
FIXVerify exchange-mode aggressive and local-id-type name are set on the branch, and that the local-name value is exactly what the HQ policy-template configuration expects for that store.
SYMPTOMThe Tunnel Comes Up, But Protected Traffic Still Gets NATed
IKE and IPSec SAs both show as established, but traffic to headquarters arrives with a translated source address instead of the original one.
CAUSEThe EasyIP NAT rule on the outbound interface is evaluated without an exception for the IPSec-protected destination, so traffic matching the tunnel's ACL is translated before it ever reaches the IPSec policy.
FIXAdd a deny rule for the IPSec-protected destination at the top of the NAT outbound ACL, exactly as shown in the HQ configuration above, so that traffic is excluded from translation before the permit rule is reached.
Frequently Asked Questions
Does the 4G backup replace the wired link permanently, or only during an outage?
Only during an outage. standby track is revertive by design — once the NQA probe over the wired path succeeds again, the cellular interface automatically returns to standby, no manual intervention needed.
Does the site need two separate VPN tunnels, or one tunnel that migrates between uplinks?
Two independent, always-established tunnels — one bound to the wired interface, one bound to the cellular interface, both protecting the same ACL-defined traffic. The switchover is an interface-state change, not a tunnel migration.
Can a branch that's cellular-only skip the dual-link planning entirely?
Yes — that's exactly the chain-agency case in this note. There's no wired path to prefer, so there's no NQA/track failover mechanism needed; the design question there is scaling one HQ gateway to many branches, not failover.
How does headquarters accept dozens of branch stores without a static configuration per branch?
An ipsec policy-template combined with aggressive-mode IKE and name-based peer identification (local-name / remote-name) — any branch presenting the right pre-shared key and identity name is accepted through the template without a dedicated peer entry.
Is SM3/SM4 required, or can standard AES/SHA-2 be used instead?
SM3/SM4 is what the self-service terminal case in this note uses because national cryptographic algorithms were a requirement in that deployment; the NQA/track failover mechanism and the policy-template scaling mechanism both work identically with AES/SHA-2 where national crypto isn't mandated.
Related Solution Designs
Retail & Chain Store Network
The full store-network design this dual-link and multi-branch pattern feeds into, from a single kiosk to a nationwide chain.
Banking & Financial Branch Network
Segmented branches, SD-WAN wide-area transport, dual-link redundancy and compliance-ready audit for regulated branch networks.
Planning a store rollout with dual-link resilience?
Tell us how many sites, what carriers are available locally, and whether national cryptographic algorithms are required.