OpenWrt Project

This page describes all available tunnelling protocol usable in /etc/config/network and their options. Some example configurations are provided at the end of the page.

Note that, for most protocols, installing a opkg package is required for protocol support.

The package pptp must be installed to use PPtP. You need to have another section to configure the “parent” device, and you might need to add “<vpn>” to your “wan” zone in the firewall (<vpn> being the “logical interface name” of this section).

The package aiccu must be installed to use this protocol. This utility is not meant to be operated in a headless mode. Do not use it if you have some other option. Only AYIYA tunnel type has been tested. For static or heartbeat tunnels, use native 6in4 tunnel instead, perhaps with the he.net Tunnel Broker.

This protocol is available for Barrier Breaker and newer versions only.

Note: This protocol type does not need an ifname option set in the interface section. The interface name is derived from the section name, e.g. config interface sixbone would result in an interface named aiccu-sixbone.

The package relayd must be installed to use this protocol.

The package gre must be installed to use GRE. Additionally, you need kmod-gre and/or kmod-gre6.

GRE support has been introduced in Barrier Breaker. Four protocols are defined (“gre”, “gretap”, grev6“, and “grev6tap”), which will generate GRE interfaces named:

All four protocols accept the following common options:

The following options are supported, in addition to all common options above:

The following options are supported, in addition to all common options above:

ipaddr may be required in some setups. Repeated log entries about “setting up now” and “now down” may be related to this.

Additionally, the resolveip package may also be needed. ./gre.sh: eval: line 1: resolveip: not found in the logs are an indication of the need.

The following options are supported, in addition to all common options above:

The following options are supported, in addition to all common options above:

VTI Tunnels are IPsec policies with a fwmark set. The traffic is redirected to the matching VTI interface.

The following options are supported, in addition to all common options above:

XFRM Tunnel interfaces are bound to if_id set in the sa policy.

The packages wireguard-tools and kmod-wireguard must be installed to use wireguard.

Each wireguard interface is configured in two parts:

• the configuration relative to the interface itself (private key, MTU, UDP port to bind to, etc)
• configuration relative to each peer (public key, IP address, etc)

Interface configuration (using proto wireguard):

The name of the network interface will be the name of the configuration section.

Peer configuration, for each peer:

The name of a peer section must be wireguard_XX where XX is the name of the wireguard interface section.

Below are a few examples for special, non-standard interface configurations.

Avoid OpenVPN tunnel interface declaration to prevent L3-configuration loss because of network service restart.

If you still want to manage VPN-interface such as “tun0” via UCI-configuration and LuCI:

config interface 'tun0'
        option ifname 'tun0'
        option proto 'none'

Follow IPv4/IPv6 Transition Technologies.

This example establishes a Pseudowire Tunnel and bridges it to the LAN ports. The existing lan interface is reused with protocol l2tp instead of static.

config interface 'lan'
        option proto     'l2tp'
        option type      'bridge'
        option ifname    'eth0'
        option ipaddr    '192.168.1.1'
        option netmask   '255.255.255.0'
        option localaddr '178.24.154.19'
        option peeraddr  '89.44.33.61'
        option encap     'udp'
        option sport     '4000'
        option dport     '5410'

This example sets up a relayd pseudo bridge between a wireless client network and LAN, so that it works similarly to the Broadcom Bridged Client mode.

Wireless configuration (excerpt):

config wifi-iface
        option device     'radio0'
        option mode       'sta'
        option ssid       'Some Wireless Network'
        option encryption 'psk2'
        option key        '12345678'
        option network    'wwan'

Network configuration (excerpt):
Note that the LAN subnet must be different from the one used by wireless network's DHCP.

config interface 'lan'
        option ifname     'eth0.1'
        option proto      'static'
        option ipaddr     '192.168.1.1'
        option netmask    '255.255.255.0'
 
config interface 'wwan'
        option proto      'dhcp'
 
config interface 'stabridge'
        option proto      'relay'
        option network    'lan wwan'

In contrast to true bridging, traffic forwarded in this manner is affected by firewall rules, therefore both the wireless client network and the lan network should be covered by the same LAN firewall zone with forward policy set to accept to allow traffic flow between both interfaces:

config zone
        option name        'lan'
        option network     'lan wwan'  # Important
        option input       'ACCEPT'
        option forward     'ACCEPT'    # Important
        option output      'ACCEPT'

Create a GRE tunnel with static address 10.42.0.253/30, adding it to an existing firewall zone called tunnels:

See warning on top of page about interface-name length. Previous interface names here were too long and silently fail.

config interface 'tunA'
        option proto    'gre'
        option zone     'tunnels'
        option peeraddr '198.51.100.42'
 
config interface 'tunAA'
        option proto    'static'
        option ifname   '@tunA'
        option ipaddr   '10.42.0.253'
        option netmask  '255.255.255.252'
        # Fixes IPv6 multicast (long-standing bug in kernel).
        # Useful if you run Babel or OSPFv3.
        option ip6addr  'fe80::42/64'

This adds support for configuring VTI interfaces within /etc/config/network. VTI interfaces are used to create IPsec tunnel interfaces. These interfaces may be used for routing and other purposes.

config interface 'vti1'
	option proto 'vti'
	option mtu '1500'
	option tunlink 'wan'
	option peeraddr '192.168.5.16'
	option zone 'VPN'
	option ikey 2
	option okey 2
 
config interface 'vti1_static'
	option proto 'static'
	option ifname '@vti1'
	option ipaddr '192.168.7.2/24'

The options ikey and okey correspond to the fwmark value of a ipsec policy. The may be null if you do not want fwmarks. Also peeraddr may be 0.0.0 if you want all ESP packets go through the interface.

Example strongswan config:

conn vti
	left=%any
	leftcert=peer2.test.der
	leftid=@peer2.test
	right=192.168.5.16
	rightid=@peer3.test
	leftsubnet=0.0.0.0/0
	rightsubnet=0.0.0.0/0
	mark=2
	auto=route

Create a WireGuard tunnel interface named foo that connects to one peer (VPN server at vpn.example.com) and allows another peer (e.g. road warrior) to connect. Peer configurations are managed via one or more wireguard_<ifname> sections.

config interface 'foo'
	option proto 'wireguard'
	option private_key 'qLvQnx5CpXPDo6oplzdIvXLNqkbgpXip3Yv4ouHWZ0Q='
	list addresses 'fd00:13:37:ffff::1/64'
 
config wireguard_foo
	option public_key '9mD+mTiOp7SGIkB4t3ZfWAcfp5iA/WwQRdVypKKwrjY='
	option route_allowed_ips '1'
	list allowed_ips 'fd00:13:37::/64'
	option endpoint_host 'vpn.example.com'
	option persistent_keepalive '25'
 
config wireguard_foo
	option public_key '4mLeSytW6/y4UcOT6rNorw1Ae9nXSxhXUjxsdzMWkUA='
	option preshared_key 'M1IbkkDVwXsQbFbURiMXiVe/iUCjC5TKHCmemVs+oLQ='
	list allowed_ips 'fd00:13:37:ffff::2'