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.disabled uci del wireless.@wifi-iface.network uci set wireless.@wifi-iface.mode=sta uci commit wireless wifi
Now we can issue the
iwlist scan command to list networks in range, the required information is highlighted:
| If you see a message like
killall -9 wpa_supplicant iwlist scan
/etc/config/network and change the WAN interface by editing the existing
Note that the
wan network section must not contain any
Supposed we want to connect to the network called "Vodafone-0E0301", the previous scan result revealed the following information:
/etc/config/wireless, locate the existing
wifi-iface section and change its network option to point to the WAN interface.
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.
Reconfigure the wireless network.
ifup wan wifi
| If the target network uses the 192.168.1.0/24 subnet, you must change the default LAN IP address to a different subnet, e.g. 192.168.2.1 .
You can determine the assigned WAN address with the following command:
. /lib/functions/network.sh; network_get_ipaddr IP_WAN wan; echo $IP_WAN 192.168.1.30
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.
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.
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:
/etc/config/firewall file and locate the WAN zone definition.
Disable masquerading and set the incoming traffic policy to ACCEPT:
Proceed with adding a new forwarding section allowing traffic flow from WAN to LAN:
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
| 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 192.168.2.1
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.
Reconfigure the wireless network.
ifup wan wifi
Restart the firewall.
This is due to the reason that AP router (in this case 192.168.1.1) does not masquerade client subnet (192.168.2.0/24).
If you cannot (or don't want to) modify AP router's firewall in deep, you can configure client router (192.168.2.1) in the following way:
/etc/config/firewall file and locate the WAN zone definition.
Please note that in this way client router (192.168.2.1) will masquerade everything EXCEPT AP subnet and AP router (192.168.1.1) 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!!
(assumption: you know how to apply the changes)
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
config interface 'lan' option type 'bridge' option ifname 'eth0.0' option proto 'static' option netmask '255.255.255.0' option ipaddr '192.168.10.1'
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
sta mode and is attached to the network
ap mode, as follows (file
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
192.168.11.0/24 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 '192.168.11.1' option netmask '255.255.255.0' config interface 'wan' option proto 'dhcp' option hostname 'WC'
Now we want that both networks see each other.
For the lan side of WC there is not so much problem to reach the
192.168.10.0/24 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
192.168.10.0/24 this is done in this way (file
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 '!192.168.10.1/24' 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).
In particular we want that if a packet coming on the wan side of WC has the source in the network
192.168.10.0/24 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 '192.168.10.0/24' option proto all option target ACCEPT #this means: if a packet, of whatever protocol, is coming on the wan side from a source in 192.168.10.0/24 # 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
192.168.11.0/24 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 192.168.10.20 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
config 'route' 'to_repeater' option 'interface' 'lan' option 'target' '192.168.11.0' option 'netmask' '255.255.255.0' option 'gateway' '192.168.10.20' 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... 192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 br-lan 192.168.11.0 192.168.10.20 255.255.255.0 UG 0 0 0 br-lan
So it seems that if a packet is coming from br-lan and wants to go to 192.168.11.0, 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
192.168.10.0/24 can communicate with computers in
192.168.11.0/24 and viceversa using original ip addresses.