ATM Connectivity over OpenVPN: What Happens When the WAN Fails?
An ATM may regain internet access before it can process the next transaction. When a wired connection fails, switching to cellular restores the underlying network path. The OpenVPN tunnel still has to reconnect, and the transaction application has to recover.
Following those steps explains why WAN failover, VPN recovery and application recovery need to be considered together. This article traces that path from a remote ATM to the processing systems in a data center, including what happens when the connection is shared with cameras or other site equipment.
The wired link drops. What happens next?
Consider a site where an ATM and a camera recorder share a wired internet connection. The ATM has its own network segment, while the recorder uploads footage in the background. The router also has two SIMs from different carriers.
If the wired link fails, the router detects the failure and switches to the first cellular connection. That gives it another way to reach the internet. It does not, by itself, show that the ATM can reach the transaction-processing system.
The OpenVPN client must establish its tunnel over the new path. The server authenticates the router, and the configured routes carry ATM traffic to the processing systems behind it. The application can then attempt its next exchange. How quickly that exchange succeeds depends on the network recovery and the application's own behaviour.
If the first carrier later becomes unavailable, switching to the second SIM starts another recovery sequence. A second carrier provides an alternative path when its service is available; the switchover still needs testing. At sites without a fixed line, the same reasoning applies to cellular as the primary connection.
These are useful distinctions when investigating an outage: an active WAN, a connected VPN and a successful transaction are three different observations.
Why the router initiates the tunnel
The ATM connects to the site router over Ethernet. The router acts as the OpenVPN client and initiates a connection to a reachable OpenVPN server in the data center. Transaction-processing systems sit behind that server.
This direction is useful on cellular networks, where a carrier may place the SIM behind address translation and restrict incoming connections. The site does not need an inbound public address for this design. It needs an outbound path to the server's configured address and port.
When the WAN changes, the router's external address may change too. Its client certificate still identifies it to the server. A fixed tunnel address, assigned through the server's per-client configuration, can keep site addressing and firewall rules consistent across reconnections.
The OpenVPN manual describes the controls that help the client recover:
Keepalive and restart settings detect a silent peer and trigger reconnection after the configured timeout.
Persist settings can retain the tunnel interface across supported restarts. They do not keep packets flowing while the underlying connection is unavailable.
Name-resolution retries let the client keep trying while network access returns.
Multiple `remote` entries provide alternative server endpoints if the first cannot be reached.
The available settings depend on the router's firmware and the server configuration. Their purpose is to make recovery predictable enough to test at the actual site.
Keep the ATM's route separate from other site traffic
An ATM may share its router with an alarm panel, cameras, digital signage, a point-of-sale device or staff Wi-Fi. Recovering the WAN should not give all of those devices access to the processing network.
Place the ATM on its own VLAN and subnet, then define what that subnet may reach. VLANs separate network segments; routing and firewall rules enforce access between them. The ATM subnet can be routed through OpenVPN to the required processing hosts and ports. Other devices can use local internet access, a separate tunnel or a restricted path according to their purpose.
Give each site a distinct ATM subnet from a planned address range. The data center then has an unambiguous return route to each site, and logs can distinguish one location from another. Per-client route entries on the OpenVPN server, together with the required system routes and firewall rules, connect those subnets to the correct clients.
This separation matters during normal operation as much as during failover. A camera recorder should not gain access to the ATM simply because both devices use the same uplink.
Protect transaction traffic when the backup link is busy
The camera upload may still be running when the site moves to cellular. The ATM's small, time-sensitive messages now compete with bulk traffic on the available uplink.
QoS gives the router a way to prioritise those messages where it controls the queue. Classify ATM traffic by its VLAN or subnet before encryption, then apply the appropriate priority on the WAN. Once traffic is encrypted, the outer packets no longer expose the same application details.
OpenVPN can copy the inner packet's type-of-service marking to the outer packet. That preserves the marking for the next part of the path; it does not establish how a carrier will treat it. Test with the background traffic that the site actually generates, rather than with an otherwise idle connection.
Packet size also deserves attention. VPN encapsulation adds overhead, and a cellular path may behave differently from the wired one. If small exchanges work but larger transfers stall, investigate the path MTU and the appropriate MTU or TCP MSS settings. A successful ping is only one part of that check.
Prepare the recovery settings before deployment
The useful configuration is the one that reconnects correctly after a failure. This short checklist brings the client and server settings together without assuming every firmware exposes them in the same way.
Setting | What to establish |
|---|---|
Server address(es) and port | A reachable server endpoint, plus a standby endpoint if the deployment requires one. |
Transport (UDP or TCP) | A transport matching the server listener and permitted by the site network. Where appropriate, TCP on port 443 is an alternative to test. |
CA certificate, client certificate and key | A separate identity for each router, with its private key protected and a way to revoke its certificate. |
Server certificate verification | Verification that the client is connecting to the intended server, including the expected server certificate role. |
Routes | Paths to the required processing networks and return paths to each site's ATM subnet. |
Keepalive and persist options | Failure detection, restart behaviour and interface handling across reconnection. |
MTU / MSS | Packet sizes that work over both the wired and cellular paths. |
ToS passthrough | Whether inner traffic markings need to be carried onto the outer tunnel packets. |
On the server, keep the per-client tunnel address, site subnet, route entries and firewall policy consistent. Giving every router its own certificate lets an administrator remove one site's access without replacing credentials across the fleet.
Test one site before copying the configuration
The most useful pilot is a small version of the deployment: a reference router, the intended SIMs, access to the server and representative application traffic.
Prepare the data center. Set up the CA, server certificate, per-client configuration and firewall rules. Include a second endpoint if one is part of the design.
Configure the reference site. Set its VLANs, routes, QoS and OpenVPN profile, then establish the intended failover order: wired WAN, SIM 1 and SIM 2.
Exercise each failure. Run an authorised test transaction, disconnect the wired link, switch between SIMs and repeat the application test after each change. Observe the WAN, tunnel and application separately, including under background load.
Replicate with unique site values. Keep the common settings, but assign each router its own certificate, key, ATM subnet and tunnel address.
Label and commission the equipment. Confirm power, Ethernet, the wired WAN where used, and the antennas. Verify the installed site's connection instead of relying only on the bench result.
This produces a practical answer to the question that started the article: after a link fails, which part recovers first, which part takes longer, and when can the ATM complete a transaction again?
Choose cellular connectivity for the location
The cellular technology is a choice within this design. Coverage and the usable connection at the installation matter more than selecting a generation in isolation.
For this application, Wavetel's WR565 provides LTE-A Cat 6 connectivity, while the WR575 adds 5G. Both support OpenVPN, Gigabit Ethernet, dual SIMs and wired-to-cellular WAN failover. Confirm the required interfaces and configuration options against the model and firmware used for the project.
Choose between them using the site's carrier coverage and deployment requirements, then test the complete path. The same approach applies when comparing industrial cellular routers: the relevant outcome is recovered application communication over the intended backup connection.
For a deployment review, contact Wavetel with the proposed carrier connections, site network and data-center endpoint.
FAQ
The VPN is connected again. Why might the ATM still fail a transaction?
A connected tunnel confirms only part of the path. Check the route to the processing host, the return route, firewall permissions and the application's connection state. Use an authorised application test to confirm recovery rather than treating the VPN status alone as the result.
Does switching carriers require a different client certificate?
Changing the WAN path does not normally require a new client certificate. The certificate identifies the router independently of its current external address. The new path still has to reach a server that trusts that certificate.
Can a site run entirely on cellular?
Yes, this design can use cellular as the primary WAN where no wired connection is available. Test the intended carriers at the installation and verify how the tunnel and application recover when the active SIM changes.
Does a second SIM provide a second VPN server?
No. It provides another cellular access path. A standby VPN endpoint is a separate part of the data-center design and must be configured on the client, for example through additional remote entries.
References
OpenVPN 2.6 Manual — remote, keepalive, ping-restart, persist-tun, client-config-dir, iroute, remote-cert-tls and passtos.
