Note: For this configuration, all other items are left at
default.
These are working settings
for a Netgate
PowerG8 WRAP setup. This unit is setup to be a node
under the main access point. These settings are based on
original configuration files kindly provided courtesy of www.socalfreenet.org.
System: General setup
Note: If you set this to HTTPS, be extremely
careful that you remember to put the "s" in https. If this
is set to HTTP on one node and HTTPS on another node, it is extremely
easy get yourself confused and think that the webGUI isn't loading,
when in fact it is a user error.
System Static
Routes
Note: Notice that the static routes
configured on the main unit are gone in node.
Warning: After you click "Save", you must
reboot the firewall to make the changes take effect. You
may also have to do one or more of the following steps
before you can access your firewall again:
change the IP address of your
computer
renew its DHCP lease
access the webGUI with the new
IP address
Note: Unlike the main unit, on the node, the
LAN will be sis0, the WLAN will be an 802.11b AP, and the WAN
will be an 802.11a, that will get it's data from the main unit
and pass it to the WLAN interface.
Warning: after you click "Save", you
must reboot your firewall for changes to take effect.
You may also have to do one or more of the following
steps before you can access your firewall again:
Note: All options not
mentioned here — PPPoE configuration, BigPond Cable
configuration, etc. — are left at default, unless needed for
a specific reason.
Wireless
configuration
Standard
Mode
Note: IBSS mode is sometimes also called
"ad-hoc" mode;
BSS mode is also known as "infrastructure"
mode
SSID
Channel
Note: Not all channels may be supported by your card
Station name
Hint: this field can usually be left blank
WEP
Enable WEP
TX key
Key 1:
Key 2:
Key 3:
Key 4:
40 (64) bit keys may be entered as 5 ASCII characters or
10 hex digits preceded by '0x'.
104 (128) bit keys may be entered as 13 ASCII characters
or 26 hex digits preceded by '0x'.
Block private networks
When set, this option blocks traffic from IP addresses
that are reserved for private networks as per RFC 1918
(10/8, 172.16/12, 192.168/16) as well as loopback
addresses (127/8). You should generally leave this
option turned on, unless your WAN network lies in such a
private address space, too.
Note: If advanced outbound NAT is
enabled, no outbound NAT rules will be
automatically generated anymore. Instead, only
the mappings you specify below will be used.
With advanced outbound NAT disabled, a mapping
is automatically created for each interface's
subnet (except WAN). If you use target
addresses other than the WAN interface's IP
address, then depending on
the way your WAN connection is setup, you may
also need proxy
ARP.
Note: The ping function will be one of your
main diagnostics tools. From here, you should start testing by
pinging your interfaces (LAN, WAN, Backhaul (a.k.a. OPT1). If
these pings are successful, ping up stream from the unit you
are on. If you are on a node, ping the unit above it. If
successful, ping the default gateway and DNS servers, and then
ping outside of your network.
Note: As important as this diagnostic tool
is, also connect to the unit wirelessly and ping the unit from
a command line. If your rules aren't configured properly, and
you haven't enabled the webGUI interface (sis0) permission to
access an interface, it is possible that the unit is working
and a ping from your connected device would be successful, yet
a ping from the webGUI would fail. Pay careful attention to
this, as you could waste a lot of time on a non-existent connectivity
problem, when in all actuality, it is a firewall rule problem.
Note:
Since this is a node getting its data from the main unit, from
the m0n0wall diagnostic tool, ping all the interfaces on
the node. If successful, ping the interfaces on the main unit.
If successful, ping your network gateway. If all are
successfully pinged, but pings from your laptop's command line
go through to the unit, but fail on pinging the up stream unit
or your network's default gateway, you probably need to
configure a static route in your router or firewall pointing
back to the subnet(s) configured on the units.
If you can ping from m0n0wall but not your laptop - its
possible you are missing a static route somewhere along the
line - i.e. so the packet goes out as, say, 10.12.12.180 but
can't come back becuase the 10.12.12.160/27 subnet isn't
listed anywhere. A quick way to tell if this might be
the case is to turn NAT back on (NAT -> advanced,
uncheck option) and then try surfing from your laptop.
Also, Other things that may cause similar
problems is if -- assuming you have captive portal
enabled -- you haven't clicked through it yet. Or, you don't
have an exception for the m0n0wall box itself.
Note: While the owners of any copyrighted information retain ownership of
their respective copyrights, all other information presented here is published
under a creative commons license:
This document released under the
Attribution-NonCommercial-ShareAlike 2.0
You are free:
to copy, distribute, display, and perform the work
to make derivative works
Under the following conditions:
Attribution. You must give the original
author credit.
Noncommercial. You may not use this work
for commercial purposes.
Share Alike. If you alter, transform, or
build upon this work, you may distribute the resulting
work only under a license identical to this one.
For any reuse or distribution, you must make clear
to others the license terms of this work.
Any of these conditions can be waived if you get
permission from the copyright holder.
Your fair use and
other rights are in no way affected by the above.
