DMZ Wireless access in a small network using a WRT54G v7.0

Jurjen Bokma

May 2010


As shown in Conference under Docker, the third Wrt54g is a version 7.0 with an Atheros chipset, which cannot be used with openWRT. Other Open Source OS'es may be available, but I won't bother. We 're going to work with it as it came from the shop, with the built-in OS and GUI.

I need wireless access for laptops and guests. But I'll put them in their own network, separated from the rest of my intranet by the firewall on the router.

There are several HOWTOs describing how to turn a WRT54G into a WAP by connecting it on the LAN side only, like some TomsHardware docs, some HomeCommunity forum and some Aperture.com blog. But we are going to do things differently. We will connect the WAN port to the router, and let the Linksys do NAT...

Figure 1.  The initial situation with the LinkSys3
A router connected to the internet on the WAN side, and on the LAN side on one port to a PC through a switch, and on another port to the LinkSys on its WAN side. A laptop is connected to the Linksys it its LAN side.

The initial situation is as shown in Conference under Docker: the LinkSys is not the gateway. Rather, it is attached on its WAN port to the gateway (through a switch), and to a laptop on its LAN side (directly). The router serves DHCP to the Linksys, and the Linksys serves DHCP to the laptop and other machines behind it. (This is necessary, as the Linksys won't relay the DHCP DISCOVER broadcast from LAN to WAN.)

  1. I got the little box second hand, and I don't know the previous owner's password, wo we'll have to reset it. As documented at a technicallyeasy page, the reset button (at the back of the device, next to the WAN port, should be pressed for 30 seconds.

    [Note]Note

    There are also docs that speak of 30 seconds reset while powered on, then 30 while powered off, then another powered on again. That drops us in a firmware upgrade dialog, and another brief press of the reset button will get us out of that, after which I don't see much difference with the just-once-30-seconds approach.

  2. We now disconnect the cable to the router from the Linksys, so it is only connected to the laptop. Then we do a DHCP RENEW on the laptop. y (For Linux, that's sudo dhclient eth0.) It will receive an IP number, and the LinkSys' GUI will be available on 192.168.1.1, with username blank and passwd 'admin'. We now have the situation as in Conference under Docker.

    Figure 2.  The situation after factory reset of the Linksys
    Still the same situation, but now the Linksys has IP number 192.168.1.1 on its LAN side, and the laptop has/gets 192.168.1.100. And the WAN side of the Linksys is disconnected.


    [Note]Note

    Disconnecting the router just makes sure the router's DHCP daemon doesn't interfere iwth the Linksys (yet). It reduces confusion.

  3. The wireless interface of the Linksys is turned on by default, with no security whatsoever. This is necessary to make the thing work out of the box. And we only expose the laptop by leaving it on. But I turned it off anyway.

  4. Under Administration->Management, we now set a new password, then click Save Settings.

  5. We now want access to the Linksys' GUI from the PC.

    Now we can access the GUI at http://10.0.137.251 from a browser on the PC. We do so from now on.

  6. The Linksys cannot do DHCP for its own IP number on the LAN side, so we must configure that manually.

  7. Figure 3.  The Linksys with wireless
    The Linksys connected on the WAN side again, but not on the LAN side, where wireless now works. The laptop connected through wireless to the Linksys.


    We have now gotten to the situation of Conference under Docker. Wireless access to the laptop is accomplished. The situation can now be 'finetuned' further (e.g. tighten wireless access with MAC filters, add firewall rules on the router to disable access from the wireless network to the rest of the intranet, etc. etc.)