Table of Contents

Routed Client

In the default configuration, OpenWrt bridges the wireless network to the LAN of the device. Most wireless drivers do not support bridging in client mode (see Bridged Client Mode Issues), therefore the traffic between LAN and the wireless client must be routed.


If you have no administrative access (e.g. ability to configure static route entries) to the target Access Point, the local LAN subnet must be masqueraded to ensure proper routing.
When configuration of the target Access Point is possible, start with the masqueraded configuration below and proceed with the steps in the Using routing section to define a fully routed setup.


The steps outlined below cover the process of putting the radio into client mode and reusing the existing WAN interface and its NAT firewall rules to connect to the target network.


The changes below assume an OpenWrt default configuration, the relevant files are:

Before doing any actual configuration, the wifi interface must be enabled and put into station mode in order to be able to scan for networks in the vicinity:

uci del wireless.@wifi-device[0].disabled
uci del wireless.@wifi-iface[0].network
uci set wireless.@wifi-iface[0].mode=sta
uci commit wireless

Now we can issue the iwlist scan command to list networks in range, the required information is highlighted:

root@OpenWrt:~# iwlist scan wlan0 Scan completed : Cell 01 - Address: 00:1D:19:0E:03:8F ESSID:"Vodafone-0E0301" Mode:Managed Channel:9 Quality:3/5 Signal level:-69 dBm Noise level:-92 dBm IE: IEEE 802.11i/WPA2 Version 1 Group Cipher : TKIP Pairwise Ciphers (2) : TKIP CCMP Authentication Suites (1) : PSK Preauthentication Supported IE: WPA Version 1 Group Cipher : TKIP Pairwise Ciphers (2) : TKIP CCMP Authentication Suites (1) : PSK Encryption key:on Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s 11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s
If you see a message like Device or resource busy, a wpa_supplicant instance is most likely locking the interface. In this case kill the running process and repeat the scan:
killall -9 wpa_supplicant
iwlist scan

Step 1: Change the WAN interface

Edit /etc/config/network and change the WAN interface by editing the existing ifname option:

config 'interface' 'wan' option 'proto' 'dhcp'

Note that the wan network section must not contain any ifname option.

Step 2: Change the existing wireless network

Supposed we want to connect to the network called "Vodafone-0E0301", the previous scan result revealed the following information:

In /etc/config/wireless, locate the existing wifi-iface section and change its network option to point to the WAN interface. Change the mode option to sta (Station) and alter the SSID and encryption options to match those of the target network. Channel doesn't necessary have to match.

config 'wifi-device' 'wlan0' option 'type' 'broadcom' option 'channel' '9' config 'wifi-iface' option 'device' 'wlan0' option 'network' 'wan' option 'mode' 'sta' option 'ssid' 'Vodafone-0E0301' option 'encryption' 'psk2' option 'key' 'secret-key'

Apply changes

Reconfigure the wireless network.

ifup wan

If the target network uses the subnet, you must change the default LAN IP address to a different subnet, e.g. .
You can determine the assigned WAN address with the following command:
. /lib/functions/; network_get_ipaddr IP_WAN wan; echo $IP_WAN

At this point, the masqueraded client configuration should be finished. Optionally you can bridge former wan ethernet port to switch, so you will be able to use all ethernet ports as lan clients. Note, that following config works for atheros routers, where wan port is usually eth1, but you should find the correct port name using ifconfig command.

vi /etc/config/network

config interface 'lan' option ifname 'eth0 eth1' option type 'bridge' option proto 'static' . .

Using routing

In contrast to masquerading, a fully routed setup allows access from hosts of the Access Point network to hosts in the client network by using the client routers WAN IP address as gateway for the client network behind it.

This kind of network topology is not possible when the client does NAT, since the addresses behind the NAT are not reachable from the outside, unless additional measures like port forwardings are configured.

Routed network topology

This section covers the process of changing the firewall config to allow incoming WAN traffic and disabling masquerading in the corresponding zone.

