Why a connected Tomato OpenVPN client can still leave your network offline

Configuring a Tomato-family router as an OpenVPN client requires more than copying certificates: routing, DNS, NAT and server-side forwarding must all match the chosen tunnel design.

Setting a Tomato-family router to use its own OpenVPN server is less about toggling a single switch than matching the server’s profile exactly. In FreshTomato, the client is usually configured under VPN > VPN Tunnelling > OpenVPN Client, but the important point is the role: the router acts as the OpenVPN client, while the remote host or gateway remains the server that authenticates the device, assigns tunnel addressing and pushes any routes or DNS settings. iTechGuides stresses that the server profile should be treated as authoritative, because a locally plausible choice of cipher, key type or transport can still prevent the session from working.

The first decision is architectural. A full-tunnel setup sends LAN traffic, and usually DNS queries as well, through the VPN server, whereas a split-tunnel design keeps ordinary internet traffic on the WAN and sends only selected destinations into the tunnel. That distinction matters because a connected VPN session does not automatically prove that traffic forwarding, name resolution or access to a remote private subnet is working. If the server-side network is the target, the router also needs an explicit route and a working return path; a default route through the VPN does not create visibility to every internal network behind it.

Before touching the Tomato interface, the router should have a dedicated client profile generated for it alone. According to iTechGuides, the necessary material normally includes the remote hostname or address, port, transport protocol, CA certificate, client certificate, private key and, where used, a tls-auth or tls-crypt control-channel key. This is the point at which many setups fail: a matching certificate pair cannot compensate for the wrong server address, an incorrect direction flag on the static key, or a certificate copied from a different profile. FreshTomato’s fields should mirror the server configuration rather than improvising a substitute from the options exposed in the menu.

On the Basic tab, the usual routed design uses TUN rather than TAP, with the protocol set to whatever the server specifies, most often UDP but sometimes TCP. The server address and port should be copied exactly, along with the chosen authentication mode and any username-and-password requirement if the server profile calls for it. Tomato’s option to create NAT on the tunnel should be enabled when the goal is to hide LAN clients behind the router’s VPN address, but that is not the same as making remote resources reachable. If the server expects the Tomato LAN subnet to stay visible for routed access, NAT can interfere with that design. Guides from Surfshark, SlickVPN, VPNUK, IVPN, hide.me and ExpressVPN all follow the same general pattern: set the client role, match the server details precisely, then save and start the profile.

The Keys tab is where exactness matters most. The certificate authority belongs in the CA field, the client certificate and private key must be a matched pair, and any static control-channel block must be pasted in full if the server uses one. iTechGuides notes that Tomato forks differ on whether they expect full inline PEM blocks or only the body of each block, so the server’s instructions should dictate the format rather than a guess. The router clock should also be correct, because an inaccurate time can make valid certificates appear not yet valid or already expired. Where the firmware offers a server-certificate check such as remote-cert-tls server, it should be enabled unless the server profile explicitly says otherwise.

Routing and DNS then need verification, not just configuration. If the design is a full tunnel, Tomato’s redirect of internet traffic should be enabled, and the server must provide either NAT or a usable return route for the client network. If the server pushes DNS addresses, Tomato should accept them only if those resolvers are reachable through the chosen route; otherwise the tunnel can appear healthy while domain lookups fail. IVPN’s Tomato guide also emphasises the value of checking DNS behaviour and applying a kill-switch style approach where appropriate, while iTechGuides recommends testing three separate outcomes: tunnel establishment, public IP change and private-network access. Those checks distinguish a genuine end-to-end setup from a session that merely authenticates.

Troubleshooting is best done by symptom. TLS or certificate errors usually point to the wrong CA, a mismatched client key pair, an incorrect static key direction or a transport mismatch. A tunnel that shows as connected but carries no internet traffic often means the server is not forwarding packets, not translating return traffic or not permitting the client subnet through its firewall. If numeric IP addresses work but names do not, the problem is more likely DNS reachability than certificate validation. Repeated reconnects usually indicate a mismatch in cipher, data-cipher, port or protocol, while partial page loads can suggest fragmentation or MTU issues. If a full-tunnel design makes the router difficult to manage, the safest recovery is a local LAN connection and a manual stop of the client before changing routing rules again.

A successful deployment is straightforward to describe, even if it takes care to achieve. The router starts the VPN client only after WAN is available, authenticates with the server-issued credentials and establishes a stable tunnel address. LAN devices then follow the selected policy: all traffic through the VPN, selected destinations only, or access to a remote private LAN without changing the normal internet path. DNS continues to resolve correctly under that policy, and when the client stops, the network returns cleanly to the ordinary WAN route. That is the difference between a configuration that merely connects and one that is actually usable.