v2008 Coursebook

Coursebook V2008
SmoothWall
Technical Training
For SmoothWall Version 2008 products
Version 1.0
Copyright SmoothWall Limited 2008 Page 1 of 110

Coursebook V2008
Table of Contents
Welcome to the SmoothWall V2008 Course...............................................................................................................7
Figure 1: Smoothwall GPL v0.99.................................................................................................................7
What is new in version 2008.............................................................................................................................8
About this book.................................................................................................................................................8
Glossary:................................................................................................................................................................9
Chapter 1: Network Basics...................................................................................................................................11
MAC Addresses – Media Access Control........................................................................................................11
Figure 2: Example MAC address...............................................................................................................11
Figure 3: Replacing network cards.............................................................................................................11
DNS – Domain Name Server..........................................................................................................................12
Figure 4: WINS and DNS name resolution................................................................................................12
WINS – Windows Internet Name Server.........................................................................................................13
DHCP – Dynamic Host Configuration Protocol...............................................................................................13
Figure 5: Client resolving hostnames.........................................................................................................13
Default Gateway and Routing.........................................................................................................................13
Figure 6: Default gateway illustration.........................................................................................................14
Figure 7: Routing from A to B.....................................................................................................................14
Chapter 2: Hardware.................................................................................................................................................15
Linux and Drivers............................................................................................................................................15
Choosing the Hardware..................................................................................................................................15
SmoothGuard 1000-UTM appliance...............................................................................................................15
Hardware RAID vs Fake Raid vs Software RAID............................................................................................16
Serial Attached SCSI (SAS)............................................................................................................................16
SmoothWall Service Pack CD.........................................................................................................................16
Other Hardware Specific Issues...........................................................................................................................16
Chipsets..........................................................................................................................................................16
64 bit Capable CPUs......................................................................................................................................16
PCI Network Cards.........................................................................................................................................17
Multi NIC cards...............................................................................................................................................17
USB Network adapters ..................................................................................................................................17
Wireless Network Cards ................................................................................................................................17
Figure 8: Wireless access point attached to the SmoothWall....................................................................17
VMWare Drivers..............................................................................................................................................17
USB Devices...................................................................................................................................................17
ADSL Modems................................................................................................................................................18
Figure 9: SmoothWall Firewall/NAT setup examples.................................................................................18
Multiple External Connections........................................................................................................................19
Chapter 3: Installation..........................................................................................................................................20
Figure 10: The SmoothWall install boot screen..........................................................................................20
Activating advanced install options.................................................................................................................21
Figure 11: Swap and RAM disk options.....................................................................................................21
Multiple Ways of Installing...............................................................................................................................21
Installing modules...........................................................................................................................................21
Manuals..........................................................................................................................................................21
Chapter 4: Setup Options...............................................................................................................................23
Figure 12: The setup menu........................................................................................................................23
Restore Configuration.....................................................................................................................................23
Figure 13: Removing the active switch file.................................................................................................24
Keyboard Mapping..........................................................................................................................................24
Hostname.......................................................................................................................................................24
Networking......................................................................................................................................................24
Figure 14: Disconnecting the external connection from the command line................................................24
Network Cards................................................................................................................................................24
Address Settings.............................................................................................................................................25
DNS and Default Gateway .............................................................................................................................25

Coursebook V2008
Figure 15: Using the setup program to access the internet........................................................................25
Figure 16: Using the interfaces page in the Web GUI ...............................................................................26
Default interface..............................................................................................................................................26
VLAN..............................................................................................................................................................26
Diagnostics.....................................................................................................................................................26
Hardware Options...........................................................................................................................................27
Figure 17: Disabling APIC during initial boot..............................................................................................27
Resetting Admin Access.................................................................................................................................27
Serial Console................................................................................................................................................27
Web Proxy......................................................................................................................................................27
ADSL Configuration........................................................................................................................................27
ISDN Configuration.........................................................................................................................................28
Resetting System Passwords.........................................................................................................................28
Figure 18: Booting in single user mode – AF, SG and NG vs CF...............................................................28
Chapter 5: Installation/Migration Best Practises Flowchart.......................................................................................29
Preliminaries...................................................................................................................................................29
Installation and Initial Configuration................................................................................................................29
Final Configuration and Sanity Check.............................................................................................................30
Figure 19: Restoring settings using the Web interface...............................................................................30
Final Touches..................................................................................................................................................30
A few words about sanity checking.................................................................................................................31
Chapter 6: Networking.........................................................................................................................................32
Filtering Section:.............................................................................................................................................32
Figure 20: Zone bridging and bidirectional rules........................................................................................32
Routing Section:.............................................................................................................................................33
Figure 21: Primary and secondary connections.........................................................................................34
Interfaces Section:..........................................................................................................................................34
Figure 22: DNS Settings on SmoothWall Firewall products.......................................................................35
Figure 23: Dropping direct traffic................................................................................................................36
Figure 24: External aliases........................................................................................................................36
A word about DMZ..........................................................................................................................................37
Hosting Tips and Tricks...................................................................................................................................37
Figure 25: Load balancing examples.........................................................................................................38
Figure 26: Load balancing outgoing traffic – Failover configured...............................................................39
Figure 27: Load balancing outgoing traffic – failover in place....................................................................40
Firewall Section:.............................................................................................................................................40
Figure 28: Transparent and NAT firewalling...............................................................................................41
Figure 29: Source mapping........................................................................................................................42
Outgoing section:............................................................................................................................................42
Figure 30: Outgoing rules..........................................................................................................................43
Traffic Section:................................................................................................................................................43
Chapter 7: Network services.....................................................................................................................................44
Authentication Section:...................................................................................................................................44
Proxies Section:..............................................................................................................................................44
SNMP Section:................................................................................................................................................44
IDS Section:....................................................................................................................................................45
DHCP Section:................................................................................................................................................45
Chapter 8: Main........................................................................................................................................................46
Main Section:..................................................................................................................................................46
Dashboard......................................................................................................................................................46
About Section:................................................................................................................................................46
Chapter 9: Information..............................................................................................................................................47
Reports Section:.............................................................................................................................................47
Figure 31: System load average................................................................................................................47
Alerts Section:.................................................................................................................................................48
Realtime Logs Section:...................................................................................................................................48
Figure 32: Realtime traffic graphs..............................................................................................................48
Logs Section:..................................................................................................................................................49

Coursebook V2008
Settings section:.............................................................................................................................................50
Figure 33: SMS gateway settings..............................................................................................................51
Chapter 10: System..................................................................................................................................................52
Maintenance Section:.....................................................................................................................................52
Figure 34: Replication and archiving..........................................................................................................53
Preferences Section........................................................................................................................................54
Administration Section:...................................................................................................................................55
Figure 35: Hardware failover......................................................................................................................57
Diagnostics Section:.......................................................................................................................................57
Chapter 11: Command line tools...............................................................................................................................59
Network Related Tools....................................................................................................................................59
SmoothWall file system overview....................................................................................................................60
Figure 36: CHROOT environments............................................................................................................61
The Way it all works........................................................................................................................................61
Chapter 12: Authentication........................................................................................................................................62
Directories and LDAP...........................................................................................................................................62
Connecting to Microsoft Active Directory........................................................................................................62
Figure 37: Typical Active Directory connection settings.............................................................................63
Figure 38: Advanced Active Directory connection settings.........................................................................63
Figure 39: Windows 2000 account properties............................................................................................64
Connecting to Novell eDirectory.....................................................................................................................64
Figure 40: Typical Novel eDirectory connection settings............................................................................64
Figure 41: Advanced Novell eDirectory connection settings......................................................................65
Connecting to Open LDAP..............................................................................................................................65
Figure 42: Typical OpenLDAP connection settings....................................................................................65
Figure 43: Advanced OpenLDAP connection settings...............................................................................66
Username syntax and considerations.............................................................................................................66
Chapter 13: SmoothTunnel VPN...............................................................................................................................68
About NAT......................................................................................................................................................68
NAT-Traversal.................................................................................................................................................68
IPSEC Helpers................................................................................................................................................68
IPSEC Ports and Protocols:............................................................................................................................69
SmoothWall VPN............................................................................................................................................69
Authenticating an IPSEC Connection.............................................................................................................69
Third-party Signed Certificates.......................................................................................................................70
Other Identification Factors.............................................................................................................................70
Certificates Examined.....................................................................................................................................70
RSA Encryption Basics...................................................................................................................................70
Certificate Authorities .....................................................................................................................................70
Figure 44: CA certificates...........................................................................................................................71
Certificates .....................................................................................................................................................71
Figure 45: Certificate Subject.....................................................................................................................71
Certificate ID type and value(Alternative Subject)...........................................................................................72
Figure 46: Certificate ID type and value (Alternate Name).........................................................................72
Figure 47: Certificate information...............................................................................................................72
Creating and Using Certificates on the SmoothWall.......................................................................................72
Figure 48: No crl found or crl update overdue ...........................................................................................73
Setting up Tunnels..........................................................................................................................................73
Planning and Preparing..................................................................................................................................74
Implementation...............................................................................................................................................74
Dynamic IP addresses....................................................................................................................................74
Figure 49: Tunnel setup with one peer at dynamic IP address or one peer behind NAT............................75
Figure 50: Tunnel setup with both SmoothWalls on dynamic IP.................................................................75
NAT.................................................................................................................................................................76
L2TP and IPSEC Road Warriors and NAT......................................................................................................76
Figure 51: L2TP Limitations.......................................................................................................................77
Issues when Renegotiating the Connections..................................................................................................77
Troubleshooting IPSEC Connections..............................................................................................................77

Coursebook V2008
Understanding the IPSEC Logs......................................................................................................................78
Error Messages and what they signify............................................................................................................78
IPSEC Log example........................................................................................................................................79
L2TP logging...................................................................................................................................................79
Other considerations:......................................................................................................................................79
OpenVPN Setup..................................................................................................................................................80
User authentication for OpenVPN users.........................................................................................................80
Client setup.....................................................................................................................................................80
Connecting to multiple SmoothWall systems..................................................................................................80
OpenVPN connection ports............................................................................................................................81
OpenVPN client restrictions............................................................................................................................81
OpenVPN logging...........................................................................................................................................81
Chapter 14: SmoothZap............................................................................................................................................82
Figure 52: External SMTP clients...............................................................................................................83
A word about SMTP........................................................................................................................................83
A word about mailshell....................................................................................................................................83
Managing the SMTP queue............................................................................................................................84
SMTP Logging................................................................................................................................................84
Troubleshooting tips........................................................................................................................................84
Chapter 15 – Guardian.............................................................................................................................................85
Configuring the Proxy..........................................................................................................................................86
Service Section...............................................................................................................................................86
Web filter section............................................................................................................................................87
Logging options section..................................................................................................................................87
Web proxy section..........................................................................................................................................87
Web proxy failover section..............................................................................................................................88
Automatic configuration script section.............................................................................................................88
Final touches and proxy test................................................................................................................................88
Figure 53: Illustration of service listing.......................................................................................................89
Figure 54: Web proxy service logs.............................................................................................................89
Figure 55: Web proxy log viewer................................................................................................................89
Generic Proxy Notes............................................................................................................................................89
Do not proxy the proxy:...................................................................................................................................90
Figure 56: Internet Explorer 7 Do not proxy for setting..............................................................................90
Exclude internal servers:.................................................................................................................................90
Proxy compatibility:.........................................................................................................................................91
Managing direct web access...........................................................................................................................91
Troubleshooting proxy issues..............................................................................................................................91
Web filter configuration........................................................................................................................................92
Preparing Guardian..............................................................................................................................................92
Understanding filters............................................................................................................................................92
Figure 57: Guardian categories and filters.................................................................................................93
Figure 58: Content blocking mechanics.....................................................................................................94
Building the filters............................................................................................................................................94
Creating and using the custom categories...........................................................................................................95
Creating a Content and URL filtering custom category:..................................................................................96
Creating a Custom File Security filter:.............................................................................................................96
Time rules.......................................................................................................................................................97
Creating filter policies...........................................................................................................................................97
The first policy.................................................................................................................................................98
Testing and Refining Filter Settings......................................................................................................................99
Alternative Testing Procedure..............................................................................................................................99
Tips on Content Filtering Level............................................................................................................................99
Authentication Methods.....................................................................................................................................100
Recommended authentication methods........................................................................................................101
Troubleshooting.................................................................................................................................................101
Figure 59: Example block reasons ..........................................................................................................102
Giving Guardian the reboot treatment...........................................................................................................102

Coursebook V2008
Web filter system log errors..........................................................................................................................103
A few tips...........................................................................................................................................................103
Monitor the log partition space......................................................................................................................103
Other things to remember.............................................................................................................................103
Back to the network – getting the browsers to use the filter...............................................................................104
Transparent proxy.........................................................................................................................................104
Figure 60: Transparent vs Non Transparent proxying..............................................................................105
Specific Browser issues................................................................................................................................105
Bypassing the filter and proxy.......................................................................................................................105
Automatic proxy detection.............................................................................................................................106
Chapter 16: SmoothTraffic......................................................................................................................................107
Traffic Schemes............................................................................................................................................107
New in SmoothTraffic....................................................................................................................................107
Figure 61: Diffserv marking in SmoothTraffic...........................................................................................108
General Notes about SmoothTraffic..............................................................................................................108
Figure 62: The built-in traffic rules............................................................................................................109
Looking ahead at upcoming SmoothWall products............................................................................................110
Feature pack releases...................................................................................................................................110
User portal....................................................................................................................................................110
IMSpector enhancements.............................................................................................................................110
Ajax...............................................................................................................................................................110

Coursebook V2008
Welcome to the SmoothWall V2008 Course

Welcome to the SmoothWall V2008 course. Whether you have been handed this coursebook when
attending a course with SmoothWall or using this book as a self study guide, the material and examples
within should help you become even more proficient and confident in recommending, installing,
configuring and managing SmoothWall products for your company or customers.
Since the beginning of SmoothWall, usability has been our primary goal. When the initial SmoothWall
GPL project started, ADSL was still not commonly available so options for multiple computers to share
an internet connection was limited as most internet connections were still using an analogue modem.
SmoothWall GPL firewall was an answer to that problem. With it, one could install and configure a NAT
firewall on an old PC and plug the modem into it and use it as an internet gateway for the entire home
network.
Figure 1: Smoothwall GPL v0.99.
The project immediately became popular and it was easy to see that the software filled a gap that was not
being adequately filled by existing products like the Internet Connection Sharing in Windows products.
Another “hit” for the SmoothWall style was the interface. SmoothWall tried hard to make the interface as
smooth as possible and SmoothWall also stayed with the TCPIP conventions as much as possible. While
other gateway products from varying companies have a tendency to reinvent all networking terms in order
to be different from their competitors, SmoothWall stays with the TCPIP conventions and terms as much
as possible. A port forward is called a port forward on SmoothWall products – not “One to One NAT”,
“Internet service” or “Preferred Ports” - we try to stay close to the correct terms in order to avoid
confusion and allow anyone with TCPIP knowledge to understand what is going on when configuring the
SmoothWall.
As the versions have passed us by the SmoothWall products have evolved quite a bit. End user and

Coursebook V2008
reseller comments have been instrumental in adding new features and new or changed services on the
internet has also affected the features offered on the SmoothWall products.
This latest version 2008 changes a few things about the interface. The three tiered menu system is still in
place but now it can be accessed via a drop down menu system – the previous navigation method is still
available as a setting in the user preferences option. With more features and options the interface needed a
minor workover so some areas have moved about a bit – furthermore we have tried to simplify the
interface by moving some options into an “Advanced” section on some configuration pages. The proxy
configuration page was getting quite large as it was displaying a huge amount of configurable options –
most of these options were not in common use so they were moved into an advanced section, accessible
by pressing the advanced button on the proxy configuration page – so if you cannot find an option in the
interface make sure to click any advanced button in that section to reveal options not readily accessible.
SmoothWall has evolved quite a bit since the initial versions and we are happy and grateful that so many
customers and resellers are following our progress and keep buying SmoothWall software – we must be
doing something right :)
What is new in version 2008

As always a new version brings some new and improved features to the SmoothWall products. The
interface and almost all areas has been revised and improved. The user interface has also been revamped
and a drop down menu system has been introduced. The three tier menu system is still available but needs
to be selected in the system – preferences – user interface section. The main new features are:
IM Proxy: Another open source project started by a SmoothWall employee has found it's way into our
commercial product. IMSpector is an instant messenger proxy that can log IM conversation for various
messenger applications and can replace swear words in the conversations passing through the proxy.
The main use of IMSpector is to be able to log IM conversations, not block them. SmoothWall is of the
opinion that blocking instant messenger applications will only make people seek other ways to do the
same thing but logging the conversations will hopefully help in sanitising use of instant messenger
applications in a company network.
OpenVPN SSL: In addition to the L2TP connections that have been supported since version 3
SmoothWall has now incorporated the OpenVPN SSL software in the VPN section. The OpenVPN
system will allow for connections in situations where L2TP would not be appropriate like in the case
where multiple clients are connecting from the same IP address.
Port Groups: All the port definitions has been collected in groups. The groups are editable and new
groups can be added. This greatly simplifies managing port forwards in situations with multiple servers
and services. The port groups can be used in all areas requiring port information.
Dashboard: The initial page now has a dashboard section that updates crucial system information in real
time.
Database logging: All web and mail filter logs are now sent to a database to help speed up reports. Logs
can be sent to a central SmoothWall for reporting purposes.
About this book

The main focus of this book are SmoothWall products, how they work and how they are best managed.
Network concepts will be revisited in the beginning of the course, just to refresh our network knowledge
and establish common network terminology. The points made in the network refresh section may seem

Coursebook V2008
superfluous to experienced network engineers but there is a purpose in selecting those specific areas. All
the subjects examined in the small networking section are critical points and it is very important to
understand the implications of those points when troubleshooting and diagnosing network issues – not
just when dealing with SmoothWall products.
This coursebook has been authored for use both on the two day reseller course and the three day
SmoothWall certification course as well as for use in self study. The two day course is meant mainly for
existing resellers and customers with prior knowledge of SmoothWall products. The three day course is
meant for new resellers and customers and includes the third day for setting up test scenarios and
completing an online examination in order to gain the certification.
The course is considered to be an advanced course. This book is not meant as a substitute for the manuals
and admin guides accompanying the software – it is meant as an additional resource. Our objective here is
to teach in-depth knowledge of the workings of the SmoothWall products and give you an overview of
functionality so you will quickly be able to figure out how to implement SmoothWall products in specific
customer situations and be able to tailor the best product combination to your customers needs.
Glossary:
Version 3 Products: Corporate Server 3, Corporate Guardian 3 and School Guardian 3 and all modules
that can be installed on Version 3 platforms.
Version 4 Products: Corporate Firewall 4, Advanced Firewall, Corporate Guardian 4, School Guardian 4,
Corporate Guardian 5 and all modules that can be installed on Version 4 platforms.
Version 5 Products: Corporate Firewall 5, Advanced Firewall 2, Corporate Guardian 6, School Guardian
5 and all modules that can be installed on Version 5 platforms.
Version 2008 Products: Network Guardian 2008, Advanced Firewall 2008, Corporate Firewall 2008 and
School Guardian 2008 as well as all modules available for the V2008 platform.
SmoothGuard UTM-1000: The SmoothWall appliance. A 7 interfaces, Core 2 Duo based platform with
1 GB RAM.
Primary connection: Primary connections are defined on the SmoothWall as any connection using a
connectivity profile.
Secondary connection: Secondary connections are defined as external connections NOT using a
connectivity profile. Secondary connections are static IP, network card based connections only.
Connection failover: The process of switching between connectivity profiles in case a profile fails.
Hardware failover: The process of switching to another hardware box in case the hardware fails.
Road Warrior: A term used in conjunction with VPN. The term covers any connection profile where the
peer IP address is unknown.
Zone Bridging: A term used to cover setting up access between internal and/or VPN networks or clients.
Internal interface: Any interface configured in the setup program or in the interfaces page in the
networking – interfaces section.
External interface: Any interface configured in the connectivity or secondary connections section.
Default interface: The default interface is the interface all access rules are applied to. This is the only
interface that can be used to access the SmoothWall web interface initially.

Coursebook V2008
Private IP Ranges: Private IP ranges cannot be used on the internet. They have been reserved for private
networks and should always be used when accessing the internet through a NAT device. The following
ranges are available:
10.0.0.0/255.0.0.0 A huge range with more than enough room for anyone.
172.16.0.0/255.240.0.0 Also a large range, not used that often.
192.168.0.0/255.255.0.0 Probably the range used most often.
Supernetting: The term covers enlarging a network in order to either get access to more host addresses or
allow for multiple subnets to be routed with one routing entry.
For example 192.168.0.0/255.255.254.0 encompasses 192.168.0.0/255.255.255.0 and
192.168.1.0/255.255.255.0.

Coursebook V2008
Chapter 1: Network Basics

Before we begin talking about SmoothWall products, we would like to recap some network basics – this
is meant as a reminder, a quick lookup guide and also serves to establish some of the network
terminology that we will be using throughout this course. Another reason is to identify areas of specific
interest when setting up the SmoothWall system.
MAC Addresses – Media Access Control

A MAC address is the “real” address of any network card on the data link layer of the OSI model. On
each subnet, an IP address is associated with the MAC address using ARP. Each network card has a
unique MAC address.
Figure 2: Example MAC address
MAC – Media Access Control

00:03:B2:A4:CC:78
ARP – Address Resolution Protocol

ARP is a protocol that resolves IP addresses to MAC addresses. It is a bit like DNS in that it resolves
MAC addresses to IP addresses and vice versa, whereas DNS resolved hostnames to IP addresses.
ARP is only used on the subnet the network card is connected to. When a computer tries to send a packet
to an IP address it has not contacted before, it sends out a broadcast message, asking for the MAC address
of the computer that responds to the IP address the packet is for. The target computer will respond to the
ARP broadcast with the MAC address of the network card. Once the MAC address of a specific IP is
known, the transmissions can start.
Figure 3: Replacing network cards
Old NIC arp entry

#> arp -a
192.168.1.1 ether 00:03:B2:A4:CC:78
New replacement NIC, new MAC address.

#> arp -a
192.168.1.1 ether 00:03:B2:C5:55:D8
Tip: When replacing network cards in existing computers or moving IP addresses to new
network cards, it's always a good idea to power cycle or reset any routers or switches the

Coursebook V2008
network card is attached to. Routers and some switches have mechanisms for caching MAC addresses
and it can take a couple of minutes before it clears the cache and notices the new MAC address.
ARP resolution can cause a lot of apparently strange network issues. Whenever a system is using an IP
that have been in use before on a network there is a chance that devices or hosts on the network have still
got the MAC address cached of the previous device. A typical example is the scenario where a new
computer has been purchased to replace the SmoothWall. The new computer is given the same IP address
as the old computer and is switched. Immediately, the entire network will loose internet access and the
capability to access the new computer, even though it's on the same IP address as the old installation.
Clearing the ARP cache, or waiting 5 to 10 minutes for the ARP broadcasts to resolve this, is then needed.
DNS – Domain Name Server