The fully routed client configuration is based on the masqueraded config and assumes an already working client setup.
Only proceed with the routed configuration below if you have the ability to reconfigure the remote Access Point!


In addition to the files in the masqueraded setup, the relevant config files are:

Step 1: Change the firewall configuration

Edit the /etc/config/firewall file and locate the WAN zone definition. Disable masquerading and set the incoming traffic policy to ACCEPT:

config 'zone' option 'name' 'wan' option 'input' 'ACCEPT' option 'output' 'ACCEPT' option 'forward' 'REJECT' option 'mtu_fix' '1' option 'masq' '0'

Proceed with adding a new forwarding section allowing traffic flow from WAN to LAN:

config 'forwarding' option 'src' 'wan' option 'dest' 'lan'

Step 2: Configure the Access Point

In order to make the local LAN subnet reachable for clients in the Access Point subnet, you need to configure a static route pointing to our LAN network on the AP. How to configure leases and routes on the Access Point differs from model to model. In doubt, consult the operation manual.

Since static routes need a static gateway to work properly, the WAN IP address of the client mode wireless must be fixed, there are two possible ways to achieve that:

When using the fixed IP approach, the WAN interface in /etc/config/network must be changed from the DHCP protocol to static:

config 'interface' 'wan' option 'proto' 'static' option 'ipaddr' '' option 'netmask' ''

Make sure that the address range does not overlap with the LAN network.
You must change the LAN address if it is in the same subnet, e.g. to

After fixing the WAN address, a static route must be added to the Access Point with the following information:

You may also need to set the policy of the firewall of the Access Point to 'ACCEPT' forwarded traffic for the LAN zone, in order for hosts in the Client network to communicate with hosts (other than directly to the router itself) on the Access Point network. E.g. (referring to the diagram) for Client Host 1 to communicate with LAN Host 1.

Apply changes

Reconfigure the wireless network.

ifup wan

Restart the firewall.

/etc/init.d/firewall restart

After setup everything works BUT client subnet cannot access internet

