SmallWall Handbook

SmallWall contains the following software components:

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

m0n0wall (http://m0n0.ch/wall/index.php) Copyright © 1004-2015 Manuel Kasper. All rights reserved.

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

This project 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.

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)

SmallWall is managed by Lee Sharp.

The following persons have contributed code:

Manuel Kapser (mk at neon1 dot net): m0n0wall

Andrew White (andywhite at gmail dot com>: L2TP code and many other patches

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

SmallWall is managed by Lee Sharp.

The following persons have contributed documentation to SmallWall:

Chris Buechler (m0n0wall at chrisbuechler dot com): Editor, of original m0n0wall documentation. Numerous contributions throughout.

Lee Sharp (lee at smallwall dot org): Editor, of current SmallWall documentation. Numerous rewrites and contributions throughout.

Shawn Giese (shawngiese at gmail dot com): Numerous contributions to the m0n0wall documentation.

Jim McBeath (monowall at j dot jimmc dot org): m0n0wall 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 SmallWall Developers' Handbook.

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

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

486 processor - Any 486 or higher processor is sufficient for SmallWall. 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.

128 MB of RAM - 128 MB RAM is the official suggested minimum. The CD version of SmallWall has been reported to work fine for some people with only 64 MB. When using the CompactFlash or hard drive versions of SmallWall, expect upgrades to fail with less than 128 MB. This is because SmallWall 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 SmallWall 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 SmallWall) 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.

ACPI - Advanced Configuration and Power Interface

Sometimes ACPI options can cause booting problems. If you have these, disabling it can help.

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

CompactFlash

At least an 16 MB CompactFlash card is required.

USB Stick (Thumb Drive)

At least an 16 MB USB stick can be used to boot SmallWall.

Hard Drive

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

CD and floppy/usb setup

Any IDE, SATA or SCSI (with supported controller) CD-ROM or DVD drive will work with SmallWwall. Some USB attached CD-ROMs will work, and others have problems. Also required for this setup is a 1.44 MB floppy drive with blank floppy disk or a USB stick 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

SmallWall can run the hard drive image from a Zip drive. Write the disk the same way you would write a hard drive.

Some Soekris devices are fully compatible with SmallWall. You will use the generic-pc-serial-xxx image. You will want a system with 128Mb or more ram. Others may work, but are not recommended.

Specifications

The 5500 series and the 6500 series should all be good choices.

Wireless Router Application Platform (WRAP)

PC Engines ALIX boards are fully compatible with SmallWall. Use the generic-pc-serial 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 SmallWall.

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 SmallWall 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 SmallWall. 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.

From Wyse Winterminals to Car PCs, a lot of these are in the used market, and if you can get 2 or more network cards in them, they will work.

Generally, support for these is quite good. Check for supported network cards, and you may have to work around boot problems, but they generally work quite well with amazing performance.

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 SmallWall. Cheap cards like those containing Realtek chipsets (FreeBSD rl driver) are very poor performers in comparison. If you are purchasing NIC's for your SmallWall 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. If you are looking at Atom motherboards, those with Intel chips are significantly better then the rt chips at the lower end.

For low throughput environments, like a low end 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 on a high speed bus (PCI-e) becomes much more important. With good Intel PCI-e gigabit nics on a solid computer, sustained transfers of 900 Mbps are possible.

Your CPU can be the bottleneck in your system. IPSEC can load the system, and 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, or a newer Atom CPU.

The stock SmallWall images will not use more than 512 MB RAM under most circumstances. You can install as much memory as you like, but even with all features enabled and heavy loads, you will not exhaust 1 gig.

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

The only times storage is accessed is at boot, when the configuration is being changed, and during firmware updates. At all other times, the hard drive can be set to "sleep" and it may not spin up for months at a time.

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. Flash storage (CF Card, USB stick, or DOM) 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 and PCI-e can transfer up to 1056 MBps, or about 8.25 Gbps.

If you need sustained gigabit throughput at wire speed, you will want a solid motherboard with PCI-e slots and PCI-e NIC's. (Or a board with embedded Intel nics on a PCI-e bus.

