Routing and server push

Six mechanisms for six different jobs

Start with direction: do you need to push a route to a client, allow a destination, register a network behind a client, or tunnel all device traffic?

Split tunnel and full tunnel

The default depends on the client: Linux CLI starts in split-tunnel mode, while GUI clients start in full-tunnel mode. Split mode sends the TUN pool and server-pushed routes through Qeli; full-tunnel internet egress requires NAT on the server.

# split tunnel: TUN pool, server push and include only
gateway = false
include = 10.50.0.0/16
exclude = 203.0.113.0/24

# full tunnel: route all remaining traffic through Qeli too
gateway = true
kill_switch = true

# required for full-tunnel internet egress
routing.nat.enabled = true
# WAN is detected automatically; set it explicitly when needed
routing.nat.interface = ens3

Profile and per-user routes

The key is repeatable. CIDR is required and comes first; gateway and metric are optional. The usual next hop is the server's tun.address.

# sent to every user of the profile
route = 192.168.50.0/24 gateway=10.9.0.1 metric=100
route = 10.50.0.0/16

[user:contractor]
# sent to this user only
route = 192.168.50.128/25 gateway=10.9.0.1

Loading IP addresses and subnets with route_file

route_file attaches one or more external files to local split tunnelling. The key is repeatable; entries from every file are merged with include, canonicalised and deduplicated.

# Windows
gateway = false
route_file = C:\qeli\corp-routes.txt
route_file = C:\qeli\openvpn-routes.txt

# macOS: use an absolute path
# route_file = /Users/alice/.config/qeli/routes.txt

# one network per line
10.20.0.0/16
192.0.2.0/24      # branch office

; write one IPv4 address as /32
203.0.113.17/32
route 172.16.9.7 255.255.0.0 vpn_gateway 10
route-ipv6 2001:db8:42::/48

Destination ACL and a network behind a client

allowed_networks limits a user's outbound destinations. client_subnet tells the server that a CIDR is reachable through this client. The keys are not interchangeable.

[user:branch-a]
static_ip = 10.9.0.10
# network behind branch-a: inbound iroute on the server
client_subnet = 192.168.50.0/24
# branch-a itself may access only this destination
allowed_networks = 10.9.0.0/24, 192.168.60.0/24

An empty allowed_networks means no ACL restriction, not deny all. A client_subnet must not overlap pool.cidr or networks at other sites.

Minimal site-to-site without NAT

Each gateway gets a fixed address, registers its LAN via client_subnet, and receives a personal route to the other site's LAN.

[user:branch-a]
static_ip = 10.9.0.10
client_subnet = 192.168.50.0/24
route = 192.168.60.0/24 gateway=10.9.0.1

[user:branch-b]
static_ip = 10.9.0.11
client_subnet = 192.168.60.0/24
route = 192.168.50.0/24 gateway=10.9.0.1

# server, [profile:main]
routing.nat.enabled = false
routing.forward_private = true
routing.client_to_client = true

# each Linux gateway, [qeli]
forward = true

Additional routing mechanisms

These settings do not replace route or route_file: they control NAT, app selection, IPv6 or interface lifecycle on a particular client.

DNS proxy and the address a client receives

dns.enabled starts the server proxy. dns.push_servers separately determines which address is sent to clients.

How clients apply pushed routes

All current clients apply the CIDR. Optional next-hop and metric behaviour is platform-specific, so do not use those fields as the only prioritisation mechanism.

How to find where a route was lost

Check in order: server config, actual push, client routing table, forwarding, and NAT/firewall.

Look for Pushed route applied on the client. If the push appears in the log but the OS has no route, the problem is platform application, a table conflict or permissions.

Complete routing documentation