IPSec VPN Example (H685 4G to H685 4G)

The H685t-W runs StrongSwan 5.6.3 via an OpenWrt IPsec package. This guide covers configuring a site-to-site IKEv2 tunnel between two H685t-W routers, or between an H685t-W and a third-party peer. Authentication is by pre-shared key (PSK). X.509 certificate authentication is noted separately at the end.

Platform note: The strongest viable cipher suite on this hardware is AES-256-GCM-16 + HMAC-SHA2-512-256 + MODP-4096.

Prerequisites

• Both routers have SIM cards inserted and mobile data connected — see Configure APN Settings
• At least one end of the tunnel must have a static public IP address, or a hostname that resolves to the router's current public IP (e.g. via DDNS)
• The LAN subnets at each site must not overlap — for example, Site A: 192.168.8.0/24, Site B: 192.168.31.0/24
• The same pre-shared key string must be configured on both routers

Cipher suite selection

Select ciphers from the table below. Apply the same profile to both Phase 1 and Phase 2. There is a trade-off between strength of the ciphers, and load on the device CPU which affects max data throughput.

Use Strongest for maximum security. Use Recommended if the remote peer cannot negotiate HMAC-SHA2-512 or MODP-4096. Use Fallback (AES-CBC) only if the peer has no AES-GCM support. ECP DH groups (Group 19 / Group 20) are not available on this platform — do not select them.

Configuration

Step 1 — Create a new IPsec instance

In the router WebUI, navigate to VPN > IPsec. Click Add to create a new tunnel instance. Enter a descriptive name — for example site-b. This name identifies the connection in the status output and logs.

Step 2 — General Settings

The General Settings panel controls the IKE parameters, authentication method, and tunnel behaviour.

Step 3 — Subnets

Configure which local and remote networks the tunnel will carry traffic for.

Step 4 — Phase 1 Proposal

Phase 1 (IKE SA) authenticates the peers and establishes the secure channel used for tunnel negotiation. The ciphers here protect the IKE negotiation traffic itself.

Step 5 — Phase 2 Proposal

Phase 2 (Child SA / ESP) negotiates the keys used to encrypt actual traffic through the tunnel. AES-GCM is an AEAD cipher — it handles both encryption and integrity in a single pass, with no separate HMAC step. This reduces CPU load, which matters on the software-only MT7620.

Step 6 — Save and apply

Click Save and Apply. The IPsec daemon will restart and attempt to establish the tunnel. Allow 15–30 seconds for Phase 1 and Phase 2 to complete.

Repeat the configuration on the second router, swapping Local subnet and Remote subnet, and entering the first router's public IP as the Remote VPN endpoint. The pre-shared key must match exactly on both sides.

Verifying the tunnel

Navigate to Status > VPN and click the IPSec tab. A successfully established tunnel shows in the bottom section, Security Associations (1Up). As well as both the IKE SA and Child SA as ESTABLISHED:

 Security Associations (1 up, 0 connecting):
ipsec_base[12]: ESTABLISHED, 192.168.10.1[192.168.10.1]...192.168.10.2[192.168.10.2]
ipsec_base[12]: IKE proposal: AES_GCM_16_256/PRF_HMAC_SHA2_512_256/MODP_4096
ipsec_base{48}:  INSTALLED, TUNNEL
ipsec_base{48}:  AES_GCM_16_256/MODP_4096
ipsec_base{48}:  192.168.8.0/24 === 192.168.31.0/24

The IPSec Log tab on the same page shows the full Charon daemon log, including the complete negotiation sequence. This is the first place to check when troubleshooting a tunnel that will not establish.

To confirm traffic is flowing, ping an IP on the remote LAN from a device connected to this router:

ping 192.168.31.1

SSH diagnostics

For more detailed state information, connect via SSH — see SSH Default Credentials.

# Tunnel state — negotiated ciphers, SA state, bytes in/out
ipsec statusall

# Kernel-level security associations
ip xfrm state

# Traffic selectors (confirm subnets)
ip xfrm policy

# Real-time log
logread -f | grep -i charon

Applying cipher settings via UCI (SSH)

The WebUI writes configuration to /etc/config/ipsec, which is converted to /etc/ipsec.conf and /etc/ipsec.secrets at daemon start. To apply the recommended cipher suite directly:

uci set ipsec.phase1.encryption_algorithm='aes256gcm16'
uci set ipsec.phase1.hash_algorithm='hmac_sha2_512_256'
uci set ipsec.phase1.dh_group='modp4096'
uci set ipsec.phase2.encryption_algorithm='aes256gcm16'
uci set ipsec.phase2.authentication='hmac_sha2_512_256'
uci set ipsec.phase2.pfs_group='modp4096'
uci commit ipsec
/etc/init.d/ipsec restart

Troubleshooting

X.509 certificate authentication

PSK is suitable for small deployments where all routers are under the same management. For larger deployments, X.509 (PKI) authentication is preferable:

• Each device has its own private key — it never leaves the device
• A Certificate Authority (CA) signs each device certificate; the CA certificate is the trust anchor deployed to all routers
• Individual devices can be revoked without affecting other tunnels
• Certificates expire — renewal must be planned for unattended remote sites

To set up PKI: generate a CA and per-device certificates using strongswan pki or openssl on a Linux machine. Deploy each router's private key, its signed certificate, and the CA certificate to the router via SSH. Set Authentication method to Certificate in the General Settings panel.

Platform limitations