Currently all AC wireless cards and most N cards are incompatible with SmallWall. These require drivers that are only found in FreeBSD 10+, while SmallWall is on 8.4. They also require "hostap" support. They may be supported when SmallWall is on a newer version of FreeBSD.

The following list, to the best of our knowledge, is very old. Please report any findings to Lee Sharp.

Not all wireless cards support hostap mode! (i.e. can function as an access point) This is a limitation of the hardware itself, not SmallWall 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 SmallWall on a standard PC with a CD-ROM drive and a floppy drive or USB stick. A hard disk is not required. SmallWall will boot from the CD and run from memory. The floppy is used only to store your SmallWall configuration. If you want to run SmallWall on a standard PC with a hard disk rather than a CD, follow the directions in the next section.

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

You can run SmallWall 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. SmallWall 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 SmallWall, 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.

This is commonly seen in networks with VOIP phones on a separate vlan, routed by the phone server. A static route is created to tell SmallWall that the path to that network is through the phone server.

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 SmallWall version. (not shown on CD-ROM only systems).

Figure 4.2. The Firmware screen

The options on the Advanced System page are intended for use by advanced users only. Misconfiguration here can hang the firewall.

4.3.4.1. IPv6

IPv6 support was first included in the 1.3x release. The base for this was actually contributed by Michael Hanselmann way back in 2005, and with some modifications to reflect the changes in SmallWall since then, as well as a few fixes/ improvements.

IPv6 support must be explicitly enabled on the System: General 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

While 1.3b12 was the first release with IPv6 support, it has still not been widely used or tested, so bugs in the implementation are likely. (And not just in the firewall) As always, please post on 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 SmallWall's LAN subnet from your upstream router - there's no NAT for IPv6 in SmallWall (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, 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 SmallWall's LAN Ethernet interface to resolve/proxy all DNS queries on your LAN network. When the SmallWall 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 SmallWall.

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 SmallWall 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 SmallWall.

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 SmallWall as their DNS server.

DNS Host Name Registration

If your SmallWall 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 127.0.0.1. 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.

You must have signed up with a dynamic DNS provider to 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 SmallWall. If not, check Diagnostics: System logs for information on why it failed.

The "Custom" option is handy when you want to use an unlisted Dynamic DNS service. (For example, no-ip.org which the author uses.) It can require some work to actually find the server name, however.

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 SmallWall interface which also cannot be in the range. Also leave room for static devices such as printers, servers, and VPN ranges.

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 clients, you can 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.

Alternatively, you can find your client in the DHCP Leases page and click the plus sign to auto-populate this form with the MAC address.

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 SmallWall 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 SmallWall 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.

Maximum Concurrent Connections - This is how many people can be logging in at the same time, not how many times one person can log in. This rarely needs to be changed.

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.

Redirection URL - by default, after logging in, SmallWall sends you to the page you originally requested. But you can enter a web page here, such as a page on your business website that says "Thank you for drinking Tweak Bros. Coffee!" SmallWall will then send your browser to that page instead of your original destination.

Concurrent User Logins - This allows a single user name to log in more than once. Or not. If set, login in bumps the last user off.

MAC Filtering - By default, SmallWall makes sure the MAC address does not change during the log in period. (Preventing someone from stealing a logged in IP address) If you have access points that change the MAC address, however, this can be a problem. This allows you to disable that feature.

Per-user Bandwidth Restriction - A way to limit user bandwidth. (Requires Traffic Shaper to be enabled) With RADIUS, it can allow tiered access.

Authentication - This is where you set how the SmallWall captive portal authenticates.

Primary (and secondary) RADIUS server - Enter the IP address and port of the RADIUS server which users of the captive portal have to authenticate against. 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.

Reauthentication - This will allow a users time to end before the normal timeout period set above. It can also work with accounting if you have time or bandwidth limits.

RADIUS MAC Authentication - SmallWall will use the MAC address as the username, and pass the submitted password to the RADIUS server. Note the warning in MAC filtering above for situations where this may not work.

RADIUS Options - Several additional options for extended features or to work with non-standard RADIUS implementations. (Like Cisco)

HTTPS Options - That allows the username and password form to submit over https instead of http. You can specify the server name and upload a certificate here, and it will work with most browsers.

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). The uploaded page can use assets like images and css pages, which are uploaded under the File Manager tab. The default page uses no additional files, but it does use characters in modern extend fonts. The free Symbola Font fully supports these extended characters.

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