Domain name servers are the directories of the internet. Ever since Windows 2000 was released, they
have also become a necessity in Windows domains, replacing the old WINS name resolution system.
Figure 4: WINS and DNS name resolution
WINS: WS0 1 DNS: ws0 1.mydo main.lo cal
As illustrated above, WINS have no domain part, where DNS does. Often Windows network clients will
only use the hostname of a server when it needs to connect to a share, not the full domain name. The
reason this works is because clients will have a default domain set and the name resolver will append the
default domain when searching for hosts without domain part in the name.
DNS is a distributed database system. This means, in theory, that it does not matter what DNS server the
client asks, since all DNS servers, in theory, has access to the same information or know what servers that
do.
Important: However, with the introduction of NAT, internal DNS resolution became a necessity
in many networks, creating a separate DNS zone, as it were, for the internal networks. Internal
DNS servers can be set to override any answer the public DNS system has on record and can also
forward any requests it cannot answer to the public DNS servers. This way, the internal DNS
server can screen all DNS requests and can control internal network resolution without interfering with
the public DNS server systems.
Some facts about the DNS client are less known and they play a big role in setting up the SmoothWall
firewalls and Web filters.
When multiple DNS servers are configured on a client, the following applies:
• A client will randomly select which DNS server to query.
• If a client gets a reply of “host not found” the client will not ask any other DNS server. For this
reason it is unwise to use both internal and external DNS server settings on the same client.

Coursebook V2008
• If a client cannot contact the selected DNS server, it will try to contact one of the other configured
DNS servers.
WINS – Windows Internet Name Server

The WINS server system was initially designed for NetBIOS. It can only resolve hostnames and has no
concept of DNS domain names. It is used extensively in Windows NT4 networks and can be used on a
Windows 2000+ network as well in conjunction with DNS. In a Windows 2000+ domain with properly
configured DNS and DHCP servers, there should be no need for a WINS server.
Important: A lot of connectivity issues in Windows networks can be understood better by

understanding the difference between hostname lookup (WINS) and host and domain name
lookup (DNS).
DHCP – Dynamic Host Configuration Protocol

Also a well-known service. Apart from assigning IP addresses, a DHCP server can configure a long list of
TCP/IP options. One of the most common options to configure is the domain string. The domain string
adds the domain to the computers hostname so the computer knows where it belongs. Setting the domain
string allows Windows clients to resolve DNS hosts correctly only using the hostname, since it can add
the domain name from the information retrieved from the DHCP server. This becomes important in
networks that previously relied on WINS where only the hostname, not the host and domain name, was
the full name of the system.
Figure 5: Client resolving hostnames
Client witho ut assigned do main name asks fo r “fileserver”
DNS server wo nders: fileserver. what?
Client with assigned do m ain name m ydo main.lo cal asks fo r “fileserver.mydo main.lo cal”
DNS server respo nds: fileserver.m ydo m ain.lo cal is at 1.2.3.4
Note: The DHCP server on the SmoothWall firewall products were meant for small networks
and have been designed as such. Only the most common options are supported so if the full
range of DHCP options needs to be used another DHCP server may be more useful.
Default Gateway and Routing

The Default Gateway is the IP address the client sends all packets to, that are not destined for the local
network. The Default Gateway setting is arguably the most important setting on any computer connected
to a network.

Coursebook V2008
Figure 6: Default gateway illustration.
Client o n subnet 19 2.16 8 .1.0 /255.255.255.0 sends request to smo o thwall.net
Default gateway ro utes to external netwo rk

Client o n subnet 19 2.16 8 .1.0 /255.255.255.0 sends request to lo cal fileserver:
Lo cal fileserver respo nds. No packets are reaching the default gateway
The reason for the above figure is to illustrate when the default gateway is NOT in use. As the
SmoothWall system will often be the default gateway in a network, it becomes important to know when
traffic is actually reaching the gateway for troubleshooting purposes.
Note: The default gateway has to be on the same subnet as the client.
Routing is another area with lots of pitfalls. We have always found the following rule, simple as it seems,
good to have in mind when dealing with routing. This works best if said with a Yoda like voice:
“When with routing dealing you are, always remember: It not enough is that A the route to B knows, B
also needs to know the route to A! Remember this, young Padovar!”
Figure 7: Routing from A to B
Default gateway
Ro uter
Client A kno ws that B is accessed via the ro uter. Client B has no kno wledge o f the client A netwo rk.
Reply go es to the default gateway.
Tip: When troubleshooting network issues always take it step by step and verify where the traffic
is going. Using tcpdump and/or Windump is a good way to verify where the traffic is going so
routes and gateways can be verified and confirmed.
Tip: A new diagnostic tool is available on SmoothWall systems called traffic analysis. Find it in
the system – diagnostics section. With this tool one can listen in on traffic on a network interface
for a set amount of time. This can be useful in many instances when a more detailed
understanding on what packets are reaching the SmoothWall system is required.

Coursebook V2008
Chapter 2: Hardware
Linux and Drivers
The operating system of all current SmoothWall products is Linux. Version 2008 marks the move to the
2.6 series kernel which has been a long awaited change. Using the 2.6 kernel will lessen driver issues for
anything from network cards to harddisk controllers.
As everyone is aware by now, the Linux operating system Open Source and can be distributed freely – all
device drivers are included with the kernel source code so the drivers can be created when the kernel is
compiled again.
The Linux driver model requires drivers to be compiled specifically for a target kernel Version. However,
distributing a driver in the kernel source requires the driver source code to be Open Source as well. Some
vendors do not release official driver code to the Open Source community so the community has to write
them if there is no Linux driver or the official closed source driver will have to be used.
This often requires a specific kernel Version to be run on the target machine. For this reason, SmoothWall
products cannot use vendor released driver disks. They are compiled against the popular Linux
distribution kernels, like SuSE or RedHat Linux and will not work on a SmoothWall product.
Choosing the Hardware

Selecting the proper hardware platform for the SmoothWall product is naturally important in order to get
a smoothly running system.
Some rules of thumb can be applied when selecting hardware:
• Freshly released hardware based on the newest chipsets can have issues. As a rule hardware
should be a couple of months old so the Open Source community can get a chance to test, examine
and update drivers in the kernel if necessary. As Linux has become more and more mainstream,
the driver issues are also becoming increasingly less severe with more and more companies
releasing open source drivers.
• If no mention of Linux is to be seen in product documentation, please be extra careful and confirm
the availability of drivers in the GPL Linux kernel before deciding on the hardware in question.
SmoothGuard 1000-UTM appliance

The new SmoothWall appliance is a powerhouse. Powered by the Core 2 Duo processors, they have dual
core cpu and PCI-Express based network card interfaces on all seven interfaces.
One nice side effect of using PC-Express for the NIC interface bus is that the network cards have no
speed restriction. Each of the 7 network cards are capable of running close to the theoretical maximum
network throughput – in full duplex. Ideal for an all purpose UTM device in any office handling 200 –
1000 users.
While the appliance processing power is stellar, the hard disk drive has to be 2”5 size drive due to case
size. Care should be take to create and generate reports in the off peak hours if the system generally is
under heavy load.

Coursebook V2008
Hardware RAID vs Fake Raid vs Software RAID
Hardware RAID: In all SmoothWall version 2008 products we have support for hardware RAID cards.
The support is for those hardware RAID cards that have drivers available in the open source, which most
of the hardware RAID cards do.
Fake RAID: RAID has been a buzz word for a while now and most motherboards have an embedded
SATA controller with RAID capabilities. Unfortunately the embedded RAID controllers are unsupported
as they rarely have drivers available in the open source. Embedded controllers are Fake RAID cards,
meaning that the actual work of maintaining the RAID is done by the Operating System and the CPU, not
the controller itself.
Software RAID: Software RAID is handled and maintained by the operating system. The Version 5
products all support a software raid setup. During install, if the installer discovers 2 harddisks in the
system, the installer will ask if a RAID 1 setup is wanted. If the answer is affirmative, the installer will
setup a software RAID 1 on the 2 disks. RAID 1 is mirroring data, so if a disk drive fails, the other will be
up to date and the system will be able to boot from the disk that is still functional – only drawback when
using software RAID is that the boot drive may need to be selected again in the BIOS if a drive that was
the boot drive fails. Rebuilding a failed software mirror is done in the setup program.
Serial Attached SCSI (SAS)

A new technology in the storage arena is called Serial Attached Storage or SAS for short. This is a new
disk controller technology that is now supported in all the SmoothWall products.
SmoothWall Service Pack CD

Occasionally SmoothWall will release a “compilation” install ISO image – a Service Pack release. The SP
ISO images will have all released updates preinstalled. If a SP release is available it is the preferred
installation ISO as well.
Other Hardware Specific Issues
Chipsets
When trying to find out if a specific hardware device is supported it's often helpful to find the chipset the
hardware is based on. SCSI cards, network cards and motherboards are all built around a chipset from a
specific manufacturer. The Linux drivers are often marked as drivers for a specific chipset family so
knowing the chipset used on the hardware in question is a good idea, when searching for driver and
support information. Please also include chipset Version to any requests made to support about hardware
compatibility.
64 bit Capable CPUs

All SmoothWall products will run fine on 64 bit capable CPUs. SmoothWall products themselves are not
currently running on a 64 bit OS. SmoothWall is working on 64 bit versions of the SmoothWall product
line.

Coursebook V2008
PCI Network Cards
All PCI network cards should work fine. If they do not, contact support for assistance.
Multi NIC cards

Most multiport network cards also work fine in SmoothWall products. The only pitfall we have seen
several customers experience is the D-Link DFE-580 4 port card. The card is a PCI card and currently
displays some problems when plugged into a riser in a PCI-X slot.
Tip: If a network card has been found and configured but no traffic seems to pass, try to disable
APIC in the hardware options in the setup program.
USB Network adapters

USB network adapters are not supported nor recommended.
Wireless Network Cards

Wireless network cards are not supported. Use a NIC and a wireless access point if a wireless zone is to
be set up on the SmoothWall firewall. SmoothWall is not planning to support wireless nics anytime soon.
Figure 8: Wireless access point attached to the SmoothWall.

Internet
Lo cal Netwo rk Smo o thWall
Subnet 1
Wireless access po int

Subnet 2
Memory
Guardian is the biggest memory hog of the SmoothWall product line. Both the SmoothGuardian module
and the Network Guardian stand alone web content filter solution can use large amounts of system
memory. When building a Guardian system, always have a look at our hardware calculator on the
www.smoothwall.net and be generous with memory allocation. As a rough guide it can be said that a
Guardian system needs one CPU core and 1 GB of memory for each 1000 users.
VMWare Drivers
VMWare drivers are now included in the SmoothWall product line. They will enable improved
performance and better network speeds when running SmoothWall products on a VMWare based
platform. Furthermore, VMWare server scripts are installed to handle shutdown and reboot commands
issued from the VMWare server console.
USB Devices
USB keyboards and CD-ROM drives are supported if the BIOS on the motherboard supports them.

Coursebook V2008
Booting off USB devices is also possible, if the motherboard supports it.
SmoothWall can deliver a USB install image to resellers to allow installation of all V2008 products from
a USB pendrive. This can be useful for systems with no CD attached.
ADSL Modems
ADSL modems come in many forms and shapes and have varied functionality. There are three classes of
ADSL modems:
• ADSL USB modems:
SmoothWall firewalls support a long list of USB ADSL modems. The support depends on drivers
and firmware being available to the open source community. Again the chipset used on the device
is essential in order to determine support. Supported chipsets can change if drivers and firmware
becomes available.
• ADSL Ethernet modems:
Any ADSL modem that present the internet IP address given by the provider, directly to an
ethernet interface is supported. Sometimes ethernet modems can be set up in bridging mode and a
PPPoE profile can be configured on the SmoothWall to handle the connection. This can be done
with several Linksys and Netgear modems.
• ADSL Firewall/Router modems:
All of these devices are supported.
Figure 9: SmoothWall Firewall/NAT setup examples

Internet
NAT Firewall mo dem
Subnet 1 Subnet 2
Internet
Subnet 1
Note: When the SmoothWall is used as a VPN gateway, please avoid any NAT devices in front of
the SmoothWall. NAT and VPN does not always mix and match so to avoid any VPN problems,
please do not NAT a SmoothWall that is to be used as a VPN gateway server.
Note: When setting up a SmoothWall and an ADSL line, please always contact the ISP and ask
for their recommended solution to having the real IP on the SmoothWall. The ISP should have
knowledge about setting up the modem/router hardware to pass the real IP to the SmoothWall
firewall.

Coursebook V2008
Multiple External Connections
SmoothWall Advanced Firewall can have multiple external connections. There are 2 types of external
connections that can be configured on the SmoothWall Advanced Firewall. Primary and secondary
connections. Primary connections use a connection profile that is configured in the connectivity tab in the
network – interfaces section, whereas secondary connections are configured in the secondaries tab in the
same section. Port forwards can be configured on both primary and secondary connections.
Primary connections: Can use multiple connection methods.

Can accept incoming L2TP and IPSEC connections.
Failover can be configured between connectivity profiles.
Secondary connections: Static IP, network card based connection only.

Can accept incoming IPSEC connections.
Tip: The Advanced Firewall is also capable of load balancing both incoming and outgoing
traffic across multiple external interfaces.

Coursebook V2008
Chapter 3: Installation
SmoothWall product installation is quick and painless if the hardware is supported. A typical installation
from CD only takes about 5 minutes – the real time is spent applying updates and configuring/verifying
settings. The time it takes to apply updates can be reduced by either having the updates prepared locally
or by using the latest installation CD images, as they will have the previously released updates already
applied to them.
Figure 10: The SmoothWall install boot screen
The installation procedure only asks a few questions, probes for a network card and asks for an IP address
for the discovered network card. The discovered network card is also set as the “default” interface. That is
all that is required initially. After a reboot, the SmoothWall web interface can be accessed on the default
interface and the rest of the configuration should now be made on the web interface.
If drivers needs to be loaded or any of the default setup choices needs to be modified, the advanced
installation mode should be used. Once the initial blue screen is displayed the space bar can be pressed to
activate the advanced installation mode.
Right before the installation program starts the process of partitioning and formatting the hard disk(s) a
couple of options, that relate to partition and swap size, are shown.
NEW: In version 2008 it is now possible to perform an in place upgrade. The installer will
archive settings to ramdisk from the previous installation and implement them once the new
version has been installed. It is no longer needed to create a backup archive and upload it to the
newly installed system – although that is still possible. All the migrated settings will also be saved in an
archive and listed in the archives section of the web interface of the new version.

Coursebook V2008
Activating advanced install options
When the install program starts, the user can press the space bar during the first 5 seconds to activate the
advanced install mode. This mode is only used in special circumstances and should not normally be used.
The advanced mode gives options to add drivers during install and to specify swap and ramdisk options
on compact flash based systems.
Figure 11: Swap and RAM disk options
The options are:

• Log to RAM disk: This option prompts the SmoothWall to create the log partition as a RAM disk.
This option is meant for installs done on a minimal harddrive like for example a compact flash
card.
• Minimal swap partition: This option is meant for installations using minimal harddrives, like a
compact flash card.
Common for both above options is that they require memory, so make sure that enough memory is
installed on the system, if choosing any of the above options.
Multiple Ways of Installing

There are also multiple ways of installing SmoothWall products. Booting of the install CD is the normal
way and most motherboards now support booting from CD-ROM. Easy and fast, CD-ROM has been the
preferred installation method since SmoothWall came to be.
Installing modules
Since version 5 modules can be installed directly on the system – modules page. The module has to be
valid on the serial number used when installing the SmoothWall system. Once a module has been
activated just refresh the module list and an install button will become available.
Manuals
Amazingly we often get the question where the manuals are located. They are on the install CD in the
docs directory – the module manuals will be on the installation CD for the module.

Coursebook V2008
Furthermore the manuals can be downloaded from www.smoothwall.net in the support section.

Coursebook V2008
Chapter 4: Setup Options

The setup program runs from the command line or as a part of the installation. The setup program can be
run at any time after installation by logging on as the “setup” user or the “root” user. If logged on as root,
just issue the command “setup” and the program will start. During install, the root and admin user
passwords are set but the setup user is not. Log on as root and enter the setup program and set the setup
user password if using the setup user is preferred.
The setup program contains a wide mix of functions.
Figure 12: The setup menu
Restore Configuration
Restore configuration allows the restoration of settings from a previous system. When restoring from a
Version 3 SmoothWall system, the “Version 3 floppy disk” or “Migration floppy disk” option must used –
The remaining options: “Floppy Disk”, “CD-ROM” or “USB disk” are for Version 4 and 5 archives.
In Version 3, the backup settings were written directly to a floppy disk or a floppy disk image. From
Version 4 onwards, the backup function creates a standard tar.gz file, containing all system settings.
Remember that version 2008 can now perform an in-place upgrade.
TIP: When restoring setting to a new system, with new network cards, do NOT restore Ethernet
settings. The Ethernet settings are the settings detailing the type and drivers needed for
installation of the network cards and are irrelevant if a new system is replacing the old one. If
ethernet settings are restored, reboot the machine immediately. This will start a process where the

