m0n0wall Handbook

m0n0wall contains the following software components:

m0n0wall is based upon/includes various free software packages, listed below. The author of m0n0wall would like to thank the authors of these software packages for their efforts.

FreeBSD (http://www.freebsd.org) Copyright © 1994-2003 FreeBSD, Inc. All rights reserved.

This product includes PHP, freely available from http://www.php.net. Copyright © 1999 - 2003 The PHP Group. All rights reserved.

mini_httpd (http://www.acme.com/software/mini_httpd) Copyright © 1999, 2000 by Jef Poskanzer <jef@acme.com>. All rights reserved.

ISC DHCP server (http://www.isc.org/products/DHCP) Copyright © 1996-2003 Internet Software Consortium. All rights reserved.

ipfilter (http://www.ipfilter.org) Copyright © 1993-2002 by Darren Reed.

MPD - Multi-link PPP daemon for FreeBSD (http://www.dellroad.org/mpd) Copyright © 1995-1999 Whistle Communications, Inc. All rights reserved.

ez-ipupdate (http://www.gusnet.cx/proj/ez-ipupdate) Copyright © 1998-2001 Angus Mackay. All rights reserved.

Circular log support for FreeBSD syslogd (http://software.wwwi.com/syslogd) Copyright © 2001 Jeff Wheelhouse (jdw@wwwi.com)

Dnsmasq - a DNS forwarder for NAT firewalls (http://www.thekelleys.org.uk) Copyright © 2000-2003 Simon Kelley

Racoon (http://www.kame.net/racoon) Copyright © 1995-2002 WIDE Project. All rights reserved.

before version pb23: watchdogd (watchdog) Copyright © 2002-2003 Dirk-Willem van Gulik. All rights reserved. This product includes software developed by the Stichting Wireless Leiden (http://www.wirelessleiden.nl). See LICENSE for more licensing information.

msntp (http://www.hpcf.cam.ac.uk/export) Copyright © 1996, 1997, 2000 N.M. Maclaren, University of Cambridge. All rights reserved.

UCD-SNMP (http://www.ece.ucdavis.edu/ucd-snmp) Copyright © 1989, 1991, 1992 by Carnegie Mellon University. Copyright © 1996, 1998-2000 The Regents of the University of California. All rights reserved. Copyright © 2001-2002, Network Associates Technology, Inc. All rights reserved. Portions of this code are copyright © 2001-2002, Cambridge Broadband Ltd. All rights reserved.

choparp (http://choparp.sourceforge.net) Copyright © 1997 Takamichi Tateoka (tree@mma.club.uec.ac.jp) Copyright © 2002 Thomas Quinot (thomas@cuivre.fr.eu.org)

m0n0wall was written by Manuel Kasper.

The following persons have contributed code to m0n0wall:

Bob Zoller (bob at kludgebox dot com): Diagnostics: Ping function; WLAN channel auto-select; DNS forwarder

Michael Mee (m0n0wall at mikemee dot com): Timezone and NTP client support

Magne Andreassen (magne dot andreassen at bluezone dot no): Remote syslog'ing; some code bits for DHCP server on optional interfaces

Rob Whyte (rob at g-labs dot com): Idea/code bits for encrypted webGUI passwords; minimalized SNMP agent

Petr Verner (verner at ipps dot cz): Advanced outbound NAT: destination selection

Bruce A. Mah (bmah at acm dot org): Filtering bridge patches

Jim McBeath (monowall at j dot jimmc dot org): Filter rule patches (ordering, block/pass, disabled); better status page; webGUI assign network ports page

Chris Olive (chris at technologEase dot com): enhanced "execute command" page

Pauline Middelink (middelink at polyware dot nl): DHCP client: send hostname patch

Björn Pålsson (bjorn at networksab dot com): DHCP lease list page

Peter Allgeyer (allgeyer at web dot de): "reject" type filter rules

Thierry Lechat (dev at lechat dot org): SVG-based traffic grapher

Steven Honson (steven at honson dot org): per-user IP address assignments for PPTP VPN

Kurt Inge Smådal (kurt at emsp dot no): NAT on optional interfaces

Dinesh Nair (dinesh at alphaque dot com): captive portal: pass-through MAC/IP addresses, RADIUS authentication HTTP server concurrency limit

Justin Ellison (justin at techadvise dot com): traffic shaper TOS matching; magic shaper; DHCP deny unknown clients; IPsec user FQDNs

Fred Wright (fw at well dot com): ipfilter window scaling fix; ipnat ICMP checksum adjustment fix

m0n0wall was written by Manuel Kasper.

The following persons have contributed documentation to m0n0wall:

Chris Buechler (m0n0wall at chrisbuechler.com): Editor, numerous contributions throughout.

Shawn Giese (shawngiese at gmail dot com): numerous contributions throughout.

Jim McBeath (monowall at j dot jimmc dot org): Users Guide outline, editing

Rudi van Drunen (r.van.drunen at xs4all dot nl) with thanks to Manuel Kasper, Edwin Kremer, PicoBSD, Matt Simerson and John Voight: m0n0wall Hackers Guide, used as the basis for the old Development chapter, now part of the m0n0wall Developers' Handbook.

Francisco Artes (falcor at netassassin.com): IPsec and PPTP chapters.

Fred Wright (fw at well dot com): Suggestions and review.

Axel Eble (axel+m0n0-0001 at balrog dot de): Help with the wiki, ddclient howto contribution.

Brian Zushi (brian at ricerage dot org): Linux CD burning instructions, documentation review and suggestions.

Dino Bijedic (dino.bijedic at eracom-tech dot com): Sonicwall example VPN contribution.

486 processor - Any 486 or higher processor is sufficient for m0n0wall. Exactly how much processor you will need for your particular implementation varies depending on your Internet connection bandwidth, number of simultaneous connections required, what features you will use, etc. For most deployments, a 486 or Pentium processor is sufficient.

64 MB of RAM - 64 MB RAM is the official suggested minimum. The CD version of m0n0wall has been reported to work fine for some people with only 32 MB. When using the CompactFlash or hard drive versions of m0n0wall, expect upgrades to fail with less than 64 MB. This is because m0n0wall stores everything in RAM and uses no swap space - when it runs out of RAM, it has nothing to fall back on.

There are some BIOS settings that may need to be changed for m0n0wall to function properly.

Plug and Play OS

Most system BIOS have a setting for "Plug and Play OS" or something similar. This should always be set to "no" or "disable". With this setting turned off, the BIOS assigns system resources rather than leaving that up to the OS. FreeBSD (and hence m0n0wall) works best when the BIOS handles this task.

Disabling Unnecessary Devices

You most likely won't have to worry about this, but if you have hardware-related issues, we recommend disabling all unnecessary devices in the BIOS, such as onboard sound, and in some cases parallel ports, serial ports, and other unused devices. If you aren't using it, it is safe to disable it.

m0n0wall will run off of a CompactFlash card, hard drive, or CD with floppy to store the configuration.

CompactFlash

At least an 8 MB CompactFlash card is required.

Hard Drive

Any IDE or SCSI (with supported controller) hard drive will work fine with m0n0wall.

CD/floppy setup

Any IDE or SCSI (with supported controller) CD-ROM or DVD drive will work with m0n0wall. Also required for this setup is a 1.44 MB floppy drive with blank floppy disk formatted with MS-DOS/FAT file system. Any standard floppy drive will work. For this setup, you must have a PC that supports booting from CD-ROM.

Zip drive setup

Starting with 1.2b3, m0n0wall can run the hard drive image from a Zip drive. Write the disk the same way you would write a hard drive.

All Soekris devices are fully compatible with m0n0wall. For the net4501 and other 45xx models, use the net45xx image. For the net4801 and net4826, use the net48xx image.

Specifications

For a detailed walk-through of getting up and running with m0n0wall on Soekris hardware, see the m0n0wall Soekris Quick Start Guide.

Wireless Router Application Platform (WRAP)

PC Engines WRAP boards are fully compatible with m0n0wall. Use the WRAP images available on the download page.

The Nokia IPxxx boxes were built to run Check Point, but they are standard PC hardware and will run m0n0wall.

You can pick up a used IP110 or IP120 for around $100 USD on eBay.

IP110, 120 and 130

IP330

IP440, 530, 650, 740

Even in the used market, these boxes are usually out of the price range for a typical m0n0wall installation, and you can buy or assemble a comparable standard PC for far cheaper. But, if you have one laying around or can find one cheaply, these will run m0n0wall. Some of the optional interfaces like HSSI, T-1 CSU/DSU, V.35 and X.21 serial, OC-3 ATM, FDDI, etc. will not work, but the Ethernet will work fine.

NexCom's Nexgate line of appliances all support m0n0wall. These are much more high end than the WRAP and Soekris platforms, and hence are much more costly. There are a number of different configurations available, with prices starting over $500 USD for the most basic model. Contact NexCom for pricing.

The following can be used as a rough guide to determining which embedded platform, if any, is suitable for your environment.

Your selection of network cards (NIC's) is the single most important performance factor in your setup. Cheap NIC's will keep your CPU very busy with interrupt handling, causing your CPU to be the bottleneck in your configuration. A quality NIC can increase your maximum throughput as much as two to three fold, if not more.

FreeBSD refers to network cards by their driver name followed by the interface number. For example, if you have two Intel Pro/100 cards (fxp driver) and one 3Com 3C905 card (xl driver), you will have interfaces fxp0, fxp1, and xl0 respectively.

Intel Pro/100 and Pro/1000 cards tend to be the best performing and most reliable on m0n0wall. Cheap cards like those containing Realtek chipsets (FreeBSD rl driver) are very poor performers in comparison. If you are purchasing NIC's for your m0n0wall installation, we strongly recommend purchasing Intel cards. You can find them on ebay for less than $30 USD for 3-5 cards in a bulk lot.

For low throughput environments, like any typical broadband connection 6 Mbps or less, any NIC will suffice. If you require fast throughput (more than 30-40 Mbps) between interfaces for multiple LAN networks, or between a DMZ and your LAN, then using quality NIC's becomes much more important.

Your CPU will generally be the bottleneck in your system. Network throughput with cheap NIC's will max out your CPU long before it will get maxed out with quality NIC's, so the most important factor with CPU sizing is the quality of your NIC's.

If you are using good quality NIC's like Intel cards, as a general measure, a Pentium will suffice up to 30-40 Mbps, a Pentium III will do 100 Mb at wire speed, and for gigabit wire speeds you will need a 2.8+ GHz Pentium 4.

The stock m0n0wall images will not use more than 64 MB RAM under any circumstance. You can install as much memory as you like, but even with all features enabled and heavy loads, you will not exhaust 64 MB.

m0n0wall will work fine on any hard drive or compact flash card at least 8 MB in size. At boot, m0n0wall is loaded into RAM and runs from RAM, so the speed and type of storage medium used is not a factor in system performance.

Slower storage mediums like compact flash will take slightly longer to boot than hard drives will, but boot time is the only performance factor in selecting your storage medium. Compact flash is suggested for maximum reliability since it is much less likely to fail than a hard drive.

In environments where extremely high throughput through several interfaces is required, especially with gigabit interfaces, PCI bus speed must be taken into account. When using multiple interfaces in the same system, the bandwidth of the PCI bus can easily become a bottleneck. Most typical motherboards only have one or two PCI buses, and each can run an absolute maximum of 133 MBps, or 1064 Mbps. That's less than one gigabit interface can transfer. PCI-X can transfer up to 1056 MBps, or about 8.25 Gbps.

If you need sustained gigabit throughput at wire speed, you will want a server-class motherboard with PCI-X slots and PCI-X NIC's.

Currently all g, b/g, and a/b/g wireless cards are incompatible with m0n0wall. These require drivers that are only found in FreeBSD 5.x and 6.x, while m0n0wall is on 4.11. They will be supported when m0n0wall is on a newer version of FreeBSD.

The following list, to the best of our knowledge, is 100% accurate. Please report any findings to the contrary to Chris Buechler.

Not all wireless cards support hostap mode! (i.e. can function as an access point) This is a limitation of the hardware itself, not m0n0wall or FreeBSD. If this list does not say "no hostap" next to the card, it should support hostap.

miniPCI

We recommend just trying whatever Ethernet cards you already have without bothering with the compatibility list since it includes virtually every NIC. One notable exception is some newer gigabit cards. For this reason, we suggest checking the list below for gigabit cards, or just get Intel Pro/1000 cards which are well supported.

If you have any question on what cards are compatible, refer to the FreeBSD 4.11-RELEASE Hardware Notes for a list of supported Ethernet cards.

While a large number of ISA Ethernet cards are supported, we recommend you stay away from them if possible. They can be very time consuming and difficult to get working properly. The cost of a few PCI network cards is, in my opinion, well worth the headaches it will prevent. The only time you should use ISA NIC's is when you don't have any or enough PCI slots.

If you have ISA cards that you'd like to try, by all means give them a shot. It might work out of the box, especially if you only have one ISA card along with some PCI cards. But if you experience problems getting them to work, you've been warned!

If you need to get an ISA card working, you'll probably need to change some things. First, most ISA NIC's, including the common 3Com ISA cards, have a "plug and play" mode on the card that is selected by default. FreeBSD doesn't always play nicely with devices that are set to plug and play. In the case of the 3Com cards, 3Com has a DOS utility on their support site that you will have to run in DOS to set up the resources on all of the cards manually. Check your network card manufacturer's support site for information on disabling any plug and play settings on ISA cards. This is typically jumpers on the card or a firmware utility.

Another thing you may have to do is to change some settings in the system BIOS. For example you may need to set the IRQ used by the NIC to ISA/PnP.

You can run m0n0wall on a standard PC with a CD-ROM drive and a floppy drive. A hard disk is not required. m0n0wall will boot from the CD and run from memory. The floppy is used only to store your m0n0wall configuration. If you want to run m0n0wall on a standard PC with a hard disk rather than a CD, follow the directions in the next section.

Make sure your m0n0wall PC is set to boot from CD-ROM and not from floppy.

You can run m0n0wall on a system which uses a CompactFlash (CF) card as its primary disk, such as the Soekris boxes, or on a standard PC with an IDE hard disk. m0n0wall will load from the CF card or disk and then run from memory. It does not swap to the CF card or disk, nor does it write anything to it except when you change and save your configuration.

For alternative means of installing m0n0wall, see the Installation section of the Other Documentation chapter.

The General Setup screen allows you to control some general parameters of your firewall.

Figure 4.1. The General Setup screen

The General Setup screen allows you to change the following parameters:

Static routes are necessary when you have a subnet behind another router on any of your internal networks. Static routes are never required for directly connected networks or if the network in question is reachable through your WAN interface's default gateway.

The Static Routes sub section allow the user to set up static routes in order to reach network that must use a gateway different from the default one. By pressing the + icon, the system allows the user to add new static routes.

The parameters to set up a new route are the following:

The Firmware screen allows you to upgrade or downgrade your m0n0wall version (only available if you are running a hard drive or compact flash installation).

Figure 4.2. The Firmware screen

The options on the Advanced System page are intended for use by advanced users only, and there's NO support for them.

4.3.4.1. IPv6

IPv6 support is included in the latest 1.3beta release (v12 or later). The base for this was actually contributed by Michael Hanselmann way back in 2005, and with some modifications to reflect the changes in m0n0wall since then, as well as a few fixes/ improvements (most notably easy to configure 6to4 support), it is now finally in an official release. (Belated) Thanks, Michael!

IPv6 support must be explicitly enabled on the System: Advanced setup page before any of the new options will become available. Also, by default there are no firewall rules for IPv6, so everything is blocked. Make sure to add at least a rule on your LAN interface for outbound connections if you want to use IPv6.

After IPv6 is activated, additional options will become available in the main menu for routing and firewall management. Interface pages will also offer additional IPv6 configuration options. A useful option under the LAN interface will appear to send IPv6 Router Advertisements. This allows other hosts on the LAN to automatically configure their IPv6 address based on the prefix and gateway information that the Firewall provides them.

Caution

Since 1.3b12 is the first release with IPv6 support, bugs in the implementation are likely. As always, please post on the mailing list or in the forum if you've found something odd (with a detailed description of what you did, please). Also let us know if everything worked "out of the box". :)

If you don't have native IPv6 connectivity yet, don't worry: 6to4 tunneling is supported, which should work anywhere you've got a (non- firewalled) public IPv4 address. Simply choose "6to4" for the IPv6 mode on both the WAN and LAN interfaces - no need to manually configure any IPv6 addresses (check the IPv6 RA option on the LAN interface and your LAN hosts will be able to automatically obtain an IPv6 address). It can also work with dynamic WAN IPv4 addresses (LAN/ OPT IPv6 subnets are adjusted automatically). Note that some operating systems do not use IPv6 when connecting to a host that supports both IPv4 and IPv6 if they are configured with a 6to4 IPv6 address (-> RFC 3484), so use an IPv6-only host (try http://ipv6.m0n0.ch) for browser testing, or simply do a "ping6".

If you've got native IPv6 connectivity (over PPPoE/PPTP with 1.3b13 or later), remember that you'll have to statically route your m0n0wall's LAN subnet from your upstream router - there's no NAT for IPv6 in m0n0wall (and it would be pretty pointless in most cases anyway :).

Also, if you've gotten it to work and need some IPv6 capable web sites to try it out, have a look at http://sixy.ch (or http://ipv6.sixy.ch), a directory of IPv6 enabled web sites.

Note

Although many operating systems support IPv6 by default such as MacOSX 10.4+, Windows Vista and many Linux packages, some systems need it to be activated (such as Windows XP) and some systems may not support it at all (such as the Apple iPhone 2.0 and older versions of Windows). Check your operating system documentation to see if IPv6 is available.

For more information on IPv6 check out some of the following websites.

• IPv6 Swiss Task Force

• Wikipedia IPv6

• Microsoft Technet IPv6

• ars techna: Everything you need to know about IPv6

• IPv6 Tunnel Brokers Wikipedia or LinuxReviews.org

• Cool IPv6 Stuff from sixxs.net

Additional webGui users can be added here. User permissions are determined by the admin group they are a member of.

Additional webGui admin groups can be added here as well. Each group can be restricted to specific portions of the webGUI. Individually select the desired web pages each group may access. For example, a troubleshooting group could be created which has access only to selected Status and Diagnostics pages.

The Assign sub menu allows to map the symbolic reference LAN and WAN to the physical interfaces that are present on the system. Click on the Save button to apply changes, and remember that a change in this assignment will require a system reboot for the changes to take effect.

In the LAN section, it is possible to change the IP address and the netmask (in CIDR notation) of the firewall internal interface. The system must be rebooted in order to apply the changes as suggested after pressing the "Save" button.

4.4.2.1. LAN IPv6

When IPv6 is activated in firmware 1.3 beta 13 or higher, additional IPv6 options will become available on the WAN interface.

In the WAN sub section, it is possible to set up all the parameters for WAN interface. The WAN Interface can be a Static IP address, a DHCP address, a PPPoE interface or a PPTP connection, as detailed in the following. On the basis of the connection type selected, the related sub panel must be filled.

A detailed description of all the fields follows.

4.4.3.1. WAN IPv6

When IPv6 is activated in firmware 1.3 beta 13 or higher, additional IPv6 options will become available on the WAN interface.

Optional interfaces can be used for a variety of purposes. Generally they are used as second LAN interfaces or DMZ interfaces.

The wireless interface configuration screen is only presented if a compatible wireless card is found at system startup. Options will be presented depending on the features supported for the wireless card. See the Wireless chapter for more information on wireless configuration options.

This service allows you to use the fixed IP address of your m0n0wall's LAN ethernet interface to resolve/proxy all DNS queries on your LAN network. When the m0n0wall DHCP server assigns IP addresses, it also assigns the LAN IP address as the DNS server to use. Otherwise, to benefit from this service you must manually configure the DNS IP address on your computers to be the LAN IP of your m0n0wall.

If the DNS forwarder is enabled, the DHCP service (if enabled) will automatically serve the LAN IP address as a DNS server to DHCP clients so they will use the forwarder. The DNS forwarder will use the DNS servers entered in System: General setup or those obtained via DHCP or PPP on WAN if the "Allow DNS server list to be overridden by DHCP/PPP on WAN" is checked. If you don't use that option (or if you use a static IP address on WAN), you must manually specify at least one DNS server on the System: General setup page.

This is important for instance if you have your DHCP clients renewing their IP address information every 3 days, but every day your WAN IP changes from your ISP. If your ISP changed the DNS servers on you then it would be 2 days until your DHCP clients received the correct information. By using your LAN IP address, all LAN network clients are assured of a working DNS server as long as the m0n0wall has received a good DNS IP address to use... even if it just received the new DNS information a minute ago. This also allows a network administrator to easily redirect all traffic to a new internal DNS server (maybe while transitioning a new server into the network).

Setting "Allow DNS server list to be overridden by DHCP/PPP on WAN" is necessary if your ISP might change the IP address of the DNS server. If you have a static IP address on your WAN than you would not need this option set

The DNS forwarder screen contains configuration options relevant to the DNS forwarding server on your m0n0wall.

Enabling the DNS Forwarder Check the first checkbox, "Enable DNS forwarder", to enable the service on the LAN interface. After enabling this, you will need to configure your client machines to use the LAN IP address of your m0n0wall as their DNS server.

DNS Host Name Registration

If your m0n0wall acts as the DHCP server for your LAN, and you need name resolution between hosts on the LAN, check the "Register DHCP leases in DNS forwarder" box. It will append the default domain in System:General setup to the host name of the computer that is requesting a DHCP lease. For example, if your machine name is my-pc and your default domain is example.com, it will register my-pc.example.com with the IP address assigned from DHCP, so the other hosts on your LAN can locate your machine by that name.

DNS Forwarder Overrides

If there are certain DNS host names you want to override for your internal DNS clients, add them under DNS overrides on this page. For example, if you want www.yourcompany.com to point to a different site internally than it does from the Internet, enter an override for www.yourcompany.com with the appropriate IP address. This can also be used as a rudimentary (and easy to bypass) filter on web sites LAN clients can visit, by assigning the undesired host name to an invalid IP address. For example, to block www.example.com, put in an override to redirect it to an invalid IP address, such as 1.2.3.4. Note that using a different DNS server or editing the hosts file on the client machine gets around this restriction, but doing this is sufficient to block the site for the vast majority of users.

Dynamic DNS allows you to have a permanent host name that can be used to access your network, generally used when your public IP address is assigned by DHCP and subject to change. This allows you to run your own web server, mail server, etc. using a DNS host name.

For links to providers of dynamic DNS services, visit the website of the dynamic DNS client used by m0n0wall, ez-ipupdate.

After you have signed up with one of the dynamic DNS providers listed, you can continue.

Configuring the Dynamic DNS Client

To start, first check the "Enable Dynamic DNS client" box at the top of the page.

In the "Service type" drop down box, select the service you signed up with above.

Some services support MX DNS records on dynamic DNS subdomains. This helps ensure you can get email to your host name. If your service supports this (dyndns.org is one that does, others do as well), fill in your mail server's host name in that field. If you do not need an MX record or if your provider does not support them, just leave the field blank.

Wildcards - If you want to enable wildcard on your dynamic DNS host name, check this box. This means all host names not specifically configured are redirected to your dynamic DNS name. So if your dynamic DNS is example.homeip.net, and you enable wildcards, www.example.homeip.net, mail.example.homeip.net, anything.example.homeip.net, etc. (i.e. *.example.homeip.net) will all resolve to example.homeip.net.

The next two boxes are for your username and password. Enter your account information from the dynamic DNS provider.

Click Save. Your dynamic DNS host name should immediately be updated with your WAN IP address. To verify this, ping your dynamic DNS host name. It should resolve to the IP address of the WAN interface of your m0n0wall. If not, check Diagnostics: System logs for information on why it failed.

This screen allows you to enable the DHCP server on enabled Ethernet interfaces other than WAN.

Enabling the DHCP Server

To enable the DHCP server on a particular interface, click on the appropriate tab for the interface and check the "Enable DHCP server on interface" box.

Deny unknown clients

This option allows you to implement a more secure DHCP configuration. Many companies suffer from worm outbreaks and related security issues due to unauthorized machines being plugged into their network. This option will help ensure only authorized hosts can receive a lease from your DHCP server. With this option enabled, only hosts defined at the bottom of this page will receive a lease from DHCP.

The downside to this option is that it can be difficult to maintain when you have more than a handful of hosts on your network. Many will find the increased security worth the increase in maintenance. Note that this is only sufficient to stop the typical user that expects to be able to plug into your network and obtain a DHCP lease to get on the Internet. Anyone with network and/or security expertise can easily bypass this.

Subnet, Subnet Mask, and Available range are filled in from the IP and subnet information from that particular interface.

Range

In the first box, enter the starting address of your DHCP range. In the second box, enter the ending address of the range. Note that you don't want to make this the same as the available range, as this includes the subnet address and broadcast address, which are unusable, as well as the address of your m0n0wall interface which also cannot be in the range.

WINS Servers

If you use an NT 4 domain, or have pre-Windows 2000 clients that need to access an Active Directory domain, you will need to fill in your WINS server IP addresses in these boxes. If you only have one WINS server, leave the second box blank.

Default and Maximum Lease Time

The default lease time is the length of the DHCP lease on any clients that do not request a specific expiration time on their DHCP lease. The default is 7200 seconds, or two hours. For the vast majority of network environments, this is too low. I would generally recommend setting this to a week, which is 604,800 seconds.

The maximum lease time must be more than the default lease time. Most networks will not use this value at all. In most instances, I set this to one second longer than the default lease time.

Click Save to save your changes, then click Apply to enable the DHCP server.

Static DHCP Mappings

Static DHCP mappings can be used to assign the same IP address every time to a particular host. This can be helpful if you define access rules on the firewall or on other hosts on your LAN based on IP address, but still want to use DHCP. Alternatively, you can keep the IP address box blank to assign an IP out of the available range, when you are using the "Deny unknown clients" option.

Click the + icon at the bottom of the DHCP configuration page to add a static DHCP mapping.

In the MAC address box, fill in the system's MAC address in the format xx:xx:xx:xx:xx:xx. For Windows NT/2000/XP clients, you can get determine the MAC address by opening up a command prompt and typing 'ipconfig'. For Windows 95/98/ME clients, go to Start, Run, winipcfg. For Unix clients, use ifconfig.

In the IP address box, fill in the IP address you want to be assigned to the client, or leave it blank to automatically assign one from the available DHCP range. If you put in a static IP address, it must not be within the range of the DHCP server.

It is recommended you fill in a description in the Description box to remind you what this entry is for, though this is an optional value.

Click Save when you are finished and the mapping will be added.

SNMP is a Network Management Protocol that allows a central management software to consult information on devices running an SNMP agent. You can enable a SNMP agent on your LAN interface on this screen. This is useful if you have a network management or monitoring system that takes advantage of it. This service uses UDP port 161.

The System location and System contact boxes can be left blank, but can assist you in determining which device you are monitoring if you have several monitored hosts.

The Community is generally set to "public", but if you have any regard for security at all, you should set this to something difficult to guess, containing numbers and letters. This community name is still passed over the network in clear text, so it could be intercepted, though the most anyone could get with that community name is information on the setup and utilization of your firewall. In most environments, this is likely of little to no concern, but is something to keep in mind.

After setting the values as you desire, click Save and your changes will be applied.

Proxy ARP can be used if you need m0n0wall to send ARP replies on the WAN interface for other IP addresses than its own WAN IP address (e.g. for 1:1, advanced outbound or server NAT). It is not necessary if you have a subnet routed to you or if you use PPPoE/PPTP, and it only works if the WAN interface is configured with a static IP address or DHCP.

If you enable 1:1, server, or advanced outbound NAT, you may need to enable proxy ARP for the IP address(es) being used by those translations. To do so, click the + on this page.

Enter either a single IP address, or subnet or range of addresses, optionally add a description to remind you why you made this entry, and click Save. Then click "Apply changes" for m0n0wall to enable proxy ARP.

For more information on when you do and do not need Proxy ARP, see this page.

What is Captive Portal? from wikipedia.org

The captive portal technique forces a HTTP client on a network to see a special web page (usually for Authentication) before surfing the Internet normally. This is done by intercepting all HTTP traffic, regardless of address, until the user is allowed to exit the portal. You will see captive portals in use at most Wi-Fi hotspots. It can be used to control wired access (e.g. apartment houses, business centers, "open" Ethernet jacks) as well.

Check the "Enable captive portal" box to enable.

Interface - Select the interface on which you want to enable captive portal. It can only run on one interface at a time.

Idle timeout - Clients will be disconnected after this amount of inactivity. They may log in again immediately, though. Leave this field blank for no idle timeout.

Hard timeout - Clients will be disconnected after this amount of time, regardless of activity. They may log in again immediately, though. Leave this field blank for no hard timeout (not recommended unless an idle timeout is set).

Logout popup window - If enabled, a popup window will appear when clients are allowed through the captive portal. This allows clients to explicitly disconnect themselves before the idle or hard timeout occurs. When RADIUS accounting is enabled, this option is implied.

RADIUS server - Enter the IP address and port of the RADIUS server which users of the captive portal have to authenticate against. Leave blank to disable RADIUS authentication. Leave port number blank to use the default port (1812). Leave the RADIUS shared secret blank to not use a RADIUS shared secret. RADIUS accounting packets will also be sent to port 1813 of the RADIUS server if RADIUS accounting is enabled.

Portal page contents - Here you can upload an HTML file for the portal page (leave blank to keep the current one, or the default if you have not uploaded one previously).

Authentication error page contents - The contents of the HTML file that you upload here are displayed when a RADIUS authentication error occurs (generally because of an incorrect logon or password).

This service can be used to wake up (power on) computers by sending special "Magic Packets". The NIC in the computer that is to be woken up must support Wake on LAN and has to be configured properly (WOL cable, BIOS settings).

This might be useful, for instance, if you access your home or corporate network remotely via VPN, and need to access a machine that may not be powered on at all times. You can log into the m0n0wall device at that location and send a wake up packet.

To power on a machine, just choose the appropriate interface, put the MAC address of the machine into the MAC address box, and click "Send".

If you use this feature at all, you will probably want to create a list of the machines you want to remotely power on. If you click the + at the bottom of the screen, you can add a host to the list that is displayed. Once you have added the host to your list, you can simply click on the MAC address to power on the system.

A SIP proxy configuration page is available starting in firmware 1.3. This pages activates and configures a SIP proxy/masquerading service. Only use it when other Firewall traversal options like using STUN or outgoing SIP proxy services aren't offered by your SIP service provider. If activated, configure your SIP User Agents (phone) to use this server as outbound proxy.

When enabled on port 5060, all outgoing SIP messages are redirected to this SIP proxy. Firewall rules are added automatically to the WAN interface for the UDP SIP signaling and UDP RTP streams to be reachable from the outside world. It is possible to use this service as a very simple SIP registrar (without authentication, but limited to the local LAN subnet). Use the same server for registration and outbound proxy.

Figure 4.4. The Traffic Graph screen

The traffic screen allows you to select an interface, and view real time throughput graphs on that interface. This feature was introduced in version 1.1.

The Adobe SVG viewer is required to view the graphs. This page has a link to the installation for this viewer.

More information on wireless features can be found in the Wireless chapter.

The ultimate page showing the status of your m0n0wall device is actually not shown on the menu. You simply add "/status.php" after the ip address of your m0n0wall device, for example http://10.0.0.1/status.php. This page will show statistics of the following information.

System logs are available for the following services:

System log (often called syslog) settings can also be configured on this page by clicking on the Settings tab. When sending Syslog to a remote server m0n0wall sends UDP datagrams to port 514 on the specified remote syslog server. Be sure to set syslogd on the remote server to accept syslog messages from m0n0wall and to not block the traffic in any intervening firewalls.

It is recommended that you log your m0n0wall to a remote syslog server for diagnostics and forensic purposes. There are a number of free tools receive and store syslog messages for you on Windows, Mac, and Unix based systems. These software packages also offer additional features such as automatically sending pages, emails or SMS messages as well as running software or commands based on the messages that are received. Some software packages are listed here.

Some operating systems that are by default using syslog messages, such as MacOSX, may have default configurations that limit reception of syslog messages from external sources. If you hav problems receiving messages verify that your syslog server software can receive external messages.

This screen can be used to view your active and/or expired DHCP leases. Clicking the button on this screen will switch between showing only active leases and showing both active and expired leases.

Expired DHCP leases show up in gray text, while active ones are black. (this screenshot from a system with only expired leases)

IPsec maintains two databases with connection details.

Security Association Database

First is the Security Association Database (SAD). This database maintains a list of all current IPsec Security Associations (SA's).

Security Policy Database

Second is the Security Policy Database (SPD). This database maintains a list of all the IPsec policies on the system. You will have two SPD entries for each IPsec VPN connection you have configured, regardless of whether the connection is up. This database tells the system what traffic will pass over VPN, and specifically which tunnel it traverses.

Table 4.5. The two entries for each VPN connection are as follows:

Source	Destination	Direction	Protocol	Tunnel Endpoints
local IP subnet for VPN connection	remote IP subnet for VPN connection		ESP or AH	Public IP address of local m0n0wall - Public IP address of remote endpoint
remote IP subnet for VPN connection	local IP subnet for VPN connection		ESP or AH	Public IP address of remote endpoint - Public IP address of local m0n0wall

At this screen, you will see two entries for each IPsec connection that has been successfully negotiated. One from the local public IP to the remote endpoint's public IP, and one in the opposite direction. This indicates that IPsec negotiations were successful, and that traffic should now be passing your VPN connection if everything else is configured appropriately.

By clicking on the X, you can delete the SA. m0n0wall will attempt to recreate it after deleting it. If you have a VPN connection with duplicate SA's (more than one from same src to same dst) and the connection has gone down, delete all the SA's associated with the connection. It should renegotiate and come back up within a few seconds.

This screen gives you a GUI to ping (send ICMP echo request) from the m0n0wall. Fill in the IP address or hostname of the machine to ping, choose the number of pings in the count drop down, and click the Ping button.

This screen gives you a GUI to traceroute from the m0n0wall. Fill in the IP address or hostname of the machine whose route you want to trace, choose the maximum number of hops in the drop down, and click the Traceroute button.

This page shows the current ARP table of the m0n0wall device.

This page shows the current Firewall state table. Optionally take a snapshot of the state stable and compare it to the current table.

This screen allows you to reset the state tables on your m0n0wall for the NAT and firewall state tables.

Just check the boxes for the table(s) you want to clear, and click the Reset button.

Resetting the state tables will remove all entries from the corresponding tables. This means that all open connections will be broken and will have to be re-established. This may be necessary after making substantial changes to the firewall and/or NAT rules, especially if there are IP protocol mappings (e.g. for PPTP or IPv6) with open connections.

The firewall will normally leave the state tables intact when changing rules.

NOTE: If you reset the firewall state table, the browser session may appear to be hung after clicking "Reset". Simply refresh the page to continue.

This screen allows you to backup your existing configuration, or restore a previous backup file. These files are text based XML files.

To backup your m0n0wall, click the "Download configuration" button. This will download a file called (by default) config.xml.

If you ever need to restore a previous backup file, go to this page, and under the "Restore configuration" section, click Browse. Locate the config.xml file you backed up above.

Clicking Yes on this page will reset m0n0wall to the default out of the box configuration options and clear any configuration you have done on the device.

If all else fails when trying to configure something on your m0n0wall, sometimes it is easiest to start over from scratch on the entire configuration. In that instance, use this feature to reload the default settings.

Click Yes on this page to reboot the system.

As a general rule of thumb in m0n0wall and FreeBSD in general, rebooting probably isn't going to fix any problems you are having. But it is worth a shot in many circumstances.

Unlike so many systems, rebooting isn't a suggested maintenance procedure on m0n0wall. There is no need to reboot the system unless you have a specific reason for doing so.

Go to the Firewall -> Alias screen and click the to add an alias.

Now that you have entered an alias, you can use it in any of the boxes with blue backgrounds by selecting type "Single host or alias" and typing in the alias name in the "Address" box.

There are two most commonly used and most familiar types of NAT, bidirectional or 1:1 (pronounced one to one), and Port Address Translation, or PAT. In both cases m0n0wall will change the IP header of packets that traverse the NAT enabled interface but NAT and PAT each change a different part of the IP header.

RFC 1918 - Address Allocation for Private Internets - February 1996

RFC 1631 - The IP Network Address Translator (NAT) - May 1994

Network Address Translation at Wikipedia

The IPsec specification includes many features and services. Below is a list of IPsec features, including features not currently supported by selected m0n0wall versions.

Site to site VPN's connect two locations with static public IP addresses and allow traffic to be routed between the two networks. This is most commonly used to connect an organization's branch offices back to its main office, so branch users can access network resources in the main office. Prior to VPN's, much more expensive private Wide Area Network (WAN) links like frame relay, point to point T1 lines, etc. were commonly used for this functionality. Some organizations are moving towards VPN links between sites to take advantage of reduced costs.

Site to site VPN's can also be used to link your home network to a friend's home network, to provide access to each other's network resources without opening holes in your firewalls.

While site to site VPN's are a good solution in many cases, private WAN links also have their benefits. IPsec adds processing overhead, and the Internet has far greater latency than a private network, so VPN connections are typically slower (while maybe not throughput-wise, they at least have much higher latency). A point to point T1 typically has latency of around 4-8 ms, while a typical VPN connection will be 30-80+ ms depending on the number of hops on the Internet between the two VPN endpoints.

m0n0wall provides two means of remote access VPN, PPTP and IPsec (with OpenVPN available in beta versions only for now). m0n0wall's mobile IPsec functionality has some serious limitations that hinder its practicality for many deployments. m0n0wall version 1.2 does not support NAT-Traversal (NAT-T) for IPsec, which means if any of your client machines are behind NAT, IPsec VPN will not work. This alone eliminates it as a possibility for most environments, since remote users will almost always need access from behind NAT. Many home networks use a NAT router of some sort, as do most hot spot locations, hotel networks, etc.

One good use of the m0n0wall IPsec client VPN capabilities is to secure all traffic sent by hosts on a wireless network or other untrusted network. This will be described later in this chapter.

FIXME - A second limitation is the lack of any really good, free IPsec VPN clients for Windows. Most of your remote users will likely be Windows laptop users, so this is another major hindrance.

For most situations, PPTP is probably the best remote access VPN option in m0n0wall right now. See the PPTP chapter for more information.

IPsec's Tunnel mode is supported on m0n0wall devices. This mode allows secured communication between entire subnets. When the packet leavs the subnet it will be encrypted, when it gets to the remote IPSec device the packets are decrypted and routed/ sent into the remote network.

The IPsec Specification supports a 2nd mode of operation called Transport mode. Transport mode limits encrypted communication to the 2 devices that are encrypting the information. If this was supported it would only allow secured communication to the m0n0wall device itself and not to its connected networks. Transport mode is not supported.

This option increases security during authentication by assuring that new keys (which are generated on a regular basis to ensure security) are not based on previous keys. When activated, this means that if someone obtains or discovers 1 encryption key that they cannot use it to discover previous or future keys. This can be disabled to allow faster key negotiation.

Most operating systems include IPsec clients. Windows 2000 and above includes a free IPsec client but it is also difficult to configure. MacOSX 10.3 and later also includes a free IPsec client but the free configuration tool is for a special version of IPsec called L2TP/IPsec. Free configuration tools exist for both operating systems but commercial solutions, at least for Windows, are more evolved and easier to use than the built-in free version.

Below is a list of IPsec software clients.

Starting in firmware 1.3b11 it is possible to configure a Dead Peer Detection (DPD) interval in seconds with a default of seconds. This allows the m0n0wall device to detect if a tunnel is still being used. If the DPD interval has passed and the m0n0wall devices finds an IPsec tunnel is not exchanging phase 1 IKE messages (which should be happening even if the tunnel is not being used to transmit data) the tunnel will be closed.

Without this option activated, an IPsec tunnel may be left open and active when an actual problem has appeared such as bad routing, reboot of the remote client, change of IP addresses.

Both sides of the IPsec connection must support and activate Dead Peer Detection.

Starting in firmware 1.3b6 it is possible to configure domain names to be IPsec connection endpoints. Although fixed IP addresses are recommended for building IPsec connections, using domain names allows IPsec usage with clients whose IP address may change frequently (a home Internet connection or a laptop user at a wireless hotspot for example.)

The IPsec DNS Check Interval option is under the System > Advanced menu. An interval time in seconds can be set here. If at least one IPsec tunnel has a host name (instead of an IP address) as the remote gateway, a DNS lookup is performed at the interval specified here, and if the IP address that the host name resolved to has changed, the IPsec tunnel is reconfigured. The default is 60 seconds.

The remote connection point must use a Dynamic DNS client software that registers any IP address changes with the domain server.

Starting in firmware 1.3b2 it is possible to use NAT Traversal (NAT-T) with IPsec connections. This feature allows IPsec clients to be behind a NAT device (common in a home or office firewall). Using ESP packets to transmit encrypted data does not allow it to pass through a NAT transformation but encapsulating the encrypted data in UDP packets allows the data to pass through NAT transformations.

Using NAT-T creates two types of traffic: IKE authentication (phase 1) on UDP 500 and encrypted data (phase 2) on UDP 4500. These two ports must be allowing data on the m0n0wall device and not be blocked by any intervening firewalls. This feature can be turned on or off for each IPsec connection.

Starting in firmware 1.3b6 there is firewall support for decapsulated IPsec packets (new pseudo-interface "IPsec" in firewall rule editor); this is on by default, but the default configuration contains a "pass all" rule on the new IPsec pseudo- interface (and this is also added automatically for existing configurations), which can then be deleted to actually filter IPsec VPN traffic.

To configure filtering on IPsec traffic, select the IPsec interface from the list of interfaces that packets must come in to match the selected rule.

FIXME - In some cases you have a firewall or router with layer 2 routing (protocol ACLs) sitting in front of your m0n0wall. If this is the case you will need to port forward ESP or AH (depending on which one you chose) to the m0n0wall. (NOTE: if you are running NAT on that firewall AH will not be an option.)

Starting in m0n0wall firmware 1.3 NAT-T traversal is supported. This allows all ESP packets to be encapsulated in UDP packets using port 4500. Allowing and redirecting UDP 500 traffic (used for IKE authentication in phase 1) and UDP 4500 (NAT-T encapsulated data packets in phase 2) allows the m0n0wall to be placed behind another firewall.

Figure 8.1. Example: m0n0wall behind a router

Below are some more issues that you may face when building IPSec connections.

In some cases, most for those people who are granting PPTP access to others they do not fully trust, you will want to limit access (Specific Allow Rules) or mitigate specific access with Deny Rules. With specific allow users would be granted explicit permission to access hosts, and sometimes specific ports, and all other traffic is denied. The latter would be done if you wanted the PPTP clients to access the LAN & WAN but did not want them to access your SAMBA server for instance.

Our example is an allow rule granting permission for people on the PPTP network to use SSH on a LAN server with the IP address 192.168.1.151:

Save and Apply these rules as needed. Test them all to make sure they are working as designed. Most networks are compromised because no one checked the ACLs were activated or even working properly.

As you hopefully will see you have the settings for your physical adapter (in my case I renamed it to ETH0)

You will also see the PPP Adapter with the name you gave the VPN Connection when performing the steps in the last section. It should have an IP address that is in the range you defined for the PPTP Server. It should also have the subnet of 255.255.255.255 and it will be using itself as the default gateway. Just live with it; it is how it works.

For the more advanced who wish to know if things are all working right, Figure 6, displays a full ipconfig on the virtual adapter.

As seen in the last figure, the first hop is the PPTP “Server Address” as this is the gateway/interface for the PPTP Network.

Now check things like HTTP, etc. If you have this much and followed the directions you should be able to do everything.

Adding MAC addresses as pass-through MACs allows them access through the captive portal automatically without being taken to the portal page. The pass-through MACs can change their IP addresses on the fly and upon the next access, the pass-through tables are changed accordingly. Pass-through MACs will however still be disconnected after the captive portal timeout period.

You can enter a list of MAC address (6 hex octets separated by colons) and a description here for your reference (it is not parsed).

Adding allowed IP addresses will allow IP access to/from these addresses through the captive portal without being taken to the portal page. This can be used for a web server serving images for the portal page or a DNS server on another network, for example. By specifying from addresses, it may be used to always allow pass-through access from a client behind the captive portal.

Some sample rules are:

any x.x.x.x > All connections to the IP address are allowed

x.x.x.x > any All connections from the IP address are allowed

For each entry on the Allowed IP Address list you can use From to always allow an IP address through the captive portal (without authentication). Use To to allow access from all clients (even non-authenticated ones) behind the portal to this IP address. Additionally each entry will contain an IP address and a description for your reference (it is not parsed).

Below are some of the Secure Authentication options that can be configured for use with th Captive Portal to .

When using the Local User Manager option for Authentication it is possible to store and access a list of users on the m0n0wall device itself. This list is manually entered from the web interface and includes the following parameters.

When using the Radius Authentication option for Authentication it is possible to authenticate with an existing Radius server on a connected network. The Radius server will manage the user authentication requests. This list is manually entered from the web interface and includes the following parameters.

Upload an HTML file for the portal page here (leave blank to keep the current one). Make sure to include a form (POST to "$PORTAL_ACTION$") with a submit button (name="accept") and a hidden field with name="redirurl" and value="$PORTAL_REDIRURL$". Include the "auth_user" and "auth_pass" input fields if authentication is enabled, otherwise it will always fail. Example code for the form:

<form method="post" action="$PORTAL_ACTION$">
   <input name="auth_user" type="text">
   <input name="auth_pass" type="password">
   <input name="redirurl" type="hidden" value="$PORTAL_REDIRURL$">
   <input name="accept" type="submit" value="Continue">
</form>

The contents of the HTML file that you upload here are displayed when an authentication error occurs. You may include "$PORTAL_MESSAGE$", which will be replaced by the error or reply messages from the RADIUS server, if any. You may also include a new login form in the error page to allow the user to attempt another login directly.

The loading page for custom files can be found in the File Manager section of the Captive Portal main menu.

Any files that you upload here will be made available in the root directory of the captive portal HTTP(S) server. You may reference them directly from your portal page HTML code using relative paths. Example: you've uploaded an image with the name 'test.jpg' using the file manager. Then you can include it in your portal page like this:

<img src="test.jpg" width=... height=...> 

The total size limit for all files is 256 KB.

Below are the steps to quickly setup and use the voucher functionality of m0n0wall's Captive Portal.

Each of these generated vouchers can now be used by users for the configured amount of minutes for that roll. Note that as soon as a voucher has been activated, its timer will run down to zero and then block access, no matter if the session is idle or got disconnected due to logout or session termination.

To test the vouchers in the m0n0wall GUI, click on Status->Captive Portal. New tabs, dedicated to voucher handling, show up when voucher support is enabled. Click on status->captive portal-> Test Vouchers and enter one or more of the newly generated vouchers from the downloaded CSV file and click submit. A message will be shown with the validation and duration of each given voucher.

One can add multiple rolls, e.g. to have vouchers with different time credit. It is also possible, to enter multiple vouchers, separated by space, to gain the sum of time credit of all entered vouchers.

There is more to it, read the comments to each config parameter on the voucher page.

Note on the very short public/private RSA keys: I know, those can be cracked easy and in no time, if one of the keys is known. The idea here was to make it a little bit harder than simply adding a shared password into the m0n0wall config file. Unfortunately I'm no expert on encryption but I assume with such short encrypted vouchers, there is no security difference between the used RSA keys and a symmetric encryption. Anyhow, all that encryption/decryption stuff is done in a newly added binary C program voucher.c, that is compiled and added into the m0n0wall image, and can be modified to increase the usability and security.

Below are the following parameters that can be configured for voucher use in the upcoming 1.3 m0n0wall). The Enable Vouchers checkbox must activated for these parameters to be used.

Each voucher roll has the following parameters.

Chris Burrows contributed A duffers guide to setting up a portal to allow visitors limited access to the Internet.

Jonathan De Graeve has implemented a number of new RADIUS features for Captive Portal that will be implemented in a future beta version. For now, these features are available on test images available for download from http://inf.imelda.be/downloads/m0n0wall/.

Features currently implemented in the test images include:

You can utilize Captive Portal and its MAC pass-through functionality for rudimentary MAC address restrictions.

Figure 13.1. Example Network Diagram

This depicts the network layout we will have after configuring our DMZ interface.

Log into your m0n0wall's webGUI, and click "(assign)" next to Interfaces.

Click the on this page to add your third interface.

Now restart your m0n0wall for the changes to take affect.

After your m0n0wall restarts, log back into the webGUI. Under Interfaces, you will see OPT1. Click on it.

Check the box at the top to enable the interface, give it a more descriptive name (I'll call it "DMZ"), and set up the desired IP configuration. The IP subnet must be different from the LAN subnet.

The main purpose of a DMZ is to protect the LAN from the publicly-accessible Internet hosts on your network. This way if one of them were to be compromised, your LAN still has protection from the attacker. So if we don't block traffic from the DMZ to the LAN, the DMZ is basically useless.

First we will put in a firewall rule on the DMZ interface denying all traffic to the LAN while still permitting all traffic to the WAN. Click Firewall -> Rules, and click the at the bottom of the page.

Filling out this screen as shown below will permit all traffic out the DMZ interface to the internet, but prohibit all DMZ traffic from entering the LAN. It also only permits outbound traffic from the DMZ's IP subnet since only traffic from a source IP within your DMZ should come in on the DMZ interface (unless you have a routed DMZ, which would be strange). This prevents spoofed packets from leaving your DMZ.

Click Save after verifying your selections. Then click Apply Changes.

You probably have some services on your LAN that your DMZ hosts will need to access. In our sample network, we need to be able to reach DNS on the two LAN DNS servers, cvsup protocol to our LAN cvsup-mirror server, and NTP for time synchronization to the time server that resides on the cvsup-mirror server.

Always use specific protocols, ports, and hosts when permitting traffic from your DMZ to your LAN. Make sure nothing that isn't required can get through.

My DMZ interface firewall rules now look like the following after permitting the required services from DMZ to LAN.

Note that I added a rule to deny any traffic coming in on the DMZ interface destined for the LAN. This was not required because of the way we configured the allow rule, however I like to put it in there to make it very clear where the traffic from DMZ to LAN is getting dropped.

When entering your rules, remember they are processed in top down order, and rule processing stops at the first match. So if you had left the rule we added above as the top rule, it would drop packets from DMZ to LAN without getting to the permit rules you added. I recommend you design your rules similar to how I have, with drop DMZ to LAN as the second last line, and permit DMZ to any except LAN as the last line.

Now you need to determine whether you'll use inbound or 1:1 NAT. If you have multiple public IP's, use 1:1 NAT. If you have only a single public IP, you'll need to use inbound NAT. If you have multiple public IP's, but more DMZ hosts than public IP's, you can use inbound NAT, or a combination of 1:1 and inbound.

13.1.6.1. Using 1:1 NAT

For this scenario, we'll say we have a /27 public IP subnet. We'll say it's 2.0.0.0/27. m0n0wall's WAN interface has been assigned with IP 2.0.0.2. I will use 1:1 NAT to assign the public IP 2.0.0.3 to the DMZ mail server and 2.0.0.4 to the DMZ web server.

Go to the Firewall -> NAT screen and click the 1:1 tab. Click the . I will add two entries, one each for the mail server and web server.

After adding the rules, click Apply changes. You'll now see something like the following.

13.1.6.3. Using Inbound NAT

If you have only one public IP, or more need more publicly-accessible servers than you have public IP addresses, you'll need to use inbound NAT. Go to the NAT screen, and on the Inbound tab, click .

For this example, we will assume you have only one public IP, and it is the interface address of the WAN interface.

First, anything to the WAN IP to port 25 (SMTP) will go to the mail server in our DMZ.

Click Save, and click to add the inbound NAT rule for the HTTP server.

Click "Apply changes" and your configuration will be working. It should look like the following.

After you have your network set up as shown, and the interfaces and LAN IP assigned appropriately, log into the webGUI to begin the initial configuration.

First go to System -> General setup, and configure the hostname, domain, DNS servers, change the password, switch the webGUI to HTTPS, and set your time zone. Click Save, and reboot m0n0wall for the changes to take affect.

Log back into the webGUI and go to the Interfaces -> WAN page. For the example network, we'll assign the static IP 111.111.111.10/29, default gateway 111.111.111.9. Unless your WAN network is private IP's, check the "Block private networks" box. Click Save.

Click Interfaces -> OPT. Name the interface to your liking (for the example, we'll use Servers for the name). In the "Bridge with" box, select WAN. Click Save.

Go to the System -> Advanced page and check the "Enable filtering bridge" box. Click Save.

Go to the Firewall -> Rules screen.

13.3.5.4. Firewall Rules Completed

Everything should be working as desired now, as long as the servers are configured appropriately. Test that the configuration works as desired, including all inbound and outbound rules. Once you're satisfied with the testing results, your setup is complete.

First we need to make sure the PIX has 3DES enabled.

If the "VPN-3DES-AES" line above does not show "Enabled", you need to install the PIX 3DES key. This is now available free from Cisco here for all PIX firewalls (click 3DES/AES Encryption License). Do NOT use DES for a VPN if you want it to be cryptographically secure. DES is only slightly better than transmitting in clear text.

Next we'll see if any VPN configurations are in place on the PIX.

If you only see the default policy, there are no VPN's configured. This document cannot be followed verbatim if you have current VPN's (though you should be able to figure it out, just be careful not to break your existing VPN's with any duplicate names).

Allow IPSec connections to the PIX

Enable ISAKMP on the outside interface (where "outside" is the name of the internet-facing interface)

isakmp policy command on PIX

Now we need to configure the ISAKMP policy on the PIX. Enter the following commands in configure mode:

This policy uses pre-shared keys as authenticator, 3DES encryption, md5 hashing, group 2, and 86400 second lifetime.

Now we need to define the pre-shared key for this connection. (1.1.1.1 = public IP address of m0n0wall, qwertyuiop is the shared key, randomly generate something to use for your configuration)

Now we need to create an access list defining what traffic can cross this tunnel.

Define transform set for this connection called "monovpnset"

Define security association lifetime

Now to set up the actual connection, the crypto map "monovpnmap". (where 1.1.1.1 is the public IP address of the m0n0wall device)

These lines specify type of VPN (ipsec-isakmp), peer IP address (1.1.1.1), transform set to be used (monovpnset, defined above), and that packets matching the access list "monovpn" created above should traverse this VPN connection.

Last step is to tell the PIX to not use NAT on the packets using this VPN connection and route them instead.

First we'll see if anything is currently routed.

Look for "nat (interface) 0 ..." commands. The above means any traffic matching access list "no-nat" will routed, not translated. In this instance, we are adding to a current access list (if you use a DMZ, you likely have something similar to this set up).

If you do not have a "nat (interface) 0 ..." command in your "sh nat" output, you can use the above two lines to create a "no-nat" access list. You then have to apply it with the "nat (interface-name) 0 access-list no-nat" command (replacing "interface-name" with the name of your LAN interface).

Log into the m0n0wall web GUI, and under VPN, click IPSec.

If the "Enable IPSec" box is not checked, check it and click Save.

Click the + button to add a VPN tunnel. On the "Edit tunnel" screen, fill in as follows:

Log in to Sonicwall

Click VPN -> Configure

Add/Modify IPSec Security Association

Security Policy

Destination Networks

Select "Specify destination network below".

The following screenshot shows what this screen will look like.

Click Add New Network

You will get: Edit VPN Destination Network (Note: This is Popup window – enable Popup in your browser)

Click Update

Figure 14.2. Example of Sonicwall configuration

Configure m0n0wall IPsec Edit Tunnel screen as follows.

Click Save at the bottom of the page to complete the VPN configuration.

This example assumes version 10 of SafeNet SoftRemoteLT.

This example assumes version 10 of SafeNet SoftRemoteLT.

You can utilize Captive Portal and its MAC pass-through functionality for rudimentary MAC address restrictions.

First, set up your DHCP scope. At the bottom of the Services -> DHCP screen, add every authorized MAC address on your network, and check the "Deny unknown clients" box. This will prevent an unauthorized machine from getting an IP address from DHCP.

You can ensure certain MAC addresses can only use a certain IP by using static ARP.

To add a static ARP entry, use /exec.php to run the arp command.

arp -s 192.168.1.11 ab:cd:ef:12:34:56

To verify this addition, run 'arp -a' in exec.php and you'll see the following in the list.

? (192.168.1.11) at ab:cd:ef:12:34:56 on sis2 [ethernet]

This change will not survive a reboot. You need to put the arp -s command in your config.xml in <shellcmd>. See this FAQ entry for more information on hidden config.xml options

If any of the following applies to your setup, you should be fine without proxy ARP:

Using proxy ARP under these conditions will not achieve anything. If however you use static IP addresses or DHCP on WAN and don't have a routed subnet, adding proxy ARP entries for the additional addresses/ranges/subnets in the webGUI will make sure that m0n0wall responds to ARP queries for these addresses on the WAN interface.

Adding Proxy ARP when it is not required usually will not hurt anything, so when in doubt, add it!

Note that it is never necessary (and strongly discouraged) to use IP aliasing on the WAN interface (by means of ifconfig commands).

Now click Firewall -> Rules and click the on that screen. Add a rule like the following, replacing the made up IP 12.221.133.125 with the public IP of the remote system you wish to use to administer your m0n0wall, and 64.22.12.25 with the public IP of your m0n0wall.

This makes things a little trickier. You can't set the destination IP because it will change, and when it changes you would no longer be able to get to the webGUI. You can set the source to "any" rather than the WAN IP. Note that this will grant access to anything with an inbound NAT entry for the port (likely HTTPS), or anything behind a bridged interface with a public IP on that port. Unless you have multiple public IP's, this will not grant access to anything other than the webGUI. This does not grant that host access to HTTPS for anything on your LAN. Even if you do have multiple public IP's, opening HTTPS to a host you intend to allow to configure your firewall is likely of little to no concern.

If you are using, for example, 192.168.1.0/24 at one site, and the other site uses 10.0.0.0/24, 10.0.1.0/24, 10.0.2.0/24, and 10.0.3.0/24, you can summarize the 10.x.x.x site with 10.0.0.0/22. 10.0.0.0/22 includes 10.0.0.0-10.0.3.255.

You can set up one IPsec connection for each subnet you want to connect to on the remote side. If you have a large number of subnets on the remote side, it is recommended you number them so they're easily summarized so you don't have to set up a large number of connections.

Bring up a command prompt on your machine, type in 'ping 192.168.1.1' and press Enter.

A successful ping will look like the following.

C:\>ping 192.168.1.1

Pinging 192.168.1.1 with 32 bytes of data:

Reply from 192.168.1.1: bytes=32 time<1ms TTL=64
Reply from 192.168.1.1: bytes=32 time<1ms TTL=64
Reply from 192.168.1.1: bytes=32 time<1ms TTL=64
Reply from 192.168.1.1: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.1.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

An unsuccessful ping will look like this.

C:\>ping 192.168.1.1

Pinging 192.168.1.1 with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 192.168.1.1:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

See Cannot Access webGUI as if you cannot ping, you won't be able to get into the webGUI either.

Go to the Status -> Interfaces page and look under the WAN interface. It must show status as up, and have a valid IP address, subnet mask, and gateway.

If the status shows as "down", check for a link light. See No Link Light if you do not have a link light on your WAN NIC.

If you have a dynamic IP connection like DHCP, PPPoE, or anything but static, and show a 0.0.0.0 IP, you are not getting a lease from your ISP. Check your WAN configuration page to make sure the appropriate settings are entered correctly (like username/password if applicable, etc.).

If you see a WAN IP address on the Status -> Interfaces page, make note of it as you will use it in the next step.

On the Status -> Interfaces page, make note of the WAN IP address. On the client machine you are using, try to ping that IP address.

If the ping is not successful, check the default gateway IP address on the client machine. Run 'ipconfig/all' from a command prompt if using Windows to check this. It must be set to m0n0wall's LAN IP (192.168.1.1 by default).

On the Status -> Interfaces page, make note of m0n0wall's WAN default gateway IP. Try to ping it from your client machine.

If the pings time out, double check your WAN setup. If things fail at this stage, you most likely failed the earlier Check WAN IP step as well.

From the client machine, ping something on the Internet that responds to pings, like 216.135.66.19.

If this fails but all previous steps were successful, your ISP is not letting you out onto the Internet for some reason. At this point, you will need to contact your ISP's technical support. Your ISP could potentially be blocking pings though (not likely), so your pings could time out while your Internet connection still functions (mostly) properly.

Ping a DNS name that responds to pings from the client machine, like google.com.

You should see responses to your pings. If you receive a "could not find host" message, you have a DNS issue. See the Troubleshooting DNS section.

If all else fails and you need to determine exactly which rule is dropping the traffic, go to status.php on your m0n0wall to the "last 50 filter log entries" section. Find the log line applying to the traffic in question, and make note of the rule number. The rule number is denoted by an @ followed by a number, then a colon, then another number, for example @0:18. The 0 indicates the first group, and the 18 indicates rule number 18 in group 0.

Then go up to the output of "ipfstat -nio" and find the rule in question. Anything without a group number at the end of the rule is the 0 group. @1:1 would indicate the first rule with "group 100" at the end of the rule. @2:1 would be the first rule with "group 200" at the end of the rule, and so on. Finding the exact rule, since some rules are added by the back end of m0n0wall and not visible on the rules page, may make troubleshooting easier.

The first thing to check is whether you have any shared IRQ's. This seems to be the most common cause. If you have recently rebooted your m0n0wall, you should be able to see the boot messages under Diagnostics -> Logs, on the System tab. Otherwise you can go to /exec.php on your m0n0wall and run 'dmesg'. Look through the boot messages and make note of everything you see being shown with an IRQ. This includes your NIC's as well as other devices like serial and parallel ports, etc. An example of some dmesg output follows.

sis0: <NatSemi DP83815 10/100BaseTX> port 0xe000-0xe0ff mem 0xa0001000-0xa0001fff irq 11 at device 18.0 on pci0
sis1: <NatSemi DP83815 10/100BaseTX> port 0xe100-0xe1ff mem 0xa0002000-0xa0002fff irq 5 at device 19.0 on pci0
sis2: <NatSemi DP83815 10/100BaseTX> port 0xe200-0xe2ff mem 0xa0003000-0xa0003fff irq 9 at device 20.0 on pci0

The above example shows three NIC's with IRQ's 11, 5, and 9.

If you note any two devices using a single IRQ, you may need to try other PCI slots, if possible, remove unused cards (like sound cards), and disable unused devices in the BIOS (serial ports, parallel ports, etc.).

You might want to try resetting your BIOS configuration to factory defaults, and then disabling any Plug and Play OS settings. Also check that your BIOS is updated to the latest revision.

Use hardware diagnostic utilities to ensure your RAM and system in general are functioning properly. The Ultimate Boot CD has several utilities for testing CPU and memory.

Hardware overheating is another common cause. This issue has been noted on WRAP hardware especially when using miniPCI cards. It's also possible and has happened with any type of hardware.

If nothing else, it may just be hardware or a combination of hardware that doesn't play nicely with FreeBSD. You may want to try different NIC's or a different system. This especially seems to be a problem with some old AMD K5 and K6 systems, though some work fine.