Status Page Contents - A page that will allow local users to change passwords. It does not work for RADIUS users. The uploaded page can use assets like images and css pages, which are uploaded under the File Manager tab.

Logout Page Contents - The logout popup page referenced above. The uploaded page can use assets like images and css pages, which are uploaded under the File Manager tab.

Pass Through MAC - This setting acts as a sort of "pre-authentication list" to allow users access without logging in. However, it only triggers from within captive portal.

Allowed IP Addresses - The IP addresses listed here bypass captive portal completely. (All traffic, in whatever order) When combined with a static DHCP assignment, it makes the portal totally transparent to specific users, without needed to configure their computers with a static IP.

Users - If you are using Local Authentication, this is the list of users.

Vouchers - You can enable a voucher system here to hand out one time use access. It can work in conjunction with other authentication methods.

File Manager - If any of your custom captive portal pages need additional files, they are loaded here. They can be of any type, but there are size limitations. They are loaded to the same directory as the custom portal page.

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 SmallWall 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.

SmallWall has a built in scheduler to allow timed jobs to run. It can be set for one time only, or aon a repeating schedule in as short a time as every 1 minute. It can be logged, or not.

This is the standard business class point to point VPN for connecting networks together over the Internet. It not only works from SmallWall firewall to SmallWall firewall, but has been proven to work with Cisco, Fortigate, Watchguard, and Sonicwall as well. This is not surprising, as it is designed as a standard to support interoperability. However, to insure maximum interoperability, SmallWall also supports encryption standards that have been shown to be vulnerable.

In the Tunnels tab, you can globally enable or disable all tunnels. You can create a new tunnel with the + icon.

This is the current best practice for standards based, on demand, VPN tunnels. It is one of only two methods supported by Chromebooks.

PPTP is the original on demand VPN protocol. Microsoft introduced the Point-to-Point-Tunneling-Protocol (PPTP) with Windows 95. (It was called "Dial-Up-Networking) The initial implementation (20 years ago) had essentially no security. Since then, it has improved, but it is still not considered "secure" anymore as there are known vulnerabilities in the more secure algorithms as well. Additionally, it can easily be misconfiguration to connect with no encryption, even when it is available on both sides.

On the other hand, the client is in everything! (But Chromebooks) Any system you are likely to find yourself on will have a pptp client available. This ubiquity is why it is still very useful.

Figure 4.3. The System Status screen

Along with being the log in landing page, you can see the key information of your firewall. Specifically, you can see that your memory is not full, your CPU is not loaded, and your uptime was much longer then you thought. There is also a space for a bit of documentation, like the IP address of that access point you can never remember.

Figure 4.4. 

This is where you can force a new IP address (if DHCP) or a new connection (if PPPoE) if needed. Also check for errors and duplex mismatches. And, of course, the missing link.

Figure 4.5. The Traffic Graph screen

The traffic screen allows you to select an interface, and view real time throughput graphs on that interface.

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 SmallWall device is actually not shown on the menu. You simply add "/status.php" after the ip address of your SmallWall 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 SmallWall 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 SmallWall and to not block the traffic in any intervening firewalls.

It is recommended that you log your SmallWall 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 have 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. Clicking on the plus button to the right of the entry will allow you to make a static IP address assignment for that MAC address.

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.4. 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 SmallWall - 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 SmallWall

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. SmallWall 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 SmallWall. 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 SmallWall. 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 SmallWall device. On busy systems, this page can take a while to build.

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 SmallWall 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 SmallWall, 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 SmallWall 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 SmallWall, 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 SmallWall and FreeBSD in general, rebooting probably isn't going to fix any problems you are having. It will also erase the logs, so make sure you have any information you need from them first. But it is worth a shot in many circumstances.

Unlike so many systems, rebooting isn't a suggested maintenance procedure on SmallWall. 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 SmallWall 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 SmallWall 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.

SmallWall provides three means of remote access VPN, PPTP, L2TPP and Mobile IPsec. SmallWall's mobile IPsec functionality has some serious limitations that hinder its practicality for many deployments.

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

IPsec's Tunnel mode is supported on SmallWall devices. This mode allows secured communication between entire subnets. When the packet leaves 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 SmallWall 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 only for 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.

It is possible to configure a Dead Peer Detection (DPD) interval in seconds with a default of seconds. This allows the SmallWall device to detect if a tunnel is still being used. If the DPD interval has passed and the SmallWall 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.

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.

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 SmallWall device and not be blocked by any intervening firewalls. This feature can be turned on or off for each IPsec connection.

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.

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

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 SmallWall to be placed behind another firewall.

Figure 8.1. Example: SmallWall 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.

In some cases, most for those people who are granting L2TP 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 L2TP 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 L2TP 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 L2TP 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 L2TP “Server Address” as this is the gateway/interface for the L2TP 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).