Coursebook V2008
SmoothWall will replace the “old” cards with the new ones it finds after a reboot.
TIP: If the Ethernet settings from an old system has been restored to a new system and the
system not rebooted immediately thereafter the SmoothWall system can lock up access to the
setup program network settings, because the SmoothWall thinks the external interface is active. If
that happens, have a look at figure 13 and run the command displayed:
Figure 13: Removing the active switch file
[root@CorporateFirewall root]# rm /modules/firewall/settings/red/active
rm: remove regular empty file `/modules/firewall/settings/red/active'? y
Keyboard Mapping
Sets up the keyboard map used by the system.
Hostname
This sets the hostname on the system. The hostname can be important, depending on the network setup.
The HTTPS server on the SmoothWall uses the hostname configured in this option. To prevent the web
browser from complaining about certificate errors, related to the hostname of the system, the hostname
can be set to a FQDN in the network and the SmoothWall HTTPS interface can be accessed using the
configured hostname.
Networking
Entering the network section of the setup program can only be done if no external connection is currently
active. To disconnect the external connection currently in use, go to the web interface and press
disconnect in the “Main” section.
NOTE: If the web interface is unavailable, the external connection can be closed from the setup
program or directly on the command line using this command:
Figure 14: Disconnecting the external connection from the command line
[root@CorporateFirewall4 root]# smoothcom disconnectexternal
issuing command disconnectexternal [SUCCESS]
Network Cards
The networking setup program probes for all network cards on the system and loads the drivers needed by
the network cards. If a card has been removed and replaced by a new card, the network card probe should
find the new card and discover that the old card has been removed and offer the option to use the new
card to replace the removed one.

Coursebook V2008
Address Settings
The address settings should only be used on network cards that are “internal” as seen from the
SmoothWall point of view. All external connections are configured using the web interface. All network
cards should be given a name to easily distinguish the cards. This will help when network access rules are
configured later in Zone Bridging. The settings here are the same settings found on the web interface on
version 5 products in the networking – interfaces section on the interfaces tab.
NOTE: It is vital that the internal networks attached to the SmoothWall system are private IP
networks. With so many network features and VPN connection possibilities, it has become
necessary to assume that all internal networks are configured using private IP ranges. Using
public IP ranges is not recommended for NATTED networks.
DNS and Default Gateway

On Corporate Firewall, the DNS and default gateway should normally be left as the default in the setup
program. External connection profiles will be used to configure the default gateway of the SmoothWall
system.
On Advanced Firewall, School Guardian and Network Guardian, where directory integration is planned,
the DNS server setting should be configured to point to the internal DNS server on the local network.
This allows the SmoothWall system to resolve internal hostnames on the local network. This is especially
important when integrating SmoothAuth with Active Directory domains.
Figure 15: Using the setup program to access the internet
The DNS and Default gateway settings can be used to give the SmoothWall system access to the internet,
so installation of modules and updates can be done without a configured external connection. This way, a
system can be installed and prepared, even when no external connectivity profile has been configured on
the SmoothWall system.

Coursebook V2008
Figure 16: Using the interfaces page in the Web GUI
Set up the Smo o thWall as a no rmal

netwo rk client if the external
co nnectio n is unavailable at
installatio n
The Default interface will no t

have the “Internal” tickbo x.
An unco nfigured interface

will lo o k like this:
Internal interface
co nfigured. No link to
“Co nnect External”:
External interface
selected and named :
Default interface
The default interface is the interface where full access to the administration services on the SmoothWall
will be set up. Use this option if a new default interface is desired.
VLAN
Used to set up any VLAN interfaces and tag them with the appropriate VLAN tag.
Diagnostics
The diagnostics page can be used to verify that the network cards are up and running. Some network card

Coursebook V2008
drivers are not compatible with the polling the diagnostics function uses so not all network cards will
report their status correctly. Use the diagnostics to verify that cards are working correctly but if any card
statistics are not reported, do not assume the card is malfunctioning – it may not be compatible with the
diagnostics program.
TIP: The diagnostics page uses the command “mii-tool” to get diagnostics information. Another
tool is called “ethtool”. If any cards are not showing proper diagnostics information, try leaving
the setup program and run “ethtool eth[X]” where [X] is the interface designation.
Hardware Options
The hardware options menu allows the user to configure various hardware specific options. These
include enabling the SMP kernel for multiple CPU based systems and disabling APIC.
APIC is an acronym for “Advanced Programmable Interrupt Controller” and is a technology used mainly
on multi socketed SMP systems. Some drivers have problems with APIC, so it may be necessary to
disable APIC on the SmoothWall system if network cards or storage controllers are behaving strangely.
If there are problems during installation and the SmoothWall installation program cannot find storage
controllers, it may be a good idea to try to disable APIC during install as well. This can be done by
entering “linux noapic” at the installation boot prompt.
Figure 17: Disabling APIC during initial boot
Boot: linux noapic
Resetting Admin Access

This option resets admin access rules on the default interface, so all services can be accessed. Useful if
the admin access rules have been removed from the web interface.
Serial Console
Enable serial console access.
Web Proxy
If the SmoothWall system is behind a proxy server, it may be needed to enter the proxy server details here
to allow the SmoothWall to register itself. This setting has nothing to do with the proxy server that can be
run on the SmoothWall. This can also be changed from the web interface in the administration –
preferences section on the upstream proxy tab.
ADSL Configuration
This section is used when a USB ADSL modem or a BeWAN PCI ADSL card is installed on the
SmoothWall system. Enter the menu and select the proper modem, VCI and VPI options for the ISP in use
and enable ADSL. After enabling ADSL, the modem will sync and the ADSL modem option will be
available on the “connectivity” tab of the firewall section.

Coursebook V2008
The BeWAN cards that SmoothWall resell have seen some issues in the UK when being used on noisy
lines. This could be caused by the driver not selecting the proper activation mode when it is being
activated – if there are any connectivity problems using the BeWAN card, please contact support as they
may be able to suggest a change that will help.
BeWAN cards on dual core systems will not work on the latest version – 2008. The BeWAN driver is
proprietary and some calls have been excluded from being used by proprietory drivers in the 2.6 kernel.
We currently have no workaround for this.
ISDN Configuration
This section is used when an ISDN PCI card or ISDN USB connection is present on the SmoothWall
system. Enter the appropriate values and enable ISDN. After enabling ISDN, an ISDN option should
show up as a connection option in the “connectivity” tab of the firewall section.
Resetting System Passwords

The final options are for resetting the “admin”, “root” and “setup” user password.
TIP: If the admin password has been lost, log on as setup or root and reset
the password. If the root or setup password has been lost, the system needs
to be booted in single user mode.
Figure 18: Booting in single user mode – AF, SG and NG vs CF
SmoothWall-up SmoothWall-smp
Single CP U
Boot: SmoothWall-up single
Mult iple CP U SmoothWall-up SmoothWall-smp

Boot: SmoothWall-smp single
Single user mode starts the system up normally and after the boot process and start-up is done, it does not
ask you for a username and password. Once the system has booted the setup program can be run and the
passwords for the system users can be changed.

Coursebook V2008
Chapter 5: Installation/Migration Best Practises Flowchart

The following sequence is a guideline to the actions to be taken when installing or migrating a
SmoothWall system. It is not meant as a hard and fast rule but as a guideline and a reminder when
installing a new SmoothWall system.
Preliminaries
Create backup archive with relevant settings and download it to a safe location. Upgrading to version
2008 can be done without having a backup archive handy as the installer will save settings and re-
implement them once the installation has completed but always have a backup archive ready in case of
unforeseen issues.
Guardian filtering settings are not migrated from a version 5 to version 2008 as the new filter
configuration in Guardian prevents that. Proxy settings are migrated. Before upgrading, make sure any
custom lists of domains have been saved to an available text file.
TIP: When migrating the same hardware to a new software version, it may be prudent to replace
the disk drives so the original drives can be reinserted if there are problems migrating settings.
Installation and Initial Configuration

Install the SmoothWall software and configure the system so it can access our registration servers – this
will enable the installation of extra modules and relevant updates.
By installing modules and updates before restoring system settings, the restore only have to be done once.
If the restore was made during installation and extra modules were to be installed, another restore is
needed for the module specific settings.
TIP: Always use the latest release of the software being installed. Often SmoothWall will release
and updated ISO image for all products with the currently released updates pre installed.
Then reboot the SmoothWall system.

Coursebook V2008
Final Configuration and Sanity Check
After the previous reboot, update any module specific files, such as blocklists and anti virus files for
Guardian and SmoothZap modules. Also navigate to the “maintenance – licenses” and refresh the
licenses.
If needed we can now restore module specific settings or do a full restore. When restoring settings
navigate to the “maintenance – backup” section of the web interface and upload the backup archive to the
system. Then select and restore the settings. After the restore button is pressed, a list of the saved settings
contained in the archive will be displayed and the sections to be restored can be selected and restored.
Figure 19: Restoring settings using the Web interface
NOTE: Remember to leave out ethernet settings if installing the system on new hardware. If
ethernet settings was restored to the new hardware, reboot immediately after restoring settings.
That should cause the startup procedure to replace the old network card information with the
present network cards.
After restoring settings in the setup program the passwords will be cleared and new passwords will need
to be entered. Once settings have been restored, check that the settings have been restored correctly and
reboot the system.
Final Touches
After the reboot, go through the system one last time and confirm that everything is working as it should.
Then go live.
So, a quick recap:

1: Create a settings backup archive and save it to a separate system.
2: Install new version.

Coursebook V2008
3: Setup network cards and external connectivity.
4: Install modules and updates.
5: Restore settings if necessary.
6: Sanity check the new installation.
TIP: If new hardware is used but the IP addresses are going to be the same as the previous
system had, it's often a good idea to reset switches and routers connected to the new system. This
will clear the ARP cache on the connected devices, allowing the new systems network cards to be
associated with the IP addresses the old system had.
NOTE: The password for the authentication lookup user needs to be reentered after a restore.
The password is not saved in the backup archive.
A few words about sanity checking

Every new version will have new features and settings available. Therefore its fairly important to go
through a newly installed system in order to verify that all sections are configured as they should and any
new features or options have been taken into account.

Coursebook V2008
Chapter 6: Networking
The networking sections contains all settings relevant to packet handling. Network card setup, internal
access rules and the firewall functionality as well. The networking section has been revamped a bit in
order to accommodate the traffic module and the new port groups function. There is now a settings
section where advanced TCPIP functions can be configured and a port groups section where a list of ports
can be defined for later use in port forward rules. More on that later.
Filtering Section:
Zone Bridging:
Access between internal networks and VPN connections is configured here. All internal interfaces will be
listed in the source and destination drop down lists, along with the VPN interfaces L2TP, OpenVPN and
IPSEC. For any traffic coming through an IPSEC, OpenVPN or L2TP tunnel, access needs to be
configured in the Zone Bridging section, for the traffic to be allowed into the internal networks.
The bidirectional tickbox creates a two way access rule. It is the same as creating two rules, the second
rule with source and destination interfaces reversed. If a rule is not bidirectional, traffic can go to the
destination network, but only replies to that traffic can make it back to the source. Traffic is not NATTED
between internal zones – it is routed.
Figure 20: Zone bridging and bidirectional rules
Internal Subnet 1 Internal Subnet 2

Bidirectio nal rule:
Traffic can be initiated fro m bo th
subnets
Internal Subnet 1 DMZ

Unidirectio nal rule:
Traffic can o nly be initiated fro m so urce
subnet
NOTE: A non bidirectional rule will allow traffic to pass and replies to return – this is the same
principle for the external interfaces. Traffic can leave and replies can return.
Group Bridging:

Coursebook V2008
Access to internally connected networks and VPN connections can also be configured by group
membership. The reason there is no source interface drop down list is that the IP address of the logged in
user is known to the authentication system which implies what source network they are coming in from.
Once a user is logged in and the authentication system has mapped the user to the appropriate group, the
group bridging permissions will take effect.
NOTE: OpenVPN users are authenticted by the auth subsystem so they will be logged into the
firewall as soon as they connect.
IP Block:
This section allows configuration of IP's to block or destination IP's to deny access to. There is also an
exception option that can be used to unblock access to single IP addresses within a range that has been
blocked.
Routing Section:
Subnets:
If there are any routers on the internal network, the SmoothWall can be made aware of the subnets that are
connected to those routers here. It is a simple route add command that allows the configuration of custom
routes on the SmoothWall.
TIP: After adding a subnet, it may be needed to restart the Guardian or the proxy module to
allow the newly configured subnet to access the Guardian proxy and web filter.
NOTE: Routes to any VPN connected network are added automatically by the VPN subsystem.
Do not add routes to remotely connected VPN networks in the subnets section.
NOTE: These routes will be brought up BEFORE the external interfaces so this is ONLY for
internally reachable routers.
RIP:
Routing information protocol. If needed, activate it.
Sources:
Here traffic can be directed out through any external interface based on the source IP address. This tab is
not available on the Corporate Firewall and School Guardian products, as they are not capable of having
multiple external interfaces active.
NOTE: If traffic is to be sent out through the primary connection profile, do NOT select the
interface name here, just select the Exception option. Any excepted traffic will be sent out
through the primary connection. The reason all interfaces are shown is that interfaces can be used
both for secondary and primary connections.

Coursebook V2008
Ports:
Here traffic can be directed out through any external interface based on the destination port. This tab is
not available on the Corporate Firewall and School Guardian products as they are not capable of having
multiple external interfaces active.
NOTE: If traffic is to be sent out through the primary connection, do NOT select the interface
name here, just select the Exception option. Any excepted traffic will be sent out through the
primary connection. The reason all interfaces are shown is that interfaces can be used both for
secondary and primary connections.
NOTE: Once SmoothGuardian is installed there is an option in Guardian to block direct web
access. This option blocks all access to port 80 and 443 with no possibility of exceptions. Often
it is better to use the outgoing rules to manage which IP addresses should be allowed direct web
access rather than enabling the “Block direct web access” option in the Guardian – web proxy
section.
Figure 21: Primary and secondary connections
Lo cal Netwo rk Primary co nnectio n

Inco ming VPN Internet
Po rt Fo rwards
Subnet 1 Ho sted services
Smo o thWall
DMZ
Outgo ing po rt 338 9 (RDP) redirected traffic.
Specific IP redirected by so urces traffic.
Subnet 2 Web filter traffic by Lo ad Balancing Web
Pro xy traffic.
Interfaces Section:
This section contains all the connectivity and IP address assignment options. Most of the configuration
options available in the setup program is duplicated in the interfaces tab in the interfaces section.
Interfaces:
The interfaces tab in the Interfaces section is used to configure internal interfaces, set DNS and default
gateway settings and adding VLAN interfaces. The only pitfall here is the “settings” section, where
default interface, heartbeat interface (Advanced Firewall only), DNS servers and default gateway can be
set. Here is a quick overview of when those settings should be configured and when they should be left at
the default settings:
Primary and Secondary DNS:

Coursebook V2008
Only set this if internal DNS name resolution is needed, as when connecting the authentication subsystem
to a Windows Active Directory server or when external connectivity is not present.
The DNS servers configured here are the DNS servers the SmoothWall system will use for name
resolution. The default setting of 127.0.0.1 means the SmoothWall system will use itself, which means it
will use the DNS proxy server running on the SmoothWall, which in turn, is using the DNS servers
configured in the active connectivity profile.
Figure 22: DNS Settings on SmoothWall Firewall products.
Internal DNS server

ISP DNS Server
Subnet 1
DNS Pro xy
Setting fro m External
co nnectivity pro file
Internal DNS Client

Do No t set up DNS
DNS Client client to co nnect to
Setting fro m Setup pro gram o r external DNS servers.
Interfaces Web GUI.
Internal DNS o r Lo calho st.
Default Gateway:
Only set this if no external connectivity profile is present or the external connectivity profile cannot be
connected. This setting is meant to be used when installing the SmoothWall product in a situation where
external connectivity cannot be established to register the product and download modules and updates.
The interfaces section lists all available interfaces on the SmoothWall system and allows them to be
configured as internal interfaces or reserved for external connectivity. The default interface is the only
interface that does not have an “internal” tickbox next to it, as the default interface should always be an
internal interface.
If the SmoothWall installation sets the default interface to one that is to be used for an external
connectivity profile, please change the default interface to be an internal interface.
Advanced:
The advanced tab allows customisation of some TCPIP features on the SmoothWall system. In general,
these settings should be left at the default. However, increasing the Connection tracking table size should
be done on firewall systems with more than 1000 users behind it. Also, the SYN backlog queue size
should be increased to 4096 on Guardian systems with more then 500 users behind it. This does consume
a small amount of memory.
Traffic Auditing:
The auditing settings are for logging ALL traffic going to, through or leaving the SmoothWall system.

Coursebook V2008
Needles to say, auditing all traffic will create large logs so make sure there is sufficient diskspace on the
system before enabling these logging options. The auditing logs can be seen in the information – logs –
firewall section. Just select the appropriate auditing log from the section drop down list.
Drop direct traffic on internal interfaces:

This option instructs the firewall to drop all packets addressed TO the SmoothWall system on the selected
interface. This is meant to be used on DMZ and unsecured Wireless networks. Traffic NOT destined for
the SmoothWall system will be allowed to pass through – only traffic with a destination IP address of the
selected SmoothWall interface will be dropped. This of course means that no services running on the
SmoothWall can be accessible on the network connected to the selected interface.
Figure 23: Dropping direct traffic
Internal client Smo o thWall

Traffic addressed to the Smo o thWall IP will be dro pped
Internal client Traffic sent thro ugh the Smo o thWall will be allo wed Internet
SmoothWall
External Aliases:
This page will only show up on Corporate Firewall and SchoolGuardian if the SmoothHost module is
installed. SmoothHost is included in Advanced Firewall and the SmoothGuard UTM-1000. Here it's
possible to configure multiple aliases for any external connection, primary or secondary. It is also possible
to set an alias and tie it to a specific connection profile.
Figure 24: External aliases
Smo o thWall One co nnectio n. Internet

Default IP address: 1.2.3.4
Alias 1: 1.2.3.5
Alias 2: 1.2.3.6
Alias 3: 1.2.3.7
External aliases are naturally often used in conjunction with a DMZ setup. A DMZ is a network zone,
where servers that has a direct port forward are placed. A port forward to any server is a potential security
hole so it is prudent to place the accessible servers in an isolated zone.

Coursebook V2008
NOTE: The many options available for configuring aliases, failover and source/port routing can
be a bit confusing at times. It is recommended to plan the traffic flow as specifically as possible
and always use the simplest possible configuration to achieve your desired goal. Load balancing
can be used to distribute traffic over multiple external connections but often, assigning specific
traffic to interfaces is a better idea. The main problem that multiple external connections were meant to
solve is bandwidth starvation – if web browsing is taking bandwidth from mission critical applications,
then moving all web traffic to one connection and reserving the other for the mission critical traffic would
probably be a better solution than load balancing e.g.
A word about DMZ

The DMZ is an insecure network. Since there are port forwards coming in from the internet, there is a
potential threat of crackers gaining access to one of the systems. The DMZ is there to isolate intruders
from the rest of the network if one of the accessible servers is compromised.
The following guidelines should be looked at in order to ensure proper usage of a DMZ network:
• Always isolate the DMZ from the local network.
• Always use as few of the SmoothWall services on the DMZ network.
• If any pinholes need to be created, lock them down to IP addresses and ports in order to be as
specific as possible.
Often we see a DMZ with full bidirectional access to the local network and we even get customers
wanting to VPN to the DMZ network. Both conditions completely invalidate the DMZ idea and turns the
DMZ and the LAN into an insecure local area network. If any access is needed to the servers, open access
normally, using a port forward. It's better to use the front door, rather than opening back doors into the
local network. Remember that the servers in the DMZ are not the ones protected by the DMZ – the local
area network is the zone that is protected by the presence of a DMZ because the internet accessible
servers are now on a separate network.
Hosting Tips and Tricks

There are a couple of problems when hosting services behind a NAT firewall – both are related to each
other.
The issues appear when servers on the same subnet try to communicate with each other, using the
hostname as destination address. The hostname will resolve to the external IP address and the packets
then tries to go through the NAT gateway.
However, the NAT gateway will see this as packets coming from the subnet and going to the same subnet.
Routing cannot route packets back to the originating interface so the packets will get blocked.
In the upcoming Feature Pack 1 for version 2008, SmoothWall has implemented a hostname lookup
workaround for hosts in the DMZ trying to reach each other by way of hostname resolving to the external
IP. The SmoothWall will investigate port forwards and packets and will actually rewrite packets so they
can be sent back to the target machine.
There are other ways of getting around this issue. On smaller installation, a hostfile should be able to do
the trick. Hostfiles do not hold MX records, so make sure MX records on the “real” DNS server points to
a hostname, not an IP address.

Coursebook V2008
Internal Aliases:
Here aliases can be configured on the internal interfaces. No services normally available on the parent
interface will be running on the internal aliases though.
Connectivity:
Here external connectivity profiles are created for the primary connections. Connectivity profiles are used
by the primary connection. Multiple profiles can be configured and each profile can be set to failover to
another profile in case connection is lost.
In order for failover to be configured, failover IP addresses needs to be entered. These addresses could be
the ISP Mailserver, DNS server or other IP addresses that are known to be reachable and stable. Entering
2 IP addresses decreases the likelihood of a “false” failover.
The “Auto Connect on Boot option” in the connectivity profile allows the connection profile to connect
after a reboot. It does not specify which connection will be brought up after a reboot, so all profiles can
have the option enabled. The connection that will be brought up after a reboot is the profile last selected
on the main page.
On Advanced Firewall and SmoothGuard UTM-1000 there will be an additional 2 tickboxes available for
a connectivity profile as well as for the secondaries configuration. Then enable the Outgoing Load
Balancing and Load Balance Web Proxy Traffic features.
Figure 25: Load balancing examples
Seco ndary 1 fo rwards same

po rt to 2 internal IP
addresses.
Primary
Internet
Mail server is excluded by Seco ndary 1
IP. No traffic is LB fro m the
excluded IP addresses. Seco ndary 2
Seco ndary 3
Seco ndary 2 and seco ndary 3 have po rt

Pro xy traffic is LB o n
fo rwards to this server.
all seco ndaries.
The Load Balance Web Proxy Traffic is only a valid option if the proxy is running on the SmoothWall
system. It has no effect otherwise. Also pay attention to the weighting metric set on the interface. The
metric is a way distributing traffic across load balance interfaces – if 2 interfaces had set a weighting of 1
and 3 that means that of 4 outgoing connection, 1 will go out via the interface with a metric of 1 and 3
will go out of the interface with a metric of three.

Coursebook V2008
The load balancing is based on connections not on bandwidth used.
NOTE: Even if an interface is used for a secondary connection, a primary profile can still be
created using that interface. If the primary connection profile is then activated, the secondary
connection using the same basic configuration, will be deactivated.
PPP Settings:
Fairly self explanatory page where PPP profiles are created for dial-up purposes. Do not enable “Dial on
demand” options AND “persistent connection” at the same time. Also increase the default value of 10 in
the “Maximum retries” field to 100 or more as 10 retries can sometimes finish before the ISP allows
reconnects again.
Secondary Connections:
On SmoothWall Advanced Firewall and SmoothGuard UTM-1000 it is possible to have multiple external
connections. One primary connection and multiple secondary connections. The reason they are divided
into primary and secondary connections is because the secondary connections have some restrictions to
both setup and functionality, as compared to the primary connection.
Restrictions on secondary external connections:
• Secondary connections can only be NIC based with static IP address.
• L2TP connections can not be made to a secondary connection.
The main function of the secondary interfaces is to offload traffic from the primary connection.
Figure 26: Load balancing outgoing traffic – Failover configured
Primary – Reserved fo r VPN and

Web Request 1 Ho sted services
Internet
SmoothWall
Web Request 2 Seco ndary 1 - Web request 1
Seco ndary 2 – Web Request 2
FTP Request 1 Seco ndary 1 – FTP Request 1
In Figure 26 we have 3 external connections. 1 is the primary and 2 are secondary connections. One of the
secondary connection details has also been entered as a failover profile for the primary connection.
To offload web browsing traffic from the primary interface, we are load balancing proxy traffic on the 2
secondary connections. All web traffic will now go trough the 2 secondary connections, relieving the
primary connection from handling web traffic.

Coursebook V2008
Figure 27: Load balancing outgoing traffic – failover in place
Primary – Do wn
Web Request 1
Seco ndary 1 - New Primary
All po rt fo rwards and VPN o n Internet
Smo o thWall
new primary.
Web Request 2
Seco ndary 2 – All Requests
FTP Request 1
In Figure 27, the primary connection has failed and the failover profile for the primary connection has
been activated. Since the failover profile is based on one of the secondary connections, the secondary
connection has been brought down and then activated again as a primary profile.
All web proxy traffic is now handled by the single secondary connection. Since one of the secondaries has
now been removed and reinstated as a primary, the only interface left to load balance proxy traffic is the
remaining secondary connection.
All port forwards that were in place on the primary connection are still active on the failover profile so all
hosted services will still be available albeit on a new IP address. In the case of mail servers, a MX record
can be added for both primary and failover IP addresses, with a low value for the primary connection and
a high value for the failover connection. Mail will then always be delivered to the customer, even if the
primary connection has failed over.
NOTE: Web proxy traffic can be sent out via one interface by simply enabling the load balance
proxy traffic on that interface alone.
Firewall Section:
SmoothWall firewall products are designed to be NAT firewalls. NAT stands for Network Address
Translation and the technology allows multiple computers to access the internet only using one IP
address. The firewall keeps track of outgoing requests, rewrites the source IP and port and returns any
replies to the IP address that originated the request. Traffic between internal interfaces can also be
restricted, making the SmoothWall behave a like a transparent firewall for the internal networks. All
traffic to external networks will be NATTED.
The alternative to a NAT firewall is a transparent firewall. A transparent firewall works like a router and
only allows ports through, as configured by the network administrator.
The main firewall functions can be found in the networking and firewall sections. The firewall section
deals with external connectivity and port forwards, whereas the network section deals with internal access
rule and internal routing.

Coursebook V2008
Figure 28: Transparent and NAT firewalling
Internet
Public IP address o r subnet Public IP address
NAT firewall Transparent firewall
Private IP subnet Public IP subnet
Port Forwarding:
Here is where port forwards are configured and where the incoming load balancing is set up. To set up
incoming load balancing, simply forward the same port to 2 or more different internal IP addresses
running the service. The incoming load balancer will then divide incoming requests between the
configured port forwards on a simple round-robin basis.
A new feature in version 2008 is the inclusion of port rules. Look at the list of ports and you can see the
ports list is now divided into sections or groups. One can select a single port from the list or the entire
group. Additional groups and lists can be configured in the networking - advanced – port groups section.
NOTE: Always remember to check that the correct protocol is being forwarded. DNS traffic is
UDP for example, whereas HTTP is TCP.
TIP: All port forward rules can be logged. Enable this on the configured rule and go to the
firewall log section. Select “Port Forwards” in the section drop down list and press update. You
should see all incoming packets that match the port forward rules, that have logging enabled.
TIP: Incoming load balancing can also be done over multiple external interfaces.
TIP: If the port forward uses the same destination port as the source port (i.e. 80 -> 80) it is not
neccesary to enter the destination port. The destination port will default to the same port as
specified in the source port option.
Source Mapping:

Coursebook V2008
When internal servers initiate contact to the internet, for example a mail server sending SMTP mails to
the ISP SMTP server, it is often necessary to make sure the traffic source is an alias address. The source
mapping page is used to configure what outgoing traffic should be source mapped to an alias address.
NOTE: Replies to incoming requests on an alias, will always be answered with the source
address being the same as the address the request was received on so only services that initiate
internet traffic needs to be source mapped.
Figure 29: Source mapping
Entire subnets can be so urce mapped
Reply to inco ming po rt fo rwarded traffic Internet

Smo o thWall
will always return fro m address that
received the po rt fo rward
Outgo ing traffic must be so urce mapped
Advanced:
This section allows the user to enable some helper application modules, which can assist certain protocols
in traversing NAT. Most of these helpers are obsolete except for the FTP helper.
TIP: We recommend using SCP instead of FTP – a nice SCP GUI for the Windows platform is
WinSCP. SCP only requires one port and traffic is encrypted, so it is a much easier protocol to
handle than FTP. For remote and home workers that need to be able to access or upload files it is
by far the easiest and most secure solution to manage. WinSCP is a freeware application too.
Outgoing section:
This section was previously the SmoothRule module. Here outgoing traffic can be managed by creating
outgoing firewall rules. The section works by creating rule sets and then applying the rule sets to IP
addresses, ranges or networks or applying the rule sets to authenticated groups.
Apart from blocking ports, the outgoing section module will also assist in blocking Peer to Peer data
transfers, This is done by deep packet inspection and by blocking key frames that are used by the various
Peer to Peer applications.
The external services tab is used to allow access to services only on specified servers. Enter the server IP
addresses and the service that the server hosts and that is the only server accessible for that service. For
example if all SMTP traffic should go via an external relay host, the relay host IP and port 25 can be
added to the external service list and no one will then be able to reach port 25 on any other servers than
the one specified in the external services tab.

Coursebook V2008
There are a couple of things to remember when using the outgoing section.
• Even though a port and server address has been entered on the external services tab, clients will
still need access to the configured port in their applied ruleset to allow outgoing traffic on that
port.
• Rules replace each other. Creating one rule for basic services and then creating a superset of rules
and applying them to overlapping IP addresses will replace the initial rule. Complete rulesets will
need to be created.
Figure 30: Outgoing rules
19 2.16 8 .1.0 /24 subnet

will have permissio ns
as seen in Rule 1
Co nfigured so urce
rules:
19 2.16 8 .1.10 0 will have

permissio ns as seen in
Rule 2
19 2.16 8 .1.10 0 will no t be able to access SSH o r POP3. Peer to Peer traffic will no t be
blo cked.
Traffic Section:
Please refer to the SmoothTraffic chapter later in this book.

Coursebook V2008
Chapter 7: Network services

The SmoothWall firewall series has a lot of functionality that is not readily apparent. A lot of these
functions can be found in the services section.
Authentication Section:
Please refer to the Authentication chapter later in this book.
Proxies Section:
SIP:
The SIP proxy service. Used for SIP clients – we have not tested this with VoIP PBX servers.
Web Proxy:
The Web Proxy service comes with all SmoothWall firewall products. This section is removed if
SmoothGuardian is installed as that will then have the proxy controls in the Guardian GUI.
IM Proxy:
The new addition to the long list of features in SmoothWall products. The IM proxy works by
transparently intercepting IM messages from IM applications like MSN , ICQ/AIM, Yahoo, and Gadu-
gudu – The IM proxy is limited in functionality and does not support all IM applications yet. Some, like
GoogleTalk, are using SSL traffic which of course prevents logging of conversations. MSN Live
Messenger will use proxy settings set in Internet Explorer so will not be going via the IM proxy. An
update to the IM proxy in FP1 will allow Guardian to distinguish between IM and normal web traffic and
redirect the IM traffic through the IM proxy. Until then, other clients like Pidgin can be used. They will
not automatically use the configured proxy settings and Pidgin is even add free and simple to use!
SNMP Section:
SNMP:
Fairly simple page. Just enable and enter the community string.
DNS Section:
Static DNS:
The static DNS section is basically an interface that allows the user to manipulate the host file on the
SmoothWall system. On the SmoothWall system, the hostfile will be queried first, before asking the DNS
servers for hostnames. This is useful if there are hosted services on the LAN and clients on the same LAN
need to resolve the hostname to an internal IP address.
TIP: The SmoothWall is not a DNS server. If there are more advanced requirements than just a
hostname lookup, MX Records for example, please use a proper internal DNS server.
DNS Proxy Server:

SmoothWall firewalls also include a DNS proxy server. The DNS servers used by the DNS proxy server

Coursebook V2008
are the DNS servers configured in the currently active connectivity profile. The DNS proxy service needs
to be told what interfaces to serve DNS on as the default setting only listens on the default interface.
Dynamic DNS:
Dynamic DNS providers are also supported in the SmoothWall firewall products. Some providers require
a Windows client to be installed. If that is needed, just install the client on a box behind the SmoothWall.
The Update will still be done for the source IP address and that will be the external IP of the SmoothWall
system.
IDS Section:
SmoothWall firewalls also have an intrusion detection system. We were going to offer SmoothWall
packaged rules for the IDS system, but unfortunately our talks with SNORT were put on hold as SNORT
were negotiating to be bought by a competing company. The sale has now been put on hold and
SmoothWall is renegotiating the rights to distribute SNORT IDS rules as a SmoothWall package but no
resolution is in view at the time of writing. Currently, the latest rules will have to be retrieved from the
SNORT website using the Oink code system.
Some customers were under the impression that the IDS actually blocked packets that were recognised by
the IDS system. That is not so. The IDS system does not block any traffic – it analyses and logs.
The latest IDS rules can be downloaded from www.snort.org. A paid subscription allows access to the
latest rules. Registered users can also download the same rules, but with a weeks delay. The SmoothWall
firewalls use snort version 2.6 so make sure the IDS rules are for that particular snort version.
DHCP Section:
The well known DHCP service. Read the help :) The DHCP service has only the most basic options
available for configuration via the web interface. FP1 has a scheduled addition to the DHCP server
settings that allows the user to add any of the many DHCP config options manually.

Coursebook V2008
Chapter 8: Main
The main section only displays two tabs – main and about.
Main Section:
The main page is used to connect and disconnect the primary external connection. That is the only
function that can be accessed from the main page, selecting and connecting the primary external
connection. If there are multiple connection profiles, please remember to select the appropriate profile in
the connection profile drop down list. Also remember that the select button has to be pressed after
choosing an entry in the drop down list.
The rest of the main page is used to display reports and system information – the sections displayed here
can be customised using the settings page in information, which we will be looking at shortly.
Dashboard
The dashboard is a new feature in version 2008 – the dashboard show real time information rather than
the static displays earlier seen. The various sections in the dashboard or the dashboard itself can be
enabled or disabled in information - settings – settings.
NOTE: The various dashboard reports can take a while to generate so do not be alarmed if the
reports are not filled in when the main page Is accessed initially. The reports will show when the
system has finished generating them.
About Section:
This page holds licensing and ownership information. The ownership information is the same that was
entered when first connecting to the system. If this needs to be reset or the serial number needs changing,
connect to the command line and run the following command:
# echo>>/settings/main/ownership
Once that command has been run, connect to the web interface again and the registration screen will pop
up to allow the user to enter new serial number and ownership information.

Coursebook V2008
Chapter 9: Information
The information section is where system information, reports, logs and other information can be gathered.
Alerts and email reports are also configured here.
Reports Section:
Summary:
This page is customisable by creating a report template in the information - reports section and then
setting the system summary page to display that template in information – settings – settings section. The
main page can also be customised using the same process.
Remember that a huge amount of reports will taek a long time to generate so including them on the main
page is probably not a good idea as that is the first page that is accessed when logging in. The system
summary page is a better place for custom reports.
Figure 31: System load average
System lo ad graph
Wo rry if co nsistently abo ve
10 . Multiply by number o f
CPU.
TIP: System load average can be seen on the graph pictured. The current value can also be seen
at the bottom of the main page as well as be monitored realtime running the top command.
A value of 1 means everything is handled in a timely fashion. On a dual cpu system, the value would be 2
as there are 2 CPUs. Spikes are normal and should be expected. As a very general rule, if the value
consistently is above 10 (or 20 for a duel CPU system, 40 for a quad CPU system, etc) the system cannot
cope adequately
TIP: The Traffic Statistics report is the more precise of the traffic reports. The graphs can
sometimes give misleading peak reading – the averages should be fairly accurate though.
Customize:
The customize section allows the user to generate a custom report or report templates consisting of the
reports wanted for a specific occasion.
Templates:
Once a template has been created in the Customize section, the template is listed here.

Coursebook V2008
Recent and saved:

Once a report has been generated it will be listed on this page. Scheduled reports with the option set to
save them wil also be listed here.
Scheduled:
The scheduled reports allows the configuration of a collection of reports to be generated and mailed to
configured users.
Alerts Section:
Alerts:
Same principle as the scheduled reports section. Select the configured group and then add the alerts to the
configured group. The “Instantaneous alerts” option can require some processing power and is constantly
monitoring the log files. For that reason, it is often not a good idea to enable instantaneous alerts on very
busy systems.
Realtime Logs Section:

No real explanation is needed for this section. As the title says, realtime logs. Go to the section that needs
to be looked at and look :)
Most sections in the realtime log will have a section drop down list as well, where further sorting of the
displayed logs can be done.
Figure 32: Realtime traffic graphs
The traffic graphs section is a bit of a loner in this area – a nice experiment in web coding that will show
you the traffic rates as they pass through the various interfaces on the SmoothWall. We are currently

Coursebook V2008
updating the web interface on the GPL SmoothWall Express firewall and are adding a lot more fancy web
trickery, like realtime displays of address per IP and other surprises.
TIP: Traffic graphs can also be seen on the command line using the “iftop” command. The
realtime graphs only show total traffic per interface but if traffic per IP address is needed, then
“iftop” is the tool to use.
Logs Section:
One of the strengths of SmoothWall products is the excellent logging facilities it offers. Everything can be
logged on the SmoothWall. The auditing function, which is enabled in the “network – interfaces –
advanced” section, can be set to record all traffic going to or through the SmoothWall. Logs can be
backed up to an internal or external server using the automatic backup functions in the system section or
SmoothWall can be configured to send logs to a syslog or even send them weekly to an SSH
verver.server.
All logs are saved on the /var/log partition on the SmoothWall. If there is ever the need to look at the raw
logs, they can be found in here or exported from the log viewer web GUI.
System:
The system logs tab shows all system messages. The section drop down list allows the user to select a
specific subsystem to investigate. The messages here are for the various subsystems running on the
SmoothWall – not necessarily logs about what the subsystem does when it runs. For example, the logs
from the Web Filter engine can be seen here, but to see what the web filter itself is logging, you need to
go to the web filter log page.
Ipsec:
The logs showing what the running tunnels are talking about. Later we will have a quick tour of the
IPSEC log messages and what they mean. When using the drop down list to narrow the log display down
to a single tunnel, please bear in mind that sometimes, depending on configuration options and identity
information, the initial first 2-4 messages can be listed under a different tunnel name. This is because the
identity information is not exchanged immediately but a little while into the conversation between the
involved gateways.
Firewall:
All traffic logs are accessed on the “firewall” tab. As on the “system logs” tab, the “firewall” page has a
section drop-down list, where the different types of logs can be accessed. Selecting main in the section
drop down list will display all the traffic that has been blocked by the SmoothWall. Selecting port
forwards in the section drop-down list will display any logs of port forwards. Remember that logging on a
port forward rule needs to be specifically enabled on port forward rules in order for the traffic to show up
in the port forward log. Only the port forwarded traffic will show up in the log, not any replies to a port
forwarded request.
Email:
The processed mails are listed in the maillog viewer.
TIP: When diagnosing SmoothZap issues it may be a good idea to have a quick look at the
/var/log/maillog-[year]-[month]-[day] file, as there is no web interface access to the complete

Coursebook V2008
maillog.
IDS:
Here all IDS logs are displayed. As stated before, only enable relevant rules in the IDS system or the logs
will become large and subsequently time consuming to look through.
Web filter/Web proxy:

The Web Filter tab is available on all Guardian products and on SmoothWall firewalls with
SmoothGuardian installed, the web proxy tab is available when the proxy module is installed. The viewer
page has plenty of sorting and filtering options, so it is possible to get a listing of almost every
combination of search parameters.
Settings section:
Settings:
Here the reports shown on the main page and the information pages are configured. Just tick and save.
The main page is the initial page shown – if the more complicated reports are selected to be shown on the
main page, the main page will take some time to load. The more extensive reports should probably only
be shown on the system summary page in the information section.
Logging Options:
The logging options tab accesses the log settings. On this page, the log system can be set to watch out for
disk space, set retention of the different logs and a syslog server can be configured. One of the options in
the log retention drop down lists are postfixed with the designation “Large” - this option should be used
on busy systems that generate large log files. The option will rotate logs each day, still keeping them for
whatever period is set in the retention options. That should prevent any log from growing to over 2GB in
size as that is the limit where the log subsystem has problems with parsing the log files. Smaller files are
easier for the log viewer pages to display too, so if any slowness is experienced when viewing logs,
setting one of the “Large” options for those logs would also be a good idea.
NOTE: It is a good idea to set the logging options to one of the “Large” options so they rotate
daily, both for Guardian and Zap, in almost all circumstances. It will probably be the default
setting in upcoming versions.
Groups:
This section will allow you to configure the recipients of reports and alert email and SMS messages. To
be able to send SMS messages, access to an SMS gateway provider is needed.

Coursebook V2008
Alert settings:
The alert settings set the values for when the alerts should be generated.
Output settings:
The output settings allows the configuration of smtp servers and sms gateways.
Figure 33: SMS gateway settings
Example pro viders: http://www.intelliso ftware.co .uk

http://clickatell.co m
http://www.24x.co m
http://wo rld-text.co m

Coursebook V2008
Chapter 10: System

The system section holds various options relating to maintenance, administration access diagnostics and a
host of other options not really belonging in any of the other sections of the interface.
Maintenance Section:
Most pages in the maintenance section are self explanatory and will not be elaborated on in this course. If
there is any doubt as to functionality, please refer to the help page for the section.
Updates:
The updates page is for downloading and installing released updates. This procedures for installing
updates has changed in version 2008. Basically the system will download all available updates and install
them in the correct sequence. No longer do you need to install each update separately as the SmoothWall
will take care of all pending updates in one go and in the correct sequence.
Modules:
The modules page is for installing and removing modules. Version 2008 will install any and all modules
that were installed on the previous version, if an in place upgrade is performed.
Licenses:
The licenses page is for refreshing the system licenses. This page needs to be updated when new licenses
for the system has been purchased.
NOTE: If new Guardian licenses have been added, the Guardian module will need to be
restarted, for the new licenses to take effect.
Archives:
This section allows the configuration of various types of archive profiles. Archives can be created that are
meant for replication, configuration backups or log archiving.
When restoring an archive a list of settings contained in the archive is displayed so areas can be
deselected before the restore occurs. Try to mark an archive and press the restore button.
NOTE: When uploading a backup archive to the archives page, remember to enter a name in the
“archive name” field, before uploading it.
NOTE: When restoring settings to new hardware, especially a system with new network cards,
do not restore the ethernet settings section.
Scheduler:

Coursebook V2008
This section allows the user to configure the system to do various tasks automatically. The system can
check for and download any released updates but it will not install them. Automated installation of
updates can be set on the updates page – however the system will not automatically reboot even if an
update requires it. A backup can be taken and both the backup and log files can be archived weekly to an
ssh server.
The “Remote archive destinations” section sets up the remote ssh servers and the “Remote Archival”
section allows the selection of a location and a profile to be executed weekly.
Figure 34: Replication and archiving.
If target is external, the target address must be external too.
TIP: The SSH server receiving the backup files does not need to be on the internal networks.
SmoothWall can send these files to an external server if need be. A reseller of ours is backing up
his customers SmoothWall configuration each week to their own SmoothWall system.
NOTE: When replicating settings or archiving logs, do not enter a target IP that is behind a VPN
where the SmoothWall system is an endpoint. When archiving to external systems, the external
IP address needs to be the target IP.
TIP: When creating archives for remote backup or replication do not include the blocklist or the
download cache options. Blocklists are downloaded automatically daily by Guardian itself and
the download cache is not needed. Omitting these two sections keeps the archive size under 1
MB, which is good for speedy transfers to slave systems or remote archival destinations.
Replication:
The replication page allows the configuration of a SmoothWall system as a master or a slave. A master
replicates settings to the configured slave systems. This is NOT the same as hardware failover setup.
Replication is meant to be used when some settings can be shared between two independent systems, like
web filter settings.
Shutdown Page:

Coursebook V2008
The shutdown page is for remotely rebooting or halting the SmoothWall box. There are timer options on
the page too, so a reboot can be scheduled for off hours. A scheduled reboot can be cancelled as well.
Once a scheduled reboot has been configured, a cancel button will be displayed.
Shell:
When this section is opened, a java ssh client applet is run. This allows the user to connect to the
command line of the SmoothWall system. Java needs to be installed an enabled in the browser for this to
function correctly. Once the java applet has loaded, a login box will be displayed. Log in as root or setup
to access the command line.
NOTE: The setup user does not have a password initially and it is not asked for at installation
time anymore. Log on as root and run the setup program by issuing the command “setup” and
then configure a password for the setup user.
Preferences Section
Fairly small section with a couple of important areas.
User interface:
Various options for the web interface. The description field sets the name shown in the browser title bar –
it does NOT change the hostname of the system. The hostname needs to be changed on the hostname tab
in the same section or in the setup program.
Time:
The SmoothWall can also get time from internet time servers and can function as a time server for the
internal networks. A time proxy if you will. The time service is NTP and it runs on port 123. Remember to
enable all the interfaces you want the time service to be running on.
Also remember to enable the “Save time to RTC” feature if the time needs to be saved to the hardware
clock.
NOTE: When setting the hardware clock in the BIOS, please set the time to GMT time. Once
that is done, the OS will adjust the system time and can also adjust the hardware clock if need be.
TIP: Windows servers can be set to use a NTP time server using the setsntp command.
Remember to restart the time service after issuing the setsntp command.
Upstream proxy:
This setting has nothing to do with the proxy or web filtering services that can run on the SmoothWall
system. This settings is used by the SmoothWall itself when the system tries to register with our
registration servers.
Hostname:
This tab allows the user to change the hostname of the system. A reboot is required for the system to
generate a new SSL certificate used by the HTTPS connections.

Coursebook V2008
Administration Section:
Admin options:
Here the SSH server is enabled. Also, welcome messages can be configured to be displayed both on the
SSH Login and on the web login.
External access:
The term can be a bit misleading as access on the internal interfaces is configured here as well. The list of
ports that can be opened are:
● SMTP (25) This is used to open up 25 for SmoothZap.

● Other HTTP (80) This port serves the block page, proxy.pac and wpad files.
● Admin on HTTP (81) This is the HTTP admin port.
● SNMP (161) This is the SNMP port.
● SSH based admin (222) The SSH port.
● Heartbeat admin on HTTPS (440) This port redirects to the slave system in a heartbeat setup.
● Admin on HTTPS (441) This is the HTTPS admin port.
● Other HTTPS (442) This is the SSL login port and the bypass/unblock port.
● SIP (5060) The incoming SIP proxy port.
● Database (5432) The database port.
All available interfaces will be listed in the interface drop down list as well as the L2TP and the IPSEC
interfaces. If access to any of the services in the above list is accessed from a VPN connection, the
appropriate rules will have to be created.
TIP: Contrary to previous versions of SmoothWall software, rule configurations are NOT deleted
when they are edited.
Passwords:
The passwords section allows the setup of multiple users and permissions. The admin user is the default
user and cannot be removed. If other usernames are wanted, enter them and check the areas the user
should be given access to.
NOTE: If two people are logging in using the same username, user 2 will logout user 1 when he
logs in. Use separate usernames for different administrators, This also has the benefit of being
able to see who was logged in when.
Hardware Section:
The hardware section deals with UPS settings, hardware failover (on Advanced Firewall ), modem
settings and firmware upload to the Thomson Speedtouch ADSL modems.

Coursebook V2008
UPS:
Only APC UPS devices are supported by the UPS software on the SmoothWall systems.
Failover:
This allows two Advanced Firewalls to be setup in Active/Passive failover mode. The failover mechanism
is fairly simple – an interface is configured on both systems to connect the two systems. This interface is
named the heartbeat interface. Configuration information and “are you still well?” questions are
transferred over the heartbeat connection.
Once the connection between the heartbeat interfaces is broken, the slave system will go live and send out
ARP broadcasts to the connected networks to make routers and clients forget about the MAC addresses
associated with the IP addresses configured on the SmoothWall.
To setup two systems in a failover mode, the setup routine needs to be followed to the letter.
1. Install and configure the master system.

2. Select the heartbeat interface in the network - interfaces - interfaces section. Do NOT configure
the heartbeat interface with an IP address on the interfaces page. The IP is set in the system –
hardware – failover section.
3. Configure the failover settings in the system – hardware – failover section. Remember to enable
the master as master and enable the failover.
4. Enable the SSH server in the system – administration – admin options.
5. Reboot the master machine
6. After the reboot, go to the failover section and create the slave archive. Do NOT create the slave
archive before rebooting.
Now the master should be up with the heartbeat service running. Prepare a transfer medium and put the
slave archive on it. A CD or a USB pendrive is probably the best options as the slave archive probably
will not fit on a floppy disk.

Coursebook V2008
Figure 35: Hardware failover
Master
Internal NIC External NIC
Internet
Lo cal Netwo rk
Heartbeat interfaces
Internal NIC External NIC
Slave
Then install the slave system:

1. Install slave system.
2. When asked about restoring settings, select “Yes”
3. Insert the medium with the slave archive and restore settings.
4. Reboot.
After a reboot of the slave, the failover system should be running. Confirm that the slave is accessible by
accessing it using the url: https://master.ip.address:440
Settings will replicate to the slave system every 5 minutes. The time of the last replication will be
displayed on the slave system, however the replicated settings will not be displayed on the slave system
until the slave is brought live.
Updates will be transferred to the slave system and be applied once they have been applied to the master –
however the slave system will not reboot if any of the updates require it – that will need to be initiated by
an administrator.
Once the slave is up and running and accessible on port 440, try putting the master into standby mode.
After about 1-2 seconds, the slave should have taken over. The Slave can then be told to go into standby
made and after 1-2 seconds, the master should have taken over again.
Firmware Upload Page:

Lastly, a firmware upload page allows the user to upload firmware for the Thompson Speedtouch USB
ADSL modems.
Diagnostics Section:
The Diagnostics section has a couple of tools and diagnostics utilities which could prove helpful in
troubleshooting network issues.

Coursebook V2008
Configuration tests:
A set of standard diagnostics that the system can run to perform a self check. A green button next to the
specific test means the test passed and all is OK. A yellow button means the test failed in an inconclusive
way – possibly because the value tested has not been configured. Red buttons indicate a condition that
needs to be addressed.
Diagnostics:
The diagnostics page can generate a text file with most of the configuration files on the SmoothWall
system. This file will be asked for often by SmoothWall support. The diagnostics file contains ownership
information and the serial number and configured IP addresses and network but no passwords or other
sensitive information is included.
The diagnostics file also contains the last 50 lines of the various system logs which can be a great help in
diagnosing web interface issues.
IP Tools:
The IP tools contains a web interface to the “ping” and “traceroute” command. Both useful tools when
troubleshooting network issues.
NOTE: Clients behind the SmoothWall system will not be able to ping the external IP address of
the SmoothWall. Allowing that opens a possible security hole so it has been disabled.
Whois:
A whois lookup can also be done directly from the firewall log viewer – mark an IP address and press the
lookup button at then bottom of the firewall log viewer page. That will link to the whois IP tools page and
run a whois on the selected IP address.
Traffic analysis:
While the realtime traffic statistics viewer and the traffic statistics table shows the amount of traffic going
through the various interfaces, this traffic analysis tool will display exactly what type of traffic that has
passed through the selected interface during the time period specified. This is a good way to find IP
addresses consuming a lot of bandwidth or just to get an overview of what type of traffic is passing
through an interface.
Once the analysis has run for the specified amount of time, the results will be collated and displayed in a
report.

Coursebook V2008
Chapter 11: Command line tools

WARNING: The following section contains command line information. There is nothing about
buttons and mouse clicks!
All SmoothWall products are designed to be managed and configured from the web interface. In order to
successfully manage a SmoothWall firewall, the command line should not be needed. For troubleshooting
purposes however, the command line can prove invaluable. Here we will go through some of the
commands available and the uses the administrator can put those tools to.
Tools for looking at logs and configuration files
grep: Returns lines matching a specified text string from one or more files.
more: Pauses output after one screen has been filled. Press space to advance.
Examples:
#> grep my_word access.log | more
#> grep my_word access.log > newlog.txt
The last example uses the “>” sign to send the output of the command to a text file instead of the monitor.
The “>” sign overwrites the named file with the output of the command.
Using “>>” will append the output to the text file.
head: Return a default or specified number of results at the start of a file

tail: Returns a default or specified number of results at the end of a file.
Can be used in a real-time mode to watch log entries as they are written. Just like the realtime log viewer
in the web interface.
Examples:
#> head –n50 access.log
Displays the first 50 lines of the access.log file.
#> tail –f access.log

Displays the last lines and shows new lines as they are added.
Network Related Tools

Listening for traffic can be a great help when troubleshooting network issues. Here are some of the
commands that can be used on the SmoothWall to listen and display what traffic is reaching any of the
SmoothWall interfaces.
tcpdump: Listen to TCP traffic on one or more interface.
arp: Displays and modifies MAC addresses.
route: List and add routes.

Coursebook V2008
Examples:
#> tcpdump -nqi ethB port 80
Displays all traffic reaching ethB on port 80.
#> tcpdump -nqi ethB host 1.1.1.1 and not port 222
Displays all traffic reaching ethB with 1.1.1.1 as either destination or source and does not display any
packets for port 222 – this can be useful when remotely connected using ssh.
iftop: Monitor network traffic on any interface.

trafficmon: Show SmoothTraffic statistics on the command line.
Examples:
#> iftop -ni ethB
Displays all traffic going through ethB.
#> TERM=linux
#> trafficmon
Show the SmoothTraffic realtime statistics in color.
scp: Securely transfer files.

netstat: Show active connections on the system.
history: shows the last 300 commands the logged in user has issued. The history
file is cleared on reboots.
Examples:
#> scp -P 222 file.txt root@smoothwall.ip.address:/tmp
Transfers the file file.txt to the /tmp directory on the SmoothWall.
TIP: All the above commands have multiple options that can be used. Search on Google for the
commands to learn more, or issue the command “man command-name” on a standard Linux
system.
TIP: All commands are stopped pressing CTRL+C.
SmoothWall file system overview.

While all SmoothWall systems are designed to be managed using the web interface, it can sometimes be
useful to look at the command line and the filesystem to troubleshoot issues. In order to do that, a few bits

Coursebook V2008
of knowledge about the SmoothWall systems and their structure is needed.
The most interesting directories would be:
/modules All modular features are installed in the “/modules”. By modular features, we
mean all the features that can be removed on the modules page.
/archives All module archives and the initial install image.
/settings All settings for the SmoothWall system. No module settings.
/var/log All logs are in here and in subdirectories.
All the modules are run in a chrooted environment. This means that the process only has access to a
limited filesystem, containing only the libraries and files the module needs to run.
This means that if any subsystem is hacked, then other areas on the firewall are still unaccessible to the
hacker, as the hacked process is unaware and unable to access the rest of the system.
Figure 36: CHROOT environments
DNS Pro xy server ro o t:

/mo dules/dnspro xy/
Mo dules canno t access IPSEC system ro o t:

Filesystem ro o t. filesystem abo ve o wn ro o t /mo dules/tunnel/
/
Web Pro xy ro o t:
/mo dules/pro xy/
The Way it all works

The way the SmoothWall interface works is to take all the configuration information input on the web
interface and store it in settings or config files. These files are normal text files that basically just lists
what ever has been entered on the web interface.
Then, the config writer programs take over, parses the flat text files that are written by the web interface
and creates the various config files needed by the system services. For this reason, changing the system
services config files, like dhcpd.conf and squid.conf directly is a bad idea as the config file will be
rewritten when a change is made in the web interface.
Changing settings multiple times in most areas can be done safely, as the configuration files are normally
only written at service restart.

Coursebook V2008
Chapter 12: Authentication

The authentication service on the SmoothWall products can connect to various LDAP based directory
services and can validate the existing usernames and passwords that exist in the directory.
Authentication is part of the base package of every SmoothWall product, but the functionality is not the
same on every product. Here is a list of what SmoothAuth can do on the various SmoothWall products.
Advanced Firewall
Directory integration Authentication can connect to a directory server
Group Bridging Internal access rules can be applied based on logged in users.
Outgoing Rules Can apply rule sets based on logged in users.
SmoothGuardian Can set web browsing permissions based on logged in users.
Corporate Firewall
School Guardian
Directory integration Authentication can connect to a directory server.
Group Bridging internal access rules can be applied based on logged in users.
Network Guardian
Directory integration Authentication can connect to a directory server.
Guardian Can set web browsing permissions based on logged in users.
Directories and LDAP.

Directories comes in many shapes and forms. All of them use a form of LDAP to hold the directory
information.
Connecting to Microsoft Active Directory

To connect to an Active Directory domain, the following prerequisites must be in place.
• Give the SmoothWall a hostname in the Active Directory Domain – this is done in the setup
program or in the hostname tab in system - preferences. Remember to add the domain name to the
hostname. This shows the SmoothWall what domain it should be looking at to find the Active
Directory servers.
• Make sure the DNS server that holds the Active Directory information has a reverse lookup zone
for the Active Directory subnet(s) and that the Active Directory servers have a PTR record in the
reverse lookup zone.
• The SmoothWall needs to be told to use the DNS servers that hold the Active Directory
information.
• Make sure the system time on the SmoothWall is within 5 minutes of the system time on the
Active Directory servers.

Coursebook V2008
• If NTLM Authentication is used, make sure the SmoothWall hostname is added to the AD DNS
server and that the system also has a PTR record.
• If NTLM Authentiction is to be used, make sure the lookup user has the right to add a computer to
the domain.
Figure 37: Typical Active Directory connection settings
Multiple domain setup.

When configuring authentication to integrate to a domain tree, rather than a single domain, things can get
complicated. Have a look at the advanced options:
Figure 38: Advanced Active Directory connection settings
If The AD DNS structure is co rrectly set up, just enable the auto matic realm disco very o ptio n:
It m ay be needed to narro w the gro up search path, as listing m o re than a co uple o f hundred gro ups in
the web gui will be to o cumberso m e.
Use the fields belo w IF the abo ve o ptio n do es no t give the desired result OR the number o f retrieved
gro ups needs to be limited. Disable the o ptio n abo ve if entering data in the fields belo w.

Coursebook V2008
There are a couple of issues that will prevent the Active Directory connection from working correctly. If
the Active Directory domain has been migrated from a previous NT4 domain, the users will likely only
have the old NT4 usernames. The migration does not automatically fill in Windows 2000 domain
usernames. Make sure the Active Directory has Windows 20000 domain style usernames for all users that
need to be authenticated.
Figure 39: Windows 2000 account properties
If Multiple domain lookup fails.

If domains have been installed and configured, but the Active directory still contains references to them,
using the automatic kerberos realm discovery feature may fail or time out. In those cases, try to specify
the domains explicitly in the advanced section.
Lastly, if the AD is big and has over 1000 groups in any of the domains, it may be necessary to limit the
lookup to only list certain LDAP paths to limit the number of groups displayed in the Web GUI.
Connecting to Novell eDirectory

Connecting to a Novell eDirectory is a bit simpler. There are no implicit DNS requirements apart from the
SmoothWall naturally has to be able to resolve the eDirectory server hostname if that has been entered in
the SmoothAuth settings. An IP address can also be entered in the LDAP server settings.
The username needs to be specified in the LDAP format, like shown in figure 40 but apart from this, no
other prerequisites are needed.
Figure 40: Typical Novel eDirectory connection settings

Coursebook V2008
As eDirectory does not use kerberos and subdmains, DNS is less important and server hostnames CAN be
given as IP addresses.
Figure 41: Advanced Novell eDirectory connection settings
It m ay be needed to narro w the gro up search path, as listing m o re than a co uple

o f hundred gro ups in the web gui will be to o cumberso m e.
Use the fields if the number o f retrieved gro ups needs to be limited o r extra
o rganisatio nal units needs to be included.
Additional organisational units and other branches in the directory can be specified in the advanced fields
– all branches has to be part of the same ldap root.
It is recommended to use TLS for authentication as most directories will not authenticate passwords for
users is the requestor has not authenticated himself in some way.
Connecting to Open LDAP

Open LDAP can be even simpler than the other directories above, but if the Open LDAP also has
Kerberos attached to it, the same requirement as for the AD connection setup applies.
Using an OpenLDAP server to simulate a Windows domain controller will probably require a
configuration closer to the Active Directory example.
Figure 42: Typical OpenLDAP connection settings
As with the Novell eDirectory, the advanced settings covers the same options and the notes for them are

Coursebook V2008
the same.
Figure 43: Advanced OpenLDAP connection settings
It m ay be needed to narro w the gro up search path, as listing m o re than a co uple o f hundred
gro ups in the web gui will be to o cumberso me.
Use the fields if the number o f retrieved gro ups needs to be lim ited o r extra
o rganisatio nal units needs to be included.
Using Local Users

It is also possible to use the user list in the Auth section to configure usernames and password, instead of
retrieving them from a directory server.
The local users list can also be used in conjunction with a directory server lookup – in case of duplicate
usernames, the local users list takes precedence. This also means that the local users list can be used to
override the directory lookup for specified users, allowing an administrator to quickly add a user to a
group, without having to make any changes to the directory server – adding a username to the banned
users group in the local users list will immediately ban the user, no matter what group the user is part of in
the directory.
Username syntax and considerations

The way the various directory services store and reference usernames is different from directory to
directory. This has implications when users need to enter username for authentication. If we look at the
SSL login page, the username format examples would be:
Active Directory top level domain: username or username@domain.local

Active Directory sub level domain: username@subdomain.domain.local
eDirectory: username.context.organisation or
cn=username,ou=context,o=organisation
OpenLDAP: cn=username,ou=context,o=organisation
This affects most customers when they are using Guardian with any form of authentication. NTLM
authentication will just transmit the username (Not the domain) so NTLM cannot be used in multi domain
environments.
NTLM is also a Windows proprietary protocol and will not work with eDirectory or OpenLDAP. NTLM

Coursebook V2008
is actually NT4 Lan Manager technology so it is fairly old and even Microsoft is phasing it out slowly as
it is not really suited for Windows 2000+ environments.
SmoothWall recommends the use of the SSL Login page or Ident method for setting up authentication in
environments where NTLM is not wanted or otherwise unsuitable.
The SSL Login application available on https://support.smoothwall.net can be used to setup transparent
authentication when users log in to their Windows workstations – the application comes with setup
instructions for domain deployment and a user tool to setup initial parameters.
Another method we have had success with is to use this ident server software:
http://www.softpedia.com/progDownload/Windows-Ident-Server-Download-21005.html
This server can be told to read the Ident response from a file. We assisted a customer to create a logon
script that write the username in the correct format to this file. Ident would then send the username to
Guardian once it asked and the user got identified correctly – all transparently and done with standard and
well documented tools. Ident servers are available for all platforms, the one mentioned above is for
Windows.

Coursebook V2008
Chapter 13: SmoothTunnel VPN

VPN has become an essential component of most every network during the last 5 years. Multiple
technologies exist – SSL VPN, IPSEC VPN and a host of other proprietary or open source VPN type
solutions. Initially SmoothTunnel only supported IPSEC tunnels but over time L2TP support was added
and now SmoothWall has also added OpenSSL VPN to SmoothTunnel. The main reason for adding
OpenSSL VPN was to alleviate some of the drawbacks the road warrior IPSEC and L2TP based
connections have. IPSEC road warrior connections needs a third party client and can be difficult to
configure. Furthermore third party clients rarely have option to use a new DNS server once connected
which is a drawback when connecting to Active Directory networks.
L2TP connections work well but multiple L2TP clients behind the same NAT endpoint does not work
which can be a drawback depending on usage patterns.
The OpenSSL connections does not suffer from any of the above mentioned issues. OpenSSL connections
are fairly secure and uses normal TCP or UDP, are easy to setup and supports the use of a separate DNS
server once connected. If any of the limitations of IPSEC or L2TP based road warrior connections are
encountered, using the OpenSSL client is a sound and valid choice.
About NAT
The introduction of NAT introduced some problems to IPSEC as the protocols used for transmitting the
encrypted data have no ports. With no ports to assign, NAT has a hard time keeping track of what packets
belong to where. In order to allow IPSEC to succeed in connecting through a NAT device, a NAT
application helper was concocted, like the FTP helper and the IRC helper. Helper application would
identify and tag the IPSEC traffic, so the IPSEC protocols could pass through the NAT without any errors.
That solution was not sufficient however. NAT was becoming more and more widespread and often the
IPSEC client would have no way of influencing the NAT device if the VPN connection did not work. A
client trying to connect from a hotel room, for example, would not be able to get the hotel IT staff to
troubleshoot their NAT device, in case of connection problems.
NAT-Traversal
A solution that did not rely on the NAT device was needed and a fairly simple solution was found. Instead
of using the standard IPSEC protocol directly they would become embedded in UDP packets, solving the
issue of the IPSEC protocols being portless and allowing NAT to correctly map connections. This solution
was called NAT-Traversal. Both the client and the gateway need to support it, but nothing needs to be
configured on any NAT device the traffic is passing. This is now the preferred method of passing through
NAT devices for all major vendors of IPSEC software and devices.
IPSEC Helpers
However, the old IPSEC/VPN application helpers were not removed from most black box devices – most
manufacturers apparently felt it would be removing a feature and would make their products less
competitive – which is kind of a paradox: “IPSEC Helpers break VPN connections that rely on NAT
Traversal, but we can’t remove it, because our competitors also break VPN connections.”
Fairly typical example of how sales and marketing completely disregards reality sometimes :)
In fairness the NAT Traversal technology took a little time to become universally adopted so keeping the

Coursebook V2008
helpers around was probably a good idea – however on some vendors boxes the helpers could not be
deactivated. By now most manufacturers have either removed the feature as it is by now deprecated or
they have at least put in an option to disable VPN/IPSEC passthrough.
IPSEC Ports and Protocols:

Phase 1, ISAKMP or IKE. UDP 500: This port is used for the initial contact.
Phase 2 or IPSEC. UDP 4500: This is the NAT traversal port. Used instead of
ESP when NAT is detected.
ESP: Protocol 50 is a specific IPSEC protocol and has no
ports. Used when no NAT is detected.
OpenVPN ports: TCP 443: The HTTPS port can be used by OpenVPN clients.
UDP 1194: Second option for OpenVPN client port.
Other ports: TCP 1701: L2TP port. Encapsulated in ESP or UDP 4500
when using L2TP over IPSEC.
TCP 1723: PPTP port. Not used by IPSEC but can be seen
hitting the firewall when L2TP clients first connect as the
connection will try PPTP first, unless specifically configured
not to.
GRE: Protocol 47 is the data transfer protocol of PPTP.
SmoothWall VPN
The SmoothWall VPN module comes as standard on the Advanced Firewall with 20 configuration
licenses. On Corporate Firewall and SchoolGuardian the tunnel module have 1 connection license as
standard. The tunnel licensing is for the number of configured tunnels – not concurrent users.
The OpenVPN licensing is included – the amount of IP's given out by the OpenVPN subsystem to
connected clients will also be limited by the number of tunnel licenses but here one can have more
configured clients than licenses.
NOTE: The OpenVPN requires a license pack to work. OpenVPN will not be functional using
only the built in single license that comes with Corporate Firewall or SchoolGuardian.
Authenticating an IPSEC Connection

With all security protocols, authentication and verification of identities is paramount. There is very little
point in having secure data transmissions if there is no way to tell if the secure data stream is being
received by the right party. Verifying the remote identity can be done using certificates or pre-shared keys
along with an ID value that helps the IPSEC system to quickly identify what connection is being used.
Pre-Shared Keys
The simplest authentication method is using Pre-Shared Keys. A Pre-Shared Key, or PSK for short, is just
a string that both peers have access to. The PSK is actually not the “password” that authenticates both
sides to each other – it is the encryption key, the seed used to encrypt the traffic. The authentication is
done using the IDs of the systems involved.
Self Signed Certificates

Coursebook V2008
X.509 certificates can also be used. This authentication method is the SmoothWall preferred method. The
SmoothTunnel module can create self signed certificates for this purpose. Security wise this is a far better
option than using PSK.
Third-party Signed Certificates

SmoothTunnel can also import certificates created by a third party. Using a public certificate authority to
verify the certificates is the most secure option.
Other Identification Factors

All other information contained in the tunnel configuration is also compared when a peer tries to connect.
The subnet information contained in the tunnel configuration has to be the same on both peers and so do
the encryption protocols and options used. Key life can be set differently and does not have to match.
TIP: It will probably be a good idea to have a worksheet where tunnel information can be noted
down. A Tunnel Worksheet for every configured tunnel could be distributed to remote site
administrators and for local storage, in case tunnels need to be restored.
Certificates Examined
Digital certificates are becoming more and more common, but not a lot of people know what they are and
how they work. Hopefully, this section will shed some light on what they are and how they are used.
RSA Encryption Basics

Certificates are a way to package encryption keys. Along with the encryption keys, the certificate also has
information about the certificate holder’s identity. The keys are what we will be talking about in this first
part.
A complete certificate comes with 2 keys: a private key and a public key. As the name implies, the public
key can be made available to anyone. The public key is used to encrypt any messages sent to the holder of
the private key. The only key that can decrypt this message is the private key. This is the basic principle
behind public-private key encryption. An analogy could be padlocks - I have lots of padlocks, but only
one key. I give away all the padlocks to the people that need to send me packages that no one else should
be able to open. They secure the packages with a padlock, send it to me, and I can then open the package
with my padlock key.
The reason behind creating the public-private encryption scheme was security. If the same key was to be
used for both encryption and decryption, the key would have to be kept secret and only given to trusted
parties. As soon as a key became compromised, it would have to be substituted. Handing over keys to
trusted parties also posed a problem. The key might be intercepted in transit or disclosed to other parties,
while being transferred between the trusted parties. Using a public-private key encryption scheme negates
the problem of transferring a key to the trusted parties that need to be able to communicate securely. As
the public key cannot decrypt anything, transferring the public key is not a security risk.
Certificate Authorities
A Certificate Authority can be loosely compared to a passport issuing authority. A country will issue a
passport to a citizen. To verify that the passport is genuine and that the holder is the same person that is

Coursebook V2008
depicted in the passport, one can contact the issuing country and examine the passport. If a country ceases
to be, the passports from that country are worthless. So the comparison to countries and passports is a
good analogy to keep in mind, since a CA is really just another form of certificate, which tends to be a bit
confusing.
The reason why a CA is needed should also become apparent if one considers the passport analogy.
Without an issuing government, a person could just write his name on a piece of paper, attach a photo and
try to use this as proof of identity. A paper like that would probably not allow you through any passport
control stations. There needs to be a third party involved that will vouch for the correctness of the
information contained in the passport, or in our case, certificate. This is what companies like Verisign and
Thawte does - They can issue your company a digital CA, signed by them. Their signature on your CA
and subsequent certificates is the third party involved. They vouch for the authenticity of the certificates
created by the CA they have delivered or signed.
Figure 44: CA certificates
Certificate Autho rity issues certificates.

Certificate Autho rity public key validates certificates issued.
Certificates
As previously stated, a certificate has ownership information and 2 keys: a public and a private key. Any
information encrypted with the public key can only be decrypted using the private key - it is therefore
important to keep the private key private and inaccessible to others. The public key, on the other hand,
can be published widely.
Apart from the encryption keys, the certificate also has text information about the holder of the certificate.
That information is called the certificate subject and the certificate alternative subject. When creating a
certificate a number of fields need to be filled. The fields will be name, email, country, state, location,
department and so on. All meant to be used as identity information. The certificate subject consists of all
those values concatenated on a single line like this:
Figure 45: Certificate Subject
Certificate Subject:
C=UK/ST=Hampshire/L=Soton/O=SmoothWall Ltd/OU=Support/
CN=Soton SmoothWall/emailAddress=support@smoothwall.net

Coursebook V2008
Certificate ID type and value(Alternative Subject)
Another value is also added, the certificate ID. This is a single value, where both type and value is
specified at certificate creation time. The types of values that can be used are email address, host and
domain name and IP address. The reason for the certificate ID is to have a brief string as an identifier,
instead of using the full certificate subject. The certificate ID is also the value we recommend using when
setting up SmoothTunnel VPN connections. It looks like this:
Figure 46: Certificate ID type and value (Alternate Name)
Certificate ID type and ID value.

There are three ID types that can be used:
Host and domain name: DNS:vpngateway.domain.com

IP Address: IP: 1.2.3.4
E-mail address: email:user@domain.com
Specifying the alternative subject is easier than using the whole certificate subject, especially since the
formatting of the full certificate subject can vary from implementation to implementation.
Using the passport analogy, the certificate subject and certificate alternative subject can be compared to
all the text information in the passport, which serves to identify the holder. The authenticity of the
passport is verified by the physical passport itself and the picture of the holder. The picture can in some
ways be compared to the public and private key. Anyone can see the picture but only the holder looks like
the picture.
Figure 47: Certificate information
Creating and Using Certificates on the SmoothWall

The SmoothTunnel module can create a self-signed CA and issue certificates based on that CA. Creating
a self-signed CA means that no third party is involved in verifying the authenticity of the CA and
certificates issued by that CA. This is adequate in most cases, where the certificates are mainly used by
the VPN gateways and road warrior connections configured on the SmoothTunnel.
However, the SmoothTunnel is not a certificate server in itself. It can create a self-signed CA and issue
certificates, but there is no Web enrollment facilities or certificate revocation lists. For that reason, relying

Coursebook V2008
on the SmoothTunnel as a PKI certificate server is not a good idea. Better to use a proper certificate
server if that is the case.
Certificates generated by a certificate server can be imported on the SmoothTunnel and used, just like
certificates issued by the SmoothTunnel itself. Remember to import the CA for the certificates imported,
as the SmoothTunnel does not have a list of standard CA certificates installed.
The first step before starting CA and certificate creation on the SmoothTunnel is always to check system
time. Navigate the web interface on the SmoothWall and go to "Preferences - Time". Make sure the
proper time zone and local time are set correctly. If any changes have been made, reboot the SmoothWall.
Once time has been set correctly the CA can be created and certificates issued. First create a CA - notice
that the ownership information entered when installing the SmoothWall will be pre-filled in the relevant
fields. This can be changed if need be.
Once the CA has been created on the SmoothTunnel, certificates can now be issued. Remember that the
CA is not a certificate in the traditional sense, so even if a CA has been created a certificate will still need
to be created for the SmoothTunnel itself. An initial setup of 2 SmoothWall firewalls connecting via a
VPN would be 1 CA and 2 certificates. One certificate for each SmoothTunnel.
NOTE: Sometimes a warning will be seen in the IPSEC logs, stating that “No CRL list found”
or other reference to CRL. CRL stands for Certificate Revocation List. This error is not fatal it
only means that the IPSEC system tries to check validity of the installed certificates, but is
unable to, as the SmoothTunnel is not a certificate server and does not keep revocation lists.
Figure 48: No crl found or crl update overdue
Hopefully this section will have explained a bit about certificates and what they are. Using certificates is
not hard - it just takes time to learn the terminology and the relationships between CA and certificates.
NOTE: In previous versions, Certificate Subject Alternate Name was referred to in the local ID
type drop down list. This has now been changed to “Default local Certificate ID”.
NOTE: The drop down list “Authenticate by” has an option to authenticate by “Any locally
signed certificate” - That phrasing is somewhat confusing as the certificates do not have to be
signed locally for that option to be valid. The phrasing should be “Certificate provided by peer” -
this will get changed in an upcoming update.
Setting up Tunnels
The manual, setup guide, course slide and on-line help have very detailed walkthroughs of setting up
tunnels, so we will not be detailing the procedure here. Instead, we will be looking at common errors and
pitfalls, as well as best practises, when setting up IPSEC tunnel connections. We will also be explaining
the inner workings of the IPSEC protocols briefly.

Coursebook V2008
Planning and Preparing
Authentication – What authentication method will be used? Decide on certificates or PSK authentication
as early as possible. Certificates, which are the recommended way of authenticating SmoothTunnel
IPSEC tunnels, require some additional planning. Where will the CA be created and will this CA be
responsible for all certificates or is there a need for all the locations to have their own CA?
Naming conventions for the certificate ID value should also be decided upon, so there is consistent
naming on the issued certificates.
Finally, make sure the system time is set correctly before creating any CA or certificates.
NOTE: Most IPSEC capable devices does not support certificate authentication, so when
interoperating with those devices, PSK will have to be used.
NOTE: When using L2TP over IPSEC connections, the certificate the client is using has to be
created by the same CA that created the certificate used on the SmoothTunnel. This is the reason
for the “Local Certificate” field on the L2TP configuration screen.
Then examine the connection methods of the involved SmoothTunnels. Are any of the SmoothWall
devices behind a NAT device? NAT and IPSEC do not always coexist peacefully, so it's essential to know
if there is a NAT device in play.
A good look at the subnets that are to be connected is also a priority. This part of the planning stage is not
so much IPSEC related, technology wise. Routing is the issue to be examined here, so during this phase,
try to stay away from IPSEC specific technologies, as they have no impact on routing. When a tunnel is
up, it is transparent to the network and works just like a network cable connecting the two networks.
Adding a tunnel is basically just adding a route so try to isolate routing issues from IPSEC configuration,
as those two often gets mixed up and tend to confuse troubleshooting and planning at times.
Example: Creating a subnet tunnel between two locations that each use the same subnet will not
work. This is fairly evident when the problem is looked at as a routing issue, but not if the
problem is looked at from an IPSEC point of view.
Implementation
When the circumstances surrounding the IPSEC setup has been investigated, it's time to plan
implementing the tunnels. Some situations require special considerations when configuring the tunnel –
we will look at the most common scenarios here:
Dynamic IP addresses
Some obvious measures have to be taken when connecting to a SmoothTunnel that is using a dynamic IP
address. For the most stable solution, at least one of the SmoothTunnels should have a static IP address.
1 dynamic IP address
Set the SmoothTunnel with the dynamic IP address to initiate the tunnel. On the SmoothTunnel with a
static IP address, do not specify remote IP or hostname, just leave that field blank.

Coursebook V2008
Figure 49: Tunnel setup with one peer at dynamic IP address or one peer behind NAT.
Tunnel initiates fro m Smo o thWall with Dynamic IP o r behind NAT
Smo o thWall with Dynamic IP address. On peer, tunnel co nfiguratio n is do ne

with no remo te IP address.
2 dynamic IP addresses
When dealing with 2 dynamic IP addresses, dynamic DNS hostnames needs to be used. The snag here is
that the SmoothTunnel only looks up hostnames when the IPSEC subsystem is restarted. This creates an
obvious problem, if one of the SmoothTunnels has been disconnected and then connects again on a new
IP. The reconnected SmoothTunnel will try to contact the peer, but the peer will try to send its response to
the IP address it last found when looking up the hostname.
Figure 50: Tunnel setup with both SmoothWalls on dynamic IP.
Lo o kup o n Peer DNS name is do ne at VPN system start

Tunnel co nnects using dynamic DNS name to find peer
Peer disco nnects and tunnel is bro ken
Peer reco nnects with new IP address, lo o ks up peer IP and initiates co nnectio n
Reply to peer go es to o riginal IP address

VPN System needs to be restarted fo r new DNS nam e lo o kup
There is no easy solution to this issue currently. One way of handling this is to set up the most stable
connection as the “static” peer and let the remaining SmoothTunnels initiate the connection. When set up
this way, the only step needed to bring up a failed tunnel, would be to restart the VPN on the peer
SmoothTunnels that receive the connection.
Dynamic IP on Road Warrior gateway

When the SmoothTunnel is only used for accepting incoming L2TP or IPSEC Road Warrior connections,
a dynamic IP can be safely used. A dynamic DNS hostname will need to be obtained, but as the Road
Warriors will initiate the connection every time, the change of IP address will not affect them as it does a
SmoothTunnel subnet to subnet connection.

Coursebook V2008
NAT
The general advice here is to get rid of the NAT device. When dealing with IPSEC subnet tunnels, we
assume the tunnel is mission critical so any potential problem should be eliminated if possible. If
removing the NAT device is not an option, it will have to be factored into the connection settings.
If both endpoints of a tunnel are behind NAT devices, removing at least one of the NAT devices becomes
essential, depending on the features of the NAT device.
With one SmoothTunnel behind a NAT device, that SmoothTunnel should be set to initiate the
connection. The SmoothTunnel on a real IP address will not be able to initiate connections to the
SmoothWall behind a NAT, unless port forwards has been configured. Even with port forwards in place, it
is still a good idea to initiate the connection from the SmoothTunnel behind the NAT device.
If two SmoothTunnels are behind a NAT, port forwards becomes essential. Forward UDP ports 500, 4500
and the protocol ESP to the SmoothTunnels behind the NAT devices. Disable any IPSEC pass through
features that the NAT device may have and try to connect. There is no guarantee this will work in every
case, so please try to avoid having both endpoints of an IPSEC tunnel behind a NAT.
NOTE: This applies to IPSEC subnet tunnels but only partially to IPSEC Road Warriors and
L2TP connections. When setting up a SmoothTunnel to accept Road Warrior connections,
NEVER use a NAT device in front of the SmoothWall.
L2TP and IPSEC Road Warriors and NAT

When dealing with L2TP and IPSEC Road Warrior connections, never use a NAT device in front of the
SmoothTunnel that is to accept these connections. With IPSEC road Warrior connections it MAY work, if
the port forwards mentioned earlier are in effect, but there is no guarantee and depends on the NAT device
and its capabilities. With L2TP connections, having the SmoothTunnel behind a NAT will not work.
L2TP has another limitation when NAT is in play, this time if the NAT device is in front of the client.
Only one L2TP connection can be made from behind a NAT device. It is currently not possible to connect
2 or more L2TP clients, if they all are originating from the same IP address.
Secondly, and often more importantly, when an L2TP connection is in place from behind a NAT device,
any other connections made to the SmoothTunnel, from the NAT device, will have the replies routed back
through the L2TP tunnel.
Both are limitations we have very little control over but are looking to overcome in later versions of our
product.

Coursebook V2008
Figure 51: L2TP Limitations
L2TP client 1
Smo o thWall L2TP client 1 co nnects NAT Device
L2TP client 2 is stopped L2TP client 2
Client tries accessing server ho sted behind Sm o o thWall

No rmal client
Reply gets sent do wn L2TP tunnel. Reply never reaches client.
Issues when Renegotiating the Connections

The encryption keys used by the tunnel are renegotiated regularly. This renegotiation can sometimes
cause issues, especially when dealing with IPSEC Road Warriors. In the Road Warrior situation, when a
connection is going through a NAT device and that connection has been idle for awhile, the NAT device
may forget the state of the VPN connection, refusing any contact initiated from the SmoothTunnel. This
causes the IPSEC connection to time out, as the SmoothTunnel will assume the peer is not available.
The solution here is to enable the option “Do not rekey” in the advanced section of the tunnel
configuration. This will instruct the SmoothWall not to try to renegotiate the connection and wait until the
peer initiates the renegotiation.
This scenario has also been seen when trying to interoperate with other vendors IPSEC implementation.
In those cases, it is not a case of a NAT device not allowing the connection through, it's more a case of the
peer IPSEC device not responding correctly or not understanding the SmoothTunnels request for a
renegotiation to take place. Again, setting the key life to 0 for the specific tunnel will resolve the issue.
Troubleshooting IPSEC Connections

The sheer amount of factors to take into consideration is often the main factor that prevents successful
resolution of IPSEC tunnel issues.
The first step to successfully resolving IPSEC tunnel issues is always to check the control page. If the
tunnel is shown as open at both ends, the issue quickly becomes one of routing and access rules. Make
sure a Zone Bridging rule has been configured that allows access to the network from the IPSEC or L2TP
interfaces.
If the tunnel is shown as closed and even pressing the up button does not open the tunnel, the logs will
have to be consulted. Note that we used the plural for log here because both system IPSEC logs should be
looked at and there is a very good reason for that. Unlike other connection types, the IPSEC system does
not give specific errors to the peer when the tunnel parameters are not correct. This is to prevent a

Coursebook V2008
possible attacker getting information by trying repeatedly to connect to the IPSEC gateway. We do not
want the system to tell a possible attacker what ID value to use or what subnet he should be connecting
from or to. The local logs will show any configuration problems, but the peer log will mainly just show a
message of “INVALID_ID INFORMATION”. For this reason, the IPSEC logs on both systems should be
looked at when troubleshooting any IPSEC tunnel.
Understanding the IPSEC Logs

Another good trick when examining the IPSEC logs, especially on systems with more than one
connection running, is to select the specific connection name in the log viewer and update the logs. That
will only show log entries from the connection selected and thus improve the overview considerably.
Error Messages and what they signify

No answer messages, No acceptable response or similar....
Any messages stating that a connection is being tried (main mode initiated) and reporting that no answer
is getting back is likely caused by the Peer side not responding at all. Common causes for this will be that
the VPN engine is not running or the Peer IP address has been set wrong in the configuration of the
Tunnel. Comparing the two logs should reveal this soon enough. If there are no entries in the Peer log,
one of the above explanations should be examined. The "No Acceptable Response" messages can also be
indicative of NAT problems. See the explanations offered in the next message group.
Incomplete ISAKMP, Part of previous message, Phase 1 reply received but already at
phase 2 or similar...
If any part of the above messages is displayed in the logs, this will most likely be due to NAT or network
port access problems. If dealing with a Road Warrior type configuration the peer end will possibly have
"No Acceptable Response" messages or "No reply" messages in the log. If you are dealing with a client
behind a firewall doing NAT, the obvious answer would be that the firewall in front of the client has
IPSEC-Passthrough enabled. Please have a look at our knowledge base for a discussion on solving IPSEC
Passthrough problems. Use the link provided in the URL list at the bottom of this document.
No Proposal Chosen
If this error shows up at either end of the connection, the most likely cause of problems are incompatible
encryption settings. On a SmoothWall to SmoothWall tunnel, the error is most likely that compression has
been enabled on either of the ends, and not enabled on the other. If you are trying a Road Warrior
connection or a connection to a VPN Gateway from another vendor, double check all the encryption
algorithm settings and make sure they are the same on both endpoints.
Invalid ID, No connection known errors or similar....
Check for any mismatch between IP Subnet settings and ID value settings in the tunnel configuration. The
subnet definitions and, in case of a Road Warrior, the IP allocated to the Road Warrior, must match on
both ends. Also check that the ID Value used by certificate authentication is entered correctly. Bring up
both configuration screens at the same time, to better be able to compare them. In case of an L2TP
connection, make sure you have selected the certificate issued to the L2TP client in the "Authenticate by"
field, instead of "Certificate Provided by Peer".
No key known, Cannot load my private key, No public key known for, or similar...
Errors like those, popping up in the log, almost certainly has to do with invalid certificates. Check the
time and date on the SmoothWall systems and that the certificates are valid with the current date and time
set. Also check that the CA has been installed on each SmoothWall and Road Warrior that needs access to
the CA certificate to be able to verify the validity of the created certificates.

Coursebook V2008
The above pointers should get the troubleshooting started at the right track. Remember of course, that
multiple configuration errors can exist, and that when one error is corrected, the next might show up in
the log, but with the above pointers, you should at least be able to move on to the next type of error,
instead of trying to correct the wrong parameters.
IPSEC Log example

The following snippet of the IPSEC log shows a connection attempt succeeding in establishing the IPSEC
security association.
The first phase, called IKE for Internet Key Exchange ends successfully when the message ISAKMP SA
established.
#1: responding to Main Mode
#1: transition from state (null) to state STATE_MAIN_R1
#1: NAT-Traversal: Result using RFC 3947: no NAT detected
#1: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
#1: Main mode peer ID is ID_FQDN: '@soton.smoothwall.net'
#1: Issuer CRL not found
#1: Issuer CRL not found
#1: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
#1: sent MR3, ISAKMP SA established
After the Phase 1 or IKE phase has concluded successfully, the IPSEC phase is next: The dual entries
seen in the logs are each of the peers concluding their own phases of the negotiation.
#2: initiating Quick Mode RSASIG+ENCRYPT+COMPRESS+TUNNEL+PFS+DISABLEARRIVALCHECK
#3: responding to Quick Mode
#3: transition from state (null) to state STATE_QUICK_R1
#2: transition from state STATE_QUICK_I1 to state STATE_QUICK_I2
#2: sent QI2, IPsec SA established
#3: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
#3: IPsec SA established
As with the IKE phase, the IPSEC phase is concluded successfully with the message of “IPSEC SA
Established”.
L2TP logging
The L2TP connections are actually first using IPSEC and then, once the IPSEC tunnel is established,
L2TP inside the IPSEC tunnel. For this reason, there are 2 places to check logs for the L2TP connections.
The first part will be seen in the IPSEC logs section and the second part can be found in information –
logs – system. Select L2TP PPP in the section drop down list and press update to see the latest L2TP PPP
logs.
Other considerations:
One consideration that often surprises clients is that the Windows Network Neighbourhood is not
populated when using IPSEC or L2TP connections. The Windows Network Neighbourhood relies on
broadcasts, which are not sent over the VPN.
There are various means available, depending on the client software, to resolve this. When using the
L2TP connections, make sure the global settings on the SmoothTunnel specifies internal DNS and/or
WINS servers to use. Third party IPSEC clients will often have a setting to use a different DNS server
when connected – search for these settings when setting up a third party client. If there is no such setting

Coursebook V2008
on the client software a hostfile will need to be used if the client needs to access servers by hostname.
OpenVPN Setup
As mentioned in the introduction, OpenVPN has been included in the VPN functionality on SmoothWall
firewall products. OpenVPN provides another way of supplying road warrior connectivity to the networks
behind the SmoothWall. The setup differs a bit from both L2TP and IPSEC road warrior setups in that the
OpenVPN clients will connect and get an IP address on a “virtual” network. The network address is set in
the global options page in the VPN section and this network needs to on a different subnet than any other
networks attached to the SmoothWall system.
A zone bridging rule still needs to be configured to allow access to the LAN networks for the connected
OpenVPN users.
The options to “Force clients to use SSL VPN as gateway:” is used to make sure all traffic leaving the
clients local network is passed down the OpenVPN tunnel – this is analogous to the option to “Use
gateway on remote network” that can be found in the advanced tcpip settings on the Windows L2TP
client.
The option “SSL VPN client gateway:” is there to supply the client configuration with a hostname or a
different IP than the external one to connect to.
User authentication for OpenVPN users

The OpenVPN user authentication is taken care of by the authentication subsystem on the SmoothWall.
This is also different from how IPSEC or L2TP road warrior connections are setup. User credentials can
be entered in the local users list in the services – authentication – local users list or retrieved from a
directory connection. Any user in the local user list or in the directory with an OpenVPN client installed
should be able to connect and authenticate to the SmoothWall system – once connected the user group
assignment can be used to either allow or deny access to services on the internal networks by using the
Group Bridging features in the filtering section.
Client setup
Installing the client on a Windows PC is fairly easy. Just supply the clients with the install archive that
can be generated from the SmoothWall system, ask them to unpack and install the client using the setup
program.
Once installed, an OpenVPN icon will show up in the notification area. Click on that icon to start the
connection.
Connecting to multiple SmoothWall systems

The client archive comes with a .ovpn file that contains the configuration options specific to the
connection parameters configured on the specific SmoothWall system. This .ovpn file is placed in the
OpenVPN client install directory in a subfolder called configs. The three files that are needed for a
connection is the .ovpn, the servercert.pem and the cacert.pem file. Rename those three files to reference
the connection and edit the .ovpn file to reflect the new cacert.pem file name.
Once that is done, right-click the .ovpn file and select “start OpenVPN with this config file”. Shortcuts
can be placed on the desktop or in other suitable locations for the different .ovpn file connections.

Coursebook V2008
OpenVPN connection ports
There are two possible ports the OpenVPN server can be told to listen on. Only one of the ports can be
used, not both at the same time. The two ports are the normal HTTPS port 443 and UDP port 1194. The
OpenVPN connections are only possible on the primary interface IP address.
OpenVPN client restrictions

The only restriction is that the user need local admin rights on a Windows system in order to run the client
successfully. In order to add a route to a Windows system administrator rights are needed.
SmoothWall is currently working on an OpenVPN client that can be started as a system service but no ETA is
available currently.
OpenVPN logging
The OpenVPN logs can be found in the information – logs – system section. Select OpenVPN is the
system drop down list to see the OpenVPN logs.

Coursebook V2008
Chapter 14: SmoothZap.

SmoothZap is our mail relay and anti spam product. The content filtering is taken care of by the third
party product Mailshell so the content filtering features of SmoothZap does require a license for the
Mailshell in addition to the SmoothZap module.
In the non mailshell version SmoothZap can virus check mails and do spam checking using various
SMTP mail domain checks, greylisting and RBL blocking. With no Mailshell license, there is no licensing
in place to limit the number of users the SmoothZap system can handle mail for.
The setup of SmoothZap is fairly simple. Configure the domains Zap should be handling mail for, tell it
what the internal IP of the mail server is and set anti spam options – all relevant information for the setup
options are available in the manual and the on-line help as usual. However, some things are not
mentioned in the manual.
For example:
● Blacklisting and Whitelisting only works on incoming SMTP.
● POP Mails are NOT counted in the mail reports.
● A Greylisted mail counts as an RBL block in the reports.
● The “Processed by SmoothZap” message cannot be removed via the interface.
To remove the Zap message, clear the text from:
/modules/zap/settings/filter/simpledisclaimer.txt
and
/modules/zap/settings/filter/simpledisclaimer.html
● Without a mailshell license, none of the content filtering spam features are functional.
Some points of interest are:

• The “Relay host” fields on the smtp relay page is for an EXTERNAL mail relay host.
• To be able to receive mail, any port forwards for port 25 should be removed and access to port 25
should be opened in the “admin access” tab of the “preferences” section. When SmoothZap is
installed, another service option becomes available in the “admin access” service drop down list.
TIP: If all incoming mails are coming through the ISP mail server, increase security by only
allowing the IP(s) of the ISP mail servers to access port 25 on the SmoothWall.
• Remember to configure a full hostname in the setup program. The hostname configured is the
hostname the MTA will use when sending mails to other mail servers. Often mail servers require a
full hostname from the server delivering the mails or the mails will be rejected. However, do not
configure the SmoothWall with the same hostname used for the mail servers domain in the DNS
servers MX record as that will confuse the SmoothZap system into thinking it should be
forwarding mails to itself.
The receiving mail servers will look up the mx record for the domain and get the IP address the
mail is coming from, so the hostname of the SmoothWall can be different from the MX record
hostname with no issues.
• Avoid using more than 2 RBL servers. Both as a courtesy and because RBL lookups could then

Coursebook V2008
delay mail processing unnecessarily.
• The greylisting feature will reject mails initially and only accept them if they are resent. The
theory is that spam mails will not be resent, as spam mail servers just pump out a host of mails in
one go and then moves on. This introduces a delay in delivering the mails initially – subsequent
mails from already registered addresses will be allowed immediately.
• Some customers wanted external clients to be able to send SMTP mails through their internal mail
server and asked the clients to send mail to port 25 on the external SmoothWall IP. Those mails
will get rejected as the SmoothZap is not a mail server and will think someone is spoofing their
domain email address in order to try to relay mail through Zap. If clients needs to send mails
through the internal mail server, forward another port than 25 to the mail server and configure the
mail clients to send SMTP to that port.
• Automatic whitelisting only works for domains added in the incoming domains list.
• The format for entering email domains in multi line lists is to list each domain starting with an @
sign on each new line.
• If mails are retrieved using POP3, most reports will not be counting the mails. However, if the
domain used by the POP3 accounts is entered in the incoming WITHOUT the @ sign, the mails
should be counted in outgoing smtp reports.
Figure 52: External SMTP clients.

External client tries po rt 25. Zap receives
mail claiming to be fro m internal do m ain
but arriving fro m an external so urce.
Smo o thWall The relay will be refused
Po rt fo rwarding to the smtp server
External client sends to e.g. po rt 225.

Po rt 225 is fo rwarded to po rt 25
o n the internal mail server.
A word about SMTP

We have gotten quite a few support queries about SMTP error codes and what they mean. While we are
happy to help, SMTP error codes are readily available by doing a simple google search and should be the
first port of call when investigating why a specific code is seen.
A word about mailshell

Mailshell is the anti-spam filtering engine used by SmoothZap. It is a third party product and will need a
license in addition to the SmoothZap purchase. None of the features on the anti spam page will work if no
mailshell license is available.

Coursebook V2008
Managing the SMTP queue
The SMTP queue information can be found in the email section on the queue tab – here the current queue
will be displayed. All mails displayed here are waiting to get successfully sent. They have been retained
because of problems with mail delivery.
The SMTP queue can be manually flushed by pressing the manual flush button. This does not delete the
mail but initiates a SMTP send for all the mails in the queue.
TIP:If a single mail needs to be deleted, run this command on the command line:
#/modules/zap/usr/sbin/postsuper -d emailID
The email ID will be shown in the queue viewer.
SMTP Logging
The SMTP logs can be found in the information section – both in realtime and in logs. The web gui log
viewer is concentrating more on email messages than actual engine messages so for troubleshooting it
may be needed to have a quick look at the entries in the actual maillog file on the SmoothWall system.
The maillog file is found in /var/log and is called mail-year-month-day.
Troubleshooting tips
Mail is also one of the areas we get relatively many support questions regarding. In many cases we are
asked about simple SMTP error messages that has been received or sent by a client or server – as said
earlier, SMTP and other error codes are easily looked up to get a head start on the troubleshooting process
and this should be attempted every time an error code is seen.
One other questions that pops up quite a lot is one of connectivity – is the SmoothWall open to incoming
mail requests for example. One easy way of checking this is to simply telnet on port 25 to the
SmoothWall external IP address – this can actually be done to any mail server and you should see a
connected message and a hello from the mailserver, which will prove that the connection is open and
available.
Telnet can be used like this to check access to other services as well and can be a useful tool for quickly
deciding if a port or service is open.

Coursebook V2008
Chapter 15 – Guardian
Now it is time to sink our teeth into configuring the Guardian part of the SmoothWall system.
Configuring Guardian is quite a task – not so much because it is difficult, more because there are a lot of
things to remember and even more things to be aware of. In the following we are assuming that the
SmoothWall base system is up and running and that networking options have been configured correctly.
Often the initial configuration of Guardian gets a bit messy because an attempt has been made to
configure everything at once. A slow , steady approach is better, at least initially, until the software is
understood better. Separating the various configuration areas and preparing them one at a time will allow
a slow build up and also allow for much better troubleshooting options, as only one area is being worked
on. The sequence should be like this:
1. Configure the proxy

Set all proxy options in the web proxy tab of the Guardian section and start the proxy. Verify the
proxy is starting and that the web proxy service shows up with a green light on the information
page. Manually configure a browser to connect to the proxy and verify that the proxy is accepting
connections and that it is possible to web browse using the proxy.
2. Configure the filtering settings
Once the proxy is working the filtering settings are next on the list. Update the blocklist, configure
filtering options and allow the unauthenticated users filtered access. Once the basic filtering
options have been set, verify that browsing and filtering works as expected. Configuring the filter
before setting up the advanced authentication options allows one to verify that the filter is working
and running.
3. Setup authentication
Once the above two steps are concluded successfully, we will move on to configuring
authentication, which will allow separate web access configurations for authenticated users. We
looked at the authentication subsystem in chapter 12 and will be touching ion it here as well.
4. Setting up browser proxy settings and revisiting filtering options
Then we will look at how to instruct the browsers to use the proxy and go through various options
for settings those configuration options.
5. Revisiting filtering options
Finally, once the authentication has been configured and the browsers have been setup, it's time to
revisit the filtering settings and create different filter settings for the various authenticated groups
we have setup in the authentication.
Following this sequence should minimise any configuration issues and get the SmoothWall system up and
running in record time. This chapter deals with the initial Guardian related tasks – we will move to new
chapters once we reach the third item in the above list.

Coursebook V2008
Configuring the Proxy
Most settings found on the web proxy tab in the Guardian section relates to the web proxy. A single
section relates to the we filter and some of the logging options are also filter specific. When looking at the
logging options bear in mind that there are two logs – the proxy logs and the filter logs. The filter logs
will contain all the information the proxy logs have, so the proxy logs have been disabled by default.
Service Section
Proxy port:
The port setting here sets the port the clients should connect to. The port setting is actually the filter port –
the proxy port will be port 801. This becomes important if an IP address needs to be bypassing the filter
but not the proxy. If an IP tries to access the proxy port directly, the IP will get rejected unless the IP has
been added to the “Exception Local IP Addresses” list.
Transparent:
Transparent proxying will redirect any normal HTTP requests to the proxy. This method of proxying
somewhat negates the need to configure proxy settings on the client but has a large number of drawbacks.
In general, SmoothWall does not recommend the use of transparent proxying – we will discuss why later,
when we are investigating how to setup the client browsers.
There is also a couple of excellent articles available on support.smoothwall.net about transparent
proxying and about Guardian in general. Please have a look at the support.smoothwall.net site as there are
a good number of resources available both for firewall and filtering products.
Remote proxy:
When configuring the remote proxy option, use the format:
ip.address.of.proxy:port
This is the proxy the Guardian web filter needs to go through and may be the same setting as the proxy
settings found in system – preferences – upstream proxy.
Cache size:
The default value of 1500 MB for cache should be sufficient enough in most cases. Most web pages are
dynamically create these days and will not be cached anyhow, so the cache is really only useful for
images and other web resources.
If there are daily web downloads of large files, the cache will also be able to help there, provided the
object size is set large enough to allow large files in the cache.
Memory is used by the cache to store the map of the cached object and it goes without saying that a lot of
spacer gifs can be held in a couple of GB of cache, eating up memory for every single reference to a
cached object.
Banned and Exception IP addresses:
These two fields are proxy related. Exception IP addresses will be allowed to access the proxy directly on
the port 801, so they can completely bypass the filtering software. Only IP addresses listed in the
exception IP field will be allowed to access the proxy port directly this way.

Coursebook V2008
NOTE: IP addresses in the exception field will NOT be in the license count. Only filtered IP
addresses will be counted as using a license.
The banned IP list is a list of IP addresses that will be rejected when they try to use the proxy – this will
happen even if a previous authentication method allows filter access.
Web filter section

The stealth mode option is very useful in the planning stages of the Guardian setup – the filter can be set
to log but not block, but log all the blocks that would have occurred according to the current filtering
settings – once the filter has run for a week or more in this mode, reports can be generated to check what
the web browsing facility is being used for in the company. This makes it easier to define web filtering
rules and also for the management to decide on the Acceptable Use Policy that should be defined in every
company.
It is also a great sales option – the filter can be installed in the network as a logging service only – once
data has been accumulated and reports have been generated, it is much easier for management to decide
whether a web filtering solution is needed on their site or not.
Logging options section

Notice that proxy logging has been disabled by default. Since the web filter log already contains all the
information that is found in the proxy logs, the proxy logging has been disabled by default.
Another option of note is the ability to have the filter log anonymously, which is needed in certain
countries where legislators have realised the possible negative consequences of logging usernames in the
web filter log.
We found that a number of customers liked the logging options so much that they turned them all on but
they apparently did not realise that logs take up space. The more that is logged the more space is needed.
We also saw that when the squid proxy log files grew larger then 2 GB the proxy would refuse to start up
correctly, which is another reason proxy logging is disabled by default. On busy systems with more than
500 users the log retention options for the web filter and proxy log should be set to one of the periods
marked with (Large). This will cause the SmoothWall system to rotate logs daily, preventing them from
growing to an unmanageable size, but still retain them for the selected period.
When dealing with a system that has more than 1000 users make sure that the logging options are
investigated – logs can be kept for up to a year on the SmoothWall system provided there is space enough
to store them. We will look at logging options later when we discuss the reporting and monitoring options
available in the SmoothWall Guardian system.
Web proxy section

Most settings in this section are easily identifiable and also well explained in the help. The admin port
access option is to allow access to the SmoothWall web based admin ports 81 and 441, when going
through the proxy. The default setting is to only allow web requests on port 80 and 443. If any other non-
standard ports needs to be accessed via the proxy add them in the “Allow access to web servers on these
additional ports” field.

Coursebook V2008
Web proxy failover section
This option is a sort of failover solution for the Guardian proxy. If the internet path is broken for a
Guardian box, it can be instructed to use a proxy server as a failover option.
Consider two Guardians, each using a different internet connection but able to see each other on the LAN.
Both Guardians can be set to use the other Guardian as their failover proxy in case their internet path gets
broken.
Combined with a DNS setup that load balances traffic between the two Guardians using the round robin
DNS method and the Guardians sharing the cache using the ICP option, one could create a fairly stable
Guardian setup where failure to reach the internet from any client would only happen if both internet
connections were disabled at the same time.
Automatic configuration script section

This area only affects clients using the proxy.pac or wpad.dat files to set proxy settings on their browser.
Add host or IP addresses to the “Custom direct hosts” field and the browser will not use the proxy when
going to those addresses – this can be configured directly on the browser or in security policies as well.
NOTE: When using proxy.pac or wpad.dat files with Internet Explorer please be aware that
Internet Explorer has a setting that caches proxy settings and stops using the proxy if it thinks
the proxy is not working correctly any more. Because Guardian sometimes blocks pages,
Internet Explorer may start thinking that the proxy is not working any more. The symptom is
that Internet Explorer will browse happily until a block page is encountered – after that, Internet Explorer
will throw up the “Page cannot be displayed” error and will keep giving that error until Internet Explorer
decides to try the proxy again. The SmoothWall support site features an article with links to the Microsoft
knowledge base articles that details this issue and also shows what registry key is needed to change this
behaviour.
Final touches and proxy test

No, we are not done yet – just the proxy part. Remember that we are enabling one “engine” at a time in
order to make sure it is running before moving on to the other “engines” on the SmoothWall Guardian
system. Now is the time to check that the proxy is running and accepting connections.
Go to the authentication page in the Guardian section. Select “No user authentication” and allow the
unauthenticated IP group to use the proxy – just select filtered mode even though we have not enabled the
filter yet.
After pressing the “Save and restart” button, the proxy service should be running. Have a look at the
information section. The information page itself will have a service listing and the web proxy service
should have a nice green button after it, which means the service is running.

Coursebook V2008
Figure 53: Illustration of service listing
Also have a look in the information-logs section. The system logs page has a section drop down list.
Select the web proxy option from the section drop down list and press update.
Figure 54: Web proxy service logs.
If the proxy is running, try configuring a browser manually to go through the proxy and verify that the
proxy is accepting connections and browsing is possible. If proxy logging has been enabled, have a look
at the web filter log page in the information-logs section. Remember to select web proxy logs in the
dropdown list.
Figure 55: Web proxy log viewer.
Generic Proxy Notes

There are a couple of initial proxy specific gotchas which can confuse the initial setup and

Coursebook V2008
implementation of the proxy. In todays internet, web protocols are not just used for web pages anymore –
many applications try to use the web ports and protocols because they are the ports most likely to be open
and accessible. Instant messenger applications, Skype and peer to peer applications are just some
examples of applications that are using the web ports and protocols. Some of these applications are
capable of being proxied, while others will not work correctly if they are being proxied. In order to avoid
any proxy issues the following guidelines should be followed:
Do not proxy the proxy:

The proxy.pac and wpad.dat file written on the SmoothWall system automatically adds the SmoothWall IP
address as a “Do not proxy for” IP address. The SmoothWall IP needs to be exempt from being proxied to
prevent any recurring error condition.
For example: I am trying to authenticate to the proxy. Before I can access the proxy though, I need to be
authenticated, but to access the proxy I need to be authenticated.
Figure 56: Internet Explorer 7 Do not proxy for setting.
Exclude internal servers:

Also exclude any internal servers from being proxied. While the Guardian system is quite capable of
proxying internal servers as well as external ones, there are some other considerations that come into play.
Internal intranet servers are often more specialised than an internet web server – intranet tools, file
sharing and folder sharing and all sorts of web strangeness can be seen on intranet pages which may not
be particularly happy about being proxied.
When entering internal servers into the “Do not proxy” for fields, it is important to know how the clients
are accessing the servers. Are they using IP address, hostname or host and domain name – if the clients
are using all of those, then both IP and hostname is needed in the “Do not proxy for” settings, where ever
they may be configured.
Any and all settings that can be configured in the proxy settings dialogue in Internet Explorer can be set
in a security policy as well.

Coursebook V2008
Proxy compatibility:
As mentioned before (and again later) some applications do not like proxies. This can be because they
need to be told that it is behind a proxy – if so there is a proxy configuration setting in the application
configuration menu somewhere or it could be that the application cannot be proxied at all.
In any case, any application currently in use in your organisation should be checked for proxy
compatibility, if it is using the web ports and protocols.
As always in a network, multiple devices and configurations have to fit together in order to get the best
results. Identifying the correct areas to investigate in case of problems is a large part of a consultant or
network administrators job. To be able to do that reliably, awareness of the various subsystems a process
or service is running is essential – when the proxy is generating errors, the proxy should be checked,
when a user is not being authenticated, the authentication settings should be checked and so on. Try first
to positively identify what subsystem is generating the error and keep configuration changes within the
subsystem – that will save hours, if not days, off the troubleshooting process.
Managing direct web access

If there are applications that can not be configured to use a proxy or cannot use a proxy, even in
transparent mode – the application will need to have direct access to the web ports, unhindered by the
proxy – this is configured differently depending on product used. If Network Guardian is used, then
bypassing the proxy for the specific web site needs to be done for the IP address the application is coming
from – this is done on the firewall.
If a SmoothWall firewall system with Guardian is used, then the configuration becomes a bit more
involved. First, the option to block direct web access in the Guardian web proxy section needs to be
disabled – with it enabled, Guardian will block all web access attempts on ports 80 and 443.
Access to ports 80 and 443 now needs to be denied and granted, according to requirements, in the
networking – outgoing section. Here rules can be configured to only allow certain IP addresses access to
the relevant ports. Furthermore, once the access to the web ports have been granted, the external services
tab can be used to limit access on the open ports to only a certain set of external IP addresses.
Using the outgoing section in networking instead of the block direct web access option in Guardian can
allow a more finely tuned configuration of which IP addresses are allowed to access the web ports
directly and even which addresses the direct access is allowed to go to.
Troubleshooting proxy issues

If the proxy does not start the first step should be to investigate the system logs, specifically the web
proxy messages found in the service drop down selection list on the system logs page. The web filter log
should also be checked in the same section – sometimes filter configuration errors will prevent both the
filter and proxy from starting.
When the proxy subsystem stops running, there will normally be a message and an exit code listed in the
web proxy logs. Unfortunately there is no precise definition for the errors so use the following as a rough
guide only
● “Exiting due to error 6”. This message is seen often if the proxy logs have grown beyond the 2GB
mark – if that happens, the proxy logger will fail and the proxy subsystem refuse to start. Please
make sure that the log retention options have been set to one of the “Large” options, as that will
rotate logs daily, keeping logs from reaching the 2GB size.

Coursebook V2008
● “Exiting due to error 9”. This usually means that one or more subsystems cannot start, as the
SmoothWall system already thinks they are running or a resource has been locked, that the process
should have access to. This can happen when multiple configuration changes and restarts have
been made, without a previous restart being complete yet. Because a web interface is not the best
at returning status messages, users sometimes restart a service that is already restarting. A reboot
of the SmoothWall system will clear any resource locks and allow the subsystem to start again. If
a reboot is not possible, disable the subsystem and restart it. Then enable and restart the
subsystem. That can also clear up any locked resources preventing a successful startup.
● On some rare occasions, applying an update may cause the Guardian system to fail to start. If that
happens it is usually because the update has implemented new configuration options or settings.
Saving the guardian settings should allow the configuration writer to rewrite the configuration
files with the new added options and allow the filtering service to start again.
● It may also be possible that the authentication service and Guardian becomes “out of sync” in rare
cases. This most often happens when trying to use the NTLM identification/authentication
schemes. If the clients suddenly get “proxy access denied” messages (not the Guardian block
page) try a save and restart of first the Authentication service and the Guardian in order to make
sure that the implemented settings in both subsystems are in accordance.
Web filter configuration

Now that we have verified that the proxy is running, we can start to turn out attention to the filter. One of
the major changes in Guardian 2008 to the version 5 or earlier of our Guardian products is the way filters
are defined and applied. Previous Guardians asked you to create a full filter set for each group. This new
version allows you to define filters and then apply them to one or multiple groups – while this initially
can be a bit confusing, once the concept is understood, the administration is a lot easier.
For example – a site that is blocked in the blocklist needs to be allowed. In previous versions, the domain
needed to be added to every single group, in Guardian 2008 you just add the domain to your “Custom
allowed content” filter and apply that filter to all groups. This example saves the user from about 40-50
mouse clicks and waiting time in front of the web interface.
The only drawback, apart from having to learn this new method, is that filter configurations from a
version 5 Guardian cannot be imported in Guardian version 2008. The upshot is that recreating the filter
can be done a lot faster than it could in the previous versions.
Preparing Guardian
Before we go into creating the filters we need to update the blocklist. Go to the Guardian – blocklist page
and check for blocklist updates. Download and install them if any are available.
The blocklist page hides another major update from previous versions. Blocklists are now updated
incrementally and automatically daily – previous versions required a complete manual download of the
blocklist whenever an update was available.
Understanding filters
Guardian 2008 comes with a set of predefined filters which can be used immediately – the default values
will serve as a good starting point for most organisations. Here however, we are going to delete all the

Coursebook V2008
predefined filters and start from scratch. A couple of full sets of predefined filter configurations can be
downloaded from the SmoothWall support site
NOTE: Before we delete any filters, go to the system – maintenance – archives page and create
a backup of the existing Guardian configuration. That way we can reinstate the default filters if
need be.
Filter types
There are three different filter types in Guardian – each have their special meaning and function.
Figure 57: Guardian categories and filters
Filters can be set to o ne o f three different types
Each catego ry has po p-up descriptio ns to explain catego ry co ntent.
Content and URL filtering

This is the main filter type and blocks or allows depending on domain name, URL or web page content.
URL and domain name blocking is fairly simple to understand. If a listed URL or domain name is found
in the address part of the browser request, Guardian intervenes and blocks the page.
Content filtering is a bit more involved. Filtering by content is one of the great strengths of the Guardian
product line – Guardian reads the words on any given page and compares those words with a list of
phrases stored in the blocklist. Each listed phrase has a numerical value attached to it. When a listed
phrase is encountered, the value is added to the sum of previous encountered phrases on the same page. If
the combined value of the found phrases exceeds the limit set in the content filtering options, the page is
blocked by Guardian.
In the categories list one can find several “Good phrases” categories. These categories help to prevent
overblocking when content filtering is in use. The “Goodphrases” lists contain phrases with negative
value attributes, detracting the values from the accumulated content block score – this will cause medical
sites to be allowed, even if some instances of phrases that would normally block a page, is encountered.

Coursebook V2008
Figure 58: Content blocking mechanics
Assuming a web page co ntains these wo rds:
Hone y, Swe e t , Sugar and Diabe t e s.
If a catego ry called sweets had been enabled, the fo llo wing wo rds co uld be co unted:
Hone y, Swe e t and Sugar.
Assuming the phrase list value fo r tho se wo rds is 6 0 , the accumulated value o f the page wo uld be
18 0 (6 0 +6 0 +6 0 ) and assuming the blo ck phrase value was set to 150 , the page wo uld get blo cked.
No w we enable the catego ry “go o dphrases”, in o rder to prevent o verblo cking. The fo llo wing wo rds
then gets picked up by the filter:
Hone y, Swe e t , Sugar and Diabe t e s.
Again assuming all the wo rd values are 6 0 and Diabetes is in the “go o dphrases” catego ry, the
accum ulated value wo uld no w be 120 (6 0 +6 0 +6 0 -6 0 ) and the page wo uld be allo wed.
File security
Fairly straightforward filter type of file types. File types can be specified by extension or mime type –
custom extensions and mime types can be added too. Other settings, such as maximum allowed size and
others are available too.
Content Security
This filter type is for web exploits and other tricks. Just like the content filtering system investigates the
text on the web site, the security content filter can examine the HTML code and remove known exploits
found in the code. Example of unwanted code could be address bar spoofing and pop-up windows.
NOTE: Each category has a short description that can be seen when hovering over the category
name with the mouse. Please read the description before enabling any category.
TIP: Do not enable the “Foreign language pornography” categories if the filter is NOT used in a
country that speaks the language. Enabling those categories can result in overblocking as there
are words in say Turkish that are naughty in Turkish but not in English.
Building the filters

Now that we hopefully understand the various filter types, we can start building filters and combine them
into policies. We will not be using authentication for now so make sure the unauthenticated IP group is
allowed to use the filter and that the Guardian is set to use no user authentication.
Defining filters:
First thing to do is to define the filter type we want – then press the update button to refresh the categories list.
For now we want a generic filter that blocks ads and other useless and bandwidth consuming frivolities.
Select the “Content and URL” filter type, press update and enter the name of “Ads and stuff” in the name

Coursebook V2008
field.
Add the following categories to the filter:
Adverts
Adult themes
Timewasting
Malware and hacking.
All of the above categories can probably be blocked in most organisations. We did not add the
“pornography keywords” category as it contains phrases in non-english languages. In general the
pornography phrase categories should only be enabled in a country that speaks the language to avoid
overblocking. Most pornographic websites will use English words in the meta tags of the page anyway in
order to get as many search hits as possible so just using the English phrases will block most pornograhy
sites regardless of language.
Once the categories have been selected, press add and the filter is done. Note the user defined categories
at the end of the category list – this is where the categories defined in the “user defined categories” are
added.
Just creating a filter has no effect in itself, the filter needs to be applied in a policy for the filter to take
effect.
Next up is a security content filter. Select the “Content security” filter type and press the update button.
Enter a name of “Generic content rules” and add the following categories:
Search engines
"firefoxurl:" cross-browser exploit
Escaped shell code
Firefox cookie stealing
The last three categories can be found in the “Recommended security rules” category. Enable any others
that you may want and press the add button.
Lastly a file security filter is needed. Select “File security” in the filter type drop down list and press
update as usual. Enter a name of “Banned files” and add the following categories:
In-page executables
Bandwith wasting
Video
and press add.
Creating and using the custom categories

As good as the blocklist is, it may still require the addition of domains, sites or other changes to adapt the
generic blocklist to more specific demands. For that purpose we need to use the user defined categories.
Two categories are preconfigured called “Custom allowed content” and “Custom blocked content” - there
is nothing intrinsic about those categories, they are just two predefined categories inserted to help users
understand what the custom categories should be used for.
Just like the filter types, the custom categories have three types.

Coursebook V2008
Creating a Content and URL filtering custom category:
Using this type of filter allows the user to add domains and URLs, phrases and regular expressions to
filter URLs. Domains and URL addition is done by entering them in Domains and URLs field.
Phrases can be added in the “Absolute and weighted phrases” field and they take two forms:
Adding ( bad phrase ) to the list will match any site containing the exact phrase “ bad phrase “ meaning
ANY page with the content “ bad phrase ” on them will get instantly blocked – even if the content only
appears once.
Adding ( bad phrase )(20) to the list will add 20 to the content block value of any page containing the
exact phrase “ bad phrase “
Note the spaces inserted before and after the phrase. Adding the phrase (sex) will match “Sussex”,
“Middlesex” and so on, but adding the phrase ( sex ) will only match “ sex “.
The “Regular expression URLs” field allows the user to enter phrases or terms that the filter will then try
to match in the URL string.
Creating a Custom File Security filter:

Not much to say about this type of filter. Just add the types you want to allow or block.
Creating a Custom Security filter:
This filter type is probably the most interesting of the custom types as you can create a lot of very
powerful filters with the options presented in the configuration dialogue. As with the Content and URL
filter there are three input fields in the Content Security filter.
Content security rules:

A fun feature that allows the filter to replace phrases on a web page:
“Paris Hilton”->”*I hope you were looking for a hotel in Paris?*”
Whenever a web site has the phrase “Paris Hilton” in the text, it will get replaced with the specified
phrase.
URL Security rules:

As above, just works in the URL area, the address bar of the browser. Fairly simple format here too:
“http://(www)?playboy.com”->”http://www.youreanaughtyboy.net”
Outgoing HTTP header security rules:

A browser will send a header to the web server it is accessing. This can be inspected by the SmoothWall
and blocked according to content. For example:
.*MSIE 5.*
Will block all outgoing request made by an Internet Explorer version 5 browser. Here is a nice little tool
that will let you see what headers your browser is sending:

Coursebook V2008
http://www.ericgiguere.com/tools/http-header-viewer.html
Time rules
Before we move on to creating the policies, just a short note about time rules. Time rules are created by
defining the time period and then applying filters for that period in the policy list. Any and all type of
filters can be applied in a time based rule.
Creating filter policies

Now we will begin creating policies. A policy uses a defined filter – the filter definition itself does not
contain the action the Guardian is supposed to take, whether it should allow or block based on the filter
contents. The policy defines that. There are 4 options to select and manage for a filter policy
Group: What group should the policy be in effect for. Either everyone or a specific group can be selected
here.
Filter: Select the relevant filter. Apart from the filters that have been created by the user, 4 different filter
types will always be present:
● Everything
A predefined filter that matches everything. In order to define a policy that only allows certain
web sites, enable this option in a block policy for the group and then add another policy that
allows access to a custom list of domains and URLs.
● URLs containing IP addresses
This type will match all URLs containing an IP rather than a hostname. Some of the larger web
sites, like msn.com and cnn.com sometimes use resources coming from servers that have no
hostname, so be careful when enabling this option.
● All HTTPS content
This rule matches all HTTPS URLs.
● HTTPS URLs containing IP addresses
Matches all HTTPS URLs with no hostname. A lot of proxy sites redirects to an IP address only
HTTPS interface, so this option is always a good one to have enabled.
After these special filters are displayed, the user defined ones will be listed. Select them just like you
would one of the built in filters.
NOTE: Take care when using the “Everything” filter type. We have had customers wanting to
block everything and then allow certain categories during certain hours. However, the blocklist
is not a complete list of all domains in the world so allowing a category will not automatically
allow every domain that could be associated to the category. Use a time based rule to apply the
“Everything” filter so the “Everything” filter can be turned off during times when access to sites should
be allowed.
Time Period: Set the time the policy should be active for. All time rules previously defined should be
selectable in here in the drop down list.
Action: This defines what action the policy should take if a match is made according to the filter. The
action selected depends on the filter type. For Content and URL filters, the following options are

Coursebook V2008
available:
● Block - this action will block a site that matches a filter criteria.
● Block (URLs only) – this action will only block using the domain and URL part of the blocklist.
● Allow – this will allow any content that matches the filter criteria.
● Skip URL blocking – this action will only do the content filtering part and not block based on
domain or URL lists.
● Categorize – this action will categorize web sites to blocklist matches but not do anything else.
This is used by the report generator
The sequence the policies are applied in is not configurable. The allow policies are processed first and if a
site is explicitly allowed or matched in the allow policies, no further processing is done and the page is
allowed through the filter.
The the block policies are processed. If a match is found the page is blocked and no further processing is
done.
Then the apply and file filter policies are applied and if the page passes those policies, the page is
allowed.
For file filter, these options are available:
● Allow the download – allows content matching the filter definition.
● Block the download – block the download matching the filter definition.
Content security rules only have one option:
● Apply – apply the contents of the filter to the Policy.
The first policy

Lets create a quick policy that blocks access to everything apart from sites we specifically allow.
1. Add the domain “google.com” to the “Custom allowed content” category.
2. Create a content and URL filter called “Basic content” only containing the category “Custom
allowed content”
3. Then go to the policy page and create a policy with the following options:
Groups: All Groups
Filter: Everything
Time Period: Always
Action: Block
4. And a second one:
Groups: All Groups
Filter: Basic content
Time Period: Always
Action: Allow

Coursebook V2008
And thats it. Now all google.com sites are allowed, but no other sites will be accessible.
NOTE: It is not possible or relevant to reorder the policies listed in the policies list. The policies
can be sorted in the list but that does not change the processing order.
Testing and Refining Filter Settings

The following procedure could be used for filter testing and refinement.
1. Select a representative collection of the employees that will use the filter and use them as test
persons for a week or a month.
2. Set their browsers to use the proxy and have them deliver feedback to the network
administrator during the test.
During this process, the test persons should also be given the unblock username and password, so they
can unblock sites without having to disturb the network administrator. The password can of course be
changed after the test run, but it is probably a good idea to give a senior employee the ability to unblock
sites during the first 2-4 months of having the filter in operation. This way, any filter problems can be
addressed in a timely fashion and then followed up later by the network administrators.
Guardian 2008 also has a softblock option that allows users to continue to a page that would otherwise be
blocked. The access is logged of course. This option allows everyone to continue at their own discretion
without having to bother an administrator to unblock the site first.
During this first test run, most of the kinks can be straightened out of the configuration. New URLs will
be blocked or allowed, and any problems can be identified without the entire network being affected.
Alternative Testing Procedure

If it is not possible to use the above method you can deploy the web content filtering but configure
Guardian to work in Stealth mode. What this does is content filter as normal and logs the results but it
never actually blocks any pages. You can then investigate the logs and reports to find out if common sites
are over blocked and tweak the settings. You will also be able to spot sites that should have been blocked
and add these in too. After a while you will be confident that when you disable stealth mode users will
have a minimal disruption to their work related web browsing.
Tips on Content Filtering Level

Content filtering is one of the great features of the SmoothWall Guardian products, but it can take a little
time to become familiar with the way content filtering works. The Guardian content filter scans the words
and phrases on a web page and compares them with the phrase list included in the blocklist. All phrases
matched by the content filter have numeric values attached to them, the total of which is compared
against a limit set in Guardian. If the total exceeds the limit, the page will be blocked.
Some of the phrase categories are called goodphrases and contain words and phrases one might find on
news, medical and technical sites. These phrases are given a negative score thus reducing the page total.
This category should always be enabled as it will significantly reduce over blocking for content filtering.

Coursebook V2008
There are 3 pre-configured page limits in Guardian: 50, 100 and 160. In keeping with the SmoothWall
tradition, it is also possible to configure this value. When first trying out the filter, set the value to 160 and
then lower that value, if the need arises.
This is a setting that is very important for correct configuration of Guardian. In a corporate environment
with adults, this setting should probably not be set lower than 160 initially.
Authentication Methods
Guardian supports a wide array of authentication methods. Setting up the authentication connection is
described in the authentication chapter so we will only deal with the types of authentication that the
Guardian system can use here.
As a rule, only one method of authentication can be used at any given time. There are exceptions of
course. On the SmoothWall support website the support knowledge base will have an article called “User
Authentication Options for Networks Comprising Mixed Computers and Browsers” - there all possible
combinations, restrictions and other considerations are listed.
Each authentication method has its own advantages and special considerations, which we will try to go
through here.
No User Authentication.
No authentication is required. Using this setting, all users are placed in the Unauthenticated IPs group.
Proxy authentication.
The standard proxy authentication pops up a dialogue when the proxy is accessed. Username and
passwords are entered and can be saved. Cannot be used if the proxy is set to transparent mode.
Proxy authentication (Terminal Services compatibility mode).
Same as above, but allows multiple different users to log in from the same IP address. Cannot be used if
the proxy is set to transparent mode.
NTLM identification.
Windows integrated identification. Outdated identification method that is still popular, even though it's
insecure and even Microsoft does not recommend using it. Main compatibility issues with NTLM are that
it's Windows specific and there is no guarantee that non Microsoft clients and browsers can support it. It
is also not capable of being used in a Windows 2000 multi domain setup, as the protocol was designed for
the flat NT4 server domain structure.
NTLM identification (Terminal Services compatibility mode).
Same as above, but will allow multiple users to log in from the same IP address.
NTLM authentication.
Same as NTLM identification but this method also checks the password – the identification only checks
the username.
NTLM authentication (Terminal Services compatibility mode).
Same as above, but will allow multiple users to log in from the same IP address.
Redirect users to SSL login page.
Selecting this option will redirect the browser to the SmoothWall SSL login page. Once there, the users
enter username and passwords to log in. The login page will need to be kept open for the login to stick –
if the page is closed, the login will time out according to the setting in the “services - authentication -

Coursebook V2008
settings” section.
Core authentication.
This option tells Guardian to query Auth for logged in users. It requires the users to be already logged in
to the SmoothWall system. This should be used when the SSL login application is being used or the
redirect to the SSL login page is done in the services - authentication – settings section instead of in
Guardian.
Ident.
The ident server software is available for all platforms. Ident is a simple little server application that binds
to port 113 and tells everyone that asks it what the username of the logged in user is. When using this
option, Guardian will ask any client that tries to use the browser, for the username. If no ident server is
running on the client, the user will be put in the Unauthenticated IP group. This solution is a great cross
platform solution – it does not do authentication, only identification, as no passwords are in use.
Windows ident applications can be set to run from a login script.
Identification by IP.
As the option name implies, the IP address is being used to determine what filter permissions the client
should have. A list of IP addresses, subnets and/or range of IP addresses, needs to be entered on the “ident
by IP” page in the Guardian section.
Recommended authentication methods

The three methods that interfere the least with the browsing process would be Ident by IP, Ident and SSL
login. None of those has any bearing on what is being sent between the browser and the web server. Both
Ident and Ident by IP are transparent to the user whereas the SSL Login can be, when the SSL Login
application is used – if not, username and password can still be saved on the SSL Login page so the users
does not have to enter them constantly.
NTLM and proxy authentication interferes with the traffic between browser and web server and will
cause issues with some sites. While NTLM is very popular because of the perceived no configuration
setup, dealing with the issues NTLM causes may be more of a hassle than it is worth in the end – it all
depends on the network and circumstances surrounding it.
NOTE: A lot of customer use NTLM rather than the SSL Login page because entering username
and password is seen as a big problem (the same username and password the user just entered
when they logging into their workstation). Remember that credentials can be saved on the SSL
login page so the username and password will only have to be entered once.
Troubleshooting
As easy as it is to configure the filter policies on SmoothWall Guardian the results can sometimes be
different from what is expected. When that happens we need to bring out our troubleshooting tools and
find out why.
Troubleshooting the Guardian filter is mostly an issue when overblocking is occurring. If users are not
placed in the expected group, it's an authentication issue and cannot be solved by reconfiguring filter
settings.
When correcting overblocking it is very important to know why the page or domain was blocked. The
blockpage can be configured to show the reason the page was blocked and this information should always

Coursebook V2008
be retrieved before any changes are made to the filter.
Figure 59: Example block reasons
This is the blo ckpage displayed when a

page is blo cked because the do main is
listed specifically in the blo cklist.
When the co ntent filter blo cks a page

the blo ckpage lo o ks like this:
A page can also be blo cked by the

o ccurrence o f a banned wo rd in the URL.
This is called “Banned Regular
Expressio n URL”.
If the block reason is given as banned domain, the domain will need to be added to the custom allowed
settings.
If the block reason is that the page exceeded the weighted phrase limit, check the web filter logs to see
what the score of the page is before raising the limit or allowing the domain/site.
If the block reason is given as Banned Regular Expression URL then a phrase has been found in the URL
that caused the page to be blocked. The site or domain can be added to the allowed content or the phrase
can be removed or exempted from the URL checks.
Giving Guardian the reboot treatment

Managing applications using a web interface is becoming more and more common. No wonder, as web
browsers are universally available on any OS. One of the drawbacks of using a web browser is feedback
from the processes running on the system – directly on the system the process can be monitored in real
time, but in a web interface, feedback is dependent on user interaction or browser refresh times.
Because of this it is possible to configure perfectly sensible Guardian options, but leave the config files in
a non functional state. Normally a save and restart of the Guardian will resolve such issues, but it may be
necessary to reboot the system. All configuration files are rewritten at boot with the options configured in

Coursebook V2008
the web interface, so if the configuration files have been corrupted, a reboot may resolve it.
Web filter system log errors

Just like the proxy has a log entry in the system logs section, so does the web filter. If the web filter does
not start, be sure to check the web filter logs for any information that may be useful. The web filter
system logs should contain at least a reference if startup has failed or succeeded. If there are problems
loading configuration files, the logs will also show that.
In case of errors in the configuration files, try to edit and resave the filter and policy settings for the
relevant group(s) and of course, do a sanity check and see if any categories have been enabled that are
mutually exclusive. The interface should warn you if such configurations are made but validation coding
is not a match for a properly tuned brain and a pair of eyes.
A few tips
Save the policy configuration regularly – while this is a fairly obvious piece of advice, the benefits are
major. Once you have the base configuration of the filtering policies save that as a backup and use it as a
template. In the downloads section of the SmoothWall support site a set of predefined policies can be
found which can be used in a pinch to reset filters and policies and start from a known good
configuration.
Monitor the log partition space

Guardian logs are big. Needless to say, the more users, the more logs. On a busy system managing 1500
to 2000 users, we have seen Guardian logs grow by 1 GB a day.
Let me repeat that number – 1 GB a day!
All Guardian logs are rotated daily by default and there should be no reason to change that – logs will be
kept for a month by default but this can be set to a year if need be. All logs are kept on a separate partition
which is mounted on
/var/log
All Guardian filter logs will be found in the dansguardian directory and the proxy logs will be in the squid
directory.
Other things to remember

When troubleshooting Guardian issues there are quite a few variables to remember. Here is a list of the
most common things we have found is useful to remember:
● Browsers are made for caching. All web browsers have caching routines in place and need to have
them in order to preserve bandwidth, load often accessed pages faster and generally speed up
browsing. Please remember to clear the browser cache to make sure the browser is not just
displaying a previously loaded page (Like a block page). Turning caching off in the browser used
to test the Guardian may be a very good idea initially.
● Remember to not go through the proxy when accessing the proxy. When using authentication
methods like NTLM and proxy authentication, please remember that the proxy IP address should

Coursebook V2008
be excluded from being proxied. If the browser is trying to go through the proxy it will be told to
authenticate itself. It then tries to send the authentication reply but tries to go through the proxy to
do it. This will fail as the proxy has not authenticated the user yet. Make sure that traffic to the
proxy itself is not being sent through the proxy, just to the proxy.
● Remember to restart the authentication subsystem in the services section when changing
authentication methods in Guardian.
Back to the network – getting the browsers to use the filter

So now we have configured the proxy and the Guardian web filter. The test browser has been manually
configured to use the filter, so we could test that everything is running and working – now it's time to look
at how we get the browser to use the filter.
Setting up the proxy settings manually is not an option in most cases as that would require setup on every
single PC in the organization. While configuring the browsers is not really a SmoothWall support issue,
we will give a couple of ideas and recommendations here as how to go about propagating the proxy
settings on your network.
Transparent proxy
Initially a lot of first time web filter/proxy users will look at the transparent setting and start to salivate.
With no configuration needed anywhere but a simple tickmark on the proxy page in the Guardian section,
the allure is powerful but watch out. There are a couple of fairly serious limitations to using transparent
proxying.
● No proxy for HTTPS. Transparent proxying works by redirecting any port 80 traffic to the proxy.
If HTTPS traffic is redirected, the connection will fail as a secure connection cannot be redirected
without the browser knowledge, as it were. Proxying HTTPS requires specific proxy setting so the
browser knows it's supposed to be proxied and a tag is attached to the http header to allow this.
● Applications are unaware they are being proxied. This can cause applications using the web ports
to fail. As more and more applications are using the web protocols, the risk of breaking
functionality is fairly big when using transparent proxying.
When telling new users that transparent is not an option they often become quite irate because they
believe they now have to manually configure all workstation at the location – but nothing could be further
from the truth. There are lots of ways to propagate proxy settings.

Coursebook V2008
Figure 60: Transparent vs Non Transparent proxying
Transparent setup Co nfigured Pro xy Settings

Client applicatio n
Redirect to Pro xy HTTPS unfiltered Pro xy HTTPS

Applicatio n sends
Applicatio n is No redirect o f Extra header adds
directly to pro xy.
unaware o f pro xy SSL packets URL info rmatio n.
DHCP: Internet Explorer can get proxy settings from a DHCP server.
Automatic discovery: Most browsers support the automatic proxy discovery feature too.
Security Policies: Proxy settings can be set in an Active Directory security policy.
Those are just three ways. Logon scripts, ini files for Firefox. Customised IE or Firefox packages are
other options.
Specific Browser issues

Microsoft Internet Explorer tries to guess at what you want quite a bit and do things behind the users
backs to help them get the most out of the software. While this is good in theory, sometimes the
automation is a hindrance rather than a help. The most serious issue we have seen with Internet Explorer
and Guardian web filter software is that Internet Explorer will cache the proxy information. If Internet
Explorer does not get the expected page, the proxy will be marked as bad and Internet Explorer will try to
use other proxies or go the direct route to the internet, via port 80.
This is all well and good if there are multiple proxies or the proxy is not also a web filter. If browsing is
blocked, Internet Explorer will see that the blockpage is not what was requested and mark the proxy as
bad and then try to use the direct route.
We have a couple of knowledge base articles dealing with this problem on the SmoothWall support site
and the corresponding Microsoft knowledge base articles can be found here:
http://support.microsoft.com/kb/271361/
http://support.microsoft.com/kb/320507/
The articles above details how to resolve this issue using a group policy. On the SmoothWall support site
we have a downloadable .reg file that can be used to set those settings on a single workstation, so the
solution can be tested before applying it globally.
Bypassing the filter and proxy

Sometimes it is needed for a machine to be able to bypass the filter or the proxy. In environments where
direct access and proxy access are both needed we normally recommend using Network Guardian instead
of SmoothGuardian on a SmoothWall Firewall product.
Bypassing filter and proxy can be difficult, depending on authentication method used. Remember there
are three separate systems in play here – authentication, proxy and guardian.

Coursebook V2008
Also, the IP of the computer that needs to bypass the proxy needs to be static. It is not possible for the
system to know, without authentication, what user is allowed to bypass the filter or not.
This is not normally an issue though, as the computers that needs to bypass the proxy are often servers
and they will normally have a static IP or static DHCP mapping.
As mentioned earlier, using the block direct web access option on a Guardian installed on a SmoothWall
firewall is not a flexible enough option if the proxy needs to be bypassed – then the outgoing rules in the
networking section should be used instead.
Automatic proxy detection

A short introduction to using the automatic proxy discovery feature is in order as it's exceedingly easy to
set up and would fit the need of most organizations.
The automatic proxy discovery works in 2 ways. One is by having the DHCP server give out proxy IP
address and the other is by having DNS do it. Internet Explorer will look for the DHCP settings first and
then try DNS if no proxy information is given out by the DHCP server. As Internet Explorer is the only
browser, to our knowledge, that uses the DHCP settings, we will look at the DNS requirements here – the
DHCP setup is fairly straightforward anyway and it should require no special skills just to add the proxy
information in the appropriate DHCP server setting field.
The DNS method works in that the client will ask for a host in it's domain called wpad. If such a host is
found, the client will ask the host for a wpad.dat file, which is just a renamed proxy.pac file. The
SmoothWall serves both proxy.pac and wpad.dat on port 80.
So to get automatic discovery to work, just add a hostname of wpad to your local DNS server and point
that host to the SmoothWall. Only snag is that the wpad host needs to be in the clients domain, as that is
the domain the client will look in.
NOTE: However, when using this method, bear in mind the Internet Explorer specific proxy
caching issue mentioned earlier in this chapter.

Coursebook V2008
Chapter 16: SmoothTraffic.

SmoothTraffic is the SmoothWall Bandwidth management module. SmoothTraffic is capable of
prioritising the traffic that goes through the SmoothWall firewall. Prioritisation does not mean QOS. For
Quality of Service type bandwidth management. QOS requires control over the physical line and the
routers the traffic passes through – SmoothTraffic can only base its priorities on the traffic arriving or
leaving the SmoothWall.
Prioritisation is also different from partitioning the bandwidth. SmoothTraffic can do basic partitioning
but the main function of SmoothTraffic is to make sure the most important traffic gets handled first.
Traffic Schemes
The included schemes should be sufficient in most cases – some schemes have a configuration option
attached to them which needs to be set – please read the on-line help for the schemes to get detailed
information on each of the provided schemes.
New in SmoothTraffic
The new version of SmoothTraffic contains many improvements. While ADSL bandwidth is slowly going
up some management of bandwidth is often still required. Slowing down unidentified traffic is a great and
harmless way of discouraging unsanctioned use of company bandwidth.
This version now supports internal management as well as external. All interface speed values should be
filled in as precisely as possible to give the traffic engine the best conditions to prioritise the bandwidth.
Some ADSL connections vary a great deal in the actual speed available, which makes it hard for
SmoothTraffic – try the lowest reasonable estimate if using SmoothTraffic seems to generate erratic
results.
Another new feature are diffserv marks. Basically, packets can be tagged with a marker, which receiving
SmoothTraffics will recognise. Those packets can then be handled by SmoothTraffic which means that
traffic sent INSIDE the VPN can be prioritised as well as normal external traffic.

Coursebook V2008
The various diffserv marks are mainly just tags to be used a seen fit. An example:
Figure 61: Diffserv marking in SmoothTraffic

Tagging o utgo ing traffic with a marker:
And creating an address rule to match:
Then receiving the inco m ing VOIP traffic:
Instead o f co nfiguring an address rule to match the tagged traffic, we just apply the rule glo bally,
happily assuming all AF12 tagged traffic is heading fo r the PBX.
Two locations have IP-PBX systems, sending VOIP traffic via VPN.
Location 1 marks outgoing traffic from the PBX IP address with the AF11 tag.
Location 2 marks outgoing traffic from the PBX IP address with the AF12 tag.
Location 1 marks incoming AF12 traffic with the desired priority.

Location 2 marks incoming AF11 traffic with the desired priority.
Lastly, there is now a peer to peer tab that is capable of handling the most popular peer to peer protocols
by protocol – port numbers are not needed.
General Notes about SmoothTraffic

Remember that SmoothTraffic prioritises traffic. For SmoothTraffic to do that, 2 things are needed:
Traffic and Time. Let SmoothTraffic run for a few minutes when verifying the configuration.
There are now 2 SmoothTraffic reports available for SmothTraffic statistics. A rule and a Class report. As
the name implies, they represent traffic statistics classified by the traffic class or rule registered by
SmoothTraffic.

Coursebook V2008
Figure 62: The built-in traffic rules
smoothadmin
smoothadmin is a built-in traffic rule that prioritises all the management ports and protocols, making sure
the SmoothWall can be accessed even when traffic is high.
webcache
webcache ensures that Proxy traffic has a min 5% of the line for its return traffic.
Localtraffic
This rule excludes local traffic from being restricted.
TIP: Try to run the program trafficmon from the command line. Issue this command first to
get nice colours on the display: TERM=linux. The trafficmon program displays real time traffic
staticstics according to SmoothTraffic Rule and Class definitions on every interface connected to
the SmoothWall. Use SHIFT+PAGEUP and SHIFT+PAGEDN to browse the list.

Coursebook V2008
Looking ahead at upcoming SmoothWall products.

The next versions of our SmoothWall products are already being worked on of course and some major
changes are in store. Here is a little list of the updates and changes to release schedule that we are
implementing over the next couple of years.
Feature pack releases

Rather than releasing a new version of the product each year or so, we have settled on releasing feature
packs. These packs will be available to all SmoothWall products that have Upgrade Assurance.
Releasing feature packs allows us to concentrate on features for longer time than releasing a completely
new version would. The feature packs will continue until such time when we decide a new version is
needed – this will happen once features needs to be added than cannot be done cleanly in the current
implementation.
Product updates are available to all SmoothWall products, irrespective of Upgrade Assurance entitlement.
User portal
A lot of configuration options, reports and other functions could be handled by end users, rather than
network admins. SmoothWall is creating a user portal to allow end users to access various functions on
the SmoothWall system. Generating reports, viewing active users and logs and blocking users from web
access are but a few of the features that will be configurable from the SmoothWall portal.
IMSpector enhancements
The IM proxy has become popular but in it's current state it is a bit unpolished. New features are planned,
including the option to redirect IM traffic that is trying to go through the web proxy to the IM proxy
instead.
Ajax
No, we are not cleaning up in the offices, we are cleaning up the SmoothWall interface. Making the
SmoothWall interface easier and more manageable is an ongoing goal and the new Ajax web coding
standards makes it possible for us to turn the web GUI into a much more responsive GUI than was
previously possible. We already have a few ajax examples in our current product and we will be adding a
lot more in the future.

v2008 Coursebook

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

v2008 Coursebook

Uploaded by

Copyright:

Available Formats

Coursebook V2008

For SmoothWall Version 2008 products

Copyright SmoothWall Limited 2008 Page 1 of 110

Copyright SmoothWall Limited 2008 Page 2 of 110

Copyright SmoothWall Limited 2008 Page 3 of 110

Copyright SmoothWall Limited 2008 Page 4 of 110

Copyright SmoothWall Limited 2008 Page 5 of 110

Copyright SmoothWall Limited 2008 Page 6 of 110

Welcome to the SmoothWall V2008 Course

Figure 1: Smoothwall GPL v0.99.

Copyright SmoothWall Limited 2008 Page 7 of 110

What is new in version 2008

About this book

Copyright SmoothWall Limited 2008 Page 8 of 110

Copyright SmoothWall Limited 2008 Page 9 of 110

Copyright SmoothWall Limited 2008 Page 10 of 110

Chapter 1: Network Basics

MAC Addresses – Media Access Control

Figure 2: Example MAC address

MAC – Media Access Control

ARP – Address Resolution Protocol

Figure 3: Replacing network cards

Old NIC arp entry

New replacement NIC, new MAC address.

Copyright SmoothWall Limited 2008 Page 11 of 110

DNS – Domain Name Server

Figure 4: WINS and DNS name resolution

WINS: WS0 1 DNS: ws0 1.mydo main.lo cal

Copyright SmoothWall Limited 2008 Page 12 of 110

WINS – Windows Internet Name Server

Important: A lot of connectivity issues in Windows networks can be understood better by

DHCP – Dynamic Host Configuration Protocol

Figure 5: Client resolving hostnames

Client witho ut assigned do main name asks fo r “fileserver”

DNS server wo nders: fileserver. what?

DNS server respo nds: fileserver.m ydo m ain.lo cal is at 1.2.3.4

Default Gateway and Routing

Copyright SmoothWall Limited 2008 Page 13 of 110

Client o n subnet 19 2.16 8 .1.0 /255.255.255.0 sends request to smo o thwall.net

Default gateway ro utes to external netwo rk

Figure 7: Routing from A to B

Copyright SmoothWall Limited 2008 Page 14 of 110

Choosing the Hardware

SmoothGuard 1000-UTM appliance

Copyright SmoothWall Limited 2008 Page 15 of 110

Serial Attached SCSI (SAS)

SmoothWall Service Pack CD

Other Hardware Specific Issues

64 bit Capable CPUs

Copyright SmoothWall Limited 2008 Page 16 of 110

Multi NIC cards

USB Network adapters

Wireless Network Cards

Figure 8: Wireless access point attached to the SmoothWall.

Wireless access po int

Copyright SmoothWall Limited 2008 Page 17 of 110

Figure 9: SmoothWall Firewall/NAT setup examples

Copyright SmoothWall Limited 2008 Page 18 of 110

Primary connections: Can use multiple connection methods.

Secondary connections: Static IP, network card based connection only.

Copyright SmoothWall Limited 2008 Page 19 of 110

Figure 10: The SmoothWall install boot screen

Copyright SmoothWall Limited 2008 Page 20 of 110