Configure OpenVPN AES-256-CBC on an eWON Cosy131 VPN

The eWON initiates the VPN request, the local OpenVPN engine reads its generated configuration plus any appended custom file, and the network carries the session to the remote OpenVPN endpoint. Follow that path in order. A custom cipher line cannot repair a failed physical link, wrong server address, blocked transport port, or rejected remote configuration.

Where does the OpenVPN request travel?

The commissioning path is: eWON network interface → local routing and name resolution → intervening network devices → remote OpenVPN listener → control-channel authentication → data-channel cipher setup. Locate the first hop that fails before changing cryptographic settings.

Item	Required value	Where to verify it
Local custom-file address	/usr/myconfig.ovpn in the documented example	eWON filesystem and VpnCfgFile
Remote server address	Use the address already defined for this installation	Active VPN profile and connection log
Transport port and protocol	Match the remote OpenVPN listener; no value is specified here	Server configuration, firewall rules, and connection log
Connection timing	Use the active profile values; no retry or timeout value is specified	Client configuration and timestamped logs
Data cipher	AES-256-CBC	Client custom file and server configuration

Check: identify the configured server address, transport protocol, and port, then verify that traffic leaves the eWON interface and reaches the remote listener.

Is the physical and IP path working first?

Layer one comes first. Confirm link state, interface addressing, default route, and name resolution where a hostname is used. Inspect interface counters while starting the tunnel. No transmitted traffic points toward a local interface, routing, or configuration problem. Transmitted traffic with no return traffic moves the investigation toward routing, address translation, firewall policy, or the remote listener.

A reachability test alone does not prove that OpenVPN is reachable. Some networks pass diagnostic traffic while blocking the VPN transport, and some servers suppress diagnostic replies while accepting VPN connections. Compare client timestamps with firewall or server-side observations for the configured address, port, and transport protocol.

Check: start one connection attempt and prove bidirectional packets at the configured VPN transport endpoint before editing VpnCfgFile.

Should VpnCfgFile append or replace the configuration?

The ComCfg parameter VpnCfgFile selects a custom OpenVPN configuration file. Its leading plus sign controls how the eWON consumes that file. This distinction explains the common failure where adding only a cipher line makes a previously usable configuration stop connecting.

VpnCfgFile value	Behavior	Appropriate content	Typical consequence
+/usr/myconfig.ovpn	Append custom options to the existing configuration	Only the additional directives, such as cipher AES-256-CBC	Preserves the generated connection settings
/usr/myconfig.ovpn	Use the custom file as the VPN configuration	A complete OpenVPN configuration	A one-line file omits the remaining connection settings

The plus sign belongs at the front of the parameter value, not in the filename. The filename extension is not mandatory: .ovpn and .txt can both be used. The file path, readability, and directive contents determine whether it works.

Check: read back the parameter. For a one-line additive file, it must show VpnCfgFile:+/usr/myconfig.ovpn, and that exact file must exist at the referenced path.

How do you add AES-256-CBC without losing settings?

1. Create a plain-text custom configuration file containing cipher AES-256-CBC.
2. Place the file in the eWON filesystem at the selected path. The documented example uses /usr/myconfig.ovpn.
3. Set the ComCfg parameter to VpnCfgFile:+/usr/myconfig.ovpn. Keep the leading + when the file contains only the added cipher directive.
4. Configure the remote OpenVPN endpoint to accept the same data-channel cipher. A client-only change can reach the server yet fail during cipher setup.
5. Reconnect the VPN so the OpenVPN process reads the updated configuration.

The eWON accepts custom directives only where they are supported by its OpenVPN 2.0.9 implementation. The remote installation referenced OpenVPN 2.4.3, so treat the two endpoints as different parser and capability sets. Use syntax supported by both sides; cipher AES-256-CBC is the working directive for this configuration.

This change replaces the use of BF-CBC for the configured data cipher, addressing the stated Sweet32 concern. It does not alter server addressing, certificates, credentials, routing, or firewall policy.

Check: reconnect and inspect the client and server logs for configuration parsing followed by successful control-channel and data-channel establishment.

Why can the tunnel still fail after the cipher change?

Observed boundary	Likely cause	Corrective check
No outbound connection traffic	Interface, route, name resolution, or inactive VPN configuration	Check link, address, route, counters, and active profile
Outbound traffic with no reply	Wrong destination, blocked transport, address translation, or inactive listener	Compare the configured endpoint with firewall and server observations
Custom file cannot be processed	Wrong path, missing file, unreadable content, or unsupported directive	Verify the exact path and OpenVPN 2.0.9 option support
Failure began after selecting the custom file	VpnCfgFile replaced the generated configuration	Add + before the path or supply a complete configuration
Control connection reaches the server but the tunnel does not pass data	Cipher mismatch, authentication failure, or routing policy	Compare both endpoint logs and the installed routes

Do not diagnose by changing several directives at once. Restore the previously working network path, append the single cipher line, reconnect, and observe the first changed failure boundary.

Check: prove that the parser reads the custom file and that both endpoints proceed beyond cipher setup before investigating tunnel routes.

How do you verify the tunnel end to end?

1. Read back VpnCfgFile:+/usr/myconfig.ovpn and verify that the referenced file contains cipher AES-256-CBC.
2. Start a fresh VPN session and correlate client and server log timestamps.
3. Confirm that the session reaches the configured server address, port, and transport protocol.
4. Confirm successful authentication and data-channel creation without an unsupported-option or cipher-mismatch failure.
5. Inspect the installed tunnel routes, then send application traffic to a permitted remote destination.
6. Verify bidirectional application data and incrementing tunnel counters. A connected status without return traffic proves only session establishment, not end-to-end operation.

Check: the commissioning test passes only when the eWON sends application traffic through the tunnel and receives the expected response through the same routed path.

FAQ