Using this with a static DHCP assignment can give specified users limited or full access to the Internet and other sections of your network.

Below are some of the Secure Authentication options that can be configured for use with the 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 SmallWall 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 SmallWall'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 SmallWall 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 SmallWall 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 the binary C program voucher.c, that is compiled and added into the SmallWall image, and can be modified to increase the usability and security.

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

Each voucher roll has the following parameters.

There used to be quite a lot of third party documentation on m0n0wall captive portal, but it seems to gave aged off the internet. If you find any, let us know!

Jonathan De Graeve implemented a number of RADIUS features for Captive Portal to give it WISPr functionality. Aside from that, these listed features are supported.

Features currently implemented include:

Figure 13.1. Example Network Diagram

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

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

Click the on this page to add your third interface.

Now restart your SmallWall for the changes to take affect.

After your SmallWall 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. SmallWall'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 SmallWall 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 for all PIX firewalls. 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 SmallWall, 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 SmallWall 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 SmallWall 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 SmallWall 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.

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

There are now many Next Generation Firewalls available. Some are referred to as "kitchen sync applications" since they include everything but the kitchen sync. This can make setup and management easy. But it also makes hacking easy. Only one layer of security for your access control, VPN, web filtering, e-mail filtering and virus scanning... Fortinet has a wonderful example of this ecosystem with the integrated firewall, application filter, endpoint protecting, and sandbox solutions. All using the same virus filters.

Verses separate and best of breed applications, all with separate credentials. This means a failure of one, is limited to only that one part. It also means that development can focus on it's core competency, and not have to worry about learning how to transparently intercept https...

Have you ever noticed that every time you update your Android apps, the entire phone gets slower? Or how if you park a 2004 Mini Cooper next to one 10 years newer, how much bigger the new one is? (Or a 10 year span of the BMW 3 series will work) Bloat and feature creep is a real problem. It increases hardware requirements, and increases the potential attack vectors. So that as you keep applying security updates, your system gets slower and slower...

So, a nicer looking GUI is fine, but not if it works on less older web browsers, or takes longer to render on the older tablet. Do we really want to add a new feature that really has nothing to do with a firewall, and causes the image to double in size? There are a lot of people happily running m0n0wall on small, embedded systems. They should be able to upgrade SmallWall without panic. You should only be forced to upgrade your hardware when you need more hardware, not just because your software got fat.

This goes back to the "Do one thing and do it well" point above. This is a firewall, and not a file and print server. It should only include components that have to do with routing and security. And the format should encourage secure principals in the setup. This may mean an extra line or to on a configuration page telling you why setting up PTP with no encryption is not a good idea.

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 SmallWall 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 SmallWall, and 64.22.12.25 with the public IP of your SmallWall.

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' (or approiate IP address) 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 SmallWall's LAN IP (192.168.1.1 by default).

On the Status -> Interfaces page, make note of SmallWall'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 SmallWall 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 SmallWall 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 SmallWall, 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 SmallWall 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. Also, it is not uncommon that the firewall is left alone for years and it is only when you see a problem that you notice that the fan gummed up weeks ago.

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.