This is due to the reason that AP router (in this case does not masquerade client subnet (

If you cannot (or don't want to) modify AP router's firewall in deep, you can configure client router ( in the following way:
Edit the /etc/config/firewall file and locate the WAN zone definition.

config 'zone' option 'name' 'wan' option 'input' 'ACCEPT' option 'output' 'ACCEPT' option 'forward' 'REJECT' option 'mtu_fix' '1' option masq_dest ! option 'masq' '1'

Please note that in this way client router ( will masquerade everything EXCEPT AP subnet and AP router ( will handle packets from client subnet to internet and vica-versa.
This is double masquerading which works fine especially if you cannot make it work otherwise. Avoid double NATting whenever possible!!

Using routing : an alternative solution

(assumption: you know how to apply the changes)

Scenario description

There is a router access point (based on openwrt 12.09 final ) and a router wifi client (based on openwrt 12.09 final). The router access point from now on is called WP (wifi provider) and the router wifi client is called WC (wifi client) The diagram of the network is the following:

Internet <---wired---> WP <---wireless---> WC

The WP is creating a lan network, through wireless and lan ports, using the subnet The WP lan interface is configured as follows (file etc/config/network ):

config interface 'lan'
        option type 'bridge'
        option ifname 'eth0.0'
        option proto 'static'
        option netmask ''
        option ipaddr ''

The WC instead, is using the wireless to connect to the WP and to create a second wifi network. In this case the wireless interface is attached to the network wan as sta mode and is attached to the network lan as ap mode, as follows (file /etc/config/wireless ):

config wifi-iface
        option device   radio0
        option network  lan
        option mode     ap
        option ssid     'Second wifi'
        option encryption       psk2
        option key      'password.2'

config wifi-iface
        option device   radio0
        option network  wan
        option mode     'sta'
        option ssid     'Master wifi'
        option encryption       psk2
        option key      'password.1'

The second network created by the WC is using the subnet and is getting a dhcp IP on the wan interface, as follows:

config interface 'lan'
        option ifname 'eth0'
        option type 'bridge'
        option proto 'static'
        option ipaddr ''
        option netmask ''
config interface 'wan'
        option proto     'dhcp'
        option hostname  'WC'

Now we want that both networks see each other.

Connecting WC lan side to the WP lan side and to the internet

For the lan side of WC there is not so much problem to reach the provided by the WP. Because the latter is seen as wan network, and to reach that network from the lan side of WC only the 'classic' forwarding lan→wan is needed. This means, in the file /etc/config/firewall, that the following rule is needed:

config forwarding
        option src              lan
        option dest             wan

In this way requests from the WC lan side are allowed to reach the WC wan side that contains the WP lan network.

But we should not forget about masquerading (explained briefly at least here network ). By default the wan zone has masquerading, but this means that when a computer from the WC lan side wants to connect to a computer on the WP lan side, its ip will be masqueraded. Therefore we should avoid masquerading when a computer on the WC lan side wants to reach an IP address in the network this is done in this way (file /etc/config/firewall ):

config zone
        option name                 wan
        list   network              'wan'
        option input                REJECT
        option output               ACCEPT
        option forward              REJECT
        option masq                 1
        #routed bridged wireless network - start
        option masq_dest            '!'
        list comment '(do not with !)'
        list comment ' masquerade what is going to the declared subnet(s)'
        list comment 'remember that is "masq_destination"'
        #routed bridged wireless network - end
        option mtu_fix              1

In this way the WC lan side is able to reach the WP lan side without "obscuration" and the internet side (this with obscuration by masquerading).

Connecting WP lan side to the WC lan side

First we should enable the possibility that packets coming on the wan side of WC could reach the lan side of WC. This is done through forwarding (see firewall and iptables_and_firewall ).

In particular we want that if a packet coming on the wan side of WC has the source in the network then it is allowed to go through the device (that is: coming from an interface and going to another interface decided by routing rules). So on WC in /etc/config/firewall we add:

config rule 'forward_from_master_net'
        option src      wan
        option dest     lan
        option src_ip   ''
        option proto    all
        option target   ACCEPT
#this means: if a packet, of whatever protocol, is coming on the wan side from a source in
#            and the routing rules are sending it towards the lan side, let it pass.

Now it is the turn of configuration on WP. First WP should know that the WC is 'a device to ask' about the network and this means a static routing rule. But a static routing rule requires a gateway that is consistently reachable. Since WC is using dhcp on lan, we have to assign a static dhcp on the WP side for WC. So on WP we modifiy /etc/config/dhcp adding a reservation for WC.

config host wc
        option ip
        option mac      '<mac address>'

Now (after we applied the changes on both systems) we have the possibility of defining a static route on WP in /etc/config/network:

config 'route' 'to_repeater'
        option 'interface' 'lan'
        option 'target' ''
        option 'netmask' ''
        option 'gateway' ''
        list comment 'to the wifi repeater'
        list comment 'as routed wireless client'
        list comment 'as exposed in the owrt wiki'

It seems all but it is not. It is a subtle problem of how the networking standards behave (but once you know them, it is ok). On the WP the command route -n shows this:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
...lines...   U     0      0        0 br-lan   UG    0      0        0 br-lan

So it seems that if a packet is coming from br-lan and wants to go to, since it will go through the same interface, no problem should occur. And instead not, different routes, even on the same interface, create a bit of obstacles. It is like that only packets coming from an interface and going through the same interface, when the source of the packet and the destination of the packet are matched by the same routing rule, do not create any problem.

In the case that the interface is the same (for input and output) but the source of the packet differs from the destination shown in the routing rule, then the packet is stopped. What do we need then? Seems counter-intuitive but: forwarding.

On WP in /etc/config/firewall we need a rule that says "a packet coming on the lan side can go through the lan side without being stopped":

config forwarding
        option src 'lan'
        option dest 'lan'

And with this we have ended our problems. Computer in can communicate with computers in and viceversa using original ip addresses.