Nexapp - OpenVPN Tunnels

OpenVPN Tunnels

OpenVPN net-to-net tunnels create a secure VPN link between two separate networks (for example, two branch offices). Traffic is encrypted and authenticated using SSL/TLS, ensuring confidentiality and integrity across the public Internet.

An OpenVPN tunnel is always built between two NexappOS firewalls, each with a defined role:

  • Server firewall: accepts incoming tunnel connections.
  • Client firewall: initiates the connection to the server.

A firewall can act as a server for some tunnels and a client for others.
All tunnels run in OpenVPN routed mode.

Important: The OpenVPN Tunnels UI is intentionally simplified for NexappOS-to-NexappOS connections and does not expose all OpenVPN options.
For third-party devices, use IPsec instead.


Configuration

To connect two firewalls:

  1. Configure the server tunnel first.
  2. Download the generated client configuration.
  3. Import it into the client firewall.

Server side

  1. Go to VPN → OpenVPN Tunnels
  2. Open the Server tunnel tab
  3. Click Add server tunnel
  4. Fill the required fields:
  • Public endpoints
    List of public IPs or hostnames a client can use to reach the server.

  • Local networks
    Networks behind the server that should be reachable from the remote side.
    If topology is p2p, this same list is mirrored as Remote networks on the client.

  • Remote networks
    Networks behind the client that should be reachable from the server LAN.

  1. Save the tunnel.
  2. From the tunnel menu, click Download → Client configuration.

Client side

  1. On the remote firewall, go to VPN → OpenVPN Tunnels
  2. Open the Client tunnel tab
  3. Click Import configuration
  4. Upload the file downloaded from the server.

Once imported and enabled, the tunnel comes up automatically.


Topology

OpenVPN tunnels support two topologies:

  • Server acts as a mini-DHCP for connected clients.
  • Authentication uses TLS certificates.
  • Server automatically pushes local routes to the client.

Best choice for most deployments.

P2P (Point-to-Point)

  • Requires one server tunnel per client.
  • Only PSK (Pre-Shared Key) authentication is supported.
  • Admin must:
    • Exchange PSK securely (SSH, HTTPS, etc.).
    • Assign a tunnel IP to both endpoints.
    • Manually define routes on both sides.

Use P2P only for special cases where subnet topology is not suitable.


Advanced Features

The UI exposes essential advanced options:

  • Multiple remote hosts
    Add multiple server endpoints for redundancy.
    The client tries them in order.

  • Protocol

    • UDP (recommended)
    • TCP for environments where UDP is blocked.
  • Compression
    Disabled by default for security and because modern traffic is already compressed.

  • Digest / Cipher
    If not selected manually, client and server negotiate best common values.

  • Minimum TLS version
    Enforces a lower bound TLS version for client connections.


MTU Issue and Packet Fragmentation

Encrypted VPN packets are larger than plain LAN packets.
If the effective MTU is too high, fragmentation can cause packet loss or broken sessions.

Fix by lowering the tunnel MTU on the server:

```bash uci set openvpn.ns.tunmtu='1300' uci commit openvpn.ns /etc/init.d/openvpn restart ns

Discard
Save
This page has been updated since your last edit. Your draft may contain outdated content. Load Latest Version

On this page

Review Changes ← Back to Content
Message Status Space Raised By Last update on