SonicWALL 5.8.1 User Manual To The D359b2c8 C743 46c6 88a2 041f422b0152

User Manual: SonicWALL 5.8.1 to the manual

Open the PDF directly: View PDF PDF.
Page Count: 1490

DownloadSonicWALL 5.8.1 User Manual  To The D359b2c8-c743-46c6-88a2-041f422b0152
Open PDF In BrowserView PDF
SonicOS 5.8.1 Administrator’s Guide

PROTECTION AT THE SPEED OF BUSINESS™

Table of Contents
Table of Contents .....................................................................................................iii
Part 1: Introduction
Chapter 1: Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
Copyright Notice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
Limited Warranty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
About this Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
Organization of this Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
Guide Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
SonicWALL Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
More Information on SonicWALL Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
Chapter 2: Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33
Key Features in SonicOS Enhanced 5.8.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33
Key Features in SonicOS Enhanced 5.8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
Key Features in SonicOS Enhanced 5.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40
Key Features in SonicOS Enhanced 5.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
Key Features in SonicOS Enhanced 5.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
Key Features in SonicOS Enhanced 5.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
Key Features in SonicOS Enhanced 5.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
Key Features in SonicOS Enhanced 5.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43
SonicWALL Management Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48

Part 2: Dashboard
Chapter 4: Using the SonicOS Visualization Dashboard . . . . . . . . . . . . . . . . . . . . . . . . .57
Visualization Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57
Enabling the Real-Time Monitor and AppFlow Collection . . . . . . . . . . . . . . . . . . . . .58
Dashboard > Real-Time Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
Using the Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62
Applications Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
Ingress and Egress Bandwidth Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66

SonicOS 5.8.1 Administrator Guide

iii

Packet Rate Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Packet Size Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Connection Count Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Dashboard > AppFlow Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Filter Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
AppFlow Monitor Tabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
AppFlow Monitor Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Group Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
AppFlow Monitor Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
AppFlow Monitor Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Using Filtering Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Dashboard > Threat Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
SonicWALL Threat Reports Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
SonicWALL Threat Reports Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Dashboard > User Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Dashboard > BWM Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Dashboard > Connections Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Viewing Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Filtering Connections Viewed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Dashboard > Packet Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Using Packet Monitor and Packet Mirror . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Dashboard > Log Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Part 3: System
Chapter 5: Viewing Status Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
System > Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Wizards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
System Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
System Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Latest Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Security Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Registering Your SonicWALL Security Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Network Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Chapter 6: Managing SonicWALL Licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
System > Licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Node License Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Security Services Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Manage Security Services Online . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Manual Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Manual Upgrade for Closed Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Chapter 7: Viewing Support Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
System > Support Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

iv

SonicOS 5.8.1 Administrator Guide

Chapter 8: Configuring Administration Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107
System > Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107
Firewall Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107
Administrator Name & Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107
Login Security Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .108
Multiple Administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .110
Web Management Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111
SSH Management Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113
Advanced Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113
Download URL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117
Selecting UI Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118
Chapter 9: Managing Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119
System > Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119
Digital Certificates Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119
Certificates and Certificate Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120
Certificate Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121
Importing Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121
Deleting a Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123
Generating a Certificate Signing Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123
Configuring Simple Certificate Enrollment Protocol . . . . . . . . . . . . . . . . . . . . . . . .125
Chapter 10: Configuring Time Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127
System > Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127
System Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127
NTP Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .128
Chapter 11: Setting Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129
System > Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129
Adding a Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131
Deleting Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132
Chapter 12: Managing SonicWALL Security Appliance Firmware . . . . . . . . . . . . . . . .133
System > Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134
Firmware Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .135
SafeMode - Rebooting the SonicWALL Security Appliance . . . . . . . . . . . . . . . . . .136
Firmware Auto-Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .138
FIPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .138
Chapter 13: Using the Packet Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139
System > Packet Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139
Packet Monitor Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139
Configuring Packet Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143
Using Packet Monitor and Packet Mirror . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .154
Verifying Packet Monitor Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .159
Related Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162

SonicOS 5.8.1 Administrator Guide

v

Chapter 14: Using Diagnostic Tools & Restarting the Appliance . . . . . . . . . . . . . . . . . 165
System > Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Tech Support Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Diagnostic Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Check Network Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Connections Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Multi-Core Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Core Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
CPU Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Link Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Packet Size Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
DNS Name Lookup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Find Network Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Ping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Core 0 Process Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Real-Time Black List Lookup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Reverse Name Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Connection Limit TopX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Check GEO Location and BOTNET Server Lookup . . . . . . . . . . . . . . . . . . . . . . . . 177
MX Lookup and Banner Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Trace Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Web Server Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
User Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
System > Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

Part 4: Network
Chapter 15: Configuring Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Network > Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Setup Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Interface Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Interface Traffic Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Physical and Virtual Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
SonicOS Enhanced Secure Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Transparent Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Layer 2 Bridge Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
IPS Sniffer Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Configuring Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Configuring Layer 2 Bridge Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Configuring IPS Sniffer Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Configuring Wire Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Chapter 16: Configuring PortShield Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Network > PortShield Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Static Mode and Transparent Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Configuring PortShield Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

vi

SonicOS 5.8.1 Administrator Guide

Chapter 17: Setting Up Failover and Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . .275
Network > Failover & Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .275
Failover and Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .275
Load Balancing Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .278
Multiple WAN (MWAN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .279
Chapter 18: Configuring Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .283
Network > Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .283
How Zones Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .284
The Zone Settings Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .287
Adding and Configuring Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .288
Deleting a Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .289
Configuring a Zone for Guest Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .290
Configuring the WLAN Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .293
Chapter 19: Configuring DNS Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .297
Network > DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .297
DNS Rebinding Attack Prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .298
Chapter 20: Configuring Address Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .299
Network > Address Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .299
Types of Address Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .299
Address Object Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .300
Creating and Managing Address Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .300
Default Address Objects and Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .301
Adding an Address Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .302
Editing or Deleting an Address Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .303
Creating Group Address Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .304
Public Server Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .304
Working with Dynamic Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .305
Chapter 21: Configuring Firewall Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .317
Network > Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .317
Default Services Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .318
Custom Services Configuration Task List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .318
Chapter 22: Configuring Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .325
Network > Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .325
Route Advertisement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .326
Route Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .327
Advanced Routing Services (OSPF and RIP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .332
Configuring Advanced Routing Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .339
Chapter 23: Configuring NAT Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .347
Network > NAT Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .347
NAT Policies Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .348
NAT Policy Settings Explained . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .349
NAT Policies Q&A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .351
NAT Load Balancing Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .352

SonicOS 5.8.1 Administrator Guide

vii

Creating NAT Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
Using NAT Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Chapter 24: Managing ARP Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
Network > ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
Static ARP Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Secondary Subnets with Static ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Navigating and Sorting the ARP Cache Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
Navigating and Sorting the ARP Cache Table Entries . . . . . . . . . . . . . . . . . . . . . . 372
Flushing the ARP Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
Chapter 25: Configuring MAC-IP Anti-Spoof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Network > MAC-IP Anti-Spoof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
MAC-IP Anti-Spoof Protection Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Configuring MAC-IP Anti-Spoof Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Chapter 26: Setting Up the DHCP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
Network > DHCP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
DHCP Server Options Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Multiple DHCP Scopes per Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Configuring the DHCP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
DHCP Server Lease Scopes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
Current DHCP Leases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
Configuring Advanced DHCP Server Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Configuring DHCP Server for Dynamic Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Configuring Static DHCP Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
Configuring DHCP Generic Options for DHCP Lease Scopes . . . . . . . . . . . . . . . . 399
DHCP Option Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
Chapter 27: Using IP Helper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Network > IP Helper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
IP Helper Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
IP Helper Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
Adding an IP Helper Policy for DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
Adding an IP Helper Policy for NetBIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Editing an IP Helper Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Deleting IP Helper Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Enhanced IP Helper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Adding User-Defined Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Editing User-Defined Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Retrieving Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Displaying IP Helper Cache from TSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
mDNS Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Chapter 28: Setting Up Web Proxy Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Network > Web Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Configuring Automatic Proxy Forwarding (Web Only) . . . . . . . . . . . . . . . . . . . . . . 418
Bypass Proxy Servers Upon Proxy Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418

viii

SonicOS 5.8.1 Administrator Guide

Chapter 29: Configuring Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .419
Network > Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .419
Supported DDNS Providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .420
Configuring Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .420
Dynamic DNS Settings Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .423
Chapter 30: Configuring Network Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .425
Network > Network Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .425
Adding a Network Monitor Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .427
Configuring Probe-Enabled Policy Based Routing . . . . . . . . . . . . . . . . . . . . . . . . .428

Part 5: 3G/Modem
Chapter 31: 3G/Modem Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .431
3G/Modem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .431
Selecting the 3G/Modem Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .432
Chapter 32: Configuring 3G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .433
3G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .433
3G Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .433
3G > Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .440
3G > Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .440
3G > Advanced . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .442
3G > Connection Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .444
3G > Data Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .450
Other 3G Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .450
3G Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .451
Chapter 33: Configuring Modem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .455
Modem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .455
Modem > Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .455
Modem > Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .456
Modem > Advanced . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .457
Modem > Connection Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .459

Part 6: Wireless
Chapter 34: Viewing WLAN Settings, Statistics, and Station Status . . . . . . . . . . . . . .467
Wireless Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .467
Considerations for Using Wireless Connections . . . . . . . . . . . . . . . . . . . . . . . . . . .468
Recommendations for Optimal Wireless Performance . . . . . . . . . . . . . . . . . . . . . .468
Adjusting the Antennas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .469
Wireless Node Count Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .469
MAC Filter List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .469
Wireless > Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .470
WLAN Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .471
WLAN Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .472
WLAN Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .472
Station Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .473
Discovered Access Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .473

SonicOS 5.8.1 Administrator Guide

ix

Chapter 35: Configuring Wireless Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
Wireless > Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
Wireless Radio Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
Wireless Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
Chapter 36: Configuring Wireless Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
Wireless > Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
Authentication Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
WPA/WPA2 Encryption Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
WEP Encryption Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
Chapter 37: Configuring Advanced Wireless Settings . . . . . . . . . . . . . . . . . . . . . . . . . 485
Wireless > Advanced . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
Beaconing & SSID Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
Advanced Radio Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
Chapter 38: Configuring MAC Filter List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
Wireless > MAC Filter List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
Allow or Deny Specific Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
Chapter 39: Configuring Wireless IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
Wireless > IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
Access Point IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
Intrusion Detection Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
Discovered Access Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
Scanning for Access Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
Authorizing Access Points on Your Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
Chapter 40: Configuring Virtual Access Points with Internal Wireless Radio . . . . . . . 495
Wireless > Virtual Access Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
Wireless VAP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
Wireless Virtual AP Configuration Task List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
VAP Sample Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507

Part 7: SonicPoint
Chapter 41: Managing SonicPoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
SonicPoint > SonicPoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
Before Managing SonicPoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516
SonicPoint Provisioning Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516
SonicPoint Deployment Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
Layer 2 and Layer 3 Considerations for SonicPoints . . . . . . . . . . . . . . . . . . . . . . . 531
Tested Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
Wiring Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
PoE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533
Spanning-Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534
VTP and GVRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534
Port-Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534
Broadcast Throttling/Broadcast Storm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534
x

SonicOS 5.8.1 Administrator Guide

VAP Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .535
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .535
Resetting the SonicPoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .536
Switch Programming Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .536
Chapter 42: Viewing Station Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .539
SonicPoint > Station Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .539
Chapter 43: Using and Configuring IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .543
SonicPoint > IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .543
Wireless Intrusion Detection Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .543
Chapter 44: Configuring Virtual Access Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .547
SonicPoint > Virtual Access Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .547
SonicPoint VAP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .547
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .550
Deployment Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .551
SonicPoint Virtual AP Configuration Task List . . . . . . . . . . . . . . . . . . . . . . . . . . . .551
Thinking Critically About VAPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .562
VAP Sample Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .565
Chapter 45: Configuring RF Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .581
SonicPoint > RF Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .581
RF Management Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .582
Enabling RF Management on SonicPoint(s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .583
Using The RF Management Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .584
Types of RF Threat Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .586
Practical RF Management Field Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . .587
Chapter 46: Using RF Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .591
SonicPoint > RF Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .591
RF Analysis Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .591
Using RF Analysis on SonicPoint(s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .592
Chapter 47: SonicPoint FairNet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .597
SonicPoint > FairNet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .597
SonicPoint FairNet Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .597
Configuring SonicPoint FairNet Bandwidth Limit Policies . . . . . . . . . . . . . . . . . . . .598

Part 8: Firewall
Chapter 48: Configuring Access Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .603
Firewall > Access Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .603
Stateful Packet Inspection Default Access Rules Overview . . . . . . . . . . . . . . . . . .604
Using Bandwidth Management with Access Rules Overview . . . . . . . . . . . . . . . . .605
Configuration Task List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .606

SonicOS 5.8.1 Administrator Guide

xi

Chapter 49: Configuring Application Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617
Application Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617
Application Control Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617
Licensing Application Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647
Firewall > App Control Advanced . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650
Firewall > App Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 659
Firewall > Match Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665
Firewall > Action Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 668
Firewall > Address Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672
Firewall > Service Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672
Firewall > Email Address Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672
Verifying App Control Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673
Useful Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673
App Control Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 680
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708

Part 9: Firewall Settings
Chapter 50: Configuring Advanced Access Rule Settings . . . . . . . . . . . . . . . . . . . . . . 711
Firewall Settings > Advanced . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711
Detection Prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712
Dynamic Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712
Source Routed Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713
Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714
Access Rule Service Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714
IP and UDP Checksum Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
Connection Limiting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
Chapter 51: Configuring Bandwidth Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717
Firewall Settings > BWM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717
Understanding Bandwidth Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718
Configuring the Firewall Settings > BWM Page . . . . . . . . . . . . . . . . . . . . . . . . . . . 719
Methods of Configuring Bandwidth Management . . . . . . . . . . . . . . . . . . . . . . . . . . 720
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733
Chapter 52: Configuring Flood Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735
Firewall Settings > Flood Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735
TCP Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736
SYN Flood Protection Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737
Configuring Layer 3 SYN Flood Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738
Configuring Layer 2 SYN/RST/FIN Flood Protection . . . . . . . . . . . . . . . . . . . . . . . 740
TCP Traffic Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741
Chapter 53: Configuring Multicast Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745
Firewall Settings > Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745
Multicast Snooping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746
Multicast Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746
IGMP State Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747

xii

SonicOS 5.8.1 Administrator Guide

Enabling Multicast on LAN-Dedicated Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . .748
Enabling Multicast Through a VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .749
Chapter 54: Managing Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .751
Firewall Settings > QoS Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .751
Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .751
Marking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .752
Conditioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .753
802.1p and DSCP QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .754
Bandwidth Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .765
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .772
Chapter 55: Configuring SSL Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .777
Firewall Settings > SSL Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .777
Overview of SSL Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .777
SSL Control Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .785
Enabling SSL Control on Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .787
SSL Control Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .787

Part 10: DPI-SSL
Chapter 56: Configuring Client DPI-SSL Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .793
DPI-SSL > Client SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .793
DPI-SSL Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .793
Configuring Client DPI-SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .794
Chapter 57: Configuring Server DPI-SSL Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . .799
DPI-SSL > Server SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .799
DPI-SSL Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .799
Configuring Server DPI-SSL Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .800

Part 11: VoIP
Chapter 58: Configuring VoIP Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .805
VoIP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .805
What is VoIP? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .805
VoIP Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .805
VoIP Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .806
SonicWALL’s VoIP Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .808
VoIP Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .815
Configuring SonicWALL VoIP Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .815
VoIP Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .825
VoIP Call Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .828

Part 12: Anti-Spam
Chapter 59: Configuring Anti-Spam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .833
Anti-Spam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .833
Anti-Spam Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .833
What is Anti-Spam? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .834
Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .834

SonicOS 5.8.1 Administrator Guide

xiii

How Does the Anti-Spam Service Work? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835
Purchasing an Anti-Spam License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 838
Anti-Spam > Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 840
Anti-Spam > Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 842
Configuring Anti-Spam for UTM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 842
Anti-Spam > Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845
Anti-Spam > Real-Time Black List Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845
Anti-Spam > Junk Box Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 849
Anti-Spam > Junk Box View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 850
Anti-Spam > Junk Box Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852
Anti-Spam > User View Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852
Anti-Spam > Address Books . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853
Anti-Spam > Manage Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856
Anti-Spam > LDAP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857
Anti-Spam > Advanced . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 861
Anti-Spam > Downloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 862

Part 13: VPN
Chapter 60: Configuring VPN Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865
VPN > Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865
VPN Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865
Configuring VPNs in SonicOS Enhanced . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 869
Configuring GroupVPN Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879
Site-to-Site VPN Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 890
Creating Site-to-Site VPN Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 890
Route Based VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905
Using Route Based VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906
Adding a Tunnel Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906
Creating a Static Route for Tunnel Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 908
Route Entries for Different Network Segments . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909
Redundant Static Routes for a Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909
Drop Tunnel Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909
VPN Auto-Added Access Rule Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910
Chapter 61: Configuring Advanced VPN Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913
VPN > Advanced . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913
Advanced VPN Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914
Chapter 62: Configuring DHCP Over VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919
VPN > DHCP over VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919
DHCP Relay Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919
Configuring the Central Gateway for DHCP Over VPN . . . . . . . . . . . . . . . . . . . . . 920
Configuring DHCP over VPN Remote Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . 921
Current DHCP over VPN Leases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 923
Chapter 63: Configuring L2TP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925
VPN > L2TP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925
Configuring the L2TP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926

xiv

SonicOS 5.8.1 Administrator Guide

Part 14: SSL VPN
Chapter 64: SSL VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .931
SSL VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .931
SSL VPN NetExtender Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .932
Configuring Users for SSL VPN Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .935
SSL VPN > Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .937
SSL VPN > Server Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .938
SSL VPN > Portal Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .939
SSL VPN > Client Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .940
SSL VPN > Client Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .943
SSL VPN > Virtual Office . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .945
Accessing the SonicWALL SSL VPN Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .945
Using NetExtender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .945
Configuring SSL VPN Bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .971
Using SSL VPN Bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .975

Part 15: Virtual Assist
Chapter 65: Configuring Virtual Assist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .985
Virtual Assist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .985
Virtual Assist Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .985
Virtual Assist > Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .985
Virtual Assist > Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .986
Using Virtual Assist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .990

Part 16: User Management
Chapter 66: Managing Users and Authentication Settings . . . . . . . . . . . . . . . . . . . . . .995
User Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .995
Introduction to User Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .995
Viewing Status on Users > Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1018
Configuring Settings on Users > Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1019
Configuring Local Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1027
Configuring Local Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1034
Configuring RADIUS Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1039
Configuring LDAP Integration in SonicOS Enhanced . . . . . . . . . . . . . . . . . . . . . .1046
Configuring Single Sign-On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1060
Configuring Multiple Administrator Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1114
Chapter 67: Managing Guest Services and Guest Accounts . . . . . . . . . . . . . . . . . . . .1123
Users > Guest Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1123
Global Guest Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1124
Guest Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1124
Users > Guest Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1125
Viewing Guest Account Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1125
Adding Guest Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1126
Enabling Guest Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1128
Enabling Auto-prune for Guest Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1128
Printing Account Details. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1128

SonicOS 5.8.1 Administrator Guide

xv

Users > Guest Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1129
Logging Accounts off the Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1129

Part 17: High Availability
Chapter 68: Setting Up High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1133
High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1133
Benefits of High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1134
How High Availability Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1135
Stateful High Availability Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1136
Active/Active DPI Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1140
High Availability License Synchronization Overview . . . . . . . . . . . . . . . . . . . . . . 1141
Stateful and Non-Stateful High Availability Prerequisites . . . . . . . . . . . . . . . . . . 1141
Associating Appliances on MySonicWALL for High Availability . . . . . . . . . . . . . . 1145
Configuring High Availability in SonicOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1154
High Availability > Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1157
High Availability > Advanced Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1159
High Availability > Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1161
Applying Licenses to SonicWALL Security Appliances . . . . . . . . . . . . . . . . . . . . 1165
Verifying High Availability Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1169
Verifying Active/Active UTM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1171

Part 18: Security Services
Chapter 70: Managing SonicWALL Security Services . . . . . . . . . . . . . . . . . . . . . . . . . 1177
SonicWALL Security Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1177
Security Services Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1178
Managing Security Services Online . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1180
Configuring Security Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1181
Activating Security Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1184
Chapter 71: Configuring SonicWALL Content Filtering Service . . . . . . . . . . . . . . . . . 1185
Security Services > Content Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1185
SonicWALL CFS Implementation with Application Control . . . . . . . . . . . . . . . . . 1186
SonicWALL Legacy Content Filtering Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 1186
CFS 3.0 Policy Management Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1187
CFS 3.0 Configuration Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1192
Legacy Content Filtering Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1200
Configuring Legacy SonicWALL Filter Properties . . . . . . . . . . . . . . . . . . . . . . . . 1204
Configuring Websense Enterprise Content Filtering . . . . . . . . . . . . . . . . . . . . . . 1213
Chapter 72: Activating SonicWALL Client Anti-Virus . . . . . . . . . . . . . . . . . . . . . . . . . 1215
Security Services > Client AV Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1215
Activating SonicWALL Client Anti-Virus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1216
Activating a SonicWALL Client Anti-Virus FREE TRIAL . . . . . . . . . . . . . . . . . . . . 1217
Enforcing Client Anti-Virus on Network Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . 1217
Configuring Client Anti-Virus Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1218

xvi

SonicOS 5.8.1 Administrator Guide

Chapter 73: Managing SonicWALL Gateway Anti-Virus Service . . . . . . . . . . . . . . . . .1223
Security Services > Gateway Anti-Virus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1223
SonicWALL GAV Multi-Layered Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1224
HTTP File Downloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1226
SonicWALL GAV Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1226
Creating a mysonicwall.com Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1227
Registering Your SonicWALL Security Appliance . . . . . . . . . . . . . . . . . . . . . . . . .1229
Activating the Gateway Anti-Virus, Anti-Spyware, and IPS License . . . . . . . . . . .1229
Activating FREE TRIALs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1231
Setting Up SonicWALL Gateway Anti-Virus Protection . . . . . . . . . . . . . . . . . . . . .1231
Enabling SonicWALL GAV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1232
Applying SonicWALL GAV Protection on Interfaces . . . . . . . . . . . . . . . . . . . . . . .1232
Applying SonicWALL GAV Protection on Zones . . . . . . . . . . . . . . . . . . . . . . . . . .1233
Viewing SonicWALL GAV Status Information . . . . . . . . . . . . . . . . . . . . . . . . . . . .1233
Updating SonicWALL GAV Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1234
Specifying Protocol Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1234
Enabling Inbound Inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1235
Enabling Outbound Inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1235
Restricting File Transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1236
Configuring Gateway AV Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1237
Configuring HTTP Clientless Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1237
Configuring a SonicWALL GAV Exclusion List . . . . . . . . . . . . . . . . . . . . . . . . . . .1238
Cloud Anti-Virus Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1238
Viewing SonicWALL GAV Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1240
Chapter 74: Activating Intrusion Prevention Service . . . . . . . . . . . . . . . . . . . . . . . . . .1243
Security Services > Intrusion Prevention Service . . . . . . . . . . . . . . . . . . . . . . . . . . . .1243
SonicWALL Deep Packet Inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1243
How SonicWALL’s Deep Packet Inspection Works . . . . . . . . . . . . . . . . . . . . . . . .1244
SonicWALL IPS Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1245
SonicWALL Gateway Anti-Virus, Anti-Spyware, and IPS Activation . . . . . . . . . . .1245
Creating a mysonicwall.com Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1246
Registering Your SonicWALL Security Appliance . . . . . . . . . . . . . . . . . . . . . . . . .1247
Activating FREE TRIALs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1248
Activating the Gateway Anti-Virus, Anti-Spyware, and IPS License . . . . . . . . . . .1248
Setting Up SonicWALL Intrusion Prevention Service Protection . . . . . . . . . . . . . .1249
Chapter 75: Activating Anti-Spyware Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1253
Security Services > Anti-Spyware Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1253
SonicWALL Gateway Anti-Virus, Anti-Spyware, and IPS Activation . . . . . . . . . . .1254
Creating a mysonicwall.com Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1255
Registering Your SonicWALL Security Appliance . . . . . . . . . . . . . . . . . . . . . . . . .1256
Activating FREE TRIALs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1256
Activating the Gateway Anti-Virus, Anti-Spyware, and IPS License . . . . . . . . . . .1257
Setting Up SonicWALL Anti-Spyware Service Protection . . . . . . . . . . . . . . . . . . .1258

SonicOS 5.8.1 Administrator Guide

xvii

Chapter 76: Configuring SonicWALL Real-Time Blacklist . . . . . . . . . . . . . . . . . . . . . 1259
SMTP Real-Time Black List Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1259
Chapter 77: Configuring Geo-IP and Botnet Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . 1261
Security Services > Geo-IP Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1262
Security Services > Botnet Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1264
Checking Geographic Location and Botnet Server Status . . . . . . . . . . . . . . . . . . 1265

Part 19: WAN Acceleration
Chapter 78: WAN Acceleration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1269
WAN Acceleration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1269
What is WAN Acceleration? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1270
Transmission Control Protocol Acceleration Overview . . . . . . . . . . . . . . . . . . . . . 1270
Windows File Sharing Acceleration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 1271
Deployment Pre-Requisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1273
Deployment Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1273
Configuration Task List Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1274
WAN Acceleration > Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1274
WAN Acceleration > TCP Acceleration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1278
Configuration Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1280
Statistics Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1281
Connections Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1282
WAN Acceleration > WFS Acceleration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1283
Configuration Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1284
Domain Details Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1285
Shares Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1292
Statistics Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1295
Tools Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1296
WAN Acceleration > System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1300
System Status Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1301
Interface Status Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1303
Management Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1305
Settings Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1306
Firmware Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1307
WAN Acceleration > Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1308
Configuring WAN Acceleration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1309
Configuring the Network Interface for the SonicWALL WXA Series Appliance . . 1309
Configuring TCP Acceleration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1315
Configuring WFS Acceleration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1326
Verifying WAN Acceleration Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1343

xviii

SonicOS 5.8.1 Administrator Guide

Part 20: Log
Chapter 79: Managing Log Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1349
Log > View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1349
Log View Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1350
Refresh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1350
Clear Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1351
Export Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1351
E-mail Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1351
Filtering Log Records Viewed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1351
Log Event Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1352
Deep Packet Forensics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1352
Distributed Event Detection and Replay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1353
Methods of Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1354
Chapter 80: Configuring Log Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1355
Log > Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1355
Log Severity/Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1356
Log Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1357
Chapter 81: Configuring Syslog Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1361
Log > Syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1361
Syslog Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1362
Syslog Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1363
Chapter 82: Configuring Log Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1365
Log > Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1365
E-mail Log Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1365
Mail Server Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1366
Solera Capture Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1366
Chapter 83: Configuring Flow Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1369
Log > Flow Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1369
External Flow Reporting Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1370
Internal App Flow Reporting Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1371
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1371
External Collector Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1372
Connection Report Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1374
Other Report Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1375
NetFlow Activation and Deployment Information . . . . . . . . . . . . . . . . . . . . . . . . .1376
User Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1377
NetFlow Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1381
Chapter 84: Configuring Name Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1387
Log > Name Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1387
Selecting Name Resolution Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1387
Specifying the DNS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1388

SonicOS 5.8.1 Administrator Guide

xix

Chapter 85: Generating Log Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1389
Log > Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1389
Data Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1390
View Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1390
Chapter 86: Activating SonicWALL ViewPoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1391
Log > ViewPoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1391
Activating ViewPoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1392
Enabling ViewPoint Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1393

Part 21: Wizards
Chapter 87: Configuring Internet Connectivity on SonicWALL Appliances . . . . . . . 1397
Wizards > Setup Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1397
Using the Setup Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1397
Configuring a Static IP Address with NAT Enabled . . . . . . . . . . . . . . . . . . . . . . . 1397
Start the Setup Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1398
Select Deployment Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1398
Change Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1399
Change Time Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1399
Configure 3G/Modem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1400
WAN Network Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1401
LAN Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1404
WLAN Radio Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1405
Ports Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1406
SonicWALL Configuration Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1407
Chapter 88: Using the Registration & License Wizard . . . . . . . . . . . . . . . . . . . . . . . . . 1409
Wizards > Registration & License Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1409
Chapter 89: Configuring a Public Server with the Wizard . . . . . . . . . . . . . . . . . . . . . . 1413
Wizards > Public Server Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1413
Chapter 90: Configuring VPN Policies with the VPN Policy Wizard . . . . . . . . . . . . . . 1417
Wizards > VPN Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1417
Using the VPN Policy Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1417
Connecting the Global VPN Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1420
Configuring a Site-to-Site VPN using the VPN Wizard . . . . . . . . . . . . . . . . . . . . . 1421
Chapter 91: Using the Application Firewall Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . 1425
Wizards > Application Firewall Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1425

xx

SonicOS 5.8.1 Administrator Guide

Part 22: Appendices
Appendix A: CLI Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1431
Input Data Format Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1431
Text Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1432
Editing and Completion Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1432
Command Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1433
Configuration Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1434
Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1434
Factory Reset to Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1434
Management Methods for the SonicWALL Network Security Appliance . . . . . . . .1435
Initiating a Management Session using the CLI . . . . . . . . . . . . . . . . . . . . . . . . . .1435
Logging in to the SonicOS CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1436
SonicOS Enhanced Command Listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1436
Configuring Site-to-Site VPN Using CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1474

Index .....................................................................................................................1481

SonicOS 5.8.1 Administrator Guide

xxi

xxii

SonicOS 5.8.1 Administrator Guide

PART 1
Part 1:

SonicOS 5.8.1 Administrator Guide

Introduction

23

24

SonicOS 5.8.1 Administrator Guide

CHAPTER 1
Chapter 1:

Preface

Preface
Copyright Notice
© 2011 SonicWALL, Inc.
All rights reserved.
Under the copyright laws, this manual or the software described within, can not be copied, in
whole or part, without the written consent of the manufacturer, except in the normal use of the
software to make a backup copy. The same proprietary and copyright notices must be affixed
to any permitted copies as were affixed to the original. This exception does not allow copies to
be made for others, whether or not sold, but all of the material purchased (with all backup
copies) can be sold, given, or loaned to another person. Under the law, copying includes
translating into another language or format.
Specifications and descriptions subject to change without notice.

Trademarks
SonicWALL is a registered trademark of SonicWALL, Inc.
Microsoft Windows 2000, Windows XP, Windows Vista, Windows Server 2003, Internet
Explorer, and Active Directory are trademarks or registered trademarks of Microsoft
Corporation.
eDirectory and NetWare are registered trademarks of Novell, Inc.
Netscape is a registered trademark of Netscape Communications Corporation in the U.S. and
other countries. Netscape Navigator and Netscape Communicator are also trademarks of
Netscape Communications Corporation and may be registered outside the U.S.
Adobe, Acrobat, and Acrobat Reader are either registered trademarks or trademarks of Adobe
Systems Incorporated in the U.S. and/or other countries.
Other product and company names mentioned herein may be trademarks and/or registered
trademarks of their respective companies and are the sole property of their respective
manufacturers.

SonicOS 5.8.1 Administrator Guide

25

Preface

Limited Warranty
SonicWALL, Inc. warrants that commencing from the delivery date to Customer (but in any case
commencing not more than ninety (90) days after the original shipment by SonicWALL), and
continuing for a period of twelve (12) months, that the product will be free from defects in
materials and workmanship under normal use. This Limited Warranty is not transferable and
applies only to the original end user of the product. SonicWALL and its suppliers' entire liability
and Customer's sole and exclusive remedy under this limited warranty will be shipment of a
replacement product. At SonicWALL's discretion the replacement product may be of equal or
greater functionality and may be of either new or like-new quality. SonicWALL's obligations
under this warranty are contingent upon the return of the defective product according to the
terms of SonicWALL's then-current Support Services policies.
This warranty does not apply if the product has been subjected to abnormal electrical stress,
damaged by accident, abuse, misuse or misapplication, or has been modified without the
written permission of SonicWALL.
DISCLAIMER OF WARRANTY. EXCEPT AS SPECIFIED IN THIS WARRANTY, ALL
EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS, AND WARRANTIES
INCLUDING, WITHOUT LIMITATION, ANY IMPLIED WARRANTY OR CONDITION OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NONINFRINGEMENT,
SATISFACTORY QUALITY OR ARISING FROM A COURSE OF DEALING, LAW, USAGE, OR
TRADE PRACTICE, ARE HEREBY EXCLUDED TO THE MAXIMUM EXTENT ALLOWED BY
APPLICABLE LAW. TO THE EXTENT AN IMPLIED WARRANTY CANNOT BE EXCLUDED,
SUCH WARRANTY IS LIMITED IN DURATION TO THE WARRANTY PERIOD. BECAUSE
SOME STATES OR JURISDICTIONS DO NOT ALLOW LIMITATIONS ON HOW LONG AN
IMPLIED WARRANTY LASTS, THE ABOVE LIMITATION MAY NOT APPLY TO YOU. THIS
WARRANTY GIVES YOU SPECIFIC LEGAL RIGHTS, AND YOU MAY ALSO HAVE OTHER
RIGHTS WHICH VARY FROM JURISDICTION TO JURISDICTION. This disclaimer and
exclusion shall apply even if the express warranty set forth above fails of its essential purpose.
DISCLAIMER OF LIABILITY. SONICWALL'S SOLE LIABILITY IS THE SHIPMENT OF A
REPLACEMENT PRODUCT AS DESCRIBED IN THE ABOVE LIMITED WARRANTY. IN NO
EVENT SHALL SONICWALL OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES
WHATSOEVER, INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS,
BUSINESS INTERRUPTION, LOSS OF INFORMATION, OR OTHER PECUNIARY LOSS
ARISING OUT OF THE USE OR INABILITY TO USE THE PRODUCT, OR FOR SPECIAL,
INDIRECT, CONSEQUENTIAL, INCIDENTAL, OR PUNITIVE DAMAGES HOWEVER
CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY ARISING OUT OF THE USE
OF OR INABILITY TO USE HARDWARE OR SOFTWARE EVEN IF SONICWALL OR ITS
SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. In no event
shall SonicWALL or its suppliers' liability to Customer, whether in contract, tort (including
negligence), or otherwise, exceed the price paid by Customer. The foregoing limitations shall
apply even if the above-stated warranty fails of its essential purpose. BECAUSE SOME
STATES OR JURISDICTIONS DO NOT ALLOW LIMITATION OR EXCLUSION OF
CONSEQUENTIAL OR INCIDENTAL DAMAGES, THE ABOVE LIMITATION MAY NOT APPLY
TO YOU.

26

SonicOS 5.8.1 Administrator Guide

About this Guide

About this Guide
Welcome to the SonicOS Enhanced 5.8 Administrator’s Guide. This manual provides the
information you need to successfully activate, configure, and administer SonicOS Enhanced
5.8 for SonicWALL security appliances.

Note

Always check  for the latest
version of this manual as well as other SonicWALL products and services documentation.

Organization of this Guide
The SonicOS Enhanced 5.8 Administrator’s Guide organization is structured into the following
parts that follow the SonicWALL Web Management Interface structure. Within these parts,
individual chapters correspond to SonicWALL security appliance management interface layout.

Part 1 Introduction
This part provides an overview of new SonicWALL SonicOS Enhanced features, guide
conventions, support information, and an overview of the SonicWALL security appliance
management interface.

Part 2 Dashboard
The SonicWALL Visualization Dashboard offers administrators an effective and efficient
interface to visually monitor their network in real time, providing effective flow charts of realtime
data, customizable rules, and flexible interface settings. The following tools are included in the
Dashboard part:
•

App Flow Monitor

•

Real-Time Monitor

•

Top Global Malware

•

Log Monitor

•

Connection Monitor

•

Packet Monitor

Part 3 System
This part covers a variety SonicWALL security appliance controls for managing system status
information, registering the SonicWALL security appliance, activating and managing
SonicWALL Security Services licenses, configuring SonicWALL security appliance local and
remote management options, managing firmware versions and preferences, and using included
diagnostics tools for troubleshooting.

Part 4 Network
This part covers configuring the SonicWALL security appliance for your network environment.
The Network section of the SonicWALL Management Interface includes:
•

Interfaces - configure logical interfaces for connectivity.

SonicOS 5.8.1 Administrator Guide

27

About this Guide

•

WAN Failover and Load Balancing - configure one of the user-defined interfaces to act
as a secondary WAN port for backup or load balancing.

•

Zones - configure security zones on your network.

•

DNS - set up DNS servers for name resolution.

•

Address Objects - configure host, network, and address range objects.

•

Routing - view the Route Table, ARP Cache and configure static and dynamic routing by
interface.

•

NAT Policies - create NAT policies including One-to-One NAT, Many-to-One NAT, Manyto-Many NAT, or One-to-Many NAT.

•

ARP - view the ARP settings and clear the ARP cache as well as configure ARP cache time.

•

DHCP Server - configure the SonicWALL as a DHCP Server on your network to
dynamically assign IP addresses to computers on your LAN or DMZ zones.

•

IP Helper - configure the SonicWALL to forward DHCP requests originating from the
interfaces on the SonicWALL to a centralized server on behalf of the requesting client.

•

Web Proxy - configure the SonicWALL to automatically forward all Web proxy requests to
a network proxy server.

•

Dynamic DNS - configure the SonicWALL to dynamically register its WAN IP address with
a DDNS service provider.

Part 5 3G/Analog Modem
This part covers the configuration of the 3G (Third Generation) wireless WAN interface on
SonicWALL UTM appliances that support this feature. This allows the SonicWALL to utilize
data connections over 3G Cellular networks when a 3G card is plugged into the appliance. This
feature can also handle Analog Modem connections when this type of device is connected to
the appliance.

Part 6 Wireless
This part covers the configuration of the built-in 802.11 antennas for wireless SonicWALL security
appliances.

Part 7 SonicPoint
This part covers the configuration of the SonicWALL security appliance for provisioning and
managing SonicWALL SonicPoints as part of a SonicWALL Distributed Wireless Solution.

Part 8 Firewall
This part describes access rules as well as Application Firewall, which is a set of applicationspecific policies that gives you granular control over network traffic on the level of users, email
users, schedules, and IP-subnets. The primary functionality of this application-layer access
control feature is to regulate Web browsing, file transfer, email, and email attachments.

Part 9 Firewall Settings
This part covers tools for managing how the SonicWALL security appliance handles traffic
through the firewall.

28

SonicOS 5.8.1 Administrator Guide

About this Guide

Part 10 DPI-SSL
This part describes the Deep Packet Inspection Secure Socket Layer (DPI-SSL) feature to allow
for the inspection of encrypted HTTPS traffic and other SSLbased traffic. Client DPI-SSL is used to
inspect HTTPS traffic when clients on the SonicWALL security appliance’s LAN access content
located on the WAN. Server DPI-SSL is used to inspect HTTPS traffic when remote clients connect
over the WAN to access content located on the SonicWALL security appliance’s LAN.

Part 1 VoIP
This part provides instructions for configuring the SonicWALL security appliance to support
H.323 or SIP Voice over IP (VoIP) connections.

Part 12 Anti-Spam
This part provides instructions for configuring the Anti-Spam feature, which provides a quick,
efficient, and effective way to add anti-spam and anti-phishing capabilities to your existing
SonicWALL UTM appliance. This feature uses the spam-filtering capabilities of SonicWALL
Email Security to reduce the amount of junk email the organization delivers to users.

Part 13 VPN
This part covers how to create VPN policies on the SonicWALL security appliance to support
SonicWALL Global VPN Clients as well as creating site-to-site VPN policies for connecting
offices running SonicWALL security appliances.

Part 14 SSL VPN
This part provides information on how to configure the SSL VPN features on the SonicWALL
security appliance. SonicWALL’s SSL VPN features provide secure, seamless, remote access
to resources on your local networkusing the NetExtender client.

Part 15 Virtual Assist
This part describes the Virtual Assist feature, which allows users to support customer technical
issues without having to be on-site with the customer. This capability serves as an immense timesaver for support personnel, while adding flexibility in how they can respond to support needs.
Users can allow or invite customers to join a “queue” to receive support, then virtually assist each
customer by remotely taking control of a customer’s computer to diagnose and remedy technical
issues.

Part 16 User Management
This part covers how to configure the SonicWALL security appliance for user level
authentication as well as manage guest services for managed SonicPoints.

Part 17 High Availability
This part explains how to configure the SonicWALL security appliance for high availability so
that in case of a loss of network connectivity, another SonicWALL security appliance resumes
all active connections.

SonicOS 5.8.1 Administrator Guide

29

About this Guide

Part 18 Security Services
This part includes an overview of available SonicWALL Security Services as well as instructions
for activating the service, including FREE trials. These subscription-based services include
SonicWALL Gateway Anti-Virus, SonicWALL Intrusion Prevention Service, SonicWALL
Content Filtering Service, SonicWALL Client Anti-Virus, and well as other services.

Part 19 Log
This part covers managing the SonicWALL security appliance’s enhanced logging, alerting, and
reporting features. The SonicWALL security appliance’s logging features provide a
comprehensive set of log categories for monitoring security and network activities.

Part 20 Wizards
This part walks you through using the SonicWALL Configuration Wizards for configuring the
SonicWALL security appliance. The SonicWALL Configuration Wizards in SonicOS Enhanced
include:
•

The Setup Wizard takes you step by step through network configuration for Internet
connectivity. There are four types of network connectivity available: Static IP, DHCP,
PPPoE, and PPTP.

•

The Registration & License Wizard simplifies the process of registering your SonicWALL
security appliance and obtaining licenses for additional security services.

•

The Public Server Wizard takes you step by step through adding a server to your network,
such as a mail server or a Web server. The wizard automates much of the configuration you
need to establish security and access for the server.

•

The VPN Policy Wizard steps you through the configuration of Group VPNs and site-tosite VPNs.

•

The Application Firewall Wizard takes you step by step through configuration of
Application Objects, Actions, Email User Objects, and Policies.

Part 21 Appendices
This part contains the Command Line Interface (CLI) guide, which describes how to configure
the SonicWALL security appliance using CLI commands.

Guide Conventions
The following conventions used in this guide are as follows:

30

Convention

Use

Bold

Highlights items you can select on the SonicWALL
security appliance management interface.

Italic

Highlights a value to enter into a field. For example, “type
192.168.168.168 in the IP Address field.”

SonicOS 5.8.1 Administrator Guide

About this Guide

Menu Item > Menu Item

Indicates a multiple step Management Interface menu
choice. For example, Security Services > Content Filter
means select Security Services, then select Content
Filter.

Icons Used in this Manual
These special messages refer to noteworthy information, and include a symbol for quick
identification:

Caution

Important information that cautions about features affecting firewall performance, security
features, or causing potential problems with your SonicWALL.

Tip

Useful information about security features and configurations on your SonicWALL.

Note

Important information on a feature that requires callout for special attention.

SonicWALL Technical Support
For timely resolution of technical support questions, visit SonicWALL on the Internet at
http://www.sonicwall.com/us/Support.html. Web-based resources are available to help you
resolve most technical issues or contact SonicWALL Technical Support. To contact SonicWALL
telephone support, see the telephone numbers listed below:

North America Telephone Support
U.S./Canada: +1 888.793.2830 or +1 408.837.4317

International Telephone Support
Australia: + 1800.35.1642
Austria: +43(0)820.400.105
EMEA: +31(0)411.617.810
France: +44 193.257.3927
Germany: +44 193.257.3910
Hong Kong: +1 800.93.0997
India: 000.800.100.3395
Italy: +44 193.257.3928
Japan: 0120.569122
New Zealand: + 800.446489
Singapore: + 800.110.1441
Spain: +44 193.257.3921

SonicOS 5.8.1 Administrator Guide

31

About this Guide

Switzerland: +44 193.257.3929
UK: +44 193.257.3929

More Information on SonicWALL Products
Contact SonicWALL, Inc. for information about SonicWALL products and services at:
Web:http://www.sonicwall.com
E-mail:sales@sonicwall.com
Phone:(408) 745-9600
Fax:(408) 745-9300

32

SonicOS 5.8.1 Administrator Guide

CHAPTER 2
Chapter 2:

Introduction

Introduction
SonicOS Enhanced 5.8.1 is the most powerful SonicOS operating system for SonicWALL
security appliances. This chapter contains the following sections:
•

“Key Features in SonicOS Enhanced 5.8.1” on page 33

•

“Key Features in SonicOS Enhanced 5.8” on page 36

•

“Key Features in SonicOS Enhanced 5.6” on page 40

•

“Key Features in SonicOS Enhanced 5.5” on page 42

•

“Key Features in SonicOS Enhanced 5.3” on page 42

•

“Key Features in SonicOS Enhanced 5.2” on page 42

•

“Key Features in SonicOS Enhanced 5.1” on page 43

•

“SonicWALL Management Interface” on page 48

Key Features in SonicOS Enhanced 5.8.1
SonicOS Enhanced 5.8.1 and higher releases include the following key features:
•

App Control Policy Configuration via App Flow Monitor - The Dashboard > App Flow
Monitor page now provides a Create Rule button that allows the administrator to quickly
configure App Rule policies for application blocking, bandwidth management, or packet
monitoring.

•

Current Users and Detail of Users Options for TSR - SonicOS 5.8.1.0 provides two new
checkboxes, Current users and Detail of users, in the Tech Support Report section of the
System > Diagnostics page. These options allow the currently connected users to be
omitted from the TSR, included as a simple summary list, or included with full details.

•

Customizable Login Page - SonicOS 5.8.1.0 provides the ability to customize the
language of the login authentication pages that are presented to users. Administrators can
translate the login related pages with their own wording and apply the changes so that they
take effect without rebooting.

SonicOS 5.8.1 Administrator Guide

33

Introduction

Although the entire SonicOS interface is available in different languages, sometimes the
administrator does not want to change the entire UI language to a specific local one.
However, if the firewall requires authentication before users can access other networks, or
enables external access services (e.g. VPN, SSL-VPN), those login related pages usually
should be localized to make them more usable for normal users.
•

Geo-IP & Botnet Filtering - This feature allows the administrator to block connections to
or from a geographic location based on IP address(es), and to or from a Botnet command
and control server. A new Security Services > Geo-IP & Botnet Filter page has been added
to the management interface.
You can look up an IP address to find out the domain, DNS server, and check whether it is
part of a Botnet. The Services > Geo-IP & Botnet Filter page provides this functionality at
the bottom of the page. The System > Diagnostics and Dashboard > App Flow Monitor
pages also provide this capability.

•

Global BWM Ease of Use Enhancements - Several enhancements are provided in this
release to improve ease of use for Bandwidth Management (BWM) configuration, and also
to increase throughput performance of managed packets:
– Support for simple bandwidth management on all interfaces.
– Support for bandwidth management on both ingress and egress.
– Support for specifying bandwidth management priority per firewall rules and app rules.
– Support for default bandwidth management Q for all traffic.
– Support for applying BWM via app flow monitor page.

Global bandwidth management provide 8 priority queues. The Guaranteed rate and
Maximum\Burst rate are user configurable. Eight queues are created for each physical
interface. As traffic flows through the firewall from interface1 to interface2, BWM is applied
on both the interfaces according to the configuration. For example, ingress BWM can be
applied based on interface1 settings and egress BWM applied on interface2 settings.
•

LDAP "Primary group" Attribute - To allow Domain Users to be used when configuring
policies, membership of the Domain Users group can be looked up via an LDAP "Primary
group" attribute, and SonicOS 5.8.1.0 provides a new attribute setting in the LDAP schema
configuration for using this feature.

•

Management Traffic Only Option for Network Interfaces - SonicOS 5.8.1.0 provides a
Management Traffic Only option on the Advanced tab of the interface configuration window,
when configuring an interface from the Network > Interfaces page. When selected, this
option prioritizes all traffic arriving on that interface. The administrator should enable this
option ONLY on interfaces intended to be used exclusively for management purposes. If
this option is enabled on a regular interface, it will still prioritize the traffic, but that may not
be the desirable result. It is up to the administrator to limit the traffic to just management;
the firmware does not have the ability to prevent pass- through traffic.
The purpose of this option is to provide the ability to access the SonicOS management
interface even when the appliance is running at 100% utilization.

•

34

Preservation of Anti-Virus Exclusions After Upgrade - SonicOS 5.8.1.0 provides an
enhancement to detect if the starting IP address in an existing range configured for
exclusion from anti-virus enforcement belongs to either LAN, WAN, DMZ or WLAN zones.
After upgrading to a newer firmware version, SonicOS applies the IP range to a newly
created address object. Detecting addresses for other zones not listed above, including
custom zones, is not supported.

SonicOS 5.8.1 Administrator Guide

Introduction

Anti-virus exclusions which existed before the upgrade and which apply to hosts residing
in custom zones will not be detected. IP address ranges not falling into the supported zones
will default to the LAN zone. Conversion to the LAN zone occurs during the restart booting
process. There is no message in the SonicOS management interface at login time
regarding the conversion.
•

SonicWALL Enforced Client Anti Virus - SonicOS 5.8.1.0 supports a new SonicWALL
Enforced Client Anti-Virus. With Enforced Client, the SonicWALL firewall does not allow
clients to connect and access the Internet unless they have client anti-virus installed.
The SonicWALL Enforced Client Beta Release Notes, available with the software on
MySonicWALL, provide detailed information about client installation and usage, and
describe administrator access to the SonicWALL Enforced Client Anti-Virus Policy and
Reporting Server (EPRS). The EPRS system allows administrators to configure policies for
clients and client groups, and to view reports showing top hazards and other client status.

Caution

Before installing SonicWALL Enforced Client on your client systems, Kaspersky Anti-Virus
must be licensed on your SonicWALL appliance. To do this, email the serial number of the
appliance to the beta alias (secbeta@sonicwall.com). After the general release, if you are
running a firmware version prior to 5.8.1 and currently licensed for McAfee Anti-Virus, the
McAfee AV license must expire or be expired before you can license Kaspersky AV. Please
note that SonicWALL cannot reinstate your McAfee licensing if it is prematurely expired on
customer request.
Please do NOT contact SonicWALL technical support with any requests about the Enforced
Client beta program. All questions and feedback should go to the above beta alias.
•

User Monitor Tool - The User Monitor tool provides a quick and easy method to monitor
the number of active users on the SonicWALL security appliance. To view the User Monitor
tool, navigate to the Dashboard > User Monitor page. The tool provides several options
for setting the scale of time over which user activity is displayed. The tool can display all
users, only users who logged in through the web portal, or only users who logged in
remotely through GVC or L2TP.

•

WAN Optimization - SonicOS 5.8.1.0 supports the use of WAN Optimization devices with
SonicWALL firewalls to optimize traffic traversing a WAN connection. For example, the
diagram below shows a WANOPT deployment between a data center and remote office. In
such a deployment, the SonicWALL gateway may be providing services such as attack
prevention, VPN, routing and anti-spam.
WAN connections such as T1/E1 or xDSL typically have a round trip time of greater 25ms
and less than 100ms. This latency causes some applications to perform less than expected
or poorly. The typical remedy is to purchase a higher quality service or larger provision of
bandwidth. WAN optimization can delay or postpone the expenditure and provide an
increase in application performance response time.

SonicOS 5.8.1 Administrator Guide

35

Introduction

•

Wire/Tap Mode - Wire Mode is a deployment option where the SonicWALL appliance can
be deployed as a "Bump in the Wire." It provides a least-intrusive way to deploy the
appliance in a network. Wire Mode is very well suited for deploying behind a pre-existing
Stateful Packet Inspection (SPI) Firewall.
Wire Mode is a simplified form of Layer 2 Bridge Mode. A Wire Mode interface does not
take any IP address and it is typically configured as a bridge between a pair of interfaces.
None of the packets received on a Wire Mode interface are destined to the firewall, but are
only bridged to the other interface.
Wire Mode operates in any one these 4 different modes:
– Bypass Mode - Bypass Mode can be configured between a pair of interfaces. All traffic

received is bridged to the paired interface. There is no SPI or Deep Packet Inspection
(DPI) processing of traffic in this mode. There is no Application Visibility or Control in
Bypass Mode.
– Inspect Mode - Inspect Mode can be configured between a pair of interfaces. All traffic

received is bridged to the paired interface; in addition, the firewall does SPI and DPI
processing of traffic. There is full Application Visibility, but no Application Control in
Inspect Mode.
– Secure Mode - Secure Mode can be configured between a pair of interfaces. All traffic

received is fully processed by the firewall. There is full Application Visibility and Control
in Secure Mode.
– Tap Mode - Tap Mode can be configured for a single interface. All traffic received is

never sent out of the firewall, but the firewall performs full SPI and DPI processing.
There is full Application Visibility, but no Application Control in Tap Mode. Typically, a
mirror port is set up on the switch to mirror the network traffic to the firewall.
Wire Mode is supported on the following SonicWALL appliance models:
– NSA E8500
– NSA E7500
– NSA E6500
– NSA E5500
– NSA 5000
– NSA 4500
– NSA 3500

Key Features in SonicOS Enhanced 5.8
SonicOS Enhanced 5.8 and higher releases include the following key features:
•

Real-Time Visualization Dashboard - With the new visualization dashboard monitoring
improvements, administrators are able to respond more quickly to network security
vulnerabilities and network bandwidth issues. Administrators can see what websites their
employees are accessing, what applications and services are being used in their networks
and to what extent, in order to police content transmitted in and out of their organizations.
SonicWALL appliances running SonicOS 5.8.0.0 or higher and already licensed for GAV/
IPS/AS, Total Secure, or Comprehensive Gateway Security Suite (CGSS) will receive a
complimentary license for the Real-Time Visualization Dashboard (App Visualization). Note
that appliances running earlier versions of SonicOS and/or appliances not licensed for
GAV/IPS/AS, Total Secure, or CGSS will receive a 30-day free trial

36

SonicOS 5.8.1 Administrator Guide

Introduction

Appliances newly registered and upgraded to SonicOS 5.8.0.0 or higher will receive a 30day free trial license of App Visualization by default.
Navigate to the Log > Flow Reporting page to manually Enable Flow Reporting and
Visualization feature. You can then view real-time application traffic on the Dashboard >
Real-Time Monitor page and application activity in other Dashboard pages for the
configured flows from the SonicWALL application signature database.
If you plan to use both internal and external flow reporting, SonicWALL recommends
enabling the following (located in the Log > Flow Reporting screen) after successfully
registering and licensing your appliance to avoid multiple restarts:
– Report to App Flow Collector
– Report to EXTERNAL Flow Collector
•

Application Intelligence + Control - This feature has two components for more network
security:
– Identification: Identify applications and track user network behaviors in real-time.
– Control: Allow/deny application and user traffic based on bandwidth limiting policies.

Administrators can now more easily create network policy object-based control rules to
filter network traffic flows based on:
– Blocking signature-matching Applications, which are notoriously dangerous and

difficult to enforce
– Viewing the real-time network activity of trusted Users and User Groups and guest

services
– Matching Content-rated categories

Network security administrators now have application-level, user-level, and content-level
real-time visibility into the traffic flowing through their networks. Administrators can take
immediate action to re-traffic engineer their networks, and quickly identify Web usage
abuse, and protect their organizations from infiltration by malware. Administrators can limit
access to bandwidth-hogging websites and applications, reserve higher priority to critical
applications and services, and prevent sensitive data from escaping the SonicWALL
secured networks.
SonicWALL appliances running SonicOS 5.8.0.0 or higher and already licensed for GAV/
IPS/AS, Total Secure, or Comprehensive Gateway Security Suite (CGSS) will receive a
complimentary license for Application Intelligence and Control (App Control). Note that
appliances running earlier versions of SonicOS and/or appliances not licensed for GAV/
IPS/AS, Total Secure, or CGSS will receive a 30-day free trial
Appliances newly registered and upgraded to SonicOS 5.8.0.0 or higher will receive a 30day free trial license of App Control by default.
Select the Enable App Control option on the Firewall > App Control Advanced page to begin
using the App. Control feature.
To create policies using App Rules (included with the App Control license), select Enable
App Rules on the Firewall > App Rules page.
•

Deep Packet Inspection of SSL encrypted data (DPI-SSL) - Provides the ability to
transparently decrypt HTTPS and other SSL-based traffic, scan it for threats using
SonicWALL's Deep Packet Inspection technology, then re-encrypt (or optionally SSLoffload) the traffic and send it to its destination if no threats or vulnerabilities are found. This
feature works for both client and server deployments. It provides additional security,
application control, and data leakage prevention functionality for analyzing encrypted
HTTPS and other SSL-based traffic. The following security services and features are

SonicOS 5.8.1 Administrator Guide

37

Introduction

capable of utilizing DPI-SSL: Gateway Anti-Virus, Gateway Anti-Spyware, Intrusion
Prevention, Content Filtering, Application Control, Packet Monitor and Packet Mirror. DPISSL is supported on SonicWALL NSA models 240 and higher.
•

Gateway Anti-Virus Enhancements (Cloud GAV) - The Cloud Gateway Anti-Virus feature
introduces an advanced malware scanning solution that compliments and extends the
existing Gateway AV scanning mechanisms present on SonicWALL firewalls to counter the
continued growth in the number of malware samples in the wild. Cloud Gateway Anti-Virus
expands the Reassembly Free Deep Packet Inspection engine capabilities by consulting
with the data center based malware analysis servers. This approach keeps the foundation
of RFDPI-based malware detection by providing a low-latency, real-time solution that is
capable of scanning unlimited numbers of files of unlimited size on all protocols that are
presently supported without adding any significant incremental processing overhead to the
appliances themselves. With this additional layer of security, SonicWALL's Next
Generation Firewalls are able to extend their current protection to cover multiple millions of
pieces of malware.

•

NTP Authentication - When adding a Network Time Protocol server, the Add NTP Server
dialog box provides a field to specify the NTP authentication type, such as MD5. Fields are
also available to specify the trust key ID, the key number and the password.

•

Link Aggregation - Link Aggregation provides the ability to group multiple Ethernet
interfaces to form a trunk which looks and acts like a single physical interface. This feature
is useful for high end deployments requiring more than 1 Gbps throughput for traffic flowing
between two interfaces. This functionality is available on all NSA E-Class platforms.
SonicOS 5.8.0.0 supports Static Link Aggregation with the ability to aggregate up to 4 ports
into a single link. A round-robin algorithm is used for load balancing traffic across the
interfaces in an aggregated link.

•

Port Redundancy - Port Redundancy provides the ability to configure a redundant physical
interface for any Ethernet interface in order to provide a failover path in case a link goes
down. Port Redundancy is available on all NSA E-Class platforms.
When the primary interface is active, it handles all traffic from/to the interface. When the
primary interface goes down, the backup interface takes over and handles all outgoing/
incoming traffic. When the primary interface comes up again, it takes over all the traffic
handling duties from the backup interface.
When Port Redundancy, High Availability and WAN Load Balancing are used together, Port
Redundancy takes precedence followed by High Availability, then followed by WAN Load
Balancing.

38

•

Content Filtering Enhancements - The CFS enhancements provide policy management
of network traffic based on Application usage, User activity, and Content type.
Administrators are now able to create multiple CFS policies per user group and set
restrictive 'Bandwidth Management Policies' based on CFS categories.

•

IPFIX and NetFlow Reporting - This feature enables administrators to gain visibility into
traffic flows and volume through their networks, helping them with tracking, auditing and
billing operations. This feature provides standards-based support for NetFlow Reporting
and IPFIX. The data exported through IPFIX contains information about network flows such
as applications, users, and URLs extracted through Application Intelligence, along with
standard attributes such as source/destination IP address (includes support for IPv6
networks), source/destination port, IP protocol, ingress/egress interface, sequence
number, timestamp, number of bytes/packets, and more.

•

Comprehensive Anti-Spam Service (CASS) 2.0 - The Comprehensive Anti-Spam Service
(CASS) feature provides a quick, efficient, and effective way to add anti-spam, antiphishing, and anti-virus capabilities to your SonicWALL security appliance. This feature

SonicOS 5.8.1 Administrator Guide

Introduction

increases the efficiency of your SonicWALL security appliance by providing you the ability
to configure user view settings and filter junk messages before users see it in their inboxes.
The following enhancements are now available with CASS 2.0:
– The Email Security Junk Store application can now reside outside the Exchange Server

system. Unlike in version 1.0, Junk Store can now be installed on another remote
server.
– Dynamic discovery of Junk Store user interface pages has been added. This feature

allows the Junk Store to inform SonicOS of a list of pages to display under Anti-Spam
in the SonicOS left hand navigation pane. For example, the pane might show Junk Box
View, Junk Box Settings, Junk Summary, User View Setup, and/or Address Books.
– User-defined Allow and Deny Lists can now be configured with FQDN and Range

address objects in addition to Host objects.
– A GRID IP Check tool has been added in the Anti-Spam > Status page. The SonicWALL

administrator can specify (on-demand) an IP address to check against the SonicWALL
GRID IP server. The result will either be LISTED or UNLISTED. Connections from a
LISTED host will be blocked by the SonicWALL security appliance running CASS
(unless overridden in the Allow List).
– A parameter to specify the Probe Response Timeout is added in the Anti-Spam >

Settings page Advanced Options section. There are deployment scenarios where a
longer timeout is needed to prevent a target from frequently being marked as
Unavailable. The default value is 30 seconds.
•

Enhanced Connection Limiting - Connection Limiting enhancements expand the original
Connection Limiting feature which provided global control of the number of connections for
each IP address. This enhancement is designed to increase the granularity of this kind of
control so that the SonicWALL administrator can configure connection limitation more
flexibly. Connection Limiting uses Firewall Access Rules and Policies to allow the
administrator to choose which IP address, which service, and which traffic direction when
configuring connection limiting.

•

Dynamic WAN Schedule - SonicOS 5.8.0.0 supports scheduling to control when Dynamic
WAN clients can connect. A Dynamic WAN client connects to the WAN interface and
obtains an IP address with the PPPoE, L2TP, or PPTP. This enhancement allows the
administrator to bind a schedule object to Dynamic WAN clients so that they can connect
when the schedule allows it and they are disconnected at the end of the configured
schedule. In the SonicOS management interface, a Schedule option is available on the
WAN interface configuration screen when one of the above protocols is selected for IP
Assignment. Once a schedule is applied, a log event is recorded upon start and stop of the
schedule.

•

NTLM Authentication with Mozilla Browsers - As an enhancement to Single Sign-On,
SonicOS can now use NTLM authentication to identify users who are browsing using
Mozilla-based browsers (including Internet Explorer, Firefox, Chrome and Safari). NTLM is
part of a browser authentication suite known as "Integrated Windows Security" and should
be supported by all Mozilla-based browsers. It allows a direct authentication request from
the SonicWALL appliance to the browser with no SSO agent involvement. NTLM
authentication works with browsers on Windows, Linux and Mac PCs, and provides a
mechanism to achieve Single Sign-On with Linux and Mac PCs that are not able to
interoperate with the SSO agent.

•

SSL VPN NetExtender Update - This enhancement supports password change capability
for SSL VPN users, along with various fixes. When the password expires, the user is
prompted to change it when logging in via the NetExtender client or SSL VPN portal. It is
supported for both local users and remote users (RADIUS and LDAP).

SonicOS 5.8.1 Administrator Guide

39

Introduction

•

DHCP Scalability Enhancements - The DHCP server in SonicWALL appliances has been
enhanced to provide between 2 to 4 times the number of leases previously supported. To
enhance the security of the DHCP infrastructure, the SonicOS DHCP server now provides
server side conflict detection to ensure that no other device on the network is using the
assigned IP address. Conflict detection is performed asynchronously to avoid delays when
obtaining an address.

•

SIP Application Layer Gateway Enhancements - SonicOS 5.8.0.0 provides SIP
operational and scalability enhancements. The SIP feature-set remains equivalent to
previous SonicOS releases, but provides drastically improved reliability and performance.
The SIP Settings section under the VoIP > Settings page is unchanged.
SIP ALG support has existed within SonicOS firmware since very early versions on legacy
platforms. Changes to SIP ALG have been added over time to support optimized media
between phones, SIP Back-to-Back User Agent (B2BUA), additional equipment vendors,
and operation on a multi-core system.
The SIP protocol is now in a position of business critical importance - protecting the voice
infrastructure, including VoIP. To accommodate the demands of this modern voice
infrastructure, SIP ALG enhancements include the following:
– SIP Endpoint Information Database - The algorithm for maintaining the state

information for known endpoints is redesigned to use a database for improved
performance and scalability. Endpoint information is no longer tied to the user ID,
allowing multiple user IDs to be associated with a single endpoint. Endpoint database
access is flexible and efficient, with indexing by NAT policy as well as by endpoint IP
address and port.
– Automatically Added SIP Endpoints - User-configured endpoints are automatically

added to the database based on user-configured NAT policies, providing improved
performance and ensuring correct mappings, as these endpoints are pre-populated
rather than "learnt."
– SIP Call Database - A call database for maintaining information about calls in progress

is implemented, providing improved performance and scalability to allow SonicOS to
handle a much greater number of simultaneous calls. Call database entries can be
associated with multiple calls.
– B2BUA Support Enhancements - SIP Back-to-Back User Agent support is more

efficient with various algorithm improvements.
– Connection Cache Improvements - Much of the data previously held in the

connection cache is offloaded to either the endpoint database or the call database,
resulting in more efficient data access and corollary performance increase.
– Graceful Shutdown - Allows SIP Transformations to be disabled without requiring the

firewall to be restarted or waiting for existing SIP endpoint and call state information to
time out.

Key Features in SonicOS Enhanced 5.6
SonicOS Enhanced 5.6 and higher releases include the following key features:
•

40

Deep Packet Inspection of SSL encrypted data (DPI-SSL) - Provides the ability to
transparently decrypt HTTPS and other SSL-based traffic, scan it for threats and nonthreats using SonicWALL's Deep Packet Inspection technology, then re-encrypt (or
optionally SSL-offload) the traffic and send it to its destination if no threats or vulnerabilities
are found. This feature works for both client and server deployments. It provides additional
security, application control, and data leakage prevention functionality for analyzing
encrypted HTTPS and other SSL-based traffic. The following security services and

SonicOS 5.8.1 Administrator Guide

Introduction

features are capable of utilizing DPI-SSL: Gateway Anti-Virus, Gateway Anti-Spyware,
Intrusion Prevention, Content Filtering, Application Firewall, Packet Capture and Packet
Mirror. DPI-SSL is initially available on NSA-3500 and above hardware platforms.
•

Dynamic DNS per Interface - Provides the ability to assign a Dynamic DNS (DDNS) profile
to a specific WAN interface. This allows administrators who are configuring multiple WAN
load balancing to advertise a predictable IP address to the DDNS service.

•

Increased UTM Connection Support - Provides the ability to increases the number of
simultaneous connections on which SonicWALL security appliances can apply Unified
Threat Management (UTM) services (Application Firewall, Anti-Spyware, Gateway AntiVirus, and IPS engine). This feature is intended for high-end (E-Class) customers who have
a need to support a large number of concurrent connections. (Note: There is a slight
performance decrease when this option is enabled.)

•

FairNet for SonicPoint-N - Provides the ability to create policies that equally distribute
bandwidth for all wireless users connected to a SonicPoint-N.

•

MAC-IP Anti-Spoof Detection and Prevention - Provides additional protection against
MAC address and IP address based spoofing attacks (such as Man-in-the-Middle attacks)
through configurable Layer 2 and Layer 3 admission control.

•

Packet Mirroring - Provides the ability to capture copies of specified network packets from
other ports. This is commonly used for network appliances that require monitoring of
network traffic, such as an intrusion-detection system. Customers can now gather data from
one of the other ports on a SonicWALL to look for threats and vulnerabilities and help aid
with diagnostics and troubleshooting.

•

Route-based VPN with Dynamic Routing Support - Extends support for advanced
routing (either OSPF or RIP) to VPN networks. This can be used to simplify complex VPN
deployments by enabling dynamic routing to determine the best path traffic should take
over a VPN tunnel.

•

Signature Download through a Proxy Server - Provides the ability for SonicWALL
security appliances that operate in networks where they must access the Internet through
a proxy server to download signatures. This feature also allows for registration of
SonicWALL security appliances through a proxy server without compromising privacy.

•

Single Sign-on for Terminal Services and Citrix - Provides support for transparent
authentication of users running Terminal Services or Citrix. This transparent authentication
enables Application Firewall and CFS policy enforcement in Terminal Services and Citrix
environments.

•

SSL-VPN Enhancements - SonicOS Enhanced 5.6.0.0 provides a number of SSL-VPN
enhancements:
– Bookmarks for SSH and RDP - Provides support for users to create bookmarks on the

SSL -VPN Virtual Office to access systems using SSH, RDP, VNC, and telnet services.
– Granular User Controls - Provides network administrators with the ability to configure

different levels of policy access for NetExtender users based on user ID.
– One-Time Password - Provides additional security by requiring users to enter a

randomly generated, single-use password in addition to the standard user name and
password credentials.
– Virtual Assist - A provides a remote assistance tool to SonicWALL security appliance

users. SonicWALL Virtual Assist is a thin client remote support tool provisioned via a
Web browser that enables a technician to assume control of a customer's PC or laptop
for the purpose of providing remote technical assistance. Note: The SonicOS Virtual
Assist client is currently not supported on Windows 7 and Windows Vista platforms.

SonicOS 5.8.1 Administrator Guide

41

Introduction

•

Virtual Access Points for SonicWALL TZ Wireless Platforms - The SonicWALL TZ
100w, TZ 200w and TZ 210w platforms now support Virtual Access Points (VAPs). VAPs
enable users to segment different wireless groups by creating logical segmentation on a
single wireless radio.

•

Wireless Bridging for SonicWALL TZ Wireless Platforms - The SonicWALL TZ 100w,
TZ 200w and TZ 210w platforms now support Wireless Bridging, which provides the ability
to extend a single wireless network across multiple SonicWALL wireless security
appliances.

Key Features in SonicOS Enhanced 5.5
SonicOS Enhanced 5.5 and higher releases include the following key features:
•

Wireless Layer 2 Bridge Mode - Security and ease of use continue to integrate with the
addition of Layer 2 bridging between wired and wireless network segments. Wireless clients
can now share the same subnet and DHCP pool as their wired counterparts.

•

Guest Services for Wired Clients - SonicWALL User Guest Services has long provided
network administrators with an easy solution for creating wireless guest passes and lockeddown Internet-only network access. With SonicOS 5.5, this functionality can be extended
to wired users on the LAN, DMZ, or public/semi-public zone of your choice.

Key Features in SonicOS Enhanced 5.4
SonicOS Enhanced 5.4 and higher releases include the following key features:
•

Anti-Spam - SonicOS Enhanced 5.4 provides support for the anti-spam and anti-phishing
capabilities that are available in SonicWALL Email Security.

Key Features in SonicOS Enhanced 5.3
SonicOS Enhanced 5.3 and higher releases include the following key features:
•

3G Support for Wireless WAN - SonicOS Enhanced 5.3 expands support for WAN over
3G (Third Generation) cellular connections.

Key Features in SonicOS Enhanced 5.2
SonicOS Enhanced 5.2 and higher releases include the following key features:
•

Apple Bonjour Support - SonicOS Enhanced 5.2 introduces support for Apple's Bonjour
protocol (also known as Rendevous or zero-configuration networking). Bonjour enables
automatic discovery of computers, devices, and services on IP networks without the need
to enter IP addresses or configure DNS servers.

•

Apple iPhone Support - SonicOS Enhanced 5.2 supports L2TP termination from the Apple
iPhone.

•

Content Filtering Enhancements - The following enhancements have been added to
SonicWALL Content Filtering Service (CFS):
– CFS Policy per IP Address - Appliances with SonicWALL CFS Premium can now

assign specific CFS policies to ranges of IP address ranges. This provides the ability
to segment CFS policies within a single zone.

42

SonicOS 5.8.1 Administrator Guide

Introduction

– Fully Customizable Block Page - The web page that is displayed when a user

attempts to access a blocked site can now be fully customized. This enables
organizations to brand the block page and display any organization-specific
information.
– Safe Search Enforcement - Safe Search Enforcement allows you to force Web search

sites like Google and Yahoo that have content restriction options always to use their
strictest settings.
•

New Firmware Auto-Update - Firmware Auto-Update helps ensure that your SonicWALL
security appliance has the latest firmware release. This feature automatically notifies the
administrator when a new firmware release is available, and it can optionally download it
automatically.

•

Outbound Inspection for Gateway Anti-Virus - The SonicWALL Gateway Anti-Virus
security service now provides outbound inspection for HTTP, FTP, and TCP traffic.

•

SonicPoint 802.11n Support - SonicOS Enhanced 5.2 supports the new SonicPoint-N,
which provides next-generation 802.11n wireless network connectivity.

•

SonicWALL SSL VPN NetExtender Support - SonicOS Enhanced 5.2 provides support
for SonicWALL's SSL VPN NetExtender, which was previously available only on the
SonicWALL SSL VPN platforms. SonicWALL NetExtender is a transparent software
application for users that enables remote users to securely connect to the remote network.

•

Support Services Page - The new Support Services page displays a summary of the
current status of support services for the SonicWALL security appliance. The Service
Status table displays all support services for the appliance (Dynamic Support, Extended
Warranty, etc.), their current status, and their expiration date.

Key Features in SonicOS Enhanced 5.1
SonicOS Enhanced 5.1 and higher releases include the following key features:
•

Tip

Strong SSL and TLS Encryption - The internal SonicWALL Web server now only supports
SSL version 3.0 and TLS with strong ciphers (128-bits or greater) when negotiating HTTPS
management sessions. SSL implementations prior to version 3.0 and weak ciphers
(symmetric ciphers less than 128-bits) are not supported. This heightened level of HTTPS
security protects against potential SSLv2 rollback vulnerabilities and ensures compliance
with the Payment Card Industry (PCI) and other security and risk-management standards.

By default, Mozilla Firefox 2.0 and Microsoft Internet Explorer 7.0 enable SSL 3.0 and TLS,
and disable SSL 2.0. SonicWALL recommends using these most recent Web browser
releases. If you are using a previous release of these browsers, you should enable SSL 3.0
and TLS and disable SSL 2.0. In Internet Explorer, go to Tools > Internet Options, click on
the Advanced tab, and scroll to the bottom of the Settings menu. In Firefox, go to Tools >
Options, click on the Advanced tab, and then click on the Encryption tab.
•

Single Sign-On User Authentication - Single Sign-On User Authentication provides
privileged access to multiple network resources with a single workstation login. Single SignOn uses the SonicWALL SSO Agent to identify user activity based on workstation IP
addresses. Access to resources is based on policy for the group to which the user belongs.

•

Stateful High Availability - Stateful High Availability provides improved failover
performance. With Stateful High Availability, the primary and backup security appliances
are continuously synchronized so that the backup can seamlessly assume all network
responsibilities if the primary appliance fails, with no interruptions to existing network

SonicOS 5.8.1 Administrator Guide

43

Introduction

connections. Once the primary and backup appliances have been associated as a high
availability pair on mysonicwall.com, you can enable this feature by selecting Enable
Stateful Synchronization in the High Availability > Advanced page.
•

Application Firewall - Application Firewall provides a way to create application-specific
policies to regulate Web browsing, file transfer, email, and email attachments. Application
Firewall enables application layer bandwidth management, and also allows you to create
custom policies for any protocol. It gives you granular control over network traffic on the
level of users, email users, and IP subnets.

•

HTTPS Filtering - HTTPS Filtering allows administrators to control user access to Web
sites when using the encrypted HTTPS protocol. HTTPS Filtering is based on the ratings
of Web sites, such as Gambling, Online Banking, Online Brokerage and Trading, Shopping,
and Hacking/Proxy Avoidance.

Note

HTTPS Filtering is IP-based, so IP addresses must be used rather than domain
names in the Allowed or Forbidden lists. You can use the nslookup command in a
DOS cmd window to convert a domain name to its IP address(es). There may be
more than one IP address associated with a domain, and if so, all must be added to
the Allowed or Forbidden list.

•

SSL Control - SSL Control is a system that provides visibility into the handshake of Secure
Socket Layer (SSL) sessions, and a method for configuring policies to control the
establishment of SSL sessions.

•

Certificate Blocking - The certificate blocking feature provides a way to specify which
HTTPS certificates to block. This feature is closely integrated with SSL Control.

•

Inbound NAT Load Balancing with Server Monitoring - Inbound NAT Load Balancing
with Server Monitoring detects when a server is unavailable and stops forwarding requests
to it. Inbound NAT Load Balancing spreads the load across two or more servers. When
Stateful High Availability (Stateful High Availability) is configured, during a failover,
SonicOS forwards all requests to the alternate server(s) until it detects that the offline
server is back online. Inbound NAT Load Balancing also works with SonicWALL SSL VPN
appliances.

•

Top Global Malware Report Page - The Top Global Malware page in the user interface
displays a summary of threats stopped by the SonicWALL security appliance. The Security
shows two types of reports:
– A Global Report that displays a summary of threat data received from all SonicWALL

security appliances worldwide.
– An Individual Appliance Report that displays a summary of attacks detected by the local

SonicWALL security appliance.

44

•

Registration & License Wizard - As part of the Top Global Malware page, SonicOS
Enhanced provides a License Wizard for both firewall registration and the purchase of
security service licenses. The available security services are the same as those that enable
Global Reports by providing threat data from SonicWALL devices around the world.

•

Multiple SSH Support - SonicOS Enhanced provides support for multiple concurrent SSH
sessions on the SonicWALL security appliance. When connected over SSH, you can run
command line interface (CLI) commands to monitor and manage the device. The number
of concurrent SSH sessions is determined by device capacity. Note that only one session
at a time can configure the SonicWALL, whether the session is on the GUI or the CLI (SSH
or serial console). For instance, if a CLI session goes to the config level, it will ask you if
you want to preempt an administrator who is at config level in the GUI or an SSH session.

SonicOS 5.8.1 Administrator Guide

Introduction

•

Multiple and Read-only Administrator Login - Multiple Administrator Login provides a
way for multiple users to be given administration rights, either full or read-only, for the
SonicOS security appliance. Additionally, SonicOS Enhanced allows multiple users to
concurrently manage the appliance, but only one user at a time can be in config mode with
the ability to change configuration settings. This feature applies to both the graphical user
interface (GUI) and the command line interface (CLI).

•

IP-Based Connection Limit - SonicOS Enhanced provides a way to limit the number of
connections on a per-source or per-destination IP address basis. This feature protects
against worms on the LAN side that initiate large numbers of connections in denial of
service attacks.

•

IKEv2 Secondary Gateway Support - IKEv2 Secondary Gateway Support provides a way
to configure a secondary VPN gateway to act as an alternative tunnel end-point if the
primary gateway becomes unreachable. While using the secondary gateway, SonicOS can
periodically check for availability of the primary gateway and revert to it, if configured to do
so. Configuration for the secondary VPN gateway is available under VPN > Settings > Add
Policy in the management interface.

•

IKEv2 Dynamic Client Support - IKEv2 Dynamic Client Support provides a way to
configure the Internet Key Exchange (IKE) attributes rather than using the default settings.
Previously, only the default settings were supported: Diffie-Hellman (DH) Group 2, the
3DES encryption algorithm, and the SHA1 authentication method. SonicOS now allows the
following IKE Proposal settings:
– DH Group: 1, 2, or 5
– Encryption: DES, 3DES, AES-128, AES-192, AES-256
– Authentication: MD5, SHA1

These settings are available by pressing the Configure button in the VPN > Advanced
screen of the management interface. However, if a VPN Policy with IKEv2 exchange mode
and a 0.0.0.0 IPsec gateway is defined, you cannot configure these IKE Proposal settings
on an individual policy basis.

Note

The VPN policy on the remote gateway must also be configured with the same
settings.

•

Wireless IDS Rogue Detection - SonicOS Enhanced supports wireless intrusion detection
on SonicPoint devices. Wireless IDS Rogue Detection allows you to configure a set of
authorized access points, defined by address object groups. If contact is attempted from an
unauthorized access point, SonicOS generates an alert.

•

RF Management - Radio Frequency Management on SonicPoint devices provides
detection of eleven types of wireless threats:
– Long duration attack
– Management frame flood
– Null probe request
– Broadcasting de-authentication
– Valid station with invalid SSID
– Ad-Hoc station
– Unassociated station
– Wellenreiter attack
– NetStumbler attack

SonicOS 5.8.1 Administrator Guide

45

Introduction

– EAPOL packet flood
– Weak WEP IV
•

SMTP Authentication - SonicOS Enhanced supports RFC 2554, which defines an SMTP
service extension that allows the SMTP client to indicate an authentication method to the
server, perform an authentication protocol exchange, and optionally negotiate a security
layer for subsequent protocol interactions. This feature helps prevent viruses that attack the
SMTP server on port 25.

•

Generic DHCP Option Support - SonicOS Enhanced supports generic DHCP
configuration, which allows vendor-specific DHCP options in DHCP server leases.

•

DHCP Server Lease Cross-Reboot Persistence - DHCP Server Lease Cross-Reboot
Persistence provides the ability to record and return to DHCP server lease bindings across
power cycles. The SonicWALL security appliance does not have to depend on dynamic
network responses to regain its IP address after a reboot or power cycle.

•

Custom IP Type Service Objects - SonicOS Enhanced supports Custom IP Type Service
Objects, allowing administrators to augment the predefined set of Service Objects.

•

Dynamic Address Objects - SonicOS Enhanced supports two changes to Address
Objects:
– MAC - SonicOS Enhanced will resolve MAC AOs to an IP address by referring to the

ARP cache on the SonicWALL.
– FQDN - Fully Qualified Domain Names (FQDN), such as ‘www.sonicwall.com’, will be

resolved to their IP address (or IP addresses) using the DNS server configured on the
SonicWALL. Wildcard entries are supported through the gleaning of responses to
queries sent to the sanctioned DNS servers.
•

Virtual Access Points - A “Virtual Access Point” (VAP) is a multiplexed instantiation of a
single physical Access Point (AP) so that it presents itself as multiple discrete Access
Points. To wireless LAN clients, each Virtual AP appears to be an independent physical AP,
when there is actually only a single physical AP. Before Virtual AP feature support, wireless
networks were relegated to a One-to-One relationship between physical Access Points and
wireless network security characteristics, such as authentication and encryption. For
example, an Access Point providing WPA-PSK security could not simultaneously offer
Open or WPA-EAP connectivity to clients. If Open or WPA-EAP were required, they would
need to have been provided by a separate, distinctly configured APs. This forced WLAN
network administrators to find a solution to scale their existing wireless LAN infrastructure
to provide differentiated levels of service. With the Virtual APs (VAP) feature, multiple VAPs
can exist within a single physical AP in compliance with the IEEE 802.11 standard for the
media access control (MAC) protocol layer that includes a unique Basic Service Set
Identifier (BSSID) and Service Set Identified (SSID). This allows segmenting wireless
network services within a single radio frequency footprint of a single physical access point
device.
VAPs allow the network administrator to control wireless user access and security settings
by setting up multiple custom configurations on a single physical interface. Each of these
custom configurations acts as a separate (virtual) access point, and can be grouped and
enforced on single or multiple physical SonicPoint access points simultaneously. You can
configure up to eight VAPs per SonicPoint access point.

•

46

Layer 2 Bridge Mode - SonicOS Enhanced supports Layer 2 (L2) Bridge Mode, a new
method of unobtrusively integrating a SonicWALL security appliance into any Ethernet
network. L2 Bridge Mode is similar to the SonicOS Enhanced Transparent Mode in that it
enables a SonicWALL security appliance to share a common subnet across two interfaces,
and to perform stateful and deep-packet inspection on all traversing IP traffic, but it is
functionally more versatile.

SonicOS 5.8.1 Administrator Guide

Introduction

L2 Bridge Mode employs a secure learning bridge architecture, enabling it to pass and
inspect traffic types that cannot be handled by many other methods of transparent security
appliance integration. Using L2 Bridge Mode, a SonicWALL security appliance can be nondisruptively added to any Ethernet network to provide in-line deep-packet inspection for all
traversing IPv4 TCP and UDP traffic. Unlike other transparent solutions, L2 Bridge Mode
can pass all traffic types, including IEEE 802.1Q VLANs, Spanning Tree Protocol,
multicast, broadcast, and IPv6, ensuring that all network communications will continue
uninterrupted.
L2 Bridge Mode provides an ideal solution for networks that already have an existing
firewall, and do not have immediate plans to replace their existing firewall but wish to add
the security of SonicWALL Unified Threat Management (UTM) deep-packet inspection,
such as Intrusion Prevention Services, Gateway Anti-Virus, and Gateway Anti Spyware.
The following feature enhancements are included in SonicOS Enhanced 5.0 and higher:
•

Enhanced Packet Capture - Enhanced Packet Capture contains improvements in both
functionality and flexibility, including the following:
– Capture control mechanism with improved granularity for custom filtering
– Display filter settings independent from capture filter settings
– Packet status indicating dropped, forwarded, generated, or consumed
– Three-window output in the user interface that provides the packet list, decoded output

of selected packet, and hexadecimal dump of selected packet
– Export capabilities that include text, HTML, hex dump, and CAP file format
– Automatic buffer export to FTP server when full
– Bidirectional packet capture based on IP address and port
– Configurable wrap-around of capture buffer when full
•

User Authentication - There are a number of enhancements to user authentication,
including optional case-sensitive user names, optional enforcement of unique login names,
support for MSCHAP version 2, and support for VPN and L2TP clients changing expired
passwords (when that is supported by the back-end authentication server and protocols
used). Note that for this purpose there is a new setting on the VPN > Advanced page to
cause RADIUS to be used in MSCHAP mode when authenticating VPN client users.

•

IP Helper Scalability - The IP Helper architecture is enhanced to support large networks.
Improvements include changes to DHCP relay and Net-BIOS functionality. DHCP relay
over VPN is now fully integrated.

•

Diagnostics Page Tool Tips - Self-documenting mouseover descriptions are provided for
diagnostic controls in the graphical user interface.

•

BWM Rate Limiting - The Bandwidth Management feature is enhanced to provide rate
limiting functionality. You can now create traffic policies that specify maximum rates for
Layer 2, 3, or 4 network traffic. This enables bandwidth management in cases where the
primary WAN link fails over to a secondary connection that cannot handle as much traffic.

•

DHCP Client Reboot Behavior Control - In SonicOS Enhanced 5.0 and higher, you can
configure the WAN DHCP client to perform a DHCP RENEW or a DHCP DISCOVERY
query when attempting to obtain a lease. The previous behavior was to always perform a
RENEW, which caused lease failures on some networks, particularly certain cable modem
service providers. The new behavior it to perform a DISCOVERY, but it is configurable. A
checkbox has been added to the Network > Interfaces > WAN >DHCP Client page:
– Enabled: when the appliance reboots, the DHCP client performs a DHCP RENEW

query.

SonicOS 5.8.1 Administrator Guide

47

Introduction

– Disabled: (Default) when the appliance reboots, the DHCP client performs a DHCP

DISCOVERY query.
•

Dynamic Route Metric Recalculation Based on Interface Availability - To better
support redundant or multiple path Advanced Routing configurations, when a defaultroute's interface is unavailable (due to no-link or negative WAN LB probe response), that
default route's metric will be changed to 255, and the route will be instantly disabled. When
a default-route's interface is again determined to be available, its metric will be changed
back to 20, and the route will be non-disruptively enabled.

SonicWALL Management Interface
The SonicWALL security appliance’s Web-based management interface provides an easy-touse graphical interface for configuring your SonicWALL security appliance. The following
sections provide an overview of the key management interface objects:
•

“Dynamic User Interface” on page 48

•

“Navigating the Management Interface” on page 48

•

“Status Bar” on page 49

•

“Common Icons in the Management Interface” on page 49

•

“Applying Changes” on page 50

•

“Tooltips” on page 50

•

“Navigating Dynamic Tables” on page 51

•

“Getting Help” on page 53

•

“Logging Out” on page 53

Dynamic User Interface
SonicOS Enhanced 5.0 introduced a new Dynamic User Interface. Table statistics and log
entries now dynamically update within the user interface without requiring users to reload their
browsers. Active connections, user sessions, VoIP calls, and similar activities can be
disconnected or flushed dynamically with a single click on the
delete icon in the Flush or
Logout column.
This lightweight dynamic interface is designed to have no impact on the SonicWALL Web
server, CPU utilization, bandwidth or other performance factors. You can leave your browser
window on a dynamically updating page indefinitely with no impact to the performance of your
SonicWALL security appliance.

Navigating the Management Interface
Navigating the SonicWALL management interface includes a hierarchy of menu buttons on the
navigation bar (left side of your browser window). When you click a menu button, related
management functions are displayed as submenu items in the navigation bar.
The left navigation bar now expands and contracts dynamically when clicked on without
automatically navigating to a sub-folder page. When you click on a top-level heading in the left
navigation bar, it automatically expands that heading and contracts the heading for the page
you are currently on, but it doesn’t not navigate away from your current page. To navigate to a

48

SonicOS 5.8.1 Administrator Guide

Introduction

new page, you first click on the heading, and then click on the sub-folder page you want. This
eliminates the delay and redundant page loading that occurred in previous versions of SonicOS
when clicking on a heading automatically loaded the first sub-folder page.

If the navigation bar continues below the bottom of your browser, an
up-and-down arrow
symbol appears in the bottom right corner of the navigation bar. Mouse over the up or down
arrow to scroll the navigation bar up or down.

Common Icons in the Management Interface
The following describe the functions of common icons used in the SonicWALL management
interface:
•

Clicking on the edit

icon displays a window for editing the settings.

•

Clicking on the delete

•

Moving the pointer over the comment

icon deletes a table entry
icon displays text from a Comment field entry.

Status Bar
The Status bar at the bottom of the management interface window displays the status of
actions executed in the SonicWALL management interface.

SonicOS 5.8.1 Administrator Guide

49

Introduction

Applying Changes
Click the Accept button at the top right corner of the SonicWALL management interface to save
any configuration changes you made on the page.

If the settings are contained in a secondary window within the management interface, when you
click OK, the settings are automatically applied to the SonicWALL security appliance.

Tooltips
SonicOS Enhanced 5.0 introduced embedded tool tips for many elements in the SonicOS UI.
These Tooltips are small pop-up windows that are displayed when you hover your mouse over
a UI element. They provide brief information describing the element. Tooltips are displayed for
many forms, buttons, table headings and entries.

Note

Not all UI elements have Tooltips. If a Tooltip does not display after hovering your mouse
over an element for a couple of seconds, you can safely conclude that it does not have an
associated Tooltip.
When applicable, Tooltips display the minimum, maximum, and default values for form entries.
These entries are generated directly from the SonicOS firmware, so the values will be correct
for the specific platform and firmware combination you are using.

50

SonicOS 5.8.1 Administrator Guide

Introduction

The behavior of the Tooltips can be configured on the System > Administration page.

Tooltips are enabled by default. To disable Tooltips, uncheck the Enable Tooltip checkbox.
The duration of time before Tooltips display can be configured:
•

Form Tooltip Delay - Duration in milliseconds before Tooltips display for forms (boxes
where you enter text).

•

Button Tooltip Delay - Duration in milliseconds before Tooltips display for radio buttons
and checkboxes.

•

Text Tooltip Delay - Duration in milliseconds before Tooltips display for UI text.

Navigating Dynamic Tables
In the SonicOS dynamic user interface, table statistics and log entries now dynamically update
within the user interface without requiring users to reload their browsers.You can navigate
tables in the management interface with large number of entries by using the navigation buttons
located on the upper right top corner of the table.

The table navigation bar includes buttons for moving through table pages.

SonicOS 5.8.1 Administrator Guide

51

Introduction

A number of tables now include an option to specify the number of items displayed per page.

Many tables can now be re-sorted by clicking on the headings for the various columns. On
tables that are sortable, a tooltip will pop-up when you mouseover headings that states Click
to sort by. When tables are sorted, entries with the same value for the column are grouped
together with the common value shaded as a sub-heading. In the following example, the Active
Connections table is sorted by Source IP. Two shaded sub-headings are displayed for
10.0.59.75 and 10.50.166.100.

Active connections, user sessions, VoIP calls, and similar activities can be disconnected or
flushed dynamically with a single click on the
delete icon in the Flush or Logout column.
Several tables include a new table statistics icon
that displays a brief, dynamically
updating summary of information for that table entry. Tables with the new statistics icon include:

52

•

NAT policies on the Network > NAT Policies page

•

Access rules on the Firewall > Access Rules page

SonicOS 5.8.1 Administrator Guide

Introduction

Several tables include a tooltip that displays the maximum number of entries that the
SonicWALL security appliance supports. For example, the following image shows the maximum
number of address groups the appliance supports.

Tables that display the maximum entry tooltip include NAT policies, access rules, address
objects, and address groups.

Getting Help
Each SonicWALL security appliance includes Web-based online help available from the
management interface.Clicking the question mark ? button on the top-right corner of every
page accesses the context-sensitive help for the page.

Tip

Accessing the SonicWALL security appliance online help requires an active Internet
connection.

Logging Out
The Logout button at the bottom of the menu bar terminates the management interface session
and displays the authentication page for logging into the SonicWALL security appliance.

SonicOS 5.8.1 Administrator Guide

53

Introduction

54

SonicOS 5.8.1 Administrator Guide

PART 2
Part 2:

SonicOS 5.8.1 Administrator Guide

Dashboard

55

56

SonicOS 5.8.1 Administrator Guide

CHAPTER 4
Chapter 4:

Using the SonicOS Visualization
Dashboard

Visualization Dashboard
The SonicWALL Visualization Dashboard offers administrators an effective and efficient
interface to visually monitor their network in real time, providing effective flow charts of realtime data, customizable rules, and flexible interface settings. With the Visualization Dashboard,
administrators can efficiently view and sort real-time network and bandwidth data in order to:
•

Identify applications and websites with high bandwidth demands

•

View application usage on a per-user basis

•

Anticipate attacks and threats encountered by the network

This document contains the following sections:
•

“Enabling the Real-Time Monitor and AppFlow Collection” section on page 58

•

“Dashboard > Real-Time Monitor” section on page 60

•

“Dashboard > AppFlow Monitor” section on page 70

•

“Dashboard > Threat Reports” section on page 79

•

“Dashboard > User Monitor” section on page 84

•

“Dashboard > BWM Monitor” section on page 85

•

“Dashboard > Connections Monitor” section on page 85

•

“Dashboard > Packet Monitor” section on page 87

•

“Dashboard > Log Monitor” section on page 91

SonicOS 5.8.1 Administrator Guide

57

Visualization Dashboard

Note

Several of the SonicWALL Visualization Dashboard pages now contain a blue pop-up button
that will display the dashboard in a standalone browser window that allows for a wider
display. Click on the blue pop-up icon to the right of the page name in the left-hand
navigating bar to display a dashboard page as a standalone page.

Enabling the Real-Time Monitor and AppFlow Collection
The real-time application monitoring features rely on the flow collection mechanism in order to
collect and display data. Before you can view the “applications” chart in the Real-Time Monitor,
AppFlow Monitor, or AppFlow Reports, you must first enable and configure the flow collection
feature.
To enable Real-Time Monitoring and Internal AppFlow collection:
Step 1

Step 2

58

Navigate to the Log > Flow Reporting page in the SonicOS management interface. For onthe-appliance flow collection, select the Enable AppFlow To Local Collector checkbox.
Select the Enable Real-Time Data Collection checkbox, and select from the Collect RealTime Data For pull-down menu the reports you would like to see captured:
•

Top apps

•

Bits per second

•

Packets per second

•

Average packet size

•

Connections per second

•

Core utility

To enable these reports, click the Accept button to save your changes.

SonicOS 5.8.1 Administrator Guide

Visualization Dashboard

Step 3

Navigate to the Network > Interfaces page.Click the Configure icon for the interface you wish
to enable flow reporting on.

Step 4

In the Advanced tab, ensure that the Enable flow reporting checkbox is selected.

Step 5

Click the OK button to save your changes.

Step 6

Repeat steps 6 through 7 for each interface you wish to monitor.
For more detailed information on configuring Flow Reporting settings, refer to the “Log > Flow
Reporting” section on page 1369.

SonicOS 5.8.1 Administrator Guide

59

Dashboard > Real-Time Monitor

Dashboard > Real-Time Monitor
The Real-Time Monitor provides administrators an inclusive, multi-functional display with
information about applications, bandwidth usage, packet rate, packet size, connection rate,
connection count, multi-core monitoring, and memory usage.

60

SonicOS 5.8.1 Administrator Guide

Dashboard > Real-Time Monitor

This section contains the following subsections:
•

“Using the Toolbar” section on page 62

•

“Applications Monitor” section on page 63

•

“Ingress and Egress Bandwidth Flow” section on page 66

•

“Packet Rate Monitor” section on page 68

•

“Packet Size Monitor” section on page 69

•

“Connection Count Monitor” section on page 70

SonicOS 5.8.1 Administrator Guide

61

Dashboard > Real-Time Monitor

Using the Toolbar
The Real-Time Monitor Toolbar contains features to specify the refresh rate, export details,
configure color palettes, change the amount of data displayed, and pause or play the data flow.
Changes made to the toolbar apply across all the data flows.

Option

Widget

Description

Refresh rate

Determines the frequency at which data is
refreshed. A numerical integer between 1 to 10
seconds is required. One second is the default.

Export

Exports the data flow into a comma separated
variable (.csv) file. The default file name is
sonicflow.csv.

Configure

Allows for customization of the color palette for
the Application Chart and Bandwidth Chart.
To customize the Color Palette:
•

Enter the desired hexadecimal color codes in
the provided text fields.

•

Select Default for a default range of colors.

•

Select Generate to generate a random range
of colors.

If a gradient is desired, select the Use Gradient
box located below the text fields.
View Range

Displays data pertaining to a specific span of
time. Two minutes is the default setting for the
view range.

Time & Date

Displays the current time in 24-hour format
(hh:mm:ss), and the current date in Month/Day
format.

Pause

Freezes the data flow. The time and date will also
freeze.
The Pause button will appear gray if the data flow
has been frozen.

Play

Unfreezes the data flow. The time and date will
refresh as soon as the data flow is updated.
The Play button will appear gray if the data flow
is live.

62

SonicOS 5.8.1 Administrator Guide

Dashboard > Real-Time Monitor

Applications Monitor
The Applications data flow provides a visual representation of the current applications
accessing the network.

Options are available to Display, Scale, and View the Application interface.
Option
Lock

Unlock
Application
Display

Widget

Description
Locks the Display options for the Application
interface. The lock and unlock option is available
when you select “Most Frequent Apps.” Most
Frequent Apps displays the top-25 apps, you can
use the lock or unlock option to keep the report
from altering the top-25 apps.
Unlock the Display options for the Application
interface.
Specifies the applications displayed in the
Application Flow Chart.
A drop menu allows the administrator to specify
Most Frequent Apps, All Apps, or individual
applications. If desired, multiple applications can
be selected by clicking more than one check box.

SonicOS 5.8.1 Administrator Guide

63

Dashboard > Real-Time Monitor

Option

Widget

Scale

Description
Allows for Auto Y-Scaling or customized scaling
of the Application Flow Chart.
The values for customized scaling must be a
numeric integer. Specifying a unit is optional. If a
unit is desired, these are the available options:

Bar Graph
Flow Chart

•

K for Kilo.

•

M for Mega.

•

G for Giga.

•

% for percentage.

If a custom scale of 100Kbps is desired, then
“100K” should be entered. The numeric integer
100 is entered followed by the unit K.
Displays the Applications data in a bar graph
format.
Displays the Applications data in a flow chart
format.

Available Formats
Administrators are able to view the Application flow charts in a bar graph format or flow chart
format. The bar graph format displays applications individually, allowing administrators to
compare applications. In this graph, the x-axis displays the name of the applications. The y-axis
displays the amount of traffic for each application. The following example is a “Flow Chart” view.

64

SonicOS 5.8.1 Administrator Guide

Dashboard > Real-Time Monitor

The flow chart format displays over lapping application data. In this graph, the x-axis displays
the current time and the y-axis displays the traffic for each application. The following example
is a “Bar Chart” view.

SonicOS 5.8.1 Administrator Guide

65

Dashboard > Real-Time Monitor

Ingress and Egress Bandwidth Flow
The Ingress and Egress Bandwidth data flow provides a visual representation of incoming and
outgoing bandwidth traffic. The current percentage of total bandwidth used, average flow of
bandwidth traffic, and the minimum and maximum amount of traffic that has gone through each
interface is available in the display. Administrators are able to view the Ingress and Egress
Bandwidth flow chart in a bar graph format or flow chart format.
The bar graph format displays data pertaining to individual interfaces in a bar graph; allowing
administrators to compare individual Bandwidth Interfaces. In this graph, the x-axis denotes the
Interfaces whereas the y-axis denotes the Ingress and Egress Bandwidth traffic.
The flow chart format overlaps the Bandwidth Interfaces; allowing administrators to view all of
the Ingress and Egress Bandwidth traffic as it occurs. The x-axis displays the current time and
the y-axis displays the Ingress and Egress Bandwidth traffic.

66

SonicOS 5.8.1 Administrator Guide

Dashboard > Real-Time Monitor

Options are available to customize the Display, Scale, and View of the Ingress and Egress
Bandwidth interface.
Option
Interface Rate
Display

Widget

Description
Specifies which Interfaces are displayed in the
Bandwidth Flow Chart.
A drop menu provides the administrator with
options to specify All Interfaces Rate, All
Interfaces, and individual interfaces.
The individual interfaces vary depending on the
number of interfaces on the administrator’s
network. Multiple interfaces can be selected if
desired.

Scale

Allows for Auto Y-Scaling or custom scaling of
the Bandwidth Flow Chart.
The values for customized scaling must be a
numeric integer. Specifying a unit is optional. If a
unit is desired, four options are available:
•

K for Kilo.

•

M for Mega.

•

G for Giga.

•

% for percentage.

Bar Graph
Format

If a custom scale of 100Kbps is desired, then
“100K” should be entered. The numeric integer
100 is entered followed by the unit K.
Displays the real-time Bandwidth data in a bar
graph format.

Flow Chart
Format

Displays the real-time Bandwidth data in a flow
chart format.

Tooltips
Rolling over the interfaces provides tooltips with information about the interface assigned zone,
IP address, and current port status.

SonicOS 5.8.1 Administrator Guide

67

Dashboard > Real-Time Monitor

Note

The Bandwidth flow charts have no direct correlation to the Application flow charts.

Packet Rate Monitor
The Packet Rate Monitor provides the administrator with information on the ingress and egress
packet rate in packet per second (pps). This can be configured to show packet rate by network
interface. The graph shows the packet rate current average, minimum packet rate, and
maximum packet rate for both ingress and egress network traffic.

68

SonicOS 5.8.1 Administrator Guide

Dashboard > Real-Time Monitor

Packet Size Monitor
The Packet Size Monitor provides the administrator with information on the ingress and egress
packet rate in kilobytes per second (Kps). This can be configured to show packet size by
network interface. The graph shows the packet size current average, minimum packet size, and
maximum packet size for both ingress and egress network traffic.

SonicOS 5.8.1 Administrator Guide

69

Dashboard > AppFlow Monitor

Connection Count Monitor
The Connection Count data flow provides the administrator a visual representation of “current”
total number of connections, “peak” number of connections, and maximum. In this example, the
y-axis displays the total number of connections from 0C (zero connections) to 1KC (one kilo
connections).
.

Dashboard > AppFlow Monitor
The AppFlow Monitor provides administrators with real-time, incoming and outgoing network
data. Various views and customizable options in the AppFlow Monitor Interface assist in
visualizing the traffic data by applications, users, URLs, initiators, responders, threats, VoIP,
VPN, devices, or by contents.

70

SonicOS 5.8.1 Administrator Guide

Dashboard > AppFlow Monitor

This section contains the following subsections:
•

“Filter Options” section on page 71

•

“AppFlow Monitor Tabs” section on page 72

•

“AppFlow Monitor Toolbar” section on page 73

•

“Group Options” section on page 74

•

“AppFlow Monitor Status” section on page 75

•

“AppFlow Monitor Views” section on page 76

Filter Options
The AppFlow Monitor Filter Options allows the administrator to filter out incoming, real-time
data. Administrators can apply, create, and delete custom filters to customize the information
they wish to view. The Filter Options apply across all the Application Flow tabs. Please refer to
the “Using Filtering Options” section on page 78.

Option
Add to Filter

Widget

Description
Adds current selection to filter.
At least 1 item must be selected in order to use
the Filter Options. After doing so, all other tabs
will update with information pertaining to the
items in the filter.

Remove from
Filter

Removes the current selection from the filter
view by clicking on the X.

Load Filter

Loads existing filter settings.

Save

Saves the current filter settings.

Delete

Deletes the current filter settings.

SonicOS 5.8.1 Administrator Guide

71

Dashboard > AppFlow Monitor

AppFlow Monitor Tabs
The AppFlow Monitor Tabs contains details about incoming and outgoing network traffic. Each
tab provides a faceted view of the network flow. The data is organized by Applications, Users,
URLs, Initiators, Responders, Threats, VoIP, VPN, Devices, and Content.

72

•

The Applications tab displays a list of Applications currently accessing the network.

•

The Users tab displays a list of Users currently connected to the network.

•

The URLs tab displays a list of URLs currently accessed by Users.

•

The Initiators tab displays details about current connection initiators.

•

The Responders tab displays details about current connection responders.

•

The Threats tab displays a list of threats encountered by the network.

•

The VoIP tab displays current VoIP and media traffic.

•

The VPN tab displays a list of VPN sessions connected to the network.

•

The Devices tab displays a list of devices currently connected to the network.

•

The Contents tab displays information about the type of traffic flowing through the network.

SonicOS 5.8.1 Administrator Guide

Dashboard > AppFlow Monitor

AppFlow Monitor Toolbar
The AppFlow Toolbar allows for customization of the AppFlow Monitor interface. The ability to
create rules and add items to filters allows for more application and user control. Different
views, pause and play abilities, customizable data intervals and refresh rates are also
available to aid in visualizing incoming, real-time data.

Option

Widget

Description

Filter View

Adds selected items to the filter.

Interval

The span of time in which data is collected.

Group

Categorizes selections according to the available
grouping options which vary depending on the
tab that is selected.
Please refer to the “Group Options” section on
page 74.

List View

Provides a detailed list view of the data flow.

Pie Chart View

Provides a pie chart view of the data flow.

Flow Chart View

Provides a flow chart view of the data flow.

Export

Exports the data flow in comma separated
variable (.csv) format.

Configuration

Allows for customization of the display by
enabling or disabling columns for Applications,
Sessions, Packets, Bytes, Rate, and Threats.
Also allows the administrator to enable or disable
commas in numeric fields.

Refresh Button

Refreshes the real-time data.

Status Update

Provides status updates about App signatures,
GAV Database, Spyware Database, IPS
Database, Country Database, Max Flows in
Database, and CFS Status. Please refer to the
“AppFlow Monitor Status” section on page 75 for
more information.
A green status icon signifies that all appropriate
signatures and databases are active.
A yellow status icon signifies that some or all
signature databases are still being downloaded
or could not be activated.

SonicOS 5.8.1 Administrator Guide

73

Dashboard > AppFlow Monitor

Option

Widget

Refresh Rate

Description
Rate at which data is refreshed.
A numeric integer between 10 and 999 must be
specified.
If 300 is entered in the numeric field, that means
the data flow will refresh every 300 seconds.

Pause/Play

Freezes and unfreezes the data flow. Doing so
gives the administrator flexibility when analyzing
real-time data.

Group Options
The Group option sorts data based on the specified group. Each tab contains different grouping
options.
•

The Applications tab can be grouped by:
– Application: Displays all traffic generated by individual applications.
– Category: Groups all traffic generated by an application category.

•

The Users tab can be grouped by:
– User Name: Groups all traffic generated by a specific user.
– IP Address: Groups all traffic generated by a specific IP address.
– Domain Name: Groups all traffic generated by a specific domain name.
– Auth Type: Groups all traffic generated by a specific authorizing method.

•

The URL tab can be grouped according to:
– URL: Displays all traffic generated by each URL.
– Domain Name: Groups all traffic generated by a domain name.
– Rating: Groups all traffic generated based on CFS rating.

•

The Initiators tab can be grouped according to:
– IP Address: Groups all traffic generated by a specific IP address.
– Interface: Groups all traffic according to the firewall interface.
– Country: Groups all traffic generated by each country, based on country IP database.
– Domain Name: Groups all traffic generated by a domain name.

•

The Responders tab can be grouped according to:
– IP Address: Groups all traffic by IP address.
– Interface: Groups responders by interface.
– Country: Groups responders by each country, based on country IP database.
– Domain Name: Groups responders by domain name.

•

The Threats tab can be grouped according to:
– Intrusions: Displays flows in which intrusions have been identified.
– Viruses: Displays flows in which viruses have been identified.
– Spyware: Displays flows in which spyware has been identified.
– Spam: Shows all flows that fall under the category of spam.

74

SonicOS 5.8.1 Administrator Guide

Dashboard > AppFlow Monitor

•

The VoIP tab can be grouped according to:
– Media Type: Groups VoIP flows according to media type.
– Caller ID: Groups VoIP flows according to caller ID.

•

The VPN tab can be grouped according to:
– Remote IP Address: Groups VPN flows access according to the remote IP address.
– Local IP Address: Groups VPN flows access according to the local IP address.
– Name: Groups VPN flows access according to the tunnel name.

•

The Devices tab can be grouped according to:
– IP Address: Groups flows by IP addresses inside the network.
– Interface: Groups flows by interfaces on the firewall.
– Name: Groups flows by device name, or MAC address.

•

The Contents tab can be grouped according to:
– Email Address: Groups contents by email address.
– File Name: Groups flows by file type detected.

AppFlow Monitor Status
The AppFlow Monitor Status dialog appears when the cursor rolls over the Status button in the
toolbar. The AppFlow Monitor Status provides signature updates about App Rules, App Control
Advanced, GAV, IPS, Anti-Spyware, CFS, Anti-Spam, BWM, and country databases.
The option to enable or disable the flow collection is available in the Status dialog. If the Status
dialog is no longer wanted, click close in the upper-right corner.

SonicOS 5.8.1 Administrator Guide

75

Dashboard > AppFlow Monitor

AppFlow Monitor Views
Three views are available for the AppFlow Monitor: Detailed, Pie Chart, and Flow Chart View.
Each view provides the administrator a unique display of incoming, real-time data.

List View
In the List View, each AppFlow tab is comprised of columns displaying real-time data. These
columns are organized into sortable categories.

•

Check Box: Allows the administrator to select the line item for creation of filters.

•

Main Column: The title of the Main Column is dependent on the selected tab. For example,
if the Users Tab is the selected, then the Main Column header will read “Users”. In that
column, the name of the Users connected to the network are shown. Clicking on the items
in this column will bring up a popup with relevant information on the item displayed.

•

Sessions: Clicking on this number will bring up a table of all active sessions.

•

Packets: Displays the number of data packets transferred.

•

Bytes: Displays the number of bytes transferred.

•

Rate (KBps): Displays the rate at which data is transferred.

•

Threats: Displays the number of threats encountered by the network.

•

Total: Displays the total Sessions, Packets, and Bytes sent during the duration of the
current interval.

Application Details

Each item listed in the Main Column provides a link to an Application Detail dialog. A display
appears when the item links are clicked. The dialog provides:
•

76

A description of the item.

SonicOS 5.8.1 Administrator Guide

Dashboard > AppFlow Monitor

•

Information pertaining to the category, threat level, type of technology the item falls under,
and other additional information.

•

Application details are particularly useful when an Administrator does not recognize the
name of an Application.

Graph View
The Graph View displays the top applications and the percentage of bandwidth used. The
percentage of bandwidth used is determined by taking the total amount of bandwidth used by
the top applications, and dividing that total by the amount of top applications.

SonicOS 5.8.1 Administrator Guide

77

Dashboard > AppFlow Monitor

Using Filtering Options
Using filtering options allow administrators to reduce the amount of data seen in the AppFlow
Monitor. By doing so, administrators can focus on points of interest without distraction from
other applications. To use the Filtering Options:
Step 1

Log into the SonicWALL Network Security Appliance and go to Dashboard > AppFlow
Monitor > Applications Tab. Then select the check boxes of the applications you wish to add
to the filter. In this case, BitTorrent is selected.

Step 2

Click Filter View to add BitTorrent to the filter.

Step 3

Once the application is added to the filter, only BitTorrent is visible in the Applications tab.
More information about Users, peer connectivity, and packets sent are visible in the AppFlow
Monitor tabs. The Users using BitTorrent are visible in the Users tab. The IP Addresses of these
users are visible in the Initiators tab. The IP Addresses of the connected peers who are sharing
packets are visible in the Responders Tab.

78

SonicOS 5.8.1 Administrator Guide

Dashboard > Threat Reports

Dashboard > Threat Reports
This section describes how to use the SonicWALL Threat Reports feature on a SonicWALL
security appliance. This chapter contains the following sections:
•

“SonicWALL Threat Reports Overview” on page 79

•

“SonicWALL Threat Reports Configuration Tasks” on page 81

SonicWALL Threat Reports Overview
This section provides an introduction to the Threat Reports feature. This section contains the
following subsections:
•

“What Are Threat Reports?” on page 80

•

“Benefits” on page 81

•

“How Does the Threat Reports Work?” on page 81

SonicOS 5.8.1 Administrator Guide

79

Dashboard > Threat Reports

What Are Threat Reports?
The SonicWALL Threat Reports provides reports of the latest threat protection data from a
single SonicWALL appliance and aggregated threat protection data from SonicWALL security
appliances deployed globally. The SonicWALL Threat Reports displays automatically upon
successful authentication to a SonicWALL security appliance, and can be viewed at any time
by navigating to the Dashboard > Threat Reports menu in the left-hand menu.
Reports in the Threat Reports include:

80

•

Viruses Blocked

•

Intrusions Prevented

•

Spyware Blocked

•

Multimedia (IM/P2P) Detected/Blocked

SonicOS 5.8.1 Administrator Guide

Dashboard > Threat Reports

Each report includes a graph of threats blocked over time and a table of the top blocked threats.
Reports, which are updated hourly, can be customized to display data for the last 12 hours, 14
days, 21 days, or 6 months. For easier viewing, SonicWALL Threat Reports reports can be
transformed into a PDF file format with the click of a button.

Benefits
The Threat Reports provides the latest threat protection information to keep you informed about
potential threats being blocked by SonicWALL security appliances. If you subscribe to
SonicWALL’s security services, including Gateway Anti-Virus, Gateway Anti-Spyware,
Intrusion Prevention Service (IPS), and Content Filtering Service, you are automatically
protected from the threats reported by the SonicWALL Threat Reports. SonicWALL’s security
services include ongoing new signature updates to protect against the latest virus and spyware
attacks.

How Does the Threat Reports Work?
The SonicWALL Threat Reports provides global and appliance-level threat protection statistics.
At the appliance level, threat protection data from your SonicWALL security appliance is
displayed. At the global level, the SonicWALL Threat Reports is updated hourly from the
SonicWALL backend server with aggregated threat protection data from globally-deployed
SonicWALL security appliances. Data provided by the SonicWALL backend server is cached
locally for reliable delivery.
To be protected from the threats reported in the SonicWALL Threat Reports, it is recommended
that you purchase SonicWALL security services. For more information about SonicWALL
security services, see “SonicWALL Security Services” on page 1177.

Note

The SonicWALL security appliance must have Internet connectivity (including connection to
a DNS server) to receive the latest threat protection statistics from the SonicWALL backend
server, which reports aggregated data from globally deployed SonicWALL security
appliances. If you lose connectivity, cached data from the last update will display, and the
latest data will not be available until connectivity is restored.

SonicWALL Threat Reports Configuration Tasks
The SonicWALL Threat Reports can be configured to display global or appliance-level
statistics, to display statistics for different time periods, and to generate a custom PDF file.

SonicOS 5.8.1 Administrator Guide

81

Dashboard > Threat Reports

The SonicWALL Threat Reports displays automatically upon successful login to a SonicWALL
security appliance. You can access the SonicWALL Threat Reports at any time by navigating
to Dashboard > Threat Reports in the left-hand menu. You may see the introductory screen
shown below while the appliance is gathering the latest threat data.

The following sections describe the Threat Report:

82

•

“Switching to Global or Appliance-Level View” on page 83

•

“Selecting Custom Time Interval” on page 83

•

“Generating a Threat Reports PDF” on page 83

SonicOS 5.8.1 Administrator Guide

Dashboard > Threat Reports

Switching to Global or Appliance-Level View
To view SonicWALL Threat Reports global reports, select the radio button next to Global in the
top of the Dashboard > Threat Reports screen. To view appliance-level reports, select the
radio button next to the appliance serial number.

Selecting Custom Time Interval
The SonicWALL Threat Reports reports default to a view of reports from the “Last 14 Days,”
providing an aggregate view of threats blocked during that time period. You can configure each
report to one of four optional time periods. Each report can be configured to reflect a different
time period. To change a report to reflect a different time period, perform the following steps:
Step 1

Select the report you want to change:
– Viruses Blocked
– Intrusions Prevented
– Spyware Blocked
– Multimedia (IM/P2P) Detected/Blocked

Step 2

Next to the title of the selected report, click the pull-down menu and select one of the following
options:
– Last 12 Hours - Displays threat information from the last 12 hours
– Last 14 Days - Displays threat information from the last 14 days
– Last 21 Days - Displays threat information from the last 21 days
– Last 6 Months - Displays threat information from the last 6 months

Generating a Threat Reports PDF
To create a PDF version of the SonicWALL Threat Reports, first select the desired view (global
or appliance-level) and the desired time period for each report (the last 12 hours, 14 days,
21 days, or 6 months). Click the
button at the top of the page.

SonicOS 5.8.1 Administrator Guide

83

Dashboard > User Monitor

Dashboard > User Monitor
The Dashboard > User Monitor page displays details on all user connections to the
SonicWALL security appliance.

84

SonicOS 5.8.1 Administrator Guide

Dashboard > BWM Monitor

Dashboard > BWM Monitor
The Dashboard > BWM Monitor page displays per-interface bandwidth management for ingress
and egress network traffic. The BWM monitor graphs are available for real-time, highest, high,
medium high, medium, medium low, low and lowest policy settings. The view range is
configurable in 60 seconds, 2 minutes, 5 minutes, and 10 minutes (default). The refresh interval
rate is configurable from 3 to 30 seconds. The bandwidth management priority is depicted by
guaranteed, maximum, and dropped.

Dashboard > Connections Monitor
The Dashboard > Connections Monitor page displays details on all active connections to the
SonicWALL security appliance.

SonicOS 5.8.1 Administrator Guide

85

Dashboard > Connections Monitor

Viewing Connections
The connections are listed in the Connections Monitor table.

Filtering Connections Viewed
You can filter the results to display only connections matching certain criteria. You can filter by
Source IP, Destination IP, Destination Port, Src Interface, Dst Interface, and Protocol.
Enter your filter criteria in the Connections Monitor Settings table.
The fields you enter values into are combined into a search string with a logical AND. For
example, if you enter values for Source IP and Destination IP, the search string will look for
connections matching:
Source IP AND Destination IP
Check the Group box next to any two or more criteria to combine them with a logical OR. For
example, if you enter values for Source IP, Destination IP, and Protocol, and check Group
next to Source IP and Destination IP, the search string will look for connections matching:
(Source IP OR Destination IP) AND Protocol
Click Apply Filter to apply the filter immediately to the Active Connections table. Click Reset
to clear the filter and display the unfiltered results again.
You can export the list of active connections to a file. Click Export Results, and select if you
want the results exported to a plain text file, or a Comma Separated Value (CSV) file for
importing to a spreadsheet, reporting tool, or database. If you are prompted to Open or Save
the file, select Save. Then enter a filename and path and click OK.

86

SonicOS 5.8.1 Administrator Guide

Dashboard > Packet Monitor

Dashboard > Packet Monitor
Note

For increased convenience and accessibility, the Packet Monitor page can be accessed
either from Dashboard > Packet Monitor or System > Packet Monitor. The page is identical
regardless of which tab it is accessed through. For detailed overview and configuration
information on Packet Monitor, refer to the “System > Packet Monitor” on page 139.

Using Packet Monitor and Packet Mirror
In addition to the Configure button, the top of the Dashboard > Packet Monitor page provides
several buttons for general control of the packet monitor feature and display. These include the
following:
•

Monitor All – Resets current monitor filter settings and advanced page settings so that
traffic on all local interfaces is monitored. A confirmation dialog box displays when you click
this button.

•

Monitor Default – Resets current monitor filter settings and advanced page settings to
factory default settings. A confirmation dialog box displays when you click this button.

•

Clear – Clears the packet monitor queue and the displayed statistics for the capture buffer,
mirroring, and FTP logging. A confirmation dialog box displays when you click this button.

•

Refresh – Refreshes the packet display windows on this page to show new buffer data.

SonicOS 5.8.1 Administrator Guide

87

Dashboard > Packet Monitor

The Dashboard > Packet Monitor page is shown below:

For an explanation of the status indicators near the top of the page, see “Understanding Status
Indicators” on page 159.
The other buttons and displays on this page are described in the following sections:
•

“Starting and Stopping Packet Capture” on page 88

•

“Starting and Stopping Packet Mirror” on page 89

•

“Viewing Captured Packets” on page 89

Starting and Stopping Packet Capture
You can start a packet capture that uses default settings without configuring specific criteria for
packet capture, display, FTP export, and other settings. If you start a default packet capture,
the SonicWALL appliance will capture all packets except those for internal communication, and
will stop when the buffer is full or when you click Stop Capture.

88

Step 1

Navigate to the Dashboard > Packet Monitor page.

Step 2

Optionally click Clear to set the statistics back to zero.

Step 3

Under Packet Monitor, click Start Capture.

Step 4

To refresh the packet display windows to show new buffer data, click Refresh.

SonicOS 5.8.1 Administrator Guide

Dashboard > Packet Monitor

Step 5

To stop the packet capture, click Stop Capture.
You can view the captured packets in the Captured Packets, Packet Detail, and Hex Dump
sections of the screen. See “Viewing Captured Packets” on page 89.

Starting and Stopping Packet Mirror
You can start packet mirroring that uses your configured mirror settings by clicking Start Mirror.
It is not necessary to first configure specific criteria for display, logging, FTP export, and other
settings. Packet mirroring stops when you click Stop Mirror.
Step 1

Navigate to the Dashboard > Packet Monitor page.

Step 2

Under Packet Monitor, click Start Mirror to start mirroring packets according to your
configured settings.

Step 3

To stop mirroring packets, click Stop Mirror.

Viewing Captured Packets
The Dashboard > Packet Monitor page provides three windows to display different views of
captured packets. The following sections describe the viewing windows:
•

“About the Captured Packets Window” on page 89

•

“About the Packet Detail Window” on page 91

•

“About the Hex Dump Window” on page 91

About the Captured Packets Window
The Captured Packets window displays the following statistics about each packet:
•

# - The packet number relative to the start of the capture

•

Time - The date and time that the packet was captured

•

Ingress - The SonicWALL appliance interface on which the packet arrived is marked with
an asterisk (*). The subsystem type abbreviation is shown in parentheses. Subsystem type
abbreviations are defined in the following table.

Abbreviation

Definition

i

Interface

hc

Hardware based encryption or decryption

sc

Software based encryption or decryption

m

Multicast

r

Packet reassembly

s

System stack

ip

IP helper

f

Fragmentation

SonicOS 5.8.1 Administrator Guide

89

Dashboard > Packet Monitor

•

Egress - The SonicWALL appliance interface on which the packet was captured when sent
out
– The subsystem type abbreviation is shown in parentheses. See the table above for

definitions of subsystem type abbreviations
•

Source IP - The source IP address of the packet

•

Destination IP - The destination IP address of the packet

•

Ether Type - The Ethernet type of the packet from its Ethernet header

•

Packet Type - The type of the packet depending on the Ethernet type; for example:
– For IP packets, the packet type might be TCP, UDP, or another protocol that runs over

IP
– For PPPoE packets, the packet type might be PPPoE Discovery or PPPoE Session
– For ARP packets, the packet type might be Request or Reply
•

Ports [Src, Dst] - The source and destination TCP or UDP ports of the packet

•

Status - The status field for the packet
The status field shows the state of the packet with respect to the firewall. A packet can be
dropped, generated, consumed or forwarded by the SonicWALL appliance. You can
position the mouse pointer over dropped or consumed packets to show the following
information.
Packet status

Displayed value

Definition of displayed value

Dropped

Module-ID = 

Value for the protocol subsystem ID

Drop-code = 

Reason for dropping the packet

Reference-ID: 

SonicWALL-specific data

Module-ID = 

Value for the protocol subsystem ID

Consumed
•

90

Length [Actual] - Length value is the number of bytes captured in the buffer for this packet.
Actual value, in brackets, is the number of bytes transmitted in the packet.

SonicOS 5.8.1 Administrator Guide

Dashboard > Log Monitor

About the Packet Detail Window
When you click on a packet in the Captured Packets window, the packet header fields are
displayed in the Packet Detail window. The display will vary depending on the type of packet
that you select.

About the Hex Dump Window
When you click on a packet in the Captured Packets window, the packet data is displayed in
hexadecimal and ASCII format in the Hex Dump window. The hex format is shown on the left
side of the window, with the corresponding ASCII characters displayed to the right for each line.
When the hex value is zero, the ASCII value is displayed as a dot.

Dashboard > Log Monitor
Note

For increased convenience and accessibility, the Log Monitor page can be accessed either
from Dashboard > Log Monitor or Log > View. The two pages provide identical functionality.
For information on using Log Monitor, see “Log > View” on page 1349.

SonicOS 5.8.1 Administrator Guide

91

Dashboard > Log Monitor

92

SonicOS 5.8.1 Administrator Guide

PART 3
Part 3:

SonicOS 5.8.1 Administrator Guide

System

93

94

SonicOS 5.8.1 Administrator Guide

CHAPTER 5
Chapter 5:

Viewing Status Information

System > Status
The System > Status page provides a comprehensive collection of information and links to
help you manage your SonicWALL security appliance and SonicWALL Security Services
licenses. It includes status information about your SonicWALL security appliance organized
into five sections: System Messages, System Information, Security Services, Latest
Alerts, and Network Interfaces as well as the Wizards button for accessing the SonicWALL
Configuration Wizard.

SonicOS 5.8.1 Administrator Guide

95

System > Status

Wizards
The Wizards button on the System > Status page provides access to the SonicWALL
Configuration Wizard, which allows you to easily configure the SonicWALL security appliance
using the following sub-wizards:
•

Setup Wizard - This wizard helps you quickly configure the SonicWALL security appliance
to secure your Internet (WAN) and LAN connections.

•

Registration and License Wizard - This wizard simplifies the process of registering your
SonicWALL security appliance and obtaining licenses for additional security services.

•

Public Server Wizard - This wizard helps you quickly configure the SonicWALL security
appliance to provide public access to an internal server, such as a Web or E-mail server.

•

VPN Wizard - This wizard helps you create a new site-to-site VPN Policy or configure the
WAN GroupVPN to accept VPN connections from SonicWALL Global VPN Clients.

•

Application Firewall Wizard - Supported on SonicWALL NSA series appliances, this
wizard helps you quickly configure your SonicWALL security appliance with policies to
inspect application level network traffic. With the wizard you will be able to create
Application Firewall Policies based on series of predefined steps.

For more information on using the SonicWALL Configuration Wizard, see “Wizards” on
page 1395.

System Messages
Any information considered relating to possible problems with configurations on the
SonicWALL security appliance such as password, log messages, as well as notifications of
SonicWALL Security Services offers, new firmware notifications, and upcoming Security
Service s expirations are displayed in the System Messages section.

System Information
The following information is displayed in this section:

96

•

Model - Type of SonicWALL security appliance product.

•

Product Code - The numeric code for the model of SonicWALL security appliance.

•

Serial Number - Also the MAC address of the SonicWALL security appliance.

•

Authentication Code - The alphanumeric code used to authenticate the SonicWALL
security appliance on the registration database at https://www.mysonicwall.com.

•

Firmware Version - The firmware version loaded on the SonicWALL security appliance.

•

Safemode Version - The SafeMode firmware version loaded on the SonicWALL security
appliance.

•

ROM Version - Indicates the ROM version.

•

CPUs - Displays the average CPU usage over the last 10 seconds and the type of the
SonicWALL security appliance processor.

•

Total Memory - Indicates the amount of RAM and flash memory.

•

System Time - The time registered on the internal clock on the SonicWALL appliance.

•

Up Time - The length of time, in days, hours, and seconds the SonicWALL security
appliance is active.

SonicOS 5.8.1 Administrator Guide

System > Status

•

Connections - Displays the maximum number of network connections the SonicWALL
security appliance can support, the peak number of conncurent connections, and the
current number of connections.

•

Connection Usage - The percentage of the maximum number of connections that are
currently established (i.e. this percentage is the current number of connections divided by
the maximum number of connections).

•

Last Modified By - The IP address of the user who last modified the system and the time
stamp of the last modification.

•

Registration Code - The registration code is generated when your SonicWALL security
appliance is registered at http://www.mysonicwall.com.

Latest Alerts
Any messages relating to system errors or attacks are displayed in this section. Attack
messages include AV Alerts, forbidden e-mail attachments, fraudulent certificates, etc. System
errors include WAN IP changed and encryption errors. Clicking the blue arrow displays the
Log > Log View page.

For more information on SonicWALL security appliance logging, see “Log” on page 1347.

Security Services
If your SonicWALL security appliance is not registered at mysonicwall.com, the following
message is displayed in the Security Services folder: Your SonicWALL security appliance
is not registered. Click here to Register your SonicWALL security appliance. You need a
mysonicwall.com account to register your SonicWALL security appliance or activate security
services. You can create a mysonicwall.com account directly from the SonicWALL
management interface.

If your SonicWALL security appliance is registered, a list of available SonicWALL Security
Services are listed in this section with the status of Licensed or Not Licensed. If Licensed,
the Status column displays the number of licenses and the number of licenses in use. Clicking

SonicOS 5.8.1 Administrator Guide

97

System > Status

the Arrow icon displays the System > Licenses page in the SonicWALL Web-based
management interface. SonicWALL Security Services and SonicWALL security appliance
registration is managed by mysonicwall.com.

Refer to “Security Services” on page 1175 for more information on SonicWALL Security
Services and activating them on the SonicWALL security appliance.

Registering Your SonicWALL Security Appliance
Once you have established your Internet connection, it is recommended you register your
SonicWALL security appliance. Registering your SonicWALL security appliance provides the
following benefits:
•

Try a FREE 30-day trial of SonicWALL Intrusion Prevention Service, SonicWALL Gateway
Anti-Virus, Content Filtering Service, and Client Anti-Virus

•

Activate SonicWALL Anti-Spam

•

Activate SonicWALL security services and upgrades

•

Access SonicOS firmware updates

•

Get SonicWALL technical support

Before You Register
If your SonicWALL security appliance is not registered, the following message is displayed in
the Security Services folder on the System > Status page in the SonicWALL management
interface: Your SonicWALL is not registered. Click here to Register your SonicWALL. You
need a mysonicwall.com account to register the SonicWALL security appliance.
If your SonicWALL security appliance is connected to the Internet, you can create a
mysonicwall.com account and register your SonicWALL security appliance directly from the
SonicWALL management interface. If you already have a mysonicwall.com account, you can
register the SonicWALL security appliance directly from the management interface.
Your mysonicwall.com account is accessible from any Internet connection by pointing your
Web browser to https://www.mysonicwall.com. mysonicwall.com uses the HTTPS
(Hypertext Transfer Protocol Secure) protocol to protect your sensitive information.

Note

98

Make sure the Time Zone and DNS settings on your SonicWALL security appliance are
correct when you register the device. See SonicWALL Setup Wizard instructions for
instructions on using the Setup Wizard to set the Time Zone and DNS settings.

SonicOS 5.8.1 Administrator Guide

System > Status

Note

mysonicwall.com registration information is not sold or shared with any other company.
You can also register your security appliance at the https://www.mysonicwall.com site by using
the Serial Number and Authentication Code displayed in the Security Services section.
Click the SonicWALL link to access your mysonicwall.com account. You will be given a
registration code after you have registered your security appliance. Enter the registration code
in the field below the You will be given a registration code, which you should enter below
heading, then click Update.

Creating a MySonicWALL Account
Creating a MySonicWALL account is fast, simple, and FREE. Simply complete an online
registration form in the SonicWALL management interface. To create a MySonicWALL account
from the SonicWALL management interface:
Step 1

In the Security Services section on the System > Status page, click the update your
registration link.

Step 2

Click the link for If you do not have a mysonicwall account, please click here to create one.

Step 3

In the MySonicWALL Account page, enter in your information in the Account Information,
Personal Information and Preferences fields in the mysonicwall.com account form. All fields
marked with an * are required fields.

Note

Remember your username and password to access your mysonicwall.com account.

Step 4

Click Submit after completing the MySonicWALL Account form.

Step 5

When the mysonicwall.com server has finished processing your account, a page is displayed
confirming your account has been created. Click Continue.

Step 6

Congratulations! Your mysonicwall.com account is activated. Now you need to log into
mysonicwall.com from the management appliance to register your SonicWALL security
appliance.

SonicOS 5.8.1 Administrator Guide

99

System > Status

Registering Your SonicWALL Security Appliance
If you already have a mysonicwall.com account, follow these steps to register your security
appliance:
Step 1

In the Security Services section on the System > Status page, click the Register link in Your
SonicWALL is not registered. Click here to Register your SonicWALL. The mysonicwall
Login page is displayed.

Step 2

In the mysonicwall.com Login page, enter your mysonicwall.com username and password in
the User Name and Password fields and click Submit.

Step 3

The next several pages inform you about free trials available to you for SonicWALL’s Security
Services:
•

Gateway Anti-Virus - protects your entire network from viruses

•

Client Anti-Virus - protects computers on your network from viruses

•

Premium Content Filtering Service - protects your network and improves productivity by
limiting access to unproductive and inappropriate Web sites

•

Intrusion Prevention Service - protects your network from Trojans, worms, and
application layer attacks

Step 4

Click Continue on each page.

Step 5

At the top of the Product Survey page, enter a friendly name for your SonicWALL security
appliance in the Friendly name field, and complete the optional product survey.

Step 6

Click Submit.

Step 7

When the mysonicwall.com server has finished processing your registration, a page is
displayed confirming your SonicWALL security appliance is registered.

Step 8

Click Continue. The Manage Services Online table on the System > Licenses page
displayed.

Network Interfaces
Network Interfaces displays information about the interfaces for your SonicWALL security
appliance. Clicking the blue arrow displays the Network > Interfaces page for configuring your
Network settings. The available interfaces displayed in the Network Interfaces section depend
on the SonicWALL security appliance model.

100

SonicOS 5.8.1 Administrator Guide

CHAPTER 6
Chapter 6:

Managing SonicWALL Licenses

System > Licenses
The System > Licenses page provides links to activate, upgrade, or renew SonicWALL
Security Services licenses. From this page in the SonicWALL Management Interface, you can
manage all the SonicWALL Security Services licensed for your SonicWALL security appliance.
The information listed in the Security Services Summary table is updated from your
mysonicwall.com account. The System > Licenses page also includes links to FREE trials of
SonicWALL Security Services.

Warning

By design, the SonicWALL License Manager cannot be configured to use a third
party proxy server. Networks that direct all HTTP and HTTPS traffic through a third
party proxy server may experience License Manager issues.

Node License Status
A node is a computer or other device connected to your LAN with an IP address.
If your SonicWALL security appliance is licensed for unlimited nodes, the Node License Status
section displays the message: The SonicWALL is licensed for unlimited Nodes/Users. No
other settings are displayed.
If your SonicWALL security appliance is not licensed for unlimited nodes, the Node License
Status table lists how many nodes your security appliance is licensed to have connected at any
one time, how many nodes are currently connected, and how many nodes you have in your
Node License Exclusion List.

The Currently Licensed Nodes table lists details on each node connected to your security
appliance. The table is not displayed if no nodes are connected.

SonicOS 5.8.1 Administrator Guide

101

System > Licenses

Excluding a Node
When you exclude a node, you block it from connecting to your network through the security
appliance. Excluding a node creates an address object for that IP address and assigns it to the
Node License Exclusion List address group. To exclude a node:
Step 1

Select the node you want to exclude in the Currently Licensed Nodes table on the
icon in the Exclude column for that node.
System > Licenses page, and click the

Step 2

A warning displays, saying that excluding this node will create an address object for it and place
it in the License Exclusion List address group. Click OK to exclude the node.
You can manage the License Exclusion List group and address objects in the Network >
Address Objects page of the management interface. Click the Node License Exclusion List
link to jump to the Network > Address Objects page. See “Network > Address Objects” on
page 299 for instructions on managing address objects.

Security Services Summary
The Security Services Summary table lists the available and activated security services on
the SonicWALL security appliance.

The Security Service column lists all the available SonicWALL Security Services and
upgrades available for the SonicWALL security appliance. The Status column indicates is the
security service is activated (Licensed), available for activation (Not Licensed), or no longer
active (Expired). The number of nodes/users allowed for the license is displayed in the Count
column. The Expiration column displays the expiration date for any Licensed Security Service.
The information listed in the Security Services Summary table is updated from your
mysonicwall.com account the next time the SonicWALL security appliance automatically
synchronizes with your mysonicwall.com account (once a day) or you can click the link in To
synchronize licenses with mysonicwall.com click here in the Manage Security Services
Online section.
For more information on SonicWALL Security Services, see “SonicWALL Security Services” on
page 1177.

102

SonicOS 5.8.1 Administrator Guide

System > Licenses

Manage Security Services Online
To activate, upgrade, or renew services, click the link in To Activate, Upgrade, or Renew
services, click here. Click the link in To synchronize licenses with mysonicwall.com click
here to synchronize your mysonicwall.com account with the Security Services Summary
table.

You can also get free trial subscriptions to SonicWALL Content Filter Service and Client AntiVirus by clicking the For Free Trials click here link. When you click these links, the
mysonicwall.com Login page is displayed.

Enter your mysonicwall.com account username and password in the User Name and Password
fields and click Submit. The Manage Services Online page is displayed with licensing
information from your mysonicwall.com account.

Manual Upgrade
Manual Upgrade allows you to activate your services by typing the service activation key
supplied with the service subscription not activated on mysonicwall.com. Type the activation
key from the product into the Enter upgrade key field and click Submit.

SonicOS 5.8.1 Administrator Guide

103

System > Licenses

Manual Upgrade for Closed Environments
If your SonicWALL security appliance is deployed in a high security environment that does not
allow direct Internet connectivity from the SonicWALL security appliance, you can enter the
encrypted license key information from http://www.mysonicwall.com manually on the System
> Licenses page in the SonicWALL Management Interface.

Note

Manual upgrade of the encrypted License Keyset is only for Closed Environments. If your
SonicWALL security appliance is connected to the Internet, it is recommended you use the
automatic registration and Security Services upgrade features of your appliance.

From a Computer Connected to the Internet
Step 1

Make sure you have an account at http://www.mysonicwall.com and your SonicWALL security
appliance is registered to the account before proceeding.

Step 2

After logging into www.mysonicwall.com, click on your registered SonicWALL security
appliance listed in Registered SonicWALL Products.

Step 3

Click the View License Keyset link. The scrambled text displayed in the text box is the License
Keyset for the selected SonicWALL security appliance and activated Security Services. Copy
the Keyset text for pasting into the System > Licenses page or print the page if you plan to
manually type in the Keyset into the SonicWALL security appliance.

From the Management Interface of your SonicWALL Security Appliance
Step 1

Make sure your SonicWALL security appliance is running SonicOS Standard or Enhanced 2.1
(or higher).

Step 2

Paste (or type) the Keyset (from the step 3) into the Keyset field in the Manual Upgrade section
of the System > Licenses page (SonicOS).

Step 3

Click the Submit or the Apply button to update your SonicWALL security appliance. The status
field at the bottom of the page displays The configuration has been updated.

Step 4

You can generate the System > Diagnostics > Tech Support Report to verify the upgrade
details.

Note

Caution

104

After the manual upgrade, the System > Licenses page does not contain any registration
and upgrade information.

The warning message: SonicWALL Registration Update Needed. Please update your
registration information remains on the System > Status page after you have registered
your SonicWALL security appliance. Ignore this message.

SonicOS 5.8.1 Administrator Guide

CHAPTER 7
Chapter 7:

Viewing Support Services

System > Support Services
The System > Support Services page displays a summary of the current status of support
services for the SonicWALL security appliance. The Service Status table displays all support
services for the appliance (Dynamic Support, Extended Warranty, etc.), their current status, and
their expiration date.

The Support Services page also contains information on methods of obtaining help, including
a link to the SonicWALL product documentation page located at
http://www.sonicwall.com/us/support.html

SonicOS 5.8.1 Administrator Guide

105

System > Support Services

106

SonicOS 5.8.1 Administrator Guide

CHAPTER 8
Chapter 8:

Configuring Administration Settings

System > Administration
The System Administration page provides settings for the configuration of SonicWALL security
appliance for secure and remote management. You can manage the SonicWALL using a
variety of methods, including HTTPS, SNMP or SonicWALL Global Management System
(SonicWALL GMS). This chapter contains the following sections
•

“Firewall Name” on page 107

•

“Administrator Name & Password” on page 107

•

“Login Security Settings” on page 108

•

“Web Management Settings” on page 111

•

“SSH Management Settings” on page 113

•

“Advanced Management” on page 113

•

“Download URL” on page 117

Firewall Name
The Firewall Name uniquely identifies the SonicWALL security appliance and defaults to the
serial number of the SonicWALL. The serial number is also the MAC address of the unit. To
change the Firewall Name, type a unique alphanumeric name in the Firewall Name field. It
must be at least 8 characters in length.

Administrator Name & Password
The Administrator Name can be changed from the default setting of admin to any word using
alphanumeric characters up to 32 characters in length. To create a new administrator name,
type the new name in the Administrator Name field. Click Accept for the changes to take
effect on the SonicWALL.

SonicOS 5.8.1 Administrator Guide

107

System > Administration

Changing the Administrator Password
To set a new password for SonicWALL Management Interface access, type the old password
in the Old Password field, and the new password in the New Password field. Type the new
password again in the Confirm New Password field and click Accept. Once the SonicWALL
security appliance has been updated, a message confirming the update is displayed at the
bottom of the browser window.

Tip

It is recommended you change the default password “password” to your own custom
password.
One-Time Password
One-Time Password (OTP) is a two-factor authentication scheme that utilizes systemgenerated, random passwords in addition to standard user name and password credentials.
Once users submit the correct basic login credentials, the system generates a one-time
password which is sent to the user at a pre-defined email address. The user must retrieve the
one-time password from their email, then enter it at the login screen.

Login Security Settings
The internal SonicWALL Web-server now only supports SSL version 3.0 and TLS with strong
ciphers (12 -bits or greater) when negotiating HTTPS management sessions. SSL
implementations prior to version 3.0 and weak ciphers (symmetric ciphers less than 128-bits)
are not supported. This heightened level of HTTPS security protects against potential SSLv2
rollback vulnerabilities and ensures compliance with the Payment Card Industry (PCI) and
other security and risk-management standards.
By default, Mozilla Firefox 2.0 and MicrosoftAustralia: + 1800.35.1642
Austria: +43(0)820.400.105
EMEA: +31(0)411.617.810
France: +44 193.257.3927
Germany: +44 193.257.3910
Hong Kong: +1 800.93.0997
India: 000.800.100.3395
Italy: +44 193.257.3928
Japan: 0120.569122
New Zealand: + 800.446489
Singapore: + 800.110.1441
Spain: +44 193.257.3921
Switzerland: +44 193.257.3929
UK: +44 193.257.3929

Tip

108

Internet Explorer 7.0 enable SSL 3.0 and TLS, and disable SSL 2.0. SonicWALL
recommends using these most recent Web browser releases. If you are using a previous
release of these browsers, you should enable SSL 3.0 and TLS and disable SSL 2.0. In

SonicOS 5.8.1 Administrator Guide

System > Administration

Internet Explorer, go to Tools > Internet Options, click on the Advanced tab, and scroll to
the bottom of the Settings menu. In Firefox, go to Tools > Options, click on the Advanced
tab, and then click on the Encryption tab.

SonicOS Enhanced 5.0 introduced password constraint enforcement, which can be configured
to ensure that administrators and users are using secure passwords. This password constraint
enforcement can satisfy the confidentiality requirements as defined by current information
security management systems or compliance requirements, such as Common Criteria and the
Payment Card Industry (PCI) standard.
The Password must be changed every (days) setting requires users to change their
passwords after the designated number of days has elapsed. When a user attempts to login
with an expired password, a pop-up window will prompt the user to enter a new password. The
User Login Status window now includes a Change Password button so that users can change
their passwords at any time.
The Bar repeated passwords for this many changes setting requires users to use unique
passwords for the specified number of password changes.
The Enforce a minimum password length of setting sets the shortest allowed password.
The Enforce password complexity pulldown menu provides the following options:
•

Require both alphabetic and numeric characters

•

Require alphabetic, numeric, and symbolic characters

The Apply these password constraints for checkboxes specify which classes of users the
password constraints are applied to. The administrator checkbox refers to the default
administrator with the username admin.
The Log out the Administrator Inactivity Timeout after inactivity of (minutes) setting
allows you to set the length of inactivity time that elapses before you are automatically logged
out of the Management Interface. By default, the SonicWALL security appliance logs out the
administrator after five minutes of inactivity. The inactivity timeout can range from 1 to 99
minutes. Click Accept, and a message confirming the update is displayed at the bottom of the
browser window.

SonicOS 5.8.1 Administrator Guide

109

System > Administration

Tip

If the Administrator Inactivity Timeout is extended beyond five minutes, you should end
every management session by clicking Logout to prevent unauthorized access to the
SonicWALL security appliance’s Management Interface.
The Enable administrator/user lockout setting locks administrators out of accessing the
appliance after the specified number of incorrect login attempts.
•

Failed login attempts per minute before lockout specifies the number of incorrect login
attempts within a one minute time frame that triggers a lockout.

•

Lockout Period (minutes) specifies the number of minutes that the administrator is locked
out.

Multiple Administrators
The On preemption by another administrator setting configures what happens when one
administrator preempts another administrator using the Multiple Administrators feature. The
preempted administrator can either be converted to non-config mode or logged out. For more
information on Multiple Administrators, see “Multiple Administrator Support Overview” section
on page 1015.
•

Drop to non-config mode - Select to allow more than one administrator to access the
appliance in non-config mode without disrupting the current administrator.

•

Log Out - Select to have the new administrator preempt the current administrator.

Allow preemption by a lower priority administrator after inactivity of (minutes) - Enter the
number of minutes of inactivity by the current administrator that will allow a lower-priority
administrator to preempt.
Enable inter-administrator messaging - Select to allow administrators to send text messages
through the management interface to other administrators logged into the appliance. The
message will appear in the browser’s status bar.
Messaging polling interval (seconds) - Sets how often the administrator’s browser will check
for inter-administrator messages. If there are likely to be multiple administrators who need to
access the appliance, this should be set to a reasonably short interval to ensure timely delivery
of messages.

Enable Administrator/User Lockout
You can configure the SonicWALL security appliance to lockout an administrator or a user if the
login credentials are incorrect. Select the Enable Administrator/User Lockout on login
failure checkbox to prevent users from attempting to log into the SonicWALL security appliance
without proper authentication credentials. Type the number of failed attempts before the user
is locked out in the Failed login attempts per minute before lockout field. Type the length of
time that must elapse before the user attempts to log into the SonicWALL again in the Lockout
Period (minutes) field.

Caution

110

If the administrator and a user are logging into the SonicWALL using the same source IP
address, the administrator is also locked out of the SonicWALL. The lockout is based on the
source IP address of the user or administrator.

SonicOS 5.8.1 Administrator Guide

System > Administration

Web Management Settings
The SonicWALL security appliance can be managed using HTTP or HTTPS and a Web
browser. HTTP web-based management is disabled by default. Use HTTPS to log into the
SonicOS management interface with factory default settings.
If you wish to use HTTP management, an Allow management via HTTP checkbox is available to
allow the administrator to enable/disable HTTP management globally:

The default port for HTTPS management is 443. You can add another layer of security for
logging into the SonicWALL security appliance by changing the default port. To configure
another port for HTTPS management, type the preferred port number into the Port field, and
click Update. For example, if you configure the HTTPS Management Port to be 700, then you
must log into the SonicWALL using the port number as well as the IP address, for example,
 to access the SonicWALL.
The default port for HTTP is port 80, but you can configure access through another port. Type
the number of the desired port in the Port field, and click Accept. However, if you configure
another port for HTTP management, you must include the port number when you use the IP
address to log into the SonicWALL security appliance. For example, if you configure the port to
be 76, then you must type :76 into the Web browser, i.e. .
The Certificate Selection menu allows you to use a self-signed certificate (Use Self-signed
Certificate), which allows you to continue using a certificate without downloading a new one
each time you log into the SonicWALL security appliance. You can also choose Import
Certificate to select an imported certificate from the System > Certificates page to use for
authentication to the management interface.
The Delete Cookies button removes all browser cookies saved by the SonicWALL appliance.
Deleting cookies will cause you to lose any unsaved changes made in the Management
interface.
To see the Dashboard > Top Global Malware page first when you login, select the Use System
Dashboard View as starting page checkbox.

SonicOS 5.8.1 Administrator Guide

111

System > Administration

Changing the Default Size for SonicWALL Management Interface Tables
The SonicWALL Management Interface allows you to control the display of large tables of
information across all tables in the management Interface. You can change the default table
page size in all tables displayed in the SonicWALL Management Interface from the default 50
items per page to any size ranging from 1 to 5,000 items. Some tables, including Active
Connections Monitor, VPN Settings, and Log View, have individual settings for items per page
which are initialized at login to the value configured here. Once these pages are viewed, their
individual settings are maintained. Subsequent changes made here will only affect these pages
following a new login.
To change the default table size:
Step 1

Enter the desired number of items per page in the Default Table Size field.

Step 2

Enter the desired interval for background automatic refresh of Monitor tables (including Process
Monitor, Active Connections Monitor, and Interface Traffic Statistics) in seconds in the Autoupdated Table Refresh Interval field.

Step 3

Click Accept.

Tooltips
SonicOS Enhanced 5.0 introduced embedded tool tips for many elements in the SonicOS UI.
These Tooltips are small pop-up windows that are displayed when you hover your mouse over
a UI element. They provide brief information describing the element. Tooltips are displayed for
many forms, buttons, table headings and entries.

Note

Not all UI elements have Tooltips. If a Tooltip does not display after hovering your mouse
over an element for a couple of seconds, you can safely conclude that it does not have an
associated Tooltip.
When applicable, Tooltips display the minimum, maximum, and default values for form entries.
These entries are generated directly from the SonicOS firmware, so the values will be correct
for the specific platform and firmware combination you are using.

112

SonicOS 5.8.1 Administrator Guide

System > Administration

The behavior of the Tooltips can be configured on the System > Administration page.

Tooltips are enabled by default. To disable Tooltips, uncheck the Enable Tooltip checkbox.
The duration of time before Tooltips display can be configured:
•

Form Tooltip Delay - Duration in milliseconds before Tooltips display for forms (boxes
where you enter text).

•

Button Tooltip Delay - Duration in milliseconds before Tooltips display for radio buttons
and checkboxes.

•

Text Tooltip Delay - Duration in milliseconds before Tooltips display for UI text.

SSH Management Settings

If you use SSH to manage the SonicWALL appliance, you can change the SSH port for
additional security. The default SSH port is 22.

Advanced Management
You can manage the SonicWALL security appliance using SNMP or SonicWALL Global
Management System. The following sections explain how to configure the SonicWALL for
management by these two options.

For more information on SonicWALL Global Management System, go to http://
www.sonicwall.com.

SonicOS 5.8.1 Administrator Guide

113

System > Administration

Enabling SNMP Management
SNMP (Simple Network Management Protocol) is a network protocol used over User Datagram
Protocol (UDP) that allows network administrators to monitor the status of the SonicWALL
security appliance and receive notification of critical events as they occur on the network. The
SonicWALL security appliance supports SNMP v1/v2c and all relevant Management
Information Base II (MIB) groups except egp and at. The SonicWALL security appliance replies
to SNMP Get commands for MIBII via any interface and supports a custom SonicWALL MIB for
generating trap messages. The custom SonicWALL MIB is available for download from the
SonicWALL Web site and can be loaded into third-party SNMP management software such as
HP Openview, Tivoli, or SNMPC.
To enable SNMP on the SonicWALL security appliance, log into the Management interface and
click System, then Administration. Select the Enable SNMP checkbox, and then click
Configure. The Configure SNMP window is displayed.

Step 1

Type the host name of the SonicWALL security appliance in the System Name field.

Step 2

Type the network administrator’s name in the System Contact field.

Step 3

Type an e-mail address, telephone number, or pager number in the System Location field.

Step 4

Type a name for a group or community of administrators who can view SNMP data in the Get
Community Name field.

Step 5

Type a name for a group or community of administrators who can view SNMP traps in the Trap
Community Name field.

Step 6

Type the IP address or host name of the SNMP management system receiving SNMP traps in
the Host 1 through Host 4 fields. You must configure at least one IP address or host name, but
up to four addresses or host names can be used.

Step 7

Click OK.

Configuring Log/Log Settings for SNMP
Trap messages are generated only for the alert message categories normally sent by the
SonicWALL security appliance. For example, attacks, system errors, or blocked Web sites
generate trap messages. If none of the categories are selected on the Log > Settings page,
then no trap messages are generated.

114

SonicOS 5.8.1 Administrator Guide

System > Administration

Configuring SNMP as a Service and Adding Rules
By default, SNMP is disabled on the SonicWALL security appliance. To enable SNMP you must
first enable SNMP on the System > Administration page, and then enable it for individual
interfaces. To do this, go to the Network > Interfaces page and click on the Configure button
for the interface you want to enable SNMP on.
For instructions on adding services and rules to the SonicWALL security appliance, see Part
five Firewall.
If your SNMP management system supports discovery, the SonicWALL security appliance
agent automatically discover the SonicWALL security appliance on the network. Otherwise, you
must add the SonicWALL security appliance to the list of SNMP-managed devices on the
SNMP management system.

Enable GMS Management
You can configure the SonicWALL security appliance to be managed by SonicWALL Global
Management System (SonicWALL GMS). To configure the SonicWALL security appliance for
GMS management:
Step 1

Select the Enable Management using GMS checkbox, then click Configure. The Configure
GMS Settings window is displayed.

Step 2

Enter the host name or IP address of the GMS Console in the GMS Host Name or IP Address
field.

Step 3

Enter the port in the GMS Syslog Server Port field. The default value is 514.

Step 4

Select Send Heartbeat Status Messages Only to send only heartbeat status instead of log
messages.

Step 5

Select GMS behind NAT Device if the GMS Console is placed behind a device using NAT on
the network. Type the IP address of the NAT device in the NAT Device IP Address field.

Step 6

Select one of the following GMS modes from the Management Mode menu.
•

IPSEC Management Tunnel - Selecting this option allows the SonicWALL security
appliance to be managed over an IPsec VPN tunnel to the GMS management console. The
default IPsec VPN settings are displayed. Select GMS behind NAT Device if applicable to

SonicOS 5.8.1 Administrator Guide

115

System > Administration

the GMS installation, and enter the IP address in the NAT Device IP Address field. The
default VPN policy settings are displayed at the bottom of the Configure GMS Settings
window.

•

116

Existing Tunnel - If this option is selected, the GMS server and the SonicWALL security
appliance already have an existing VPN tunnel over the connection. Enter the GMS host
name or IP address in the GMS Host Name or IP Address field. Enter the port number in
the Syslog Server Port field.

SonicOS 5.8.1 Administrator Guide

System > Administration

Step 7

•

HTTPS - If this option is selected, HTTPS management is allowed from two IP addresses:
the GMS Primary Agent and the Standby Agent IP address. The SonicWALL security
appliance also sends encrypted syslog packets and SNMP traps using 3DES and the
SonicWALL security appliance administrator’s password. The following configuration
settings for HTTPS management mode are displayed:

•

Send Syslog Messages to a Distributed GMS Reporting Server - Sends regular
heartbeat messages to both the GMS Primary and Standby Agent IP address. The regular
heartbeat messages are sent to the specified GMS reporting server and the reporting
server port.

•

GMS Reporting Server IP Address - Enter the IP address of the GMS Reporting Server,
if the server is separate from the GMS management server.

•

GMS Reporting Server Port - Enter the port for the GMS Reporting Server. The default
value is 514.

Click OK.

Download URL
The Download URL section provides fields for specifying the URL address of a site for
downloading the SonicWALL GVC application and SonicPoint images.

•

Manually specify GVC Download URL - The SonicWALL Global VPN Client (GVC) allow
users to connect securely to your network using the GroupVPN Policy on the port they are
connecting to. GVC is required for a user to connect to the GroupVPN Policy. Depending
on how you have set up your VPN policies, if a user does not have the latest GVC software
installed, the user will be directed to a URL to download the latest GVC software.
The default URL http://help.mysonicwall.com/applications/vpnclient displays the
SonicWALL Global VPN Client download site. You can point to any URL where you provide
the SonicWALL Global VPN Client application.

•

Manually specify SonicPoint-N image URL - SonicOS Enhanced 5.0 and higher does not
contain an image of the SonicPoint firmware. If your SonicWALL appliance has Internet
connectivity, it will automatically download the correct version of the SonicPoint image from the
SonicWALL server when you connect a SonicPoint device. If your SonicWALL appliance does
SonicOS 5.8.1 Administrator Guide

117

System > Administration

not have Internet access, or has access only through a proxy server, you must manually specify
a URL for the SonicPoint firmware. You do not need to include the http:// prefix, but you do
need to include the filename at the end of the URL. The filename should have a .bin
extension. Here are examples using an IP address and a domain name:
192.168.168.10/imagepath/sonicpoint.bin
software.sonicwall.com/applications/sonicpoint/sonicpoint.bin
For more information see the “Updating SonicPoint Firmware” on page 527.

Caution

It is imperative that you download the corresponding SonicPoint image for the SonicOS
firmware version that is running on your SonicWALL. The mysonicwall.com Web site
provides information about the corresponding versions. When upgrading your SonicOS
firmware, be sure to upgrade to the correct SonicPoint image.

Selecting UI Language
If your firmware contains other languages besides English, they can be selected in the
Language Selection pulldown menu.

Note

118

Changing the language of the SonicOS UI requires that the SonicWALL security appliance
be rebooted.

SonicOS 5.8.1 Administrator Guide

CHAPTER 9
Chapter 9:

Managing Certificates

System > Certificates
To implement the use of certificates for VPN policies, you must locate a source for a valid CA
certificate from a third party CA service. Once you have a valid CA certificate, you can import
it into the SonicWALL security appliance to validate your Local Certificates. You import the valid
CA certificate into the SonicWALL security appliance using the System > Certificates page.
Once you import the valid CA certificate, you can use it to validate your local certificates.
This chapter contains the following sections:
•

“Digital Certificates Overview” section on page 119

•

“Certificates and Certificate Requests” section on page 120

•

“Certificate Details” section on page 121

•

“Importing Certificates” section on page 121

•

“Deleting a Certificate” section on page 123

•

“Generating a Certificate Signing Request” section on page 123

•

“Configuring Simple Certificate Enrollment Protocol” section on page 125

Digital Certificates Overview
A digital certificate is an electronic means to verify identity by a trusted third party known as a
Certificate Authority (CA). The X.509 v3 certificate standard is a specification to be used with
cryptographic certificates and allows you to define extensions which you can include with your
certificate. SonicWALL has implemented this standard in its third party certificate support.
You can use a certificate signed and verified by a third party CA to use with an IKE (Internet
Key Exchange) VPN policy. IKE is an important part of IPsec VPN solutions, and it can use
digital certificates to authenticate peer devices before setting up SAs. Without digital
certificates, VPN users must authenticate by manually exchanging shared secrets or symmetric
keys. Devices or clients using digital signatures do not require configuration changes every
time a new device or client is added to the network.
A typical certificate consists of two sections: a data section and a signature section. The data
section typically contains information such as the version of X.509 supported by the certificate,
a certificate serial number, information about the user’s public key, the Distinguished Name

SonicOS 5.8.1 Administrator Guide

119

System > Certificates

(DN), validation period for the certificate, and optional information such as the target use of the
certificate. The signature section includes the cryptographic algorithm used by the issuing CA,
and the CA digital signature.
SonicWALL security appliances interoperate with any X.509v3-compliant provider of
Certificates. SonicWALL security appliances have been tested with the following vendors of
Certificate Authority Certificates:
•

Entrust

•

Microsoft

•

OpenCA

•

OpenSSL

•

VeriSign

Certificates and Certificate Requests
The Certificate and Certificate Requests section provides all the settings for managing CA
and Local Certificates.
The View Style menu allows you to display your certificates in the Certificates and Certificate
Requests table based on the following criteria:
•

All Certificates - displays all certificates and certificate requests.

•

Imported certificates and requests - displays all imported certificates and generated
certificate requests.

•

Built-in certificates - displays all certificates included with the SonicWALL security
appliance.

•

Include expired and built-in certificates - displays all expired and built-in certificates.

The Certificates and Certificate Requests table displays the following information about your
certificates:

120

•

Certificate - the name of the certificate.

•

Type - the type of certificate, which can include CA or Local.

•

Validated - the validation information.

•

Expires - the date and time the certificate expires.

SonicOS 5.8.1 Administrator Guide

System > Certificates

•

Details - the details of the certificate. Moving the pointer over the
details of the certificate.

•

Configure - Displays the
entry.

edit and delete

icon displays the

icons for editing or deleting a certificate

– Also displays the Import icon

to import either certificate revocation lists (for CA
certificates) or signed certificates (for Pending requests).

Certificate Details
Clicking on the icon in the Details column of the Certificates and Certificate Requests table
lists information about the certificate, which may include the following, depending on the type
of certificate:
•

Certificate Issuer

•

Subject Distinguished Name

•

Certificate Serial Number

•

Valid from

•

Expires On

•

Status (for Pending requests and local certificates)

•

CRL Status (for Certificate Authority certificates)

The details shown in the Details mouseover popup depend on the type of certificate.
Certificate Issuer, Certificate Serial Number, Valid from, and Expires On are not shown for
Pending requests since this information is generated by the Certificate provider. Similarly, CRL
Status information is shown only for CA certificates and varies depending on the CA certificate
configuration.

Importing Certificates
After your CA service has issued a Certificate for your Pending request, or has otherwise
provided a Local Certificate, you can import it for use in VPN or Web Management
authentication. CA Certificates may also be imported to verify local Certificates and peer
Certificates used in IKE negotiation.

SonicOS 5.8.1 Administrator Guide

121

System > Certificates

Importing a Certificate Authority Certificate
To import a certificate from a certificate authority, perform these steps:

122

Step 1

Click Import. The Import Certificate window is displayed.

Step 2

Select Import a CA certificate from a PKCS#7 (*.p7b) or DER (.der or .cer) encoded file.
The Import Certificate window settings change.

Step 3

Enter the path to the certificate file in the Please select a file to import field or click Browse
to locate the certificate file, and then click Open to set the directory path to the certificate.

Step 4

Click Import to import the certificate into the SonicWALL security appliance. Once it is
imported, you can view the certificate entry in the Certificates and Certificate Requests table.

Step 5

Moving your pointer to the
information.

SonicOS 5.8.1 Administrator Guide

icon in the Details column displays the certificate details

System > Certificates

Importing a Local Certificate
To import a local certificate, perform these steps:
Step 1

Click Import. The Import Certificate window is displayed.

Step 2

Enter a certificate name in the Certificate Name field.

Step 3

Enter the password used by your Certificate Authority to encrypt the PKCS#12 file in the
Certificate Management Password field.

Step 4

Enter the path to the certificate file in the Please select a file to import field or click Browse
to locate the certificate file, and then click Open to set the directory path to the certificate.

Step 5

Click Import to import the certificate into the SonicWALL security appliance. Once it is
imported, you can view the certificate entry in the Certificates and Certificate Requests table.

Step 6

Moving your pointer to
information.

icon in the Details column displays the certificate details

Deleting a Certificate
To delete the certificate, click the delete icon. You can delete a certificate if it has expired or if
you decide not to use third party certificates for VPN authentication.

Generating a Certificate Signing Request
Tip

You should create a Certificate Policy to be used in conjunction with local certificates. A
Certificate Policy determines the authentication requirements and the authority limits
required for the validation of a certificate.

SonicOS 5.8.1 Administrator Guide

123

System > Certificates

To generate a local certificate, follow these steps:
Step 1

Click the New Signing Request button. The Certificate Signing Request window is displayed.

Step 2

In the Generate Certificate Signing Request section, enter an alias name for the certificate
in the Certificate Alias field.

Step 3

Select the Request field type from the menu, then enter information for the certificate in the
Request fields. As you enter information in the Request fields, the Distinguished Name (DN) is
created in the Subject Distinguished Name field.
You can also attach an optional Subject Alternative Name to the certificate such as the
Domain Name or E-mail Address.

Step 4

The Subject Key type is preset as an RSA algorithm. RSA is a public key cryptographic
algorithm used for encrypting data.

Step 5

Select a Subject Key size from the Subject Key Size menu.

Note

124

Not all key sizes are supported by a Certificate Authority, therefore you should check with
your CA for supported key sizes.

Step 6

Click Generate to create a certificate signing request file. Once the Certificate Signing
Request is generated, a message describing the result is displayed.

Step 7

Click Export to download the file to your computer, then click Save to save it to a directory on
your computer. You have generated the Certificate Request that you can send to your
Certificate Authority for validation.

SonicOS 5.8.1 Administrator Guide

System > Certificates

Configuring Simple Certificate Enrollment Protocol
The Simple Certificate Enrollment Protocol (SCEP) is designed to support the secure issuance
of certificates to network devices in a scalable manner. There are two enrollment scenarios for
SCEP:
•

SCEP server CA automatically issues certificates

•

SCEP request is set to PENDING and the CA administrator manually issues the certificate.

More information about SCEP can be found at:
•

http://tools.ietf.org/html/draft-nourse-scep-18

•

Microsoft SCEP Implementation Whitepaper

To use SCEP to issue certificates, follow these steps:
Step 1

Generate a signing request as described above in the “Generating a Certificate Signing
Request” section on page 123.

Step 2

Scroll to the bottom of the System > Certificates page and click on the SCEP button. The
SCEP Configuration window displays.

Step 3

In the CSR List pulldown menu, the UI will automatically select a default CSR list. If you have
multiple CSR lists configured, you can modify this.

Step 4

In the CA URL field, enter the URL for the Certificate authority.

Step 5

If the Challenge Password field, enter the password for the CA if one is required.

Step 6

In the Polling Interval(S) field, you can modify the default value for duration of time in seconds
in between when polling messages are sent.

Step 7

In the Max Polling Time(S) field, you can modify the default value for the duration of time the
firewall will wait for a response to a polling message before timing out.

Step 8

Click the Scep button to submit the SCEP enrollment.
The firewall will then contact the CA to request the certificate. The duration of time this will take
depends on whether the CA issues certificates automatically or manually. The Log > View
page will display messages on the status of the SCEP enrollment and issuance of the
certificate. After the certificate is issued, it will be displayed in the list of available certificates
on the System > Certificates page, under the Imported certificates and requests category.

SonicOS 5.8.1 Administrator Guide

125

System > Certificates

126

SonicOS 5.8.1 Administrator Guide

CHAPTER 10
Chapter 10:

Configuring Time Settings

System > Time
The System > Time page defines the time and date settings to time stamp log events, to
automatically update SonicWALL Security Services, and for other internal purposes.

By default, the SonicWALL security appliance uses an internal list of public NTP servers to
automatically update the time. Network Time Protocol (NTP) is a protocol used to synchronize
computer clock times in a network of computers. NTP uses Coordinated Universal Time (UTC)
to synchronize computer clock times to a millisecond, and sometimes to a fraction of a
millisecond.

System Time
To select automatically update the time, choose the time zone from the Time Zone menu. Set
time automatically using NTP is activated by default to use NTP (Network Time Protocol)
servers from an internal list to set time automatically. Automatically adjust clock for daylight
saving time is also activated by default to enable automatic adjustments for daylight savings
time.

SonicOS 5.8.1 Administrator Guide

127

System > Time

If you want to set your time manually, uncheck Set time automatically using NTP. Select the
time in the 24-hour format using the Time (hh:mm:ss) menus and the date from the Date
menus.
Selecting Display UTC in logs (instead of local time) specifies the use universal time (UTC)
rather than local time for log events.
Selecting Display date in International format displays the date in International format, with
the day preceding the month.
Selecting Only use custom NTP servers directs SonicOS to use the manually entered list of
NTP servers to set the SonicWALL security appliance clock, rather than using the internal list
of NTP servers.
After selecting your System Time settings, click Accept.

NTP Settings
Network Time Protocol (NTP) is a protocol used to synchronize computer clock times in a
network of computers. NTP uses Coordinated Universal Time (UTC) to synchronize computer
clock times to a millisecond, and sometimes, to a fraction of a millisecond.

Tip

The SonicWALL security appliance uses an internal list of NTP servers so manually entering
a NTP server is optional.
Select Use NTP to set time automatically if you want to use your local server to set the
SonicWALL security appliance clock. You can also configure Update Interval (minutes) for the
NTP server to update the SonicWALL security appliance. The default value is 60 minutes.
To add an NTP server to the SonicWALL security appliance configuration

Step 1

Click Add. The Add NTP Server window is displayed.

Step 2

Type the IP address of an NTP server in the NTP Server field.

Step 3

Click OK.

Step 4

Click Accept on the System > Time page to update the SonicWALL security appliance.
To delete an NTP server, highlight the IP address and click Delete. Or, click Delete All to delete
all servers.

128

SonicOS 5.8.1 Administrator Guide

CHAPTER 11
Chapter 11:

Setting Schedules

System > Schedules
The System > Schedules page allows you to create and manage schedule objects for
enforcing schedule times for a variety of SonicWALL security appliance features.

SonicOS 5.8.1 Administrator Guide

129

System > Schedules

The Schedules table displays all your predefined and custom schedules. In the Schedules
table, there are three default schedules: Work Hours, After Hours, and Weekend Hours. You
can modify these schedules by clicking on the edit icon in the Configure column to display the
Edit Schedule window.

Note

You cannot delete the default Work Hours, After Hours, or Weekend Hours schedules.
You apply schedule objects for the specific security feature. For example, if you add an access
rule in the Firewall > Access Rules page, the Add Rule window provides a drop down menu
of all the available schedule objects you created in the System > Schedules page.
A schedule can include multiple day and time increments for rule enforcement with a single
schedule. If a schedule includes multiple day and time entries, a right-arrow button appears
next to the schedule name. Clicking the
button expands the schedule to display all the day
and time entries for the schedule.

130

SonicOS 5.8.1 Administrator Guide

System > Schedules

Adding a Schedule
To create schedules, click Add. The Add Schedule window is displayed.

Step 1

Enter a descriptive name for the schedule in the Name field.

Step 2

Select one of the following radio buttons for Schedule type:
•

Once – For a one-time schedule between the configured Start and End times and dates.
When selected, the fields under Once become active, and the fields under Recurring
become inactive.

•

Recurring – For schedule that occurs repeatedly during the same configured hours and
days of the week, with no start or end date. When selected, the fields under Recurring
become active, and the fields under Once become inactive.

•

Mixed – For a schedule that occurs repeatedly during the same configured hours and days
of the week, between the configured start and end dates. When selected, all fields on the
page become active.

Step 3

If the fields under Once are active, configure the starting date and time by selecting the Year,
Month, Date, Hour, and Minute from the drop-down lists in the Start row. The hour is
represented in 24-hour format.

Step 4

Under Once, configure the ending date and time by selecting the Year, Month, Date, Hour,
and Minute from the drop-down lists in the End row. The hour is represented in 24-hour format.

Step 5

If the fields under Recurring are active, select the checkboxes for the days of the week to apply
to the schedule or select All.

SonicOS 5.8.1 Administrator Guide

131

System > Schedules

Step 6

Under Recurring, type in the time of day for the schedule to begin in the Start field. The time
must be in 24-hour format, for example, 17:00 for 5 p.m.

Step 7

Under Recurring, type in the time of day for the schedule to stop in the Stop field. The time
must be in 24-hour format, for example, 17:00 for 5 p.m.

Step 8

Click Add.

Step 9

Click OK to add the schedule to the Schedule List.

Step 10 To delete existing days and times from the Schedule List, select the row and click Delete. Or,

to delete all existing schedules, click Delete All.

Deleting Schedules
You can delete custom schedules, but you cannot delete the default Work Hours, After Hours,
or Weekend Hours schedules.

Deleting Individual Schedules
To delete individual schedule objects that you created, perform the following steps:
Step 1

On the System > Schedules page in the Schedules table, select the checkbox next to the
schedule entry to enable the Delete button.

Step 2

Click Delete.

Deleting All Schedules
To delete all schedule objects you created:

132

Step 1

On the System > Schedules page in the Schedules table, select the checkbox next to the
Name column header to select all schedules.

Step 2

Click Delete.

SonicOS 5.8.1 Administrator Guide

CHAPTER 12
Chapter 12:

Managing SonicWALL Security
Appliance Firmware

System > Settings
This System > Settings page allows you to manage your SonicWALL security appliance’s
SonicOS versions and preferences.

SonicOS 5.8.1 Administrator Guide

133

System > Settings

Settings
Import Settings
To import a previously saved preferences file into the SonicWALL security appliance, follow
these instructions:
Step 1

Click Import Settings to import a previously exported preferences file into the SonicWALL
security appliance. The Import Settings window is displayed.

Step 2

Click Browse to locate the file which has a *.exp file name extension.

Step 3

Select the preferences file.

Step 4

Click Import, and restart the firewall.

Export Settings
To export configuration settings from the SonicWALL security appliance, use the instructions
below:
Step 1

Click Export Settings. The Export Settings window is displayed.

Step 2

Click Export.

Step 3

Click Save, and then select a location to save the file. The file is named “sonicwall.exp” but can
be renamed.

Step 4

Click Save. This process can take up to a minute. The exported preferences file can be
imported into the SonicWALL security appliance if it is necessary to reset the firmware.

Send Diagnostic Reports
Click Send Diagnostic Reports to send system diagnostics to SonicWALL Technical Support.
The status bar at the bottom of the screen displays “Please wait!” while sending the report, then
displays “Diagnostic reports sent successfully”.

134

SonicOS 5.8.1 Administrator Guide

System > Settings

Firmware Management
The Firmware Management section provides settings that allow for easy firmware upgrade
and preferences management. The Firmware Management section allows you to:

Note

•

Upload and download firmware images and system settings.

•

Boot to your choice of firmware and system settings.

•

Manage system backups.

•

Easily return your SonicWALL security appliance to the previous system state.

SonicWALL security appliance SafeMode, which uses the same settings used Firmware
Management, provides quick recovery from uncertain configuration states.

Firmware Management Table

The Firmware Management table displays the following information:
•

Firmware Image - in this column, the following types types of firmware images are listed:
– Current Firmware - firmware currently loaded on the SonicWALL security appliance.
– Current Firmware with Factory Default Settings - rebooting using this firmware

image resets the SonicWALL security appliance to its default IP addresses, username,
and password.
– Current Firmware with Backup Settings - a firmware image created by clicking

Create Backup. This option is only available on SonicWALL TZ platforms and the NSA
220, 240, and 250M that store backup settings but not a standalone backup firmware
image, as the higher platforms do.
– Uploaded Firmware - the latest uploaded version from mysonicwall.com.
– Uploaded Firmware with Factory Default Settings - the latest version uploaded with

factory default settings.
– Uploaded Firmware with Backup Settings - a firmware image created by clicking

Create Backup. This option is only available on SonicWALL TZ platforms and the NSA
220, 240, and 250M that store backup settings but not a standalone backup firmware
image, as the higher platforms do.
– System Backup - the backup firmware image and backup settings for the appliance.

This option is only available on SonicWALL NSA 2400 and higher platforms, which
store a standalone backup firmware image.
•

Version - the firmware version.

•

Date - the day, date, and time of downloading the firmware.

SonicOS 5.8.1 Administrator Guide

135

System > Settings

•

Size - the size of the firmware file in Mebibytes (MiB).

•

Download - clicking the icon saves the firmware file to a new location on your computer or
network. Only uploaded firmware can be saved to a different location.

•

Boot - clicking the icon reboots the SonicWALL security appliance with the firmware
version listed in the same row.

Caution

Clicking Boot next to any firmware image overwrites the existing current firmware image
making it the Current Firmware image.

Caution

When uploading firmware to the SonicWALL security appliance, you must not interrupt the
Web browser by closing the browser, clicking a link, or loading a new page. If the browser
is interrupted, the firmware may become corrupted.

Updating Firmware Manually
Click Upload New Firmware to upload new firmware to the SonicWALL security appliance. The
Upload Firmware window is displayed. Browse to the firmware file located on your local drive.
Click Upload to upload the new firmware to the SonicWALL security appliance.

Creating a Backup Firmware Image
When you click Create Backup, the SonicWALL security appliance takes a “snapshot” of your
current system state, firmware and configuration preferences, and makes it the new System
Backup firmware image. Clicking Create Backup overwrites the existing System Backup
firmware image as necessary.

SafeMode - Rebooting the SonicWALL Security Appliance
SafeMode allows easy firmware and preferences management as well as quick recovery from
uncertain configuration states. To access the SonicWALL security appliance using SafeMode,
use a narrow, straight object (such as a straightened paper clip or a toothpick) to press and hold
the reset button on the back of the security appliance for more than twenty seconds. The reset
button is in a small hole next to the console port or next to the power supply.

Note

136

Holding the reset button for two seconds will take a diagnostic snapshot to the console.
Holding the reset button for six to eight seconds will reboot the appliance in regular mode.

SonicOS 5.8.1 Administrator Guide

System > Settings

After the SonicWALL security appliance reboots, open your Web browser and enter the current
IP address of the SonicWALL security appliance or the default IP address: 192.168.168.168.
The SafeMode page is displayed:
SafeMode allows you to do any of the following:
•

Upload and download firmware images to the SonicWALL security appliance.

•

Upload and download system settings to the SonicWALL security appliance.

•

Boot to your choice of firmware options.

•

Create a system backup file.

•

Return your SonicWALL security appliance to a previous system state.

System Information
System Information for the SonicWALL security appliance is retained and displayed in this
section.

Firmware Management
The Firmware Management table in SafeMode has the following columns:
•

Firmware Image - In this column, five types of firmware images are listed:
– Current Firmware, firmware currently loaded on the SonicWALL security appliance
– Current Firmware with Factory Default Settings, rebooting using this firmware

image resets the SonicWALL security appliance to its default IP addresses, user name,
and password
– Current Firmware with Backup Settings - a firmware image created by clicking

Create Backup
– Uploaded Firmware, the last version uploaded from mysonicwall.com
– Uploaded Firmware with Factory Default Settings, rebooting using this firmware

image resets the SonicWALL security appliance to its default IP addresses, user name,
and password
– Uploaded Firmware with Backup Settings - a firmware image created by clicking

Create Backup

Note

•

Version - The firmware version is listed in this column.

•

Date - The day, date, and time of downloading the firmware.

•

Size - The size of the firmware file in Megabytes (MB).

•

Download - Clicking the icon saves the firmware file to a new location on your
computer or network. Only uploaded firmware can be saved to a different location.

•

Boot - Clicking the icon reboots the SonicWALL security appliance with the firmware
version listed in the same row.

Clicking Boot next to any firmware image overwrites the existing current firmware image
making it the Current Firmware image.
Click Boot in the firmware row of your choice to restart the SonicWALL security appliance.

SonicOS 5.8.1 Administrator Guide

137

System > Settings

Caution

Only select the Boot with firmware diagnostics enabled (if available) option if instructed
to by SonicWALL technical support.

Firmware Auto-Update
Sonic OS Enhanced 5.2 release introduces the Firmware Auto-Update feature, which helps
ensure that your SonicWALL security appliance has the latest firmware release. Firmware AutoUpdate contains the following options:

Caution

•

Enable Firmware Auto-Update - Displays an Alert icon
is available.

when a new firmware release

•

Download new firmware automatically when available - Downloads new firmware
releases to the SonicWALL security appliance when they become available.

Firmware updates are available only to registered users with a valid support contract. You
must register your SonicWALL at https://www.mysonicwall.com.

FIPS
When operating in FIPS (Federal Information Processing Standard) Mode, the SonicWALL
security appliance supports FIPS 140-2 Compliant security. Among the FIPS-compliant
features of the SonicWALL security appliance include PRNG based on SHA-1 and only FIPSapproved algorithms are supported (DES, 3DES, and AES with SHA-1).
Select Enable FIPS Mode to enable the SonicWALL security appliance to comply with FIPS.
When you check this setting, a dialog box is displayed with the following message: Warning!
Modifying the FIPS mode will disconnect all users and restart the device. Click OK to
proceed.
Click OK to reboot the security appliance in FIPS mode. A second warning displays. Click Yes
to continue rebooting. To return to normal operation, uncheck the Enable FIPS Mode check
box and reboot the SonicWALL security appliance into non-FIPS mode.

Caution

138

When using the SonicWALL security appliance for FIPS-compliant operation, the tamperevident sticker that is affixed to the SonicWALL security appliance must remain in place and
untouched.

SonicOS 5.8.1 Administrator Guide

CHAPTER 13
Chapter 13:

Using the Packet Monitor

System > Packet Monitor
Note

For increased convenience and accessibility, the Packet Monitor page can be accessed
either from Dashboard > Packet Monitor or System > Packet Monitor. The page is identical
regardless of which tab it is accessed through.
This chapter contains the following sections:
•

“Packet Monitor Overview” on page 139

•

“Configuring Packet Monitor” on page 143

•

“Using Packet Monitor and Packet Mirror” on page 154

•

“Verifying Packet Monitor Activity” on page 159

•

“Related Information” on page 162

Packet Monitor Overview
This section provides an introduction to the SonicOS Enhanced packet monitor feature. This
section contains the following subsections:
•

“What is Packet Monitor?” on page 139

•

“Benefits of Packet Monitor” on page 140

•

“How Does Packet Monitor Work?” on page 140

•

“What is Packet Mirror?” on page 142

•

“How Does Packet Mirror Work?” on page 142

What is Packet Monitor?
Packet monitor is a mechanism that allows you to monitor individual data packets that traverse
your SonicWALL firewall appliance. Packets can be either monitored or mirrored. The
monitored packets contain both data and addressing information. Addressing information from
the packet header includes the following:

SonicOS 5.8.1 Administrator Guide

139

System > Packet Monitor

•

Interface identification

•

MAC addresses

•

Ethernet type

•

Internet Protocol (IP) type

•

Source and destination IP addresses

•

Port numbers

•

L2TP payload details

•

PPP negotiations details

You can configure the packet monitor feature in the SonicOS Enhanced management interface.
The management interface provides a way to configure the monitor criteria, display settings,
mirror settings, and file export settings, and displays the captured packets.

Benefits of Packet Monitor
The SonicOS Enhanced packet monitor feature provides the functionality and flexibility that you
need to examine network traffic without the use of external utilities, such as Wireshark (formerly
known as Ethereal). Packet monitor includes the following features:
•

Control mechanism with improved granularity for custom filtering (Monitor Filter)

•

Display filter settings independent from monitor filter settings

•

Packet status indicates if the packet was dropped, forwarded, generated, or consumed by
the firewall

•

Three-window output in the management interface:
– List of packets
– Decoded output of selected packet
– Hexadecimal dump of selected packet

•

Export capabilities include text or HTML format with hex dump of packets, plus CAP file
format

•

Automatic export to FTP server when the buffer is full

•

Bidirectional packet monitor based on IP address and port

•

Configurable wrap-around of packet monitor buffer when full

How Does Packet Monitor Work?
As an administrator, you can configure the general settings, monitor filter, display filter,
advanced filter settings, and FTP settings of the packet monitor tool. As network packets enter
the packet monitor subsystem, the monitor filter settings are applied and the resulting packets
are written to the capture buffer. The display filter settings are applied as you view the buffer
contents in the management interface. You can log the capture buffer to view in the
management interface, or you can configure automatic transfer to the FTP server when the
buffer is full.

140

SonicOS 5.8.1 Administrator Guide

System > Packet Monitor

Default settings are provided so that you can start using packet monitor without configuring it
first. The basic functionality is as follows:

Start:

Click Start Capture to begin capturing all packets except those used for
communication between the SonicWALL appliance and the management
interface on your console system.

Stop:

Click Stop Capture to stop the packet capture.

Clear:

Click Clear to clear the status counters that are displayed at the top of the
Packet Monitor page.

Refresh:

Click Refresh to display new buffer data in the Captured Packets window. You
can then click any packet in the window to display its header information and
data in the Packet Detail and Hex Dump windows.

Export As:

Display or save a snapshot of the current buffer in the file format that you select
from the drop-down list. Saved files are placed on your local management
system (where the management interface is running). Choose from the
following formats:
•

Libpcap - Select Libpcap format if you want to view the data with the
Wireshark (formerly Ethereal) network protocol analyzer. This is also
known as libcap or pcap format. A dialog box allows you to open the buffer
file with Wireshark, or save it to your local hard drive with the extension
.pcap.

•

Html - Select Html to view the data with a browser. You can use File >
Save As to save a copy of the buffer to your hard drive.

•

Text - Select Text to view the data in a text editor. A dialog box allows you
to open the buffer file with the registered text editor, or save it to your local
hard drive with the extension .wri.

•

App Data - Select App Data to view only application data contained in the
packet. Packets containing no application data are skipped during the
capture. Application data = captured packet minus L2, L3, and L4 headers.

SonicOS 5.8.1 Administrator Guide

141

System > Packet Monitor

Refer to the figure below to see a high level view of the packet monitor subsystem. This shows
the different filters and how they are applied.
Capture Buffer

Management Host

Remote FTP Server
Monitor filter is applied
before copying the packet
into the capture buffer.

Packets
- Incoming
- Outgoing
- Generated
- Intermediate

What is Packet Mirror?
Packet mirroring is the process of sending a copy of packets seen on one interface to another
interface or to a remote SonicWALL appliance.
There are two aspects of mirroring:
Classification – Refers to identifying a selected set of packets to be mirrored. Incoming and
outgoing packets to and from an interface are matched against a filter. If matched, the mirror
action is applied.
Action – Refers to sending a copy of the selected packets to a port or a remote destination.
Packets matching a classification filter are sent to one of the mirror destinations. A particular
mirror destination is part of the action identifier.

Supported Platforms for Packet Mirror
On all SonicWALL NSA Series appliances running SonicOS Enhanced 5.6 or higher, packet
mirroring is fully supported.
On SonicWALL TZ Series appliances running SonicOS Enhanced 5.6 or higher, packet
mirroring is partially supported, as follows:
•

Local mirroring is not supported.

•

Remote mirroring is supported for both sending and receiving mirrored packets.

How Does Packet Mirror Work?
Every classification filter is associated with an action identifier. Up to two action identifiers can
be defined, supporting two mirror destinations (a physical port on the same firewall and/or a
remote SonicWALL firewall). The action identifiers determine how a packet is mirrored. The
following types of action identifiers are supported:
•

142

Send a copy to a physical port.

SonicOS 5.8.1 Administrator Guide

System > Packet Monitor

•

Encapsulate the packet and send it to a remote SonicWALL appliance.

•

Send a copy to a physical port with a VLAN configured.

Classification is performed on the Monitor Filter and Advanced Monitor Filter tab of the
Packet Monitor Configuration window.
A local Sonicwall firewall can be configured to receive remotely mirrored traffic from a remote
SonicWALL firewall. At the local firewall, received mirrored traffic can either be saved in the
capture buffer or sent to another local interface. This is configured in the Remote Mirror
Settings (Receiver) section on the Mirror tab of the Packet Monitor Configuration window.
SonicOS Enhanced 5.6 and higher supports the following packet mirroring options:
•

Mirror packets to a specified interface (Local Mirroring).

•

Mirror only selected traffic.

•

Mirror SSL decrypted traffic.

•

Mirror complete packets including Layer 2 and Layer 3 headers as well as the payload.

•

Mirror packets to a remote SonicWALL UTM appliance (Remote Mirroring Tx).

•

Receive mirrored packets from a remote SonicWALL appliance (Remote Mirroring Rx).

Configuring Packet Monitor
You can access the packet monitor tool on the Dashboard > Packet Monitor page of the
SonicOS management interface. There are six main areas of configuration for packet monitor,
one of which is specifically for packet mirror. The following sections describe the configuration
options, and provide procedures for accessing and configuring the filter settings, log settings,
and mirror settings:
•

“Configuring General Settings” on page 143

•

“Configuring Monitoring Based on Firewall Rules” on page 144

•

“Configuring Monitor Filter Settings” on page 145

•

“Configuring Display Filter Settings” on page 147

•

“Configuring Logging Settings” on page 149

•

“Configuring Advanced Monitor Filter Settings” on page 151

•

“Configuring Mirror Settings” on page 153

Configuring General Settings
This section describes how to configure packet monitor general settings, including the number
of bytes to capture per packet and the buffer wrap option. You can specify the number of bytes
using either decimal or hexadecimal, with a minimum value of 64. The buffer wrap option
enables the packet capture to continue even when the buffer becomes full, by overwriting the
buffer from the beginning.
To configure the general settings, perform the following steps:
Step 1

Navigate to the Dashboard > Packet Monitor page and click Configure.

SonicOS 5.8.1 Administrator Guide

143

System > Packet Monitor

Step 2

In the Packet Monitor Configuration window, click the Settings tab.

Step 3

Under General Settings in the Number of Bytes To Capture (per packet) box, type the
number of bytes to capture from each packet. The minimum value is 64.

Step 4

To continue capturing packets after the buffer fills up, select the Wrap Capture Buffer Once
Full checkbox. Selecting this option will cause packet capture to start writing captured packets
at the beginning of the buffer again after the buffer fills. This option has no effect if FTP server
logging is enabled on the Logging tab, because the buffer is automatically wrapped when FTP
is enabled.

Step 5

Under Exclude Filter, select the Exclude encrypted GMS traffic to prevent capturing or
mirroring of encrypted management or syslog traffic to or from SonicWALL GMS. This setting
only affects encrypted traffic within a configured primary or secondary GMS tunnel. GMS
management traffic is not excluded if it is sent via a separate tunnel.

Step 6

Use the Exclude Management Traffic settings to prevent capturing or mirroring of
management traffic to the appliance. Select the checkbox for each type of traffic (HTTP/
HTTPS, SNMP, or SSH) to exclude. If management traffic is sent via a tunnel, the packets are
not excluded.

Step 7

Use the Exclude Syslog Traffic to settings to prevent capturing or mirroring of syslog traffic
to the logging servers. Select the checkbox for each type of server (Syslog Servers or GMS
Server) to exclude. If syslog traffic is sent via a tunnel, the packets are not excluded.

Step 8

Use the Exclude Internal Traffic for settings to prevent capturing or mirroring of internal traffic
between the SonicWALL appliance and its High Availability partner or a connected SonicPoint.
Select the checkbox for each type of traffic (HA or SonicPoint) to exclude.

Step 9

To save your settings and exit the configuration window, click OK.

Configuring Monitoring Based on Firewall Rules
The Packet Monitor and Flow Reporting features allow traffic to be monitored based on firewall
rules for specific inbound or outbound traffic flows. This feature set is enabled by choosing to
monitor flows in the Firewall > Access Rules area of the SonicOS management interface.

144

SonicOS 5.8.1 Administrator Guide

System > Packet Monitor

To configure the general settings, perform the following steps:
Step 1

Navigate to the Firewall > Access Rules page and click Configure icon for the rule(s) you wish
to enable packet monitoring or flow reporting on.

Step 2

Select the Enable packet monitor checkbox to send packet monitoring statistics for this rule.

Step 3

Click the OK button to save your changes.

Note

Further monitor filter settings are required on the Dashboard > Packet Monitor page to
enable monitoring based on firewall rules.

Configuring Monitor Filter Settings
All filters set on this page are applied to both packet capture and packet mirroring. To configure
Monitor Filter settings, complete the following steps:
Step 1

Navigate to the Dashboard > Packet Monitor page and click Configure.

SonicOS 5.8.1 Administrator Guide

145

System > Packet Monitor

Step 2

In the Packet Monitor Configuration window, click the Monitor Filter tab.

Step 3

Choose to Enable filter based on the firewall/app rule if you are using firewall rules to
capture specific traffic.

Note

Before the Enable filter based on the firewall/app rule option is selected, be certain you
have selected one or more access rules on which to monitor packet traffic. This
configuration is done from either the Firewall Settings > Access Rules page or the
Dashboard > App Flow Mintor page.
On the Firewall Settings > Access Rules page, click on the edit icon for the Access Rule
on which you want to enable monitoring, and select the Enable packet monitor option.
On the Dashboard > App Flow Mintor page, select the item on which you want to enable
monitoring, click Create Rule, then select Packet Monitor and click Create Rule.

Step 4

146

Specify how Packet Monitor will filter packets using these options:
•

Interface Name(s) - You can specify up to ten interfaces separated by commas. Refer to
the Network > Interfaces screen in the management interface for the available interface
names. You can use a negative value to configure all interfaces except the one(s) specified;
for example: !X0, or !LAN.

•

Ether Type(s) - You can specify up to ten Ethernet types separated by commas. Currently,
the following Ethernet types are supported: ARP, IP, PPPoE-SES, and PPPoE-DIS. The
latter two can be specified by PPPoE alone. This option is not case-sensitive. For example,
to capture all supported types, you could enter: ARP, IP, PPPOE. You can use one or more
negative values to capture all Ethernet types except those specified; for example: !ARP,
!PPPoE. You can also use hexadecimal values to represent the Ethernet types, or mix hex
values with the standard representations; for example: ARP, 0x800, IP. Normally you would
only use hex values for Ethernet types that are not supported by acronym in SonicOS
Enhanced. See “Supported Packet Types” on page 162.

•

IP Type(s) - You can specify up to ten IP types separated by commas. The following IP
types are supported: TCP, UDP, ICMP, GRE, IGMP, AH, ESP. This option is not casesensitive. You can use one or more negative values to capture all IP types except those

SonicOS 5.8.1 Administrator Guide

System > Packet Monitor

specified; for example: !TCP, !UDP. You can also use hexadecimal values to represent the
IP types, or mix hex values with the standard representations; for example: TCP, 0x1, 0x6.
See “Supported Packet Types” on page 162.

Note

Step 5

•

Source IP Address(es) - You can specify up to ten IP addresses separated by commas;
for example: 10.1.1.1, 192.2.2.2. You can use one or more negative values to capture
packets from all but the specified addresses; for example: !10.3.3.3, !10.4.4.4.

•

Source Port(s) - You can specify up to ten TCP or UDP port numbers separated by
commas; for example: 20, 21, 22, 25. You can use one or more negative values to capture
packets from all but the specified ports; for example: !80, !8080.

•

Destination IP Address(es) - You can specify up to ten IP addresses separated by
commas; for example: 10.1.1.1, 192.2.2.2. You can use one or more negative values to
capture packets destined for all but the specified addresses; for example: !10.3.3.3,
!10.4.4.4.

•

Destination Port(s) - You can specify up to ten TCP or UDP port numbers separated by
commas; for example: 20, 21, 22, 25. You can use one or more negative values to capture
packets destined for all but the specified ports; for example: !80, !8080.

•

Bidirectional Address and Port Matching - When this option is selected, IP addresses
and ports specified in the Source or Destination fields on this page will be matched against
both the source and destination fields in each packet.

•

Forwarded packets only - Select this option to monitor any packets which are forwarded
by the firewall.

•

Consumed packets only - Select this option to monitor all packets which are consumed
by internal sources within the firewall.

•

Dropped packets only - Select this option to monitor all packets which are dropped at the
perimeter.

If a field is left blank, no filtering is done on that field. Packets are captured or mirrored
without regard to the value contained in that field of their headers.
To save your settings and exit the configuration window, click OK.

Configuring Display Filter Settings
This section describes how to configure packet monitor display filter settings. The values that
you provide here are compared to corresponding fields in the captured packets, and only those
packets that match are displayed. These settings apply only to the display of captured packets
on the management interface, and do not affect packet mirroring.

Note

If a field is left blank, no filtering is done on that field. Packets are displayed without regard
to the value contained in that field of their headers.

SonicOS 5.8.1 Administrator Guide

147

System > Packet Monitor

To configure Packet Monitor display filter settings, complete the following steps:

148

Step 1

Navigate to the Dashboard > Packet Monitor page and click Configure.

Step 2

In the Packet Monitor Configuration window, click the Display Filter tab.

Step 3

In the Interface Name(s) box, type the SonicWALL appliance interfaces for which to display
packets, or use the negative format (!X0) to display packets captured from all interfaces except
those specified. You can specify up to ten interfaces separated by commas. Refer to the
Network > Interfaces screen in the management interface for the available interface names.

Step 4

In the Ether Type(s) box, enter the Ethernet types for which you want to display packets, or
use the negative format (!ARP) to display packets of all Ethernet types except those specified.
You can specify up to ten Ethernet types separated by commas. Currently, the following
Ethernet types are supported: ARP, IP, PPPoE-SES, and PPPoE-DIS. The latter two can be
specified by PPPoE alone. You can also use hexadecimal values to represent the Ethernet
types, or mix hex values with the standard representations; for example: ARP, 0x800, IP.
Normally you would only use hex values for Ethernet types that are not supported by acronym
in SonicOS Enhanced. See “Supported Packet Types” on page 162.

Step 5

In the IP Type(s) box, enter the IP packet types for which you want to display packets, or use
the negative format (!UDP) to display packets of all IP types except those specified. You can
specify up to ten IP types separated by commas. The following IP types are supported: TCP,
UDP, ICMP, GRE, IGMP, AH, ESP. You can also use hexadecimal values to represent the IP
types, or mix hex values with the standard representations; for example: TCP, 0x1, 0x6. See
“Supported Packet Types” on page 162. To display all IP types, leave blank.

Step 6

In the Source IP Address(es) box, type the IP addresses from which you want to display
packets, or use the negative format (!10.1.2.3) to display packets captured from all source
addresses except those specified.

SonicOS 5.8.1 Administrator Guide

System > Packet Monitor

Step 7

In the Source Port(s) box, type the port numbers from which you want to display packets, or
use the negative format (!25) to display packets captured from all source ports except those
specified.

Step 8

In the Destination IP Address(es) box, type the IP addresses for which you want to display
packets, or use the negative format (!10.1.2.3) to display packets with all destination addresses
except those specified.

Step 9

In the Destination Port(s) box, type the port numbers for which you want to display packets,
or use the negative format (!80) to display packets with all destination ports except those
specified.

Step 10 To match the values in the source and destination fields against either the source or destination

information in each captured packet, select the Enable Bidirectional Address and Port
Matching checkbox.
Step 11 To display captured packets that the SonicWALL appliance forwarded, select the Forwarded

checkbox.
Step 12 To display captured packets that the SonicWALL appliance generated, select the Generated

checkbox.
Step 13 To display captured packets that the SonicWALL appliance consumed, select the Consumed

checkbox.
Step 14 To display captured packets that the SonicWALL appliance dropped, select the Dropped

checkbox.
Step 15 To save your settings and exit the configuration window, click OK.

Configuring Logging Settings
This section describes how to configure Packet Monitor logging settings. These settings
provide a way to configure automatic logging of the capture buffer to an external FTP server.
When the buffer fills up, the packets are transferred to the FTP server. The capture continues
without interruption.
If you configure automatic FTP logging, this supersedes the setting for wrapping the buffer
when full. With automatic FTP logging, the capture buffer is effectively wrapped when full, but
you also retain all the data rather than overwriting it each time the buffer wraps.
To configure logging settings, perform the following steps:
Step 1

Navigate to the Dashboard > Packet Monitor page and click Configure.

SonicOS 5.8.1 Administrator Guide

149

System > Packet Monitor

Step 2

In the Packet Monitor Configuration window, click the Logging tab.

Step 3

In the FTP Server IP Address box, type the IP address of the FTP server.

Note

Make sure that the FTP server IP address is reachable by the SonicWALL appliance. An IP
address that is reachable only via a VPN tunnel is not supported.

Step 4

In the Login ID box, type the login name that the SonicWALL appliance should use to connect
to the FTP server.

Step 5

In the Password box, type the password that the SonicWALL appliance should use to connect
to the FTP server.

Step 6

In the Directory Path box, type the directory location for the transferred files. The files are
written to this location relative to the default FTP root directory. For libcap format, files are
named “packet-log--<>.cap”, where the <> contains a run number and date including hour,
month, day, and year. For example, packet-log--3-22-08292006.cap. For HTML format, file
names are in the form: “packet-log_h-<>.html”. An example of an HTML file name is: packetlog_h-3-22-08292006.html.

Step 7

To enable automatic transfer of the capture file to the FTP server when the buffer is full, select
the Log To FTP Server Automatically checkbox. Files are transferred in both libcap and
HTML format.

Step 8

To enable transfer of the file in HTML format as well as libcap format, select the Log HTML File
Along With .cap File (FTP).

Step 9

To test the connection to the FTP server and transfer the capture buffer contents to it, click Log
Now. In this case the file name will contain an ‘F’. For example, packet-log-F-3-2208292006.cap or packet-log_h-F-3-22-08292006.html.

Step 10 To save your settings and exit the configuration window, click OK.

150

SonicOS 5.8.1 Administrator Guide

System > Packet Monitor

Restarting FTP Logging
If automatic FTP logging is off, either because of a failed connection or simply disabled, you
can restart it in Configure > Logging.
Step 1

Navigate to the Dashboard > Packet Monitor page and click Configure.

Step 2

In the Packet Monitor Configuration window, click the Logging tab.

Step 3

Verify that the settings are correct for each item on the page. See “Configuring Logging
Settings” on page 149.

Step 4

To change the FTP logging status on the main packet monitor page to “active”, select the Log
To FTP Server Automatically checkbox.

Step 5

To save your settings and exit the configuration window, click OK.

Configuring Advanced Monitor Filter Settings
This section describes how to configure monitoring for packets generated by the SonicWALL
appliance and for intermediate traffic.
Step 1

Navigate to the Dashboard > Packet Monitor page and click Configure.

Step 2

In the Packet Monitor Configuration window, click the Advanced Monitor Filter tab.

Step 3

To monitor packets generated by the SonicWALL appliance, select the Monitor Firewall
Generated Packets checkbox.

SonicOS 5.8.1 Administrator Guide

151

System > Packet Monitor

Even when other monitor filters do not match, this option ensures that packets generated by
the SonicWALL appliance are captured. This includes packets generated by HTTP(S), L2TP,
DHCP servers, PPP, PPPOE, and routing protocols. Captured packets are marked with ‘s’ in
the incoming interface area when they are from the system stack. Otherwise, the incoming
interface is not specified.
Step 4

To monitor intermediate packets generated by the SonicWALL appliance, select the Monitor
Intermediate Packets checkbox. Selecting this checkbox enables, but does not select, the
subsequent checkboxes for monitoring specific types of intermediate traffic.

Step 5

Select the checkbox for any of the following options to monitor that type of intermediate traffic:

Note
Step 6

152

•

Monitor intermediate multicast traffic – Capture or mirror replicated multicast traffic.

•

Monitor intermediate IP helper traffic – Capture or mirror replicated IP Helper packets.

•

Monitor intermediate reassembled traffic – Capture or mirror reassembled IP packets.

•

Monitor intermediate fragmented traffic – Capture or mirror packets fragmented by the
firewall.

•

Monitor intermediate remote mirrored traffic – Capture or mirror remote mirrored
packets after de-encapsulation.

•

Monitor intermediate IPsec traffic – Capture or mirror IPSec packets after encryption and
decryption.

•

Monitor intermediate SSL decrypted traffic – Capture or mirror decrypted SSL packets.
Certain IP and TCP header fields may not be accurate in the monitored packets, including
IP and TCP checksums and TCP port numbers (remapped to port 80). DPI-SSL must be
enabled to decrypt the packets.

•

Monitor intermediate decrypted LDAP over TLS packets – Capture or mirror decrypted
LDAPS packets. The packets are marked with “(ldp)” in the ingress/egress interface fields
and will have dummy Ethernet, IP, and TCP headers with some inaccurate fields. The
LDAP server is set to 389. Passwords in captured LDAP bind requests are obfuscated.

•

Monitor intermediate decrypted Single Sign On agent messages – Capture or mirror
decrypted messages to or from the SSO Agent. The packets are marked with “(sso)” in the
ingress/egress interface fields and will have dummy Ethernet, IP, and TCP headers with
some inaccurate fields.

Monitor filters are still applied to all selected intermediate traffic types.
To save your settings and exit the configuration window, click OK.

SonicOS 5.8.1 Administrator Guide

System > Packet Monitor

Configuring Mirror Settings
This section describes how to configure Packet Monitor mirror settings. Mirror settings provide
a way to send packets to a different physical port of the same firewall or to send packets to, or
receive them from, a remote SonicWALL firewall.
To configure mirror settings, perform the following steps:
Step 1

Navigate to the Dashboard > Packet Monitor page and click Configure.

Step 2

In the Packet Monitor Configuration window, click the Mirror tab.

Step 3

Under Mirror Settings, type the desired maximum mirror rate into the Maximum mirror rate (in
kilobits per second) field. If this rate is exceeded during mirroring, the excess packets will not
be mirrored and will be counted as skipped packets. This rate applies to both local and remote
mirroring. The default and minimum value is 100 kbps, and the maximum is 1 Gbps.

Step 4

Select the Mirror only IP packets checkbox to prevent mirroring of other Ether type packets,
such as ARP or PPPoE. If selected, this option overrides any non-IP Ether types selected on
the Monitor Filter tab.

Step 5

Under Local Mirror Settings, select the destination interface for locally mirrored packets in the
Mirror filtered packets to Interface (NSA platforms only) drop-down list.

Step 6

Under Remote Mirror Settings (Sender), in the Mirror filtered packets to remote Sonicwall
firewall (IP Address) field, type the IP address of the remote SonicWALL to which mirrored
packets will be sent.

Note

The remote SonicWALL must be configured to receive the mirrored packets.

SonicOS 5.8.1 Administrator Guide

153

System > Packet Monitor

Step 7

In the Encrypt remote mirrored packets via IPSec (preshared key-IKE) field, type the preshared key to be used to encrypt traffic when sending mirrored packets to the remote
SonicWALL. Configuring this field enables an IPSec transport mode tunnel between this
appliance and the remote SonicWALL. This pre-shared key is used by IKE to negotiate the
IPSec keys.

Note

The Encrypt remote mirrored packets via IPSec (preshared key-IKE) option is inactive
in SonicOS Enhanced 5.6, and will be supported in a future release.

Step 8

Under Remote Mirror Settings (Receiver), in the Receive mirrored packets from remote
Sonicwall firewall (IP Address) field, type the IP address of the remote SonicWALL from
which mirrored packets will be received.

Note
Step 9

Note

The remote SonicWALL must be configured to send the mirrored packets.
In the Decrypt remote mirrored packets via IPSec (preshared key-IKE) field, type the preshared key to be used to decrypt traffic when receiving mirrored packets from the remote
SonicWALL. Configuring this field enables an IPSec transport mode tunnel between this
appliance and the remote SonicWALL. This pre-shared key is used by IKE to negotiate the
IPSec keys.

The Decrypt remote mirrored packets via IPSec (preshared key-IKE) option is inactive
in SonicOS Enhanced 5.6, and will be supported in a future release.

Step 10 To mirror received packets to another interface on the local SonicWALL, select the interface

from the Send received remote mirrored packets to Interface (NSA platforms only) dropdown list.
Step 11 To save received packets in the local capture buffer, select the Send received remote

mirrored packets to capture buffer checkbox. This option is independent of sending received
packets to another interface, and both can be enabled if desired.
Step 12 To save your settings and exit the configuration window, click OK.

Using Packet Monitor and Packet Mirror
In addition to the Configure button, the top of the Dashboard > Packet Monitor page provides
several buttons for general control of the packet monitor feature and display. These include the
following:

154

•

Monitor All – Resets current monitor filter settings and advanced page settings so that
traffic on all local interfaces is monitored. A confirmation dialog box displays when you click
this button.

•

Monitor Default – Resets current monitor filter settings and advanced page settings to
factory default settings. A confirmation dialog box displays when you click this button.

•

Clear – Clears the packet monitor queue and the displayed statistics for the capture buffer,
mirroring, and FTP logging. A confirmation dialog box displays when you click this button.

•

Refresh – Refreshes the packet display windows on this page to show new buffer data.

SonicOS 5.8.1 Administrator Guide

System > Packet Monitor

The Dashboard > Packet Monitor page is shown below:

For an explanation of the status indicators near the top of the page, see “Understanding Status
Indicators” on page 159.
The other buttons and displays on this page are described in the following sections:
•

“Starting and Stopping Packet Capture” on page 155

•

“Starting and Stopping Packet Mirror” on page 156

•

“Viewing Captured Packets” on page 156

Starting and Stopping Packet Capture
You can start a packet capture that uses default settings without configuring specific criteria for
packet capture, display, FTP export, and other settings. If you start a default packet capture,
the SonicWALL appliance will capture all packets except those for internal communication, and
will stop when the buffer is full or when you click Stop Capture.
Step 1

Navigate to the Dashboard > Packet Monitor page.

Step 2

Optionally click Clear to set the statistics back to zero.

Step 3

Under Packet Monitor, click Start Capture.

Step 4

To refresh the packet display windows to show new buffer data, click Refresh.

SonicOS 5.8.1 Administrator Guide

155

System > Packet Monitor

Step 5

To stop the packet capture, click Stop Capture.
You can view the captured packets in the Captured Packets, Packet Detail, and Hex Dump
sections of the screen. See “Viewing Captured Packets” on page 156.

Starting and Stopping Packet Mirror
You can start packet mirroring that uses your configured mirror settings by clicking Start
Mirror. It is not necessary to first configure specific criteria for display, logging, FTP export, and
other settings. Packet mirroring stops when you click Stop Mirror.
Step 1

Navigate to the Dashboard > Packet Monitor page.

Step 2

Under Packet Monitor, click Start Mirror to start mirroring packets according to your
configured settings.

Step 3

To stop mirroring packets, click Stop Mirror.

Viewing Captured Packets
The Dashboard > Packet Monitor page provides three windows to display different views of
captured packets. The following sections describe the viewing windows:
•

“About the Captured Packets Window” on page 156

•

“About the Packet Detail Window” on page 158

•

“About the Hex Dump Window” on page 158

About the Captured Packets Window
The Captured Packets window displays the following statistics about each packet:

156

•

# - The packet number relative to the start of the capture

•

Time - The date and time that the packet was captured

•

Ingress - The SonicWALL appliance interface on which the packet arrived is marked with
an asterisk (*). The subsystem type abbreviation is shown in parentheses. Subsystem type
abbreviations are defined in the following table.

Abbreviation

Definition

i

Interface

hc

Hardware based encryption or decryption

sc

Software based encryption or decryption

m

Multicast

r

Packet reassembly

s

System stack

ip

IP helper

f

Fragmentation

SonicOS 5.8.1 Administrator Guide

System > Packet Monitor

•

Egress - The SonicWALL appliance interface on which the packet was captured when sent
out
– The subsystem type abbreviation is shown in parentheses. See the table above for

definitions of subsystem type abbreviations
•

Source IP - The source IP address of the packet

•

Destination IP - The destination IP address of the packet

•

Ether Type - The Ethernet type of the packet from its Ethernet header

•

Packet Type - The type of the packet depending on the Ethernet type; for example:
– For IP packets, the packet type might be TCP, UDP, or another protocol that runs over

IP
– For PPPoE packets, the packet type might be PPPoE Discovery or PPPoE Session
– For ARP packets, the packet type might be Request or Reply
•

Ports [Src,Dst] - The source and destination TCP or UDP ports of the packet

•

Status - The status field for the packet
The status field shows the state of the packet with respect to the firewall. A packet can be
dropped, generated, consumed or forwarded by the SonicWALL appliance. You can
position the mouse pointer over dropped or consumed packets to show the following
information.
Packet status

Displayed value

Definition of displayed value

Dropped

Module-ID = 

Value for the protocol subsystem ID

Drop-code = 

Reason for dropping the packet

Reference-ID: 

SonicWALL-specific data

Module-ID = 

Value for the protocol subsystem ID

Consumed
•

Length [Actual] - Length value is the number of bytes captured in the buffer for this packet.
Actual value, in brackets, is the number of bytes transmitted in the packet.
You can configure the number of bytes to capture. See “Configuring General Settings” on
page 143.

SonicOS 5.8.1 Administrator Guide

157

System > Packet Monitor

About the Packet Detail Window
When you click on a packet in the Captured Packets window, the packet header fields are
displayed in the Packet Detail window. The display will vary depending on the type of packet
that you select.

About the Hex Dump Window
When you click on a packet in the Captured Packets window, the packet data is displayed in
hexadecimal and ASCII format in the Hex Dump window. The hex format is shown on the left
side of the window, with the corresponding ASCII characters displayed to the right for each line.
When the hex value is zero, the ASCII value is displayed as a dot.

158

SonicOS 5.8.1 Administrator Guide

System > Packet Monitor

Verifying Packet Monitor Activity
This section describes how to tell if your packet monitor, mirroring, or FTP logging is working
correctly according to the configuration. It contains the following sections:
•

“Understanding Status Indicators” on page 159

•

“Clearing the Status Information” on page 161

Understanding Status Indicators
The main Packet Monitor page displays status indicators for packet capture, mirroring, and FTP
logging. Information popup tooltips are available for quick display of the configuration settings.

See the following sections:
•

“Packet Capture Status” on page 159

•

“Mirroring Status” on page 160

•

“FTP Logging Status” on page 161

•

“Current Buffer Statistics” on page 161

•

“Current Configurations” on page 161

Packet Capture Status
The packet capture status indicator is labelled as Trace, and shows one of the following three
conditions:
•

Red – Capture is stopped

•

Green – Capture is running and the buffer is not full

•

Yellow – Capture is running, but the buffer is full

The management interface also displays the buffer size, the number of packets captured, the
percentage of buffer space used, and how much of the buffer has been lost. Lost packets occur
when automatic FTP logging is turned on, but the file transfer is slow for some reason. If the
transfer is not finished by the time the buffer is full again, the data in the newly filled buffer is
lost.

Note

Although the buffer wrap option clears the buffer upon wrapping to the beginning, this is not
considered lost data.

SonicOS 5.8.1 Administrator Guide

159

System > Packet Monitor

Mirroring Status
There are three status indicators for packet mirroring:
Local mirroring – Packets sent to another physical interface on the same SonicWALL

For local mirroring, the status indicator shows one of the following three conditions:
•

Red – Mirroring is off

•

Green – Mirroring is on

•

Yellow – Mirroring is on but disabled because the local mirroring interface is not specified

The local mirroring row also displays the following statistics:
•

Mirroring to interface – The specified local mirroring interface

•

Packets mirrored – The total number of packets mirrored locally

•

Pkts skipped – The total number of packets that skipped mirroring due to packets that are
incoming/outgoing on the interface on which monitoring is configured

•

Pkts exceeded rate – The total number of packets that skipped mirroring due to rate limiting

Remote mirroring Tx – Packets sent to a remote SonicWALL

For Remote mirroring Tx, the status indicator shows one of the following three conditions:
•

Red – Mirroring is off

•

Green – Mirroring is on and a remote SonicWALL IP address is configured

•

Yellow – Mirroring is on but disabled because the remote device rejects mirrored packets
and sends port unreachable ICMP messages

The Remote mirroring Tx row also displays the following statistics:
•

Mirroring to – The specified remote SonicWALL IP address

•

Packets mirrored – The total number of packets mirrored to a remote SonicWALL appliance

•

Pkts skipped – The total number of packets that skipped mirroring due to packets that are
incoming/outgoing on the interface on which monitoring is configured

•

Pkts exceeded rate – The total number of packets that failed to mirror to a remote
SonicWALL, either due to an unreachable port or other network issues

Remote mirroring Rx – Packets received from a remote SonicWALL

For Remote mirroring Rx, the status indicator shows one of the following two conditions:
•

Red – Mirroring is off

•

Green – Mirroring is on and a remote SonicWALL IP address is configured

The Remote mirroring Rx row also displays the following statistics:

160

•

Receiving from – The specified remote SonicWALL IP address

•

Mirror packets rcvd – The total number of packets received from a remote SonicWALL
appliance

•

Mirror packets rcvd but skipped – The total number of packets received from a remote
SonicWALL appliance that failed to get mirrored locally due to errors in the packets

SonicOS 5.8.1 Administrator Guide

System > Packet Monitor

FTP Logging Status
The FTP logging status indicator shows one of the following three conditions:
•

Red – Automatic FTP logging is off

•

Green – Automatic FTP logging is on

•

Yellow – The last attempt to contact the FTP server failed, and logging is now off
To restart automatic FTP logging, see “Restarting FTP Logging” on page 151.

Next to the FTP logging indicator, the management interface also displays the number of
successful and failed attempts to transfer the buffer contents to the FTP server, the current
state of the FTP process thread, and the status of the capture buffer.
Under the FTP logging indicator, on the Current Buffer Statistics line, the management interface
displays the number of packets dropped, forwarded, consumed, generated, or unknown.
On the Current Configurations line, you can hover your mouse pointer over Filters, General, or
Logging to view the currently configured value for each setting in that category. The Filters
display includes the capture filter and display filter settings. The display for General includes
both the general and advanced settings. The Logging display shows the FTP logging settings.

Current Buffer Statistics
The Current Buffer Statistics row summarizes the current contents of the local capture buffer.
It shows the number of dropped, forwarded, consumed, generated, and unknown packets.

Current Configurations
The Current Configurations row provides dynamic information displays for the configured filter,
general, logging, and mirror settings. When you hover your mouse pointer over one of the
information icons or its label, a popup tooltip displays the current settings for that selection.

Clearing the Status Information
You can clear the packet monitor queue and the displayed statistics for the capture buffer,
mirroring, and FTP logging.
Step 1

Navigate to the Dashboard > Packet Monitor page.

Step 2

Click Clear.

Step 3

Click OK in the confirmation dialog box.

SonicOS 5.8.1 Administrator Guide

161

System > Packet Monitor

Related Information
This section contains the following:
•

“Supported Packet Types” on page 162

•

“File Formats for Export As” on page 162

Supported Packet Types
When specifying the Ethernet or IP packet types that you want to monitor or display, you can
use either the standard acronym for the type, if supported, or the corresponding hexadecimal
representation. To determine the hex value for a protocol, refer to the RFC for the number
assigned to it by IANA. The protocol acronyms that SonicOS Enhanced currently supports are
as follows:

Supported Ethernet types:

•

ARP

•

IP

•

PPPoE-DIS

•

PPPoE-SES
To specify both PPPoE-DIS and PPPoE-SES, you
can simply use PPPoE.

Supported IP types:

•

TCP

•

UDP

•

ICMP

•

IGMP

•

GRE

•

AH

•

ESP

File Formats for Export As
The Export As option on the Dashboard > Packet Monitor page allows you to display or save
a snapshot of the current buffer in the file format that you select from the drop-down list. Saved
files are placed on your local management system (where the management interface is
running). Choose from the following formats:

162

•

Libpcap - Select Libpcap format if you want to view the data with the Wireshark network
protocol analyzer. This is also known as libcap or pcap format. A dialog box allows you to
open the buffer file with Wireshark, or save it to your local hard drive with the extension
.pcap.

•

Html - Select Html to view the data with a browser. You can use File > Save As to save a
copy of the buffer to your hard drive.

•

Text - Select Text to view the data in a text editor. A dialog box allows you to open the buffer
file with the registered text editor, or save it to your local hard drive with the extension .wri.

•

App Data - Select App Data to view only application data contained in the packet. Packets
containing no application data are skipped during the capture. Application data = captured
packet minus L2, L3, and L4 headers.

SonicOS 5.8.1 Administrator Guide

System > Packet Monitor

Examples of the Html and Text formats are shown in the following sections:
•

“HTML Format” on page 163

•

“Text File Format” on page 164

HTML Format
You can view the HTML format in a browser. The following is an example showing the header
and part of the data for the first packet in the buffer.

SonicOS 5.8.1 Administrator Guide

163

System > Packet Monitor

Text File Format
You can view the text format output in a text editor. The following is an example showing the
header and part of the data for the first packet in the buffer.

164

SonicOS 5.8.1 Administrator Guide

CHAPTER 14
Chapter 14:

Using Diagnostic Tools & Restarting the
Appliance

System > Diagnostics
The System > Diagnostics page provides several diagnostic tools which help troubleshoot
network problems as well as Active Connections, CPU and Process Monitors.

SonicOS 5.8.1 Administrator Guide

165

System > Diagnostics

Tech Support Report
The Tech Support Report generates a detailed report of the SonicWALL security appliance
configuration and status, and saves it to the local hard disk using the Download Report button.
This file can then be e-mailed to SonicWALL Technical Support to help assist with a problem.

Tip

You must register your SonicWALL security appliance on mysonicwall.com to receive
technical support.
Before e-mailing the Tech Support Report to the SonicWALL Technical Support team, complete
a Tech Support Request Form at https://www.mysonicwall.com. After the form is submitted, a
unique case number is returned. Include this case number in all correspondence, as it allows
SonicWALL Technical Support to provide you with better service.

Generating a Tech Support Report

Step 1

166

In the Tech Support Report section, select any of the following four report options:
•

VPN Keys – saves shared secrets, encryption, and authentication keys to the report.

•

ARP Cache – saves a table relating IP addresses to the corresponding MAC or physical
addresses.

•

DHCP Bindings – saves entries from the SonicWALL security appliance DHCP server.

•

IKE Info – saves current information about active IKE configurations.

•

SonicPointN Diagnostics – save information on SonicPointN sessions.

•

Current users – saves basic information on user sessions

•

Detail of users – saves additional details of user sessions

Step 2

Click Download Report to save the file to your system. When you click Download Report, a
warning message is displayed.

Step 3

Click OK to save the file. Attach the report to your Tech Support Request e-mail.

Step 4

To send the TSR, system preferences, and trace log to SonicWALL Engineering (not to
SonicWALL Technical Support), click Send Diagnostic Reports. The Status indicator at the
bottom of the page displays “Please wait!” while the report is sent, and then displays
“Diagnostic reports sent successfully.” You would normally do this after talking to Technical
Support.

Step 5

To periodically send the TSR, system preferences, and trace log to MySonicWALL for
SonicWALL Engineering, select the Enable Periodic Secure Backup of Diagnostic Reports
to MySonicwall checkbox and enter the interval in minutes between the periodic reports in the
Time Interval (minutes) field.

SonicOS 5.8.1 Administrator Guide

System > Diagnostics

Diagnostic Tools
You select the diagnostic tool from the Diagnostic Tool drop-down list in the Diagnostic Tool
section of the System > Diagnostics page. The following diagnostic tools are available:
•

“Check Network Settings” on page 168

•

“Connections Monitor” on page 169

•

“Multi-Core Monitor” on page 171

•

“Core Monitor” on page 172

•

“CPU Monitor” on page 173

•

“Link Monitor” on page 174

•

“Packet Size Monitor” on page 174

•

“DNS Name Lookup” on page 175

•

“Find Network Path” on page 175

•

“Ping” on page 175

•

“Core 0 Process Monitor” on page 176

•

“Real-Time Black List Lookup” on page 176

•

“Reverse Name Resolution” on page 177

•

“Connection Limit TopX” on page 177

•

“MX Lookup and Banner Check” on page 177

•

“Trace Route” on page 178

•

“Web Server Monitor” on page 178

•

“User Monitor” on page 179

SonicOS 5.8.1 Administrator Guide

167

System > Diagnostics

Check Network Settings

Check Network Settings is a diagnostic tool which automatically checks the network
connectivity and service availability of several pre-defined functional areas of SonicOS, returns
the results, and attempts to describe the causes if any exceptions are detected. This tool helps
administrators locate the problem area when users encounter a network problem.
Specifically, the Check Network Settings tool automatically tests the following functions:
•

Default Gateway settings

•

DNS settings

•

MySonicWALL server connectivity

•

License Manager server connectivity

•

Content Filter server connectivity

The return data consists of two parts:

168

•

Test Results – Provides a summary of the test outcome

•

Notes – Provides details to help determine the cause if any problems exist

SonicOS 5.8.1 Administrator Guide

System > Diagnostics

The Check Network Settings tool is dependent on the Network Monitor feature available on
the Network > Network Monitor page of the SonicOS management interface. Whenever the
Check Network Settings tool is being executed (except during the Content Filter test), a
corresponding Network Monitor Policy appears on the Network Monitor page, with a special
diagnostic tool policy name in the form “diagTestPolicyAuto__0”.

To use the Check Network Settings tool, first select it in the Diagnostic Tools drop-down list
and then click the Test button in the row for the item that you want to test. The results are
displayed in the same row. A green check mark
signifies a successful test, and a red X
indicates that there is a problem.
To test multiple items at the same time, select the checkbox for each desired item and then
click the Test All Selected button.
If there are any failed probes, you can click the blue arrow
to the left of the IP Address field
of the failed item to jump to the configuration page to investigate the root cause.

Connections Monitor
The Connections Monitor displays real-time, exportable (plain text or CSV), filterable views
of all connections to and through the SonicWALL security appliance. Click on a column heading
to sort by that column.

SonicOS 5.8.1 Administrator Guide

169

System > Diagnostics

Active Connections Monitor Settings

You can filter the results to display only connections matching certain criteria. You can filter by
Source IP, Destination IP, Destination Port, Protocol, Src Interface, and Dst Interface.
Enter your filter criteria in the Active Connections Monitor Settings table.
The fields you enter values into are combined into a search string with a logical AND. For
example, if you enter values for Source IP and Destination IP, the search string will look for
connections matching:
Source IP AND Destination IP
Check the Group box next to any two or more criteria to combine them with a logical OR. For
example, if you enter values for Source IP, Destination IP, and Protocol, and check Group
next to Source IP and Destination IP, the search string will look for connections matching:
(Source IP OR Destination IP) AND Protocol
Click Apply Filter to apply the filter immediately to the Active Connections Monitor table.
Click Reset Filters to clear the filter and display the unfiltered results again.
You can export the list of active connections to a file. Click Export Results, and select if you
want the results exported to a plain text file, or a Comma Separated Value (CSV) file for
importing to a spreadsheet, reporting tool, or database. If you are prompted to Open or Save
the file, select Save. Then enter a filename and path and click OK.

170

SonicOS 5.8.1 Administrator Guide

System > Diagnostics

Multi-Core Monitor
The Multi-Core Monitor displays dynamically updated statistics on utilization of the individual
cores of the SonicWALL security appliances. Core 0 handles the control plane. The control
plane processes all web server requests for the SonicOS UI as well as functions like FTP and
VoIP control connections. Core 0 usage is displayed in green on the Multi-Core Monitor.
The remaining cores handle the data plane. To maximize processor flexibility, functions are not
dedicated to specific cores; instead all cores can process all data plane tasks. Memory is
shared across all cores. UTM processing is displayed in grey for the data plane cores, and all
other processing is displayed in blue.

Note

High utilization on Core 0 is normal while browsing the Web management interface and
applying changes. All Web management requests are processed by Core 0 and do not
impact the other cores. Traffic handling and other critical, performance-oriented and system
tasks are always prioritized by the scheduler, and will never be impacted by web
management usage.
Packet ordering and synchronization is maintained by assigning a unique tag to each unique
flow. A flow is defined by five pieces of information: source IP address and port number,
destination IP address and port number, and the protocol. To ensure that TCP and UTM states
are properly maintained, each flow is processed by a single core. Each core can process a
separate flow simultaneously, allowing for up to sixteen flows to be processed in parallel.

SonicOS 5.8.1 Administrator Guide

171

System > Diagnostics

Core Monitor
The Core Monitor displays dynamically updated statistics on the utilization of a single specified
core on the SonicWALL NSA E-Class series security appliances. The View Style provides a
wide range of time intervals that can be displayed to review core usage.

Note

172

High utilization on Core 0 is normal while browsing the Web management interface and
applying changes. All Web management requests are processed by Core 0 and do not
impact the other cores. Traffic handling and other critical, performance-oriented and system
tasks are always prioritized by the scheduler, and will never be impacted by web
management usage.

SonicOS 5.8.1 Administrator Guide

System > Diagnostics

CPU Monitor
The CPU Monitor diagnostic tool shows real-time CPU utilization in second, minute, hour, and
day intervals (historical data does not persist across reboots). The CPU Monitor is only included
on single core SonicWALL security appliances. The multi-core appliances display the MultiCore Monitor instead.

Note

High CPU utilization is normal during Web-management page rendering, and while saving
preferences to flash. Utilization by these tasks is an indication that available resources are
being efficiently used rather than sitting idle. Traffic handling and other critical, performanceoriented and system tasks are always prioritized by the scheduler, and never experience
starvation.

SonicOS 5.8.1 Administrator Guide

173

System > Diagnostics

Link Monitor
The Link Monitor displays bandwidth utilization for the interfaces on the SonicWALL security
appliance. Bandwidth utilization is shown as a percentage of total capacity. The Link Monitor
can be configured to display inbound traffic, outbound traffic or both for each of the physical
interfaces on the appliance.

Packet Size Monitor
The Packet Size Monitor displays sizes of packets on the interfaces on the SonicWALL
security appliance. You can select from four time periods, ranging from the last 30 seconds to
the last 30 days. The Packet Size Monitor can be configured to display inbound traffic,
outbound traffic or both for each of the physical interfaces on the appliance.
Step 1

Select one of the following from the View Style drop-down list:
– Last 30 Seconds
– Last 30 Minutes
– Last 24 Hours
– Last 30 Days

Step 2

Select the physical interface to view from the Interface Name drop-down list.

Step 3

In the Direction drop-down list, select one of the following:
– Both – Select for packets traveling both inbound and outbound
– Ingress – Select for packets arriving on the interface
– Egress – Select for packets departing from the interface

The packets are displayed in the Average Packet Size graph, where the X axis specifies when
the packets crossed the interface and the Y axis specifies the average packet size at that time.
Ingress packets are displayed in green, and egress packets are displayed in red.

174

SonicOS 5.8.1 Administrator Guide

System > Diagnostics

DNS Name Lookup
The SonicWALL security appliance has a DNS lookup tool that returns the IP address of a
domain name. Or, if you enter an IP address, it returns the domain name for that address.
Step 1

Enter the host name or IP address in the Look up name field. Do not add http to the host name.

Step 2

The SonicWALL security appliance queries the DNS Server and displays the result in the
Result section. It also displays the IP address of the DNS Server used to perform the query.
The DNS Name Lookup section also displays the IP addresses of the DNS Servers configured
on the SonicWALL security appliance. If there is no IP address or IP addresses in the DNS
Server fields, you must configure them on the Network > Settings page.

Find Network Path
Find Network Path indicates if an IP host is located on the LAN or WAN ports. This can
diagnose a network configuration problem on the SonicWALL security appliance. For example,
if the SonicWALL security appliance indicates that a computer on the Internet is located on the
LAN, then the network or Intranet settings may be misconfigured.

Find Network Path can be used to determine if a target device is located behind a network
router and the Ethernet address of the target device. It also displays the gateway the device is
using and helps isolate configuration problems.

Ping
The Ping test bounces a packet off a machine on the Internet and returns it to the sender. This
test shows if the SonicWALL security appliance is able to contact the remote host. If users on
the LAN are having problems accessing services on the Internet, try pinging the DNS server,
or another machine at the ISP location. If the test is unsuccessful, try pinging devices outside
the ISP. If you can ping devices outside of the ISP, then the problem lies with the ISP
connection.
Step 1

Select Ping from the Diagnostic Tool menu.

Step 2

Enter the IP address or host name of the target device and click Go.

Step 3

In the Interface pulldown menu, select which WAN interface you want to test the ping from.
Selecting ANY allows the appliance to choose among all interfaces—including those not listed
in the pulldown menu.

Step 4

If the test is successful, the SonicWALL security appliance returns a message saying the IP
address is alive and the time to return in milliseconds (ms).

SonicOS 5.8.1 Administrator Guide

175

System > Diagnostics

Core 0 Process Monitor
The Core 0 Process Monitor shows the individual system processes on core 0, their CPU
utilization, and their system time. The Core 0 process monitor is only available on the multi-core
NSA E-Class appliances.

Real-Time Black List Lookup
The Real-Time Black List Lookup tool allows you to test SMTP IP addresses, RBL services,
or DNS servers. Enter an IP address in the IP Address field, a FQDN for the RBL in the RBL
Domain field and DNS server information in the DNS Server field. Click Go.

176

SonicOS 5.8.1 Administrator Guide

System > Diagnostics

Reverse Name Resolution
The Reverse Name Resolution tool is similar to the DNS name lookup tool, except that it looks
up a server name, given an IP address.

Enter an IP address in the Reverse Lookup the IP Address field, and it checks all DNS servers
configured for your security appliance to resolve the IP address into a server name.

Connection Limit TopX
The Connection Limit TopX tool lists the top 10 connections by the source and destination IP
addresses. Before you can use this tool, you must enable source IP limiting and/or destination
IP limiting for your appliance. If these are not enabled, the page displays a message to inform
you that you can enable them on the Firewall > Advanced page.

Check GEO Location and BOTNET Server Lookup
The Geo-IP and Botnet Filtering feature allows administrators to block connections to or from
a geographic location based on IP address, and to or from Botnet command and control
servers. Additional functionality for this feature is available on the Security Services > Geo-IP
and Botnet Filter page. For full details, see “Security Services > Geo-IP Filter” on page 1262.

MX Lookup and Banner Check
The MX Lookup and Banner Check tool allows you to look up a domain or IP address. Your
configured DNS servers are displayed in the DNS Server 1/2/3 fields, but are not editable. After
you type a domain name, such as “google.com” into the Lookup name or IP field and click Go,

SonicOS 5.8.1 Administrator Guide

177

System > Diagnostics

the output is displayed under Result. The results include the domain name or IP address that
you entered, the DNS server from your list that was used, the resolved email server domain
name and/or IP address, and the banner received from the domain server or a message that
the connection was refused. The contents of the banner depends on the server you are looking
up.

Trace Route
Trace Route is a diagnostic utility to assist in diagnosing and troubleshooting router
connections on the Internet. By using Internet Connect Message Protocol (ICMP) echo packets
similar to Ping packets, Trace Route can test interconnectivity with routers and other hosts that
are farther and farther along the network path until the connection fails or until the remote host
responds.
Step 1

Select Trace Route from the Diagnostic Tool menu.

Step 2

Type the IP address or domain name of the destination host in the TraceRoute this host or IP
addres field.

Step 3

In the Interface pulldown menu, select which interface you want to test the trace route from.
Selecting ANY allows the appliance to choose among all interfaces—including those not listed
in the pulldown menu.

Step 4

Click Go.
A second window is displayed with each hop to the destination host. By following the route, you
can diagnose where the connection fails between the SonicWALL security appliance and the
destination.

Web Server Monitor
The Web Server Monitor tool displays the CPU utilization of the Web server over several
periods of time. The time frame of the Web Server Monitor can be changed by selecting one of
the following options in the View Style pulldown menu: last 30 seconds, last 30 minutes, last
24 hours, or last 30 days.

178

SonicOS 5.8.1 Administrator Guide

System > Diagnostics

User Monitor
The User Monitor tool displays details on all user connections to the SonicWALL security
appliance.

The following options can be configured to modify the User Monitor display:
•

View Style – Select whether to display the Last 30 Minutes, the Last 24 Hours, or the
Last 30 Days.

•

Vertical Axis – Select whether the scale of the vertial axis should be set for 500 Users or
50 Users.

SonicOS 5.8.1 Administrator Guide

179

System > Restart

•

Show – Select whether to show All Users, Remote Users with GVC/L2TP Client, or
Users Authenticated by Web Login.

System > Restart
The SonicWALL security appliance can be restarted from the Web Management interface. Click
System > Restart to display the Restart page.

Click Restart... and then click Yes to confirm the restart.
The SonicWALL security appliance takes approximately 60 seconds to restart, and the yellow
Test light is lit during the restart. During the restart time, Internet access is momentarily
interrupted on the LAN.

180

SonicOS 5.8.1 Administrator Guide

PART 4
Part 4:

SonicOS 5.8.1 Administrator Guide

Network

181

182

SonicOS 5.8.1 Administrator Guide

CHAPTER 15
Chapter 15:

Configuring Interfaces

Network > Interfaces
The Network > Interfaces page includes interface objects that are directly linked to physical
interfaces. The SonicOS Enhanced scheme of interface addressing works in conjunction with
network zones and address objects. The interfaces displayed on the Network > Interfaces page
depend on the type of SonicWALL appliance. The page pictured below is for SonicWALL TZ
100 or 200 Wireless-N appliances.

This chapter contains the following sections:
•

“Setup Wizard” on page 184

•

“Interface Settings” on page 184

•

“Interface Traffic Statistics” on page 185

•

“Physical and Virtual Interfaces” on page 185

•

“SonicOS Enhanced Secure Objects” on page 187

•

“Transparent Mode” on page 188

•

“Layer 2 Bridge Mode” on page 188

SonicOS 5.8.1 Administrator Guide

183

Network > Interfaces

•

“IPS Sniffer Mode” on page 214

•

“Configuring Interfaces” on page 219

•

“Configuring Layer 2 Bridge Mode” on page 247

•

“Configuring IPS Sniffer Mode” on page 258

•

“Configuring Wire Mode” on page 262

Setup Wizard
The Setup Wizard button accesses the Setup Wizard. The Setup Wizard walks you through
the configuration of the SonicWALL security appliance for Internet connectivity. For Setup
Wizard instructions, see “Wizards > Setup Wizard” on page 1397.

Interface Settings
The Interface Settings table lists the following information for each interface:

•

Name - listed as X0 through X8 and W0, depending on your SonicWALL security appliance
model.

Note

The X0 and X1 gigabit interfaces are for LAN and WAN, respectively. On the TZ
210 Series, X0 and X1 are the only gigabit interfaces. X2 is the only gigabit
interface for the NSA 240.

•

Zone - LAN, DMZ, WAN, and WLAN are listed by default. As zones are configured, the
names are listed in this column.

•

IP Address - IP address assigned to the interface.

•

Subnet Mask - the network mask assigned to the subnet.

•

IP Assignment - the main page displays one of the following types of IP assignments,
based on the zone type of the interfaces:
– Non-WAN: Static, Transparent, or Layer 2 Bridged Mode.
– WAN: Static, DHCP, PPPoE, PPTP, or L2TP.

184

•

Status - the link status and speed.

•

Comment - any user-defined comments.

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

•

Configure - click the Configure icon
to display the Edit Interface window, which
allows you to configure the settings for the specified interface.

Interface Traffic Statistics
The Interface Traffic Statistics table lists received and transmitted information for all
configured interfaces.

The following information is displayed for all SonicWALL security appliance interfaces:
•

Rx Unicast Packets - indicates the number of point-to-point communications received by
the interface.

•

Rx Broadcast Packets - indicates the number of multipoint communications received by
the interface.

•

RX Bytes - indicates the volume of data, in bytes, received by the interface.

•

Tx Unicast Packets - indicates the number of point-to-point communications transmitted
by the interface.

•

Tx Broadcast Bytes - indicates the number of mutlipoint communications transmitted by
the interface.

•

Tx Bytes - indicates the volume of data, in bytes, transmitted by the interface.

•

Skipped DPI - indicates the number of packet that bypassed DPI inspection.

To clear the current statistics, click the Clear Statistics button at the top right of the
Network > Interfaces page.

Physical and Virtual Interfaces
Interfaces in SonicOS can be:
•

Physical interfaces – Physical interfaces are bound to a single port

•

Virtual interfaces – Virtual interfaces are assigned as subinterfaces to a physical interface
and allow the physical interface to carry traffic assigned to multiple interfaces.

•

PortShield interfaces – PortShield interfaces are a feature of the SonicWALL TZ series
and SonicWALL NSA 240. Any number of the LAN ports on these appliances can be
combined into a single PortShield interface.

SonicOS 5.8.1 Administrator Guide

185

Network > Interfaces

Physical Interfaces
Physical interfaces must be assigned to a zone to allow for configuration of Access Rules to
govern inbound and outbound traffic. Security zones are bound to each physical interface
where it acts as a conduit for inbound and outbound traffic. If there is no interface, traffic cannot
access the zone or exit the zone.
For more information on zones, see “Network > Zones” on page 283.

Virtual Interfaces (VLAN)
Supported on SonicWALL NSA series security appliances, virtual Interfaces are subinterfaces
assigned to a physical interface. Virtual interfaces allow you to have more than one interface
on one physical connection.
Virtual interfaces provide many of the same features as physical interfaces, including zone
assignment, DHCP Server, and NAT and Access Rule controls.
Virtual Local Area Networks (VLANs) can be described as a ‘tag-based LAN multiplexing
technology’ because through the use of IP header tagging, VLANs can simulate multiple LAN’s
within a single physical LAN. Just as two physically distinct, disconnected LAN’s are wholly
separate from one another, so too are two different VLANs, however the two VLANs can exist
on the very same wire. VLANs require VLAN aware networking devices to offer this kind of
virtualization – switches, routers and firewalls that have the ability to recognize, process,
remove and insert VLAN tags in accordance with the network’s design and security policies.
VLANs are useful for a number of different reasons, most of which are predicated on the VLANs
ability to provide logical rather than physical broadcast domain, or LAN boundaries. This works
both to segment larger physical LAN’s into smaller virtual LAN’s, as well as to bring physically
disparate LAN’s together into a logically contiguous virtual LAN. The benefits of this include:

186

•

Increased performance – Creating smaller, logically partitioned broadcast domains
decreases overall network utilization, sending broadcasts only where they need to be sent,
thus leaving more available bandwidth for application traffic.

•

Decreased costs – Historically, broadcast segmentation was performed with routers,
requiring additional hardware and configuration. With VLANs, the functional role of the
router is reversed – rather than being used for the purposes of inhibiting communications,
it is used to facilitate communications between separate VLANs as needed.

•

Virtual workgroups – Workgroups are logical units that commonly share information, such
as a Marketing department or an Engineering department. For reasons of efficiency,
broadcast domain boundaries should be created such that they align with these functional
workgroups, but that is not always possible: Engineering and Marketing users might be
commingled, sharing the same floor (and the same workgroup switch) in a building, or just
the opposite – the Engineering team might be spread across an entire campus. Attempting
to solve this with complex feats of wiring can be expensive and impossible to maintain with
constant adds and moves. VLANs allow for switches to be quickly reconfigured so that
logical network alignment can remain consistent with workgroup requirements.

•

Security – Hosts on one VLAN cannot communicate with hosts on another VLAN unless
some networking device facilitates communication between them.

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

Subinterfaces
VLAN support on SonicOS Enhanced is achieved by means of subinterfaces, which are logical
interfaces nested beneath a physical interface. Every unique VLAN ID requires its own
subinterface. For reasons of security and control, SonicOS does not participate in any VLAN
trunking protocols, but instead requires that each VLAN that is to be supported be configured
and assigned appropriate security characteristics.

Note

Dynamic VLAN Trunking protocols, such as VTP (VLAN Trunking Protocol) or GVRP
(Generic VLAN Registration Protocol), should not be used on trunk links from other devices
connected to the SonicWALL.
Trunk links from VLAN capable switches are supported by declaring the relevant VLAN ID’s as
a subinterface on the SonicWALL, and configuring them in much the same way that a physical
interface would be configured. In other words, only those VLANs which are defined as
subinterfaces will be handled by the SonicWALL, the rest will be discarded as uninteresting.
This method also allows the parent physical interface on the SonicWALL to which a trunk link
is connected to operate as a conventional interface, providing support for any native (untagged)
VLAN traffic that might also exist on the same link. Alternatively, the parent interface may
remain in an ‘unassigned’ state.
VLAN subinterfaces have most of the capabilities and characteristics of a physical interface,
including zone assignability, security services, GroupVPN, DHCP server, IP Helper, routing,
and full NAT policy and Access Rule controls. Features excluded from VLAN subinterfaces at
this time are WAN dynamic client support and multicast support. The following table lists the
maximum number of subinterfaces supported on each platform.
Platform

Number of Subinterfaces
Supported

NSA 240

10

NSA 2400

25

NSA 3500

50

NSA 4500

200

NSA E5000

300

NSA E5500

400

NSA E6500

500

NSA E7500

512

SonicOS Enhanced Secure Objects
The SonicOS Enhanced scheme of interface addressing works in conjunction with network
zones and address objects. This structure is based on secure objects, which are utilized by
rules and policies within SonicOS Enhanced.
Secured objects include interface objects that are directly linked to physical interfaces and
managed in the Network > Interfaces page. Address objects are defined in the Network >
Address Objects page. Service and Scheduling objects are defined in the Firewall section of
the SonicWALL security appliance Management Interface, and User objects are defined in the
Users section of the SonicWALL security appliance Management Interface.

SonicOS 5.8.1 Administrator Guide

187

Network > Interfaces

Zones are the hierarchical apex of SonicOS Enhanced’s secure objects architecture. SonicOS
Enhanced includes predefined zones as well as allow you to define your own zones. Predefined
zones include LAN, DMZ, WAN, WLAN, and Custom. Zones can include multiple interfaces,
however, the WAN zone is restricted to a total of two interfaces. Within the WAN zone, either
one or both WAN interfaces can be actively passing traffic depending on the WAN Failover and
Load Balancing configuration on the Network > WAN Failover & LB page.
For more information on WAN Failover and Load Balancing on the SonicWALL security
appliance, see “Network > Failover & Load Balancing” on page 275.
At the zone configuration level, the Allow Interface Trust setting for zones automates the
processes involved in creating a permissive intra-zone Access Rule. It creates a
comprehensive Address Object for the entire zone and a inclusively permissive Access Rule
from zone address to zone addresses.

Transparent Mode
Transparent Mode in SonicOS Enhanced uses interfaces as the top level of the management
hierarchy. Transparent Mode supports unique addressing and interface routing.

Layer 2 Bridge Mode
SonicOS Enhanced firmware versions 4.0 and higher includes L2 (Layer 2) Bridge Mode, a
new method of unobtrusively integrating a SonicWALL security appliance into any Ethernet
network. L2 Bridge Mode is ostensibly similar to SonicOS Enhanced’s Transparent Mode in
that it enables a SonicWALL security appliance to share a common subnet across two
interfaces, and to perform stateful and deep-packet inspection on all traversing IP traffic, but it
is functionally more versatile.
In particular, L2 Bridge Mode employs a secure learning bridge architecture, enabling it to pass
and inspect traffic types that cannot be handled by many other methods of transparent security
appliance integration. Using L2 Bridge Mode, a SonicWALL security appliance can be nondisruptively added to any Ethernet network to provide in-line deep-packet inspection for all
traversing IPv4 TCP and UDP traffic. In this scenario the SonicWALL UTM appliance is not
used for security enforcement, but instead for bidirectional scanning, blocking viruses and
spyware, and stopping intrusion attempts.
Unlike other transparent solutions, L2 Bridge Mode can pass all traffic types, including IEEE
802.1Q VLANs (on SonicWALL NSA appliances), Spanning Tree Protocol, multicast,
broadcast, and IPv6, ensuring that all network communications will continue uninterrupted.
Another aspect of the versatility of L2 Bridge Mode is that you can use it to configure IPS
Sniffer Mode. Supported on SonicWALL NSA series appliances, IPS Sniffer Mode uses a
single interface of a Bridge-Pair to monitor network traffic from a mirrored port on a switch. IPS
Sniffer Mode provides intrusion detection, but cannot block malicious traffic because the
SonicWALL security appliance is not connected inline with the traffic flow. For more information
about IPS Sniffer Mode, see “IPS Sniffer Mode” on page 214.
L2 Bridge Mode provides an ideal solution for networks that already have an existing firewall,
and do not have immediate plans to replace their existing firewall but wish to add the security
of SonicWALL Unified Threat Management (UTM) deep-packet inspection, such as Intrusion
Prevention Services, Gateway Anti Virus, and Gateway Anti Spyware. If you do not have
SonicWALL UTM security services subscriptions, you may sign up for free trials from the
Security Service > Summary page of your SonicWALL.

188

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

You can also use L2 Bridge Mode in a High Availability deployment. This scenario is explained
in the “Layer 2 Bridge Mode with High Availability” section on page 209.
See the following sections:
•

“Key Features of SonicOS Enhanced Layer 2 Bridge Mode” on page 189

•

“Key Concepts to Configuring L2 Bridge Mode and Transparent Mode” on page 190

•

“Comparing L2 Bridge Mode to Transparent Mode” on page 192

•

“L2 Bridge Path Determination” on page 200

•

“L2 Bridge Interface Zone Selection” on page 201

•

“Sample Topologies” on page 203

Key Features of SonicOS Enhanced Layer 2 Bridge Mode
The following table outlines the benefits of each key feature of layer 2 bridge mode:
Feature

Benefit

L2 Bridging with Deep Packet
Inspection

This method of transparent operation means that a
SonicWALL security appliance can be added to any
network without the need for readdressing or
reconfiguration, enabling the addition of deep-packet
inspection security services with no disruption to
existing network designs. Developed with connectivity
in mind as much as security, L2 Bridge Mode can pass
all Ethernet frame types, ensuring seamless
integration.

Secure Learning Bridge Architecture True L2 behavior means that all allowed traffic flows
natively through the L2 Bridge. Whereas other methods
of transparent operation rely on ARP and route
manipulation to achieve transparency, which frequently
proves problematic, L2 Bridge Mode dynamically
learns the topology of the network to determine optimal
traffic paths.
Universal Ethernet Frame-Type
Support

All Ethernet traffic can be passed across an L2 Bridge,
meaning that all network communications will continue
uninterrupted. While many other methods of
transparent operation will only support IPv4 traffic, L2
Bridge Mode will inspect all IPv4 traffic, and will pass
(or block, if desired) all other traffic, including LLC, all
Ethertypes, and even proprietary frame formats.

SonicOS 5.8.1 Administrator Guide

189

Network > Interfaces

Feature

Benefit

Mixed-Mode Operation

L2 Bridge Mode can concurrently provide L2 Bridging
and conventional security appliance services, such as
routing, NAT, VPN, and wireless operations. This
means it can be used as an L2 Bridge for one segment
of the network, while providing a complete set of
security services to the remainder of the network. This
also allows for the introduction of the SonicWALL
security appliance as a pure L2 bridge, with a smooth
migration path to full security services operation.

Wireless Layer 2 Bridging

Use a single IP subnet across multiple zone types,
including LAN, WLAN, DMZ, or custom zones. This
feature allows wireless and wired clients to seamlessly
share the same network resources, including DHCP
addresses.The Layer 2 protocol can run between
paired interfaces, allowing multiple traffic types to
traverse the bridge, including broadcast and non-ip
packets.

Key Concepts to Configuring L2 Bridge Mode and Transparent Mode
The following terms will be used when referring to the operation and configuration of L2 Bridge
Mode:
•

L2 Bridge Mode – A method of configuring SonicWALL security appliance, which enables
the SonicWALL to be inserted inline into an existing network with absolute transparency,
beyond even that provided by Transparent Mode. Layer 2 Bridge Mode also refers to the
IP Assignment configuration that is selected for Secondary Bridge Interfaces that are
placed into a Bridge-Pair.

•

Transparent Mode – A method of configuring a SonicWALL security appliance that allows
the SonicWALL to be inserted into an existing network without the need for IP
reconfiguration by spanning a single IP subnet across two or more interfaces through the
use of automatically applied ARP and routing logic.

•

IP Assignment – When configuring a Trusted (LAN) or Public (DMZ) interface, the IP
Assignment for the interface can either be:
– Static – The IP address for the interface is manually entered.
– Transparent Mode – The IP address(es) for the interface is assigned using an Address

Object (Host, Range, or Group) that falls within the WAN Primary IP subnet, effectively
spanning the subnet from the WAN interface to the assigned interface.
– Layer 2 Bridge Mode – An interface placed in this mode becomes the Secondary

Bridge Interface to the Primary Bridge Interface to which it is paired. The resulting
Bridge-Pair will then behave like a two-port learning bridge with full L2 transparency,
and all IP traffic that passes through will be subjected to full stateful failover and deep
packet inspection.
•

190

Bridge-Pair – The logical interface set composed of a Primary Bridge Interface and a
Secondary Bridge Interface. The terms primary and secondary do not imply any inherent
level of operational dominance or subordination; both interfaces continue to be treated
according to their zone type, and to pass IP traffic according to their configured Access
Rules. Non-IPv4 traffic across the Bridge-Pair is controlled by the Block all non-IPv4 traffic
setting on the Secondary Bridge Interface. A system may support as many Bridge Pairs as
it has interface pairs available. In other words, the maximum number of Bridge-Pairs is
equal to ½ the number of physical interfaces on the platform. Membership in a Bridge-Pair

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

does not preclude an interface from conventional behavior; for example, if X1 is configured
as a Primary Bridge Interface paired to X3 as a Secondary Bridge Interface, X1 can
simultaneously operate in its traditional role as the Primary WAN, performing NAT for
Internet-bound traffic through the Auto-added X1 Default NAT Policy.
•

Primary Bridge Interface – A designation that is assigned to an interface once a
Secondary Bridge Interface has been paired to it. A Primary Bridge Interface can belong to
an Untrusted (WAN), Trusted (LAN), or Public (DMZ) zone.

•

Secondary Bridge Interface – A designation that is assigned to an interface whose IP
Assignment has been configured for Layer 2 Bridge Mode. A Secondary Bridge Interface
can belong to a Trusted (LAN), or Public (DMZ) zone.

•

Bridge Management Address – The address of the Primary Bridge Interface is shared by
both interfaces of the Bridge-Pair. If the Primary Bridge Interface also happens to be the
Primary WAN interface, it is this address that is uses for outbound communications by the
SonicWALL, such as NTP, and License Manager updates. Hosts that are connected to
either segment of the Bridge-Pair may also use the Bridge Management Address as their
gateway, as will be common in Mixed-Mode deployments.

•

Bridge-Partner – The term used to refer to the ‘other’ member of a Bridge-Pair.

•

Non-IPv4 Traffic - SonicOS Enhanced supports the following IP protocol types: ICMP (1),
IGMP (2), TCP (6), UDP (17), GRE (47), ESP (50), AH (51), EIGRP (88), OSPF (89), PIMSM (103), L2TP (115). More esoteric IP types, such as Combat Radio Transport Protocol
(126), are not natively handled by the SonicWALL, nor are non-IPv4 traffic types such as
IPX or (currently) IPv6. L2 Bridge Mode can be configured to either pass or drop Non-IPv4
traffic.

•

Captive-Bridge Mode – This optional mode of L2 Bridge operation prevents traffic that has
entered an L2 bridge from being forwarded to a non-Bridge-Pair interface. By default, L2
Bridge logic will forward traffic that has entered the L2 Bridge to its destination along the
most optimal path as determined by ARP and routing tables. In some cases, the most
optimal path might involve routing or NATing to a non-Bridge-Pair interface. Activating
Captive-Bridge mode ensures that traffic which enters an L2 Bridge exits the L2 Bridge
rather than taking its most logically optimal path. In general, this mode of operation is only
required in complex networks with redundant paths, where strict path adherence is
required. Captive-Bridge Mode is enabled by selecting the Never route traffic on this
bridge-pair checkbox on the Edit Interface window.

•

Pure L2 Bridge Topology – Refers to deployments where the SonicWALL will be used
strictly in L2 Bridge Mode for the purposes of providing in-line security to a network. This
means that all traffic entering one side of the Bridge-Pair will be bound for the other side,
and will not be routed/NATed through a different interface. This will be common in cases
where there is an existing perimeter security appliance, or where in-line security is desired
along some path (for example, inter-departmentally, or on a trunked link between two
switches) of an existing network. Pure L2 Bridge Topology is not a functional limitation, but
rather a topological description of a common deployment in heterogeneous environments.

•

Mixed-Mode Topology – Refers to deployments where the Bridge-Pair will not will not be
the only point of ingress/egress through the SonicWALL. This means that traffic entering
one side of the Bridge-Pair may be destined to be routed/NATed through a different
interface. This will be common when the SonicWALL is simultaneously used to provide
security to one or more Bridge-Pair while also providing:
– Perimeter security, such as WAN connectivity, to hosts on the Bridge-Pair or on other

interfaces.
– Firewall and Security services to additional segments, such as Trusted (LAN) or Public

(DMZ) interface, where communications will occur between hosts on those segments
and hosts on the Bridge-Pair.

SonicOS 5.8.1 Administrator Guide

191

Network > Interfaces

– Wireless services with SonicPoints, where communications will occur between wireless

clients and hosts on the Bridge-Pair.

Comparing L2 Bridge Mode to Transparent Mode
This comparison of L2 Bridge Mode to Transparent Mode contains the following sections:
•

“ARP in Transparent Mode” on page 192

•

“VLAN Support in Transparent Mode” on page 193

•

“Multiple Subnets in Transparent Mode” on page 193

•

“Non-IPv4 Traffic in Transparent Mode” on page 193

•

“Simple Transparent Mode Topology” on page 194

•

“ARP in L2 Bridge Mode” on page 194

•

“VLAN Support in L2 Bridge Mode” on page 195

•

“L2 Bridge IP Packet Path” on page 195

•

“Multiple Subnets in L2 Bridge Mode” on page 197

•

“Non-IPv4 Traffic in L2 Bridge Mode” on page 197

•

“Comparison of L2 Bridge Mode to Transparent Mode” on page 197

•

“Benefits of Transparent Mode over L2 Bridge Mode” on page 199

•

“Comparing L2 Bridge Mode to the CSM Appliance” on page 199

While Transparent Mode allows a security appliance running SonicOS Enhanced to be
introduced into an existing network without the need for re-addressing, it presents a certain
level of disruptiveness, particularly with regard to ARP, VLAN support, multiple subnets, and
non-IPv4 traffic types. Consider the diagram below, in a scenario where a Transparent Mode
SonicWALL appliance has just been added to the network with a goal of minimally disruptive
integration, particularly:
•

Negligible or no unscheduled downtime

•

No need to re-address any portion of the network

•

No need reconfigure or otherwise modify the gateway router (as is common when the router
is owned by the ISP)

ARP in Transparent Mode
ARP – Address Resolution Protocol (the mechanism by which unique hardware addresses on
network interface cards are associated to IP addresses) is proxied in Transparent Mode. If the
Workstation on Server on the left had previously resolved the Router (192.168.0.1) to its MAC
address 00:99:10:10:10:10, this cached ARP entry would have to be cleared before these hosts
could communicate through the SonicWALL. This is because the SonicWALL proxies (or
answers on behalf of) the gateway’s IP (192.168.0.1) for hosts connected to interfaces
operating in Transparent Mode. So when the Workstation at the left attempts to resolve
192.168.0.1, the ARP request it sends is responded to by the SonicWALL with its own X0 MAC
address (00:06:B1:10:10:10).
The SonicWALL also proxy ARPs the IP addresses specified in the Transparent Range
(192.168.0.100 to 192.168.0.250) assigned to an interface in Transparent Mode for ARP
requests received on the X1 (Primary WAN) interface. If the Router had previously resolved the
Server (192.168.0.100) to its MAC address 00:AA:BB:CC:DD:EE, this cached ARP entry would
have to be cleared before the router could communicate with the host through the SonicWALL.
This typically requires a flushing of the router’s ARP cache either from its management

192

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

interface or through a reboot. Once the router’s ARP cache is cleared, it can then send a new
ARP request for 192.168.0.100, to which the SonicWALL will respond with its X1 MAC
00:06:B1:10:10:11.

VLAN Support in Transparent Mode
While the network depicted in the above diagram is simple, it is not uncommon for larger
networks to use VLANs for segmentation of traffic. If this was such a network, where the link
between the switch and the router was a VLAN trunk, a Transparent Mode SonicWALL would
have been able to terminate the VLANs to subinterfaces on either side of the link, but it would
have required unique addressing; that is, non-Transparent Mode operation requiring readdressing on at least one side. This is because only the Primary WAN interface can be used
as the source for Transparent Mode address space.

Multiple Subnets in Transparent Mode
It is also common for larger networks to employ multiple subnets, be they on a single wire, on
separate VLANs, multiple wires, or some combination. While Transparent Mode is capable of
supporting multiple subnets through the use of Static ARP and Route entries, as the Technote
http://www.sonicwall.com/us/support/2134_3468.html describes, it is not an effortless process.

Non-IPv4 Traffic in Transparent Mode
Transparent Mode will drop (and generally log) all non-IPv4 traffic, precluding it from passing
other traffic types, such as IPX, or unhandled IP types.
L2 Bridge Mode addresses these common Transparent Mode deployment issues and is
described in the following section.

SonicOS 5.8.1 Administrator Guide

193

Network > Interfaces

Simple Transparent Mode Topology
SonicWALL Firewall Transparent Mode

WorkStation
IP=192.168.0.200/24
GW=192.168.0.1
MAC=00:11:22:33:44:55

Server
IP=192.168.0.200/24
GW=192.168.0.1
MAC=00:AA:BB:CC:DD:EE

Switch

LAN 192.168.0.x/24
Note: Hosts on this
segment resolve
192.168.0.1 to
00:06:B1:10:10:10:10

X0 (LAN)
IP= Transparent Mode
(Range 192.168.0.100 to 192.168.0.250)
MAC=00:06:B1:10:10:10

pc card
signal
link/act

lan wan opt

1

2

3

4

5

6
link/spd
activity

NSA 240

X1 (WAN)
IP= 192.168.0.12/24
MAC= 00:06:B1:10:10:11
GW= 192.168.0.1

Internet

Router
E0 (Internal)
IP= 192.168.0.1/24
MAC= 00:99:10:10:10:10
S0 (External)= ISP Assigned

Note: The Router
resolves all IPs
192.168.0.100-192.168.0.250
to 00:06:B1:10:10:11

ARP in L2 Bridge Mode
L2 Bridge Mode employs a learning bridge design where it will dynamically determine which
hosts are on which interface of an L2 Bridge (referred to as a Bridge-Pair). ARP is passed
through natively, meaning that a host communicating across an L2 Bridge will see the actual
host MAC addresses of their peers. For example, the Workstation communicating with the
Router (192.168.0.1) will see the router as 00:99:10:10:10:10, and the Router will see the
Workstation (192.168.0.100) as 00:AA:BB:CC:DD:EE.
This behavior allows for a SonicWALL operating in L2 Bridge Mode to be introduced into an
existing network with no disruption to most network communications other than that caused by
the momentary discontinuity of the physical insertion.
Please note that stream-based TCP protocols communications (for example, an FTP session
between a client and a server) will need to be re-established upon the insertion of an L2 Bridge
Mode SonicWALL. This is by design so as to maintain the security afforded by stateful packet
inspection (SPI); since the SPI engine can not have knowledge of the TCP connections which
pre-existed it, it will drop these established packets with a log event such as TCP packet
received on non-existent/closed connection; TCP packet dropped.

194

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

VLAN Support in L2 Bridge Mode
On SonicWALL NSA series appliances, L2 Bridge Mode provides fine control over 802.1Q
VLAN traffic traversing an L2 Bridge. The default handling of VLANs is to allow and preserve
all 802.1Q VLAN tags as they pass through an L2 Bridge, while still applying all firewall rules,
and stateful and deep-packet inspection to the encapsulated traffic. It is further possible to
specify white/black lists for allowed/disallowed VLAN IDs through the L2 Bridge.
This allows a SonicWALL operating in L2 Bridge Mode to be inserted, for example, inline into
a VLAN trunk carrying any number of VLANs, and to provide full security services to all IPv4
traffic traversing the VLAN without the need for explicit configuration of any of the VLAN IDs or
subnets. Firewall Access Rules can also, optionally, be applied to all VLAN traffic passing
through the L2 Bridge Mode because of the method of handling VLAN traffic.

L2 Bridge IP Packet Path

The following sequence of events describes the above flow diagram:
1.

802.1Q encapsulated frame enters an L2 Bridge interface (this first step, the next step, and
the final step apply only to 802.1Q VLAN traffic, supported on SonicWALL NSA series
appliances).

2.

The 802.1Q VLAN ID is checked against the VLAN ID white/black list:
– If the VLAN ID is disallowed, the packet is dropped and logged.

SonicOS 5.8.1 Administrator Guide

195

Network > Interfaces

– If the VLAN ID is allowed, the packet is de-capsulated, the VLAN ID is stored, and the

inner packet (including the IP header) is passed through the full packet handler.
3.

Since any number of subnets is supported by L2 Bridging, no source IP spoof checking is
performed on the source IP of the packet. It is possible to configure L2 Bridges to only
support a certain subnet or subnets using Firewall Access Rules.

4.

SYN Flood checking is performed.

5.

A destination route lookup is performed to the destination zone, so that the appropriate
Firewall Access rule can be applied. Any zone is a valid destination, including the same
zone as the source zone (e.g. LAN to LAN), the Untrusted zone (WAN), the Encrypted
(VPN), Wireless (WLAN), Multicast, or custom zones of any type.

6.

A NAT lookup is performed and applied, as needed.
– In general, the destination for packets entering an L2 Bridge will be the Bridge-Partner

interface (that is, the other side of the bridge). In these cases, no translation will be
performed.
– In cases where the L2 Bridge Management Address is the gateway, as will sometimes

be the case in Mixed-Mode topologies, then NAT will be applied as need (see the L2
Bridge Path Determination section for more details).
7.

Firewall Access Rules are applied to the packet. For example, on SonicWALL NSA series
appliances, the following packet decode shows an ICMP packet bearing VLAN ID 10,
source IP address 110.110.110.110 destined for IP address 4.2.2.1.

It is possible to construct a Firewall Access Rule to control any IP packet, independent of
its VLAN membership, by any of its IP elements, such as source IP, destination IP, or
service type. If the packet is disallowed, it will be dropped and logged. If the packet is
allowed, it will continue.
8.

A connection cache entry is made for the packet, and required NAT translations (if any) are
performed.

9.

Stateful packet inspection and transformations are performed for TCP, VoIP, FTP, MSN,
Oracle, RTSP and other media streams, PPTP and L2TP. If the packet is disallowed, it will
be dropped and logged. If the packet is allowed, it will continue.

10. Deep packet inspection, including GAV, IPS, Anti-Spyware, CFS and email-filtering is

performed. If the packet is disallowed, it will be dropped and logged. If the packet is
allowed, it will continue. Client notification will be performed as configured.
11. If the packet is destined for the Encrypted zone (VPN), the Untrusted zone (WAN), or some

other connected interface (the last two of which might be the case in Mixed-Mode
Topologies) the packet will be sent via the appropriate path.
12. If the packet is not destined for the VPN/WAN/Connected interface, the stored VLAN tag

will be restored, and the packet (again bearing the original VLAN tag) will be sent out the
Bridge-Partner interface.

196

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

Multiple Subnets in L2 Bridge Mode
L2 Bridge Mode is capable of handling any number of subnets across the bridge, as described
above. The default behavior is to allow all subnets, but Access Rules can be applied to control
traffic as needed.

Non-IPv4 Traffic in L2 Bridge Mode
Unsupported traffic will, by default, be passed from one L2 Bridge interface to the BridgePartner interface. This allows the SonicWALL to pass other traffic types, including LLC packets
such as Spanning Tree, other EtherTypes, such as MPLS label switched packets (EtherType
0x8847), Appletalk (EtherType 0x809b), and the ever-popular Banyan Vines (EtherType
0xbad). These non-IPv4 packets will only be passed across the Bridge, they will not be
inspected or controlled by the packet handler. If these traffic types are not needed or desired,
the bridging behavior can be changed by enabling the Block all non-IPv4 traffic option on the
Secondary Bridge Interface configuration page.

Comparison of L2 Bridge Mode to Transparent Mode
Attribute

Layer 2 Bridge Mode

Transparent Mode

Layer of Operation

Layer 2 (MAC)

Layer 3 (IP)

ARP behavior

ARP (Address Resolution Protocol)
ARP is proxied by the interfaces operating
information is unaltered. MAC addresses
in Transparent Mode.
natively traverse the L2 bridge. Packets that
are destined for SonicWALL’s MAC
addresses will be processed, others will be
passed, and the source and destinations
will be learned and cached.

Path determination

Hosts on either side of a Bridge-Pair are
dynamically learned. There is no need to
declare interface affinities.

The Primary WAN interface is always the
master ingress/egress point for
Transparent mode traffic, and for subnet
space determination. Hosts transparently
sharing this subnet space must be
explicitly declared through the use of
Address Object assignments.

Maximum interfaces

Two interfaces, a Primary Bridge Interface
and a Secondary Bridge Interface.

Two or more interfaces. The master
interface is always the Primary WAN.
There can be as many transparent
subordinate interfaces as there are
interfaces available.

Maximum pairings

The maximum number of Bridge-Pairs
allowed is limited only by available physical
interfaces. This can be described as “many
One-to-One pairings”.

Transparent Mode only allows the Primary
WAN subnet to be spanned to other
interfaces, although it allows for multiple
interfaces to simultaneously operate as
transparent partners to the Primary WAN.
This can be described as “a single One-toOne” or “a single One-to-Many pairing”.

Zone restrictions

The Primary Bridge Interface can be
Untrusted, Trusted, or Public. The
Secondary Bridge Interface can be Trusted
or Public.

Interfaces in a Transparent Mode pair
must consist of one Untrusted interface
(the Primary WAN, as the master of the
pair’s subnet) and one or more Trusted/
Public interface (e.g. LAN or DMZ).

SonicOS 5.8.1 Administrator Guide

197

Network > Interfaces

Subnets supported

Any number of subnets is supported.
Firewall Access Rules can be written to
control traffic to/from any of the subnets as
needed.

In its default configuration, Transparent
Mode only supports a single subnet (that
which is assigned to, and spanned from
the Primary WAN). It is possible to
manually add support for additional
subnets through the use of ARP entries
and routes.

Non-IPv4 Traffic

All non-IPv4 traffic, by default, is bridged
from one Bridge-Pair interface to the
Bridge-Partner interface, unless disabled
on the Secondary Bridge Interface
configuration page. This includes IPv6
traffic, STP (Spanning Tree Protocol), and
unrecognized IP types.

Non IPv4 traffic is not handled by
Transparent Mode, and is dropped and
logged.

VLAN traffic

VLAN traffic is passed through the L2
VLAN subinterfaces can be created and
Bridge, and is fully inspected by the Stateful can be given Transparent Mode Address
Object assignments, but the VLANs will be
and Deep Packet Inspection engines.
terminated by the SonicWALL rather than
passed.

VLAN subinterfaces

VLAN subinterfaces can be configured on
Bridge-Pair interfaces, but they will be
passed through the bridge to the BridgePartner unless the destination IP address in
the VLAN frame matches the IP address of
the VLAN subinterface on the SonicWALL,
in which case it will be processed (e.g. as
management traffic).

PortShield interfaces

PortShield interfaces cannot be assigned to PortShield interfaces may be assigned a
either interface of an L2 Bridge Pair.
Transparent Mode range.

Dynamic addressing

Although a Primary Bridge Interface may be
assigned to the WAN zone, only static
addressing is allowable for Primary Bridge
Interfaces.

Although Transparent Mode employs the
Primary WAN as a master interface, only
static addressing is allowable for
Transparent Mode.

VPN support

VPN operation is supported with one
additional route configured. See the “VPN
Integration with Layer 2 Bridge Mode”
section on page 258 for details.

VPN operation is supported with no special
configuration requirements.

DHCP support

DHCP can be passed through a BridgePair.

Interfaces operating in Transparent Mode
can provide DHCP services, or they can
pass DHCP using IP Helper.

Routing and NAT

Traffic will be intelligently routed in/out of
the L2 Bridge-Pair from/to other paths. By
default, traffic will not be NATed from one
Bridge-Pair interface to the Bridge-Partner,
but it can be NATed to other paths, as
needed. Custom routes and NAT policies
can be added as needed.

Traffic will be intelligently routed from/to
other paths. By default, traffic will not be
NATed from/to the WAN to/from
Transparent Mode interface, but it can be
NATed to other paths, as needed. Custom
routes and NAT policies can be added as
needed.

198

SonicOS 5.8.1 Administrator Guide

VLAN subinterfaces can be assigned to
physical interfaces operating in
Transparent Mode, but their mode of
operation will be independent of their
parent. These VLAN subinterfaces can
also be given Transparent Mode Address
Object assignments, but in any event
VLAN subinterfaces will be terminated
rather than passed.

Network > Interfaces

Stateful Packet
Inspection

Full stateful packet inspection will be
applied to all IPv4 traffic traversing the L2
Bridge for all subnets, including VLAN traffic
on SonicWALL NSA series appliances.

Full stateful packet inspection will applied
to traffic from/to the subnets defined by
Transparent Mode Address Object
assignment.

Security services

All security services (GAV, IPS, Anti-Spy,
CFS) are fully supported. All regular IP
traffic, as well as all 802.1Q encapsulated
VLAN traffic.

All security services (GAV, IPS, Anti-Spy,
CFS) are fully supported from/to the
subnets defined by Transparent Mode
Address Object assignment.

Broadcast traffic

Broadcast traffic is passed from the
receiving Bridge-Pair interface to the
Bridge-Partner interface.

Broadcast traffic is dropped and logged,
with the possible exception of NetBIOS
which can be handled by IP Helper.

Multicast traffic

Multicast traffic is inspected and passed
across L2 Bridge-Pairs providing Multicast
has been activated on the Firewall >
Multicast page. It is not dependent upon
IGMP messaging, nor is it necessary to
enable multicast support on the individual
interfaces.

Multicast traffic, with IGMP dependency, is
inspected and passed by Transparent
Mode providing Multicast has been
activated on the Firewall > Multicast page,
and multicast support has been enabled on
the relevant interfaces.

Benefits of Transparent Mode over L2 Bridge Mode
The following are circumstances in which Transparent Mode might be preferable over L2 Bridge
Mode:
•

Two interfaces are the maximum allowed in an L2 Bridge Pair. If more than two interfaces
are required to operate on the same subnet, Transparent Mode should be considered.

•

PortShield interface may not operate within an L2 Bridge Pair. If PortShield interfaces are
required to operate on the same subnet, Transparent Mode should be considered.

•

VLAN subinterfaces, supported on SonicWALL NSA series appliances, may not operate
within an L2 Bridge Pair. If VLAN subinterfaces are required to operate on the same subnet,
Transparent Mode should be considered. It is, however, possible to configure a VLAN
subinterface on an interface that is part of a Bridge-Pair; the subinterface will simply
operate independently on the Bridge-Pair in every respect.

Comparing L2 Bridge Mode to the CSM Appliance
L2 Bridge Mode is more similar in function to the CSM than it is to Transparent Mode, but it
differs from the current CSM behavior in that it handles VLANs and non-IPv4 traffic types, which
the CSM does not. Future versions of the SonicOS CF Software for the CSM will likely adopt
the more versatile traffic handling capabilities of L2 Bridge Mode.

SonicOS 5.8.1 Administrator Guide

199

Network > Interfaces

L2 Bridge Path Determination
Packets received by the SonicWALL on Bridge-Pair interfaces must be forwarded along to the
appropriate and optimal path toward their destination, whether that path is the Bridge-Partner,
some other physical or sub interface, or a VPN tunnel. Similarly, packets arriving from other
paths (physical, virtual or VPN) bound for a host on a Bridge-Pair must be sent out over the
correct Bridge-Pair interface. The following summary describes, in order, the logic that is
applied to path determinations for these cases:
1.

If present, the most specific non-default route to the destination is chosen. This would
cover, for example:
a. A packet arriving on X3 (non-L2 Bridge LAN) destined for host 15.1.1.100 subnet,

where a route to the 15.1.1.0/24 subnet exists through 192.168.0.254 via the X0
(Secondary Bridge Interface, LAN) interface. The packet would be forwarded via X0 to
the destination MAC address of 192.168.0.254, with the destination IP address
15.1.1.100.
b. A packet arriving on X4 (Primary Bridge Interface, LAN) destined for host 10.0.1.100,

where a route to the 10.0.1.0/24 exists through 192.168.10.50 via the X5 (DMZ)
interface. The packet would be forwarded via X5 to the destination MAC address of
192.168.10.50, with the destination IP address 10.0.1.100.
2.

If no specific route to the destination exists, an ARP cache lookup is performed for the
destination IP address. A match will indicate the appropriate destination interface. This
would cover, for example:
a. A packet arriving on X3 (non-L2 Bridge LAN) destined for host 192.168.0.100 (residing

on L2 Primary Bridge Interface X2). The packet would be forwarded via X2 to the known
destination MAC and IP address of 192.168.0.100, as derived from the ARP cache.
b. A packet arriving on X4 (Primary Bridge Interface, LAN) destined for host 10.0.1.10

(residing on X5 – DMZ). The packet would be forwarded via X5 to the known destination
MAC and IP address of 10.0.1.10, as derived from the ARP cache.
3.

If no ARP entry is found:
a. If the packet arrives on a Bridge-Pair interface, it is sent to the Bridge-Partner interface.
b. If the packet arrives from some other path, the SonicWALL will send an ARP request

out both interfaces of the Bridge-Pair to determine on which segment the destination IP
resides.
In this last case, since the destination is unknown until after an ARP response is
received, the destination zone also remains unknown until that time. This precludes the
SonicWALL from being able to apply the appropriate Access Rule until after path
determination is completed. Upon completion, the correct Access Rule will be applied
to subsequent related traffic.
With regard to address translation (NAT) of traffic arriving on an L2 Bridge-Pair interface:
1.

If it is determined to be bound for the Bridge-Partner interface, no IP translation (NAT) will
be performed.

2.

If it is determined to be bound for a different path, appropriate NAT policies will apply:
a. If the path is another connected (local) interface, there will likely be no translation. That

is, it will effectively be routed as a result of hitting the last-resort Any->Original NAT
Policy.
b. IIf the path is determined to be via the WAN, then the default Auto-added [interface]

outbound NAT Policy for X1 WAN will apply, and the packet’s source will be translated
for delivery to the Internet. This is common in the case of Mixed-Mode topologies, such
as that depicted in the “Internal Security” section on page 208).

200

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

L2 Bridge Interface Zone Selection
Bridge-Pair interface zone assignment should be done according to your network’s traffic flow
requirements. Unlike Transparent Mode, which imposes a system of “more trusted to less
trusted” by requiring that the source interface be the Primary WAN, and the transparent
interface be Trusted or Public, L2 Bridge mode allows for greater control of operational levels
of trust. Specifically, L2 Bridge Mode allows for the Primary and Secondary Bridge Interfaces
to be assigned to the same or different zones (e.g. LAN+LAN, LAN+DMZ, WAN+CustomLAN,
etc.) This will affect not only the default Access Rules that are applied to the traffic, but also the
manner in which Deep Packet Inspection security services are applied to the traffic traversing
the bridge. Important areas to consider when choosing and configuring interfaces to use in a
Bridge-Pair are Security Services, Access Rules, and WAN connectivity:

Security Services Directionality
As it will be one of the primary employments of L2 Bridge mode, understanding the application
of security services is important to the proper zone selection for Bridge-Pair interfaces. Security
services applicability is based on the following criteria:
1.

The direction of the service:
– GAV is primarily an Inbound service, inspecting inbound HTTP, FTP, IMAP, SMTP,

POP3, and TCP Streams. It also has an additional Outbound element for SMTP.
– Anti Spyware is primarily Inbound, inspecting inbound HTTP, FTP, IMAP, SMTP, POP3

for the delivery (i.e. retrieval) of Spyware components as generally recognized by their
class IDs. It also has an additional Outbound component, where Outbound is used
relative to the directionality (namely, Outgoing) ascribed to it by the IPS signatures that
trigger the recognition of these Spyware components. The Outgoing classifier
(described in the table below) is used because these components are generally
retrieved by the client (e.g. LAN host) via HTTP from a Web-server on the Internet
(WAN host). Referring to the table below, that would be an Outgoing connection, and
requires a signature with an Outgoing directional classification.
– IPS has three directions: Incoming, Outgoing, and Bidirectional. Incoming and

Outgoing are described in the table below, and Bidirectional refers to all points of
intersection on the table.
– For additional accuracy, other elements are also considered, such as the state of the

connection (e.g. SYN or Established), and the source of the packet relative to the flow
(i.e. initiator or responder).
2.

The direction of the traffic. The direction of the traffic as it pertains to IPS is primarily
determined by the Source and Destination zone of the traffic flow. When a packet is
received by the SonicWALL, its source zone is generally immediately known, and its
destination zone is quickly determined by doing a route (or VPN) lookup.

SonicOS 5.8.1 Administrator Guide

201

Network > Interfaces

Based on the source and destination, the packet’s directionality is categorized as either
Incoming or Outgoing, (not to be confused with Inbound and Outbound) where the following
criteria is used to make the determination:
Dest
Src

Untrusted

Public

Wireless

Encrypted

Trusted

Multicast

Untrusted

Incoming

Incoming

Incoming

Incoming

Incoming

Incoming

Public

Outgoing

Outgoing

Outgoing

Incoming

Incoming

Incoming

Wireless

Outgoing

Outgoing

Trust

Trust

Trust

Incoming

Encrypted

Outgoing

Outgoing

Trust

Trust

Trust

Outgoing

Trusted

Outgoing

Outgoing

Trust

Trust

Trust

Outgoing

Table data is subject to change.
In addition to this categorization, packets traveling to/from zones with levels of additional
trust, which are inherently afforded heightened levels of security
(LAN|Wireless|Encrypted<-->LAN|Wireless|Encrypted) are given the special Trust
classification. Traffic with the Trust classification has all signatures applied (Incoming,
Outgoing, and Bidirectional).
3.

The direction of the signature. This pertains primarily to IPS, where each signature is
assigned a direction by SonicWALL’s signature development team. This is done as an
optimization to minimize false positives. Signature directions are:
– Incoming – Applies to Incoming and Trust. The majority of signatures are Incoming, and

they include all forms of application exploits and all enumeration and footprinting
attempts. Approximately 85% of signatures are Incoming.
– Outgoing – Applies to Outgoing and Trust. Examples of Outgoing signatures would

include IM and P2P login attempts, and responses to successfully launched exploits
(e.g. Attack Responses). Approximately 10% of signatures are Outgoing.
– Bidirectional – Applies to all. Examples of Bidirectional signatures would include IM file

transfers, various NetBIOS attacks (e.g. Sasser communications) and a variety of DoS
attacks (e.g. UDP/TCP traffic destined to port 0). Approximately 5% of signatures are
Bidirectional.
4.

202

Zone application. For a signature to be triggered, the desired security service must be
active on at least one of the zones it traverses. For example, a host on the Internet (X1,
WAN) accessing a Microsoft Terminal Server (on X3, Secondary Bridge Interface, LAN) will
trigger the Incoming signature “IPS Detection Alert: MISC MS Terminal server request, SID:
436, Priority: Low” if IPS is active on the WAN, the LAN, or both.

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

Access Rule Defaults
Default, zone-to-zone Access Rules. The default Access Rules should be considered, although
they can be modified as needed. The defaults are as follows:

WAN Connectivity
Internet (WAN) connectivity is required for stack communications, such as licensing, security
services signature downloads, NTP (time synchronization), and CFS (Content Filtering
Services). At present, these communications can only occur through the Primary WAN
interface. If you require these types of communication, the Primary WAN should have a path to
the Internet. Whether or not the Primary WAN is employed as part of a Bridge-Pair will not affect
its ability to provide these stack communications (for example on a PRO 4100, X0+X2 and
X3+X4 could be used to create two Bridge-Pairs separate of X1).

Note

If Internet connectivity is not available, licensing can be performed manually and signature
updates can also be performed manually (http://www.sonicwall.com/us/support/
2134_4170.html).

Sample Topologies
The following are sample topologies depicting common deployments. Inline Layer 2 Bridge
Mode represents the addition of a SonicWALL security appliance to provide UTM services in a
network where an existing firewall is in place. Perimeter Security represents the addition of a
SonicWALL security appliance in pure L2 Bridge mode to an existing network, where the
SonicWALL is placed near the perimeter of the network. Internal Security represents the full
integration of a SonicWALL security appliance in mixed-mode, where it provides simultaneous
L2 bridging, WLAN services, and NATed WAN access. Layer 2 Bridge Mode with High
Availability represents the mixed-mode scenario where the SonicWALL HA pair provide high
availability along with L2 bridging. Layer 2 Bridge Mode with SSL VPN represents the
scenario where a SonicWALL Aventail SSL VPN or SonicWALL SSL VPN Series appliance is
deployed in conjunction with L2 Bridge mode.

SonicOS 5.8.1 Administrator Guide

203

Network > Interfaces

See the following sections:
•

“Wireless Layer 2 Bridge” on page 204

•

“Inline Layer 2 Bridge Mode” on page 205

•

“Perimeter Security” on page 207

•

“Internal Security” on page 208

•

“Layer 2 Bridge Mode with High Availability” on page 209

•

“Layer 2 Bridge Mode with SSL VPN” on page 210

Wireless Layer 2 Bridge
In wireless mode, after bridging the wireless (WLAN) interface to a LAN or DMZ zone, the
WLAN zone becomes the secondary bridged interface, allowing wireless clients to share the
same subnet and DHCP pool as their wired counterparts

204

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

To configure a WLAN to LAN Layer 2 interface bridge:
Step 1

Navigate to the Network > Interfaces page in the SonicOS management interface.

Step 2

Click the Configure icon for the wireless interface you wish to bridge. The Edit Interface
window displays.

Step 3

Select Layer 2 Bridged Mode as the IP Assignment.

Note

Although a general rule is automatically created to allow traffic between the WLAN zone and
your choosen bridged interface, WLAN zone type security properties still apply. Any specific
rules must be manually added.

Step 4

Select the Interface which the WLAN should be Bridged To. In this instance, the X0 (default
LAN zone) is chosen.

Step 5

Configure the remaining options normally. For more information on configuring WLAN
interfaces, see the “Configuring Wireless Interfaces” section on page 223.

Inline Layer 2 Bridge Mode
This method is useful in networks where there is an existing firewall that will remain in place,
but you wish to utilize the SonicWALL’s UTM services without making major changes to the
network. By placing the SonicWALL in Layer 2 Bridge mode, the X0 and X1 interfaces become
part of the same broadcast domain/network (that of the X1 WAN interface).
This example refers to a SonicWALL UTM appliance installed in a Hewlitt Packard ProCurve
switching environment. SonicWALL is a member of HP’s ProCurve Alliance – more details can
be found at the following location:
http://h20195.www2.hp.com/v2/GetPDF.aspx/4AA1-9147ENUC.pdf

SonicOS 5.8.1 Administrator Guide

205

Network > Interfaces

HP’s ProCurve Manager Plus (PCM+) and HP Network Immunity Manager (NIM) server
software packages can be used to manage the switches as well as some aspects of the
SonicWALL UTM appliance.

HP HCM/
NIM + Server

ISP
Network Security Appliance

SonicWALL

E7500

Third-party Firewall

NSA Appliance

Router

HP ProCurve
Switch

Wireless
Client

Desktop
Client

File
Server

Email
Server

DMZ Connection
WAN Connection
LAN/L2B Mode Connection

To configure the SonicWALL appliance for this scenario, navigate to the Network > Interfaces
page and click on the configure icon for the X0 LAN interface. On the X0 Settings page, set the
IP Assignment to ‘Layer 2 Bridged Mode’ and set the Bridged To: interface to ‘X1’. Also make
sure that the interface is configured for HTTP and SNMP so it can be managed from the DMZ
by PCM+/NIM. Click OK to save and activate the change.

You will also need to make sure to modify the firewall access rules to allow traffic from the LAN
to WAN, and from the WAN to the LAN, otherwise traffic will not pass successfully. You may
also need to modify routing information on your firewall if your PCM+/NIM server is placed on
the DMZ.

206

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

Perimeter Security
The following diagram depicts a network where the SonicWALL is added to the perimeter for
the purpose of providing security services (the network may or may not have an existing firewall
between the SonicWALL and the router).
SonicWALL Firewall L2 Bridge Mode

WorkStation
IP=10.0.100.200/24
GW=10.0.100.1
MAC=00:11:55:66:77:88
Workgroup Switch
VLAN 100

X0 (LAN)
IP= Transparent Mode
(Range 192.168.0.100 to 192.168.0.250)
MAC=00:06:B1:10:10:10

Server
IP=10.0.100.100/24
GW=10.0.100.1
MAC=00:CC:AA:BB:EE:EE

pc card
signal
link/act

LAN 10.0.100.x/24

1

2

3

4

5

6
link/spd
activity

NSA 240

NSA 2400

Switch

VLAN Trunk
VID 100
VID 200
Default VLAN

WorkStation
IP=10.0.200.200/24
GW=10.0.200.1
MAC=00:11:22:33:44:55
Workgroup Switch
VLAN 200
Server
IP=10.0.200.100/24
GW=10.0.200.1
MAC=00:AA:BB:CC:DD:EE

lan wan opt

Internet

X1 (WAN)
IP= 192.168.0.12/24
MAC= 00:06:B1:10:10:11
GW= 192.168.0.1
L3 Switch

Router
Interface e0
IP= 10.0.0.1
Interface s0
ISP Assigned

VALN Interface 100
IP= 10.0.100.1
VLAN Interface 200
IP=10.0.200.1
Gateway 10.0.0.1
(default VLAN)

LAN 10.0.200.x/24

In this scenario, everything below the SonicWALL (the Primary Bridge Interface segment) will
generally be considered as having a lower level of trust than everything to the left of the
SonicWALL (the Secondary Bridge Interface segment). For that reason, it would be appropriate
to use X1 (Primary WAN) as the Primary Bridge Interface.
Traffic from hosts connected to the Secondary Bridge Interface (LAN) would be permitted
outbound through the SonicWALL to their gateways (VLAN interfaces on the L3 switch and then
through the router), while traffic from the Primary Bridge Interface (WAN) would, by default, not
be permitted inbound.
If there were public servers, for example, a mail and Web server, on the Secondary Bridge
Interface (LAN) segment, an Access Rule allowing WAN->LAN traffic for the appropriate IP
addresses and services could be added to allow inbound traffic to those servers.

SonicOS 5.8.1 Administrator Guide

207

Network > Interfaces

Internal Security
SonicWALL Firewall Mixed L2 Bridge Mode
KEY

File Server
IP=192.168.0.101/24
GW=192.168.0.1
MAC=00:CC:AA:BB:EE:EE

Mail & DHCP Server
IP=192.168.0.100/24
GW=192.168.0.1
MAC=00:AA:BB:CC:DD:EE

WorkStation
IP=192.168.0.200/24
GW=192.168.0.1
MAC=00:11:22:33:44:55

X1 (WAN)
IP= 10.0.012/24
MAC= 00:06:B1:10:10:11
GW= 10.0.0.1
X2 (LAN)
IP= 192.168.0.1/24
MAC= 00:06:B1:10:10:12

Workstation
IP=192.168.0.200/24
GW=192.168.0.1
MAC=00:11:55:66:77:88

X3 (WLAN)
IP= 172.16.31.1/24
MAC= 00:06:B1:10:10:13

LAN 192.168.0.x/24

LAN 192.168.0.x/24

Switch

Switch

X2

X0
pc card
signal

lan wan opt

1

X3

Switch

2

3

4

5

6
link/spd

link/act

Wireless Client
IP= 172.16.31.100

X0 (LAN)
IP=Secondary Bridge
Interface to X2
MAC= 00:06:B1:10:10:10

activity

X1

Router

NSA 240

NSA 2400
Interface e0
IP=10.0.01
Interface s0
ISP assigned

Internet

This diagram depicts a network where the SonicWALL will act as the perimeter security device
and secure wireless platform. Simultaneously, it will provide L2 Bridge security between the
workstation and server segments of the network without having to readdress any of the
workstation or servers.
This typical inter-departmental Mixed Mode topology deployment demonstrates how the
SonicWALL can simultaneously Bridge and route/NAT. Traffic to/from the Primary Bridge
Interface (Server) segment from/to the Secondary Bridge Interface (Workstation) segment will
pass through the L2 Bridge.
Since both interfaces of the Bridge-Pair are assigned to a Trusted (LAN) zone, the following will
apply:
•

All traffic will be allowed by default, but Access Rules could be constructed as needed.
Consider, for the point of contrast, what would occur if the X2 (Primary Bridge Interface)
was instead assigned to a Public (DMZ) zone: All the Workstations would be able to reach
the Servers, but the Servers would not be able to initiate communications to the
Workstations. While this would probably support the traffic flow requirements (i.e.
Workstations initiating sessions to Servers), it would have two undesirable effects:
a. The DHCP server would be in the DMZ. DHCP requests from the Workstations would

pass through the L2 Bridge to the DHCP server (192.168.0.100), but the DHCP offers
from the server would be dropped by the default DMZ->LAN Deny Access Rule. An
Access Rule would have to be added, or the default modified, to allow this traffic from
the DMZ to the LAN.

208

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

b. Security services directionality would be classified as Outgoing for traffic from the

Workstations to the Server since the traffic would have a Trusted source zone and a
Public destination zone. This might be sub-optimal since it would provide less scrutiny
than the Incoming or (ideally) Trust classifications.
•

Security services directionality would be classified as Trust, and all signatures (Incoming,
Outgoing, and Bidirectional) will be applied, providing the highest level of security to/from
both segments.

For detailed instructions on configuring interfaces in Layer 2 Bridge Mode, see “Configuring
Layer 2 Bridge Mode” on page 247

Layer 2 Bridge Mode with High Availability
This method is appropriate in networks where both High Availability and Layer 2 Bridge Mode
are desired. This example is for SonicWALL NSA series appliances, and assumes the use of
switches with VLANs configured.

Server

d

Core
Switch - HP 100z

ge

ag
0T

AN

10

VLAN 100 172.27.100./21
VLAN 200 172.27.200./21
IP Routing Enabled
VLAN 100 tagged on ports
C2-1 and D2-1
VLAN 200 used to test routing
status during failover

VL

NSA 3500 HA Pair
Layer 2 Bridge Mode
X0 bridged to X2
X1 left as WAN with
management
IP address to access UI

C24

D24
X5 HA Link

Third-party Firewall

Third-party Firewall
Port 24

Port 23

Edge
Switch - HP 3500yl

VLAN 100 - tagged on ports
23 and 24

VLAN 100 172.27.100.20/24

HP ProCurve
Switch

The SonicWALL HA pair consists of two SonicWALL NSA 3500 appliances, connected together
on port X5, the designated HA port. Port X1 on each appliance is configured for normal WAN
connectivity and is used for access to the management interface of that device. Layer 2 Bridge
Mode is implemented with port X0 bridged to port X2.

SonicOS 5.8.1 Administrator Guide

209

Network > Interfaces

When setting up this scenario, there are several things to take note of on both the SonicWALLs
and the switches.
On the SonicWALL appliances:
•

Do not enable the Virtual MAC option when configuring High Availability. In a Layer 2 Bridge
Mode configuration, this function is not useful.

•

Enabling Preempt Mode is not recommended in an inline environment such as this. If
Preempt Mode is required, follow the recommendations in the documentation for your
switches, as the trigger and failover time values play a key role here.

•

Consider reserving an interface for the management network (this example uses X1). If it
is necessary to assign IP addresses to the bridge interfaces for probe purposes or other
reasons, SonicWALL recommends using the management VLAN network assigned to the
switches for security and administrative purposes. Note that the IP addresses assigned for
HA purposes do not directly interact with the actual traffic flow.

On the switches:
•

Using multiple tag ports: As shown in the above diagram, two tag (802.1q) ports were
created for VLAN 100 on both the Edge switch (ports 23 and 24) and Core switch (C24 D24). The NSA 3500 appliances are connected inline between these two switches. In a high
performance environment, it is usually recommended to have Link Aggregation/ Port
Trunking, Dynamic LACP, or even a completely separate link designated for such a
deployment (using OSPF), and the fault tolerance of each of the switches must be
considered. Consult your switch documentation for more information.

•

On HP ProCurve switches, when two ports are tagged in the same VLAN, the port group
will automatically be placed into a failover configuration. In this case, as soon as one port
fails, the other one becomes active.

Layer 2 Bridge Mode with SSL VPN
This sample topology covers the proper installation of a SonicWALL UTM device into your
existing SonicWALL EX-Series SSL VPN or SonicWALL SSL VPN networking environment. By
placing the UTM appliance into Layer 2 Bridge Mode, with an internal, private connection to the
SSL VPN appliance, you can scan for viruses, spyware, and intrusions in both directions. In this
scenario the SonicWALL UTM appliance is not used for security enforcement, but instead for
bidirectional scanning, blocking viruses and spyware, and stopping intrusion attempts. When
programmed correctly, the UTM appliance will not interrupt network traffic, unless the behavior
or content of the traffic is determined to be undesirable. Both one- and two-port deployments
of the SonicWALL UTM appliance are covered in this section.
WAN to LAN Access Rules

Because the UTM appliance will be used in this deployment scenario only as an enforcement
point for anti-virus, anti-spyware and intrusion prevention, its existing security policy must be
modified to allow traffic to pass in both directions between the WAN and LAN.

210

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

On the Firewall > Access Rules page, click the Configure icon for the intersection of WAN to
LAN traffic. Click the Configure icon next to the default rule that implicitly blocks uninitiated
traffic from the WAN to the LAN.

In the Edit Rule window, select Allow for the Action setting, and then click OK.
Configure the Network Interfaces and Activate L2B Mode

In this scenario the WAN interface is used for the following:
•

Access to the management interface for the administrator

•

Subscription service updates on MySonicWALL

•

The default route for the device and subsequently the “next hop” for the internal traffic of
the SSL VPN appliance (this is why the UTM device WAN interface must be on the same
IP segment as the internal interface of the SSL VPN appliance)

The LAN interface on the UTM appliance is used to monitor the unencrypted client traffic
coming from the external interface of the SSL VPN appliance. This is the reason for running in
Layer 2 Bridge Mode (instead of reconfiguring the external interface of the SSL VPN appliance
to see the LAN interface as the default route).
On the Network > Interfaces page of the SonicOS Enhanced management interface, click the
Configure icon for the WAN interface, and then assign it an address that can access the
Internet so that the appliance can obtain signature updates and communicate with NTP.
The gateway and internal/external DNS address settings will match those of your SSL VPN
appliance:
•

IP address: This must match the address for the internal interface on the SSL VPN
appliance.

•

Subnet Mask, Default Gateway, and DNS Server(s): Make these addresses match your
SSL VPN appliance settings.

SonicOS 5.8.1 Administrator Guide

211

Network > Interfaces

For the Management setting, select the HTTPS and Ping check boxes. Click OK to save and
activate the changes.

To configure the LAN interface settings, navigate to the Network > Interfaces page and click
the Configure icon for the LAN interface.
For the IP Assignment setting, select Layer 2 Bridged Mode. For the Bridged to setting,
select X1.

If you also need to pass VLAN tagged traffic, supported on SonicWALL NSA series appliances,
click the VLAN Filtering tab and add all of the VLANs that will need to be passed.

212

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

Click OK to save and activate the change. You may be automatically disconnected from the
UTM appliance’s management interface. You can now disconnect your management laptop or
desktop from the UTM appliance’s X0 interface and power the UTM appliance off before
physically connecting it to your network.
Install the SonicWALL UTM appliance between the network and SSL VPN appliance

Regardless of your deployment method (single- or dual-homed), the SonicWALL UTM
appliance should be placed between the X0/LAN interface of the SSL VPN appliance and the
connection to your internal network. This allows the device to connect out to SonicWALL’s
licensing and signature update servers, and to scan the decrypted traffic from external clients
requesting access to internal network resources.
If your SSL VPN appliance is in two-port mode behind a third-party firewall, it is dual-homed.
To connect a dual-homed SSL VPN appliance, follow these steps:
Step 1

Cable the X0/LAN port on the UTM appliance to the X0/LAN port on the SSL VPN appliance.

Step 2

Cable the X1/WAN port on the UTM appliance to the port where the SSL VPN was previously
connected.

Step 3

Power on the UTM appliance.

If your SSL VPN appliance is in one-port mode in the DMZ of a third-party firewall, it is singlehomed. To connect a single-homed SSL VPN appliance, follow these steps:
Step 1

Cable the X0/LAN port on the UTM appliance to the X0/LAN port of the SSL VPN appliance.

Step 2

Cable the X1/WAN port on the UTM appliance to the port where the SSL VPN was previously
connected.

Step 3

Power on the UTM appliance.

SonicOS 5.8.1 Administrator Guide

213

Network > Interfaces

Configure or verify settings

From a management station inside your network, you should now be able to access the
management interface on the UTM appliance using its WAN IP address.
Make sure that all security services for the SonicWALL UTM appliance are enabled. See
“Licensing Services” on page 248 and “Activating UTM Services on Each Zone” on page 250.
SonicWALL Content Filtering Service must be disabled before the device is deployed in
conjunction with a SonicWALL Aventail SSL VPN appliance. On the Network > Zones page,
click Configure next to the LAN (X0) zone, clear the Enforce Content Filtering Service check
box and then click OK.

If you have not yet changed the administrative password on the SonicWALL UTM appliance,
you can do so on the System > Administration page.
To test access to your network from an external client, connect to the SSL VPN appliance and
log in. Once connected, attempt to access to your internal network resources. If there are any
problems, review your configuration and see the “Configuring the Common Settings for L2
Bridge Mode Deployments” section on page 248.

IPS Sniffer Mode
Supported on SonicWALL NSA 2400 and above series appliances, IPS Sniffer Mode is a
variation of Layer 2 Bridge Mode that is used for intrusion detection. IPS Sniffer Mode
configuration allows an interface on the SonicWALL to be connected to a mirrored port on a
switch to examine network traffic. Typically, this configuration is used with a switch inside the
main gateway to monitor traffic on the intranet.
In the network diagram below, traffic flows into a switch in the local network and is mirrored
through a switch mirror port into a IPS Sniffer Mode interface on the SonicWALL security
appliance. The SonicWALL inspects the packets according to the Unified Threat Management
(UTM) settings configured on the Bridge-Pair. Alerts can trigger SNMP traps which are sent to
the specified SNMP manager via another interface on the SonicWALL. The network traffic is
discarded after the SonicWALL inspects it.

214

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

The WAN interface of the SonicWALL is used to connect to the SonicWALL Data Center for
signature updates or other data.

Gateway

Main

Mirrored Data

WAN Port
Data Center Access

E7500

In IPS Sniffer Mode, a Layer 2 Bridge is configured between two interfaces in the same zone
on the SonicWALL, such as LAN-LAN or DMZ-DMZ. You can also create a custom zone to use
for the Layer 2 Bridge. Only the WAN zone is not appropriate for IPS Sniffer Mode.
The reason for this is that SonicOS detects all signatures on traffic within the same zone such
as LAN-LAN traffic, but some directional specific (client-side versus server-side) signatures do
not apply to some LAN-WAN cases.
Either interface of the Layer 2 Bridge can be connected to the mirrored port on the switch. As
network traffic traverses the switch, the traffic is also sent to the mirrored port and from there
into the SonicWALL for deep packet inspection. Malicious events trigger alerts and log entries,
and if SNMP is enabled, SNMP traps are sent to the configured IP address of the SNMP
manager system. The traffic does not actually continue to the other interface of the Layer 2
Bridge. IPS Sniffer Mode does not place the SonicWALL appliance inline with the network
traffic, it only provides a way to inspect the traffic.
The Edit Interfaces screen available from the Network > Interfaces page provides a new
checkbox called Only sniff traffic on this bridge-pair for use when configuring IPS Sniffer
Mode. When selected, this checkbox causes the SonicWALL to inspect all packets that arrive
on the L2 Bridge from the mirrored switch port. The Never route traffic on this bridge-pair

SonicOS 5.8.1 Administrator Guide

215

Network > Interfaces

checkbox should also be selected for IPS Sniffer Mode to ensure that the traffic from the
mirrored switch port is not sent back out onto the network. (The Never route traffic on this
bridge-pair setting is known as Captive-Bridge Mode.)

For detailed instructions on configuring interfaces in IPS Sniffer Mode, see “Configuring IPS
Sniffer Mode” on page 258.

216

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

Sample IPS Sniffer Mode Topology
This section provides an example topology that uses SonicWALL IPS Sniffer Mode in a Hewlitt
Packard ProCurve switching environment. This scenario relies on the ability of HP’s ProCurve
Manager Plus (PCM+) and HP Network Immunity Manager (NIM) server software packages to
throttle or close ports from which threats are emanating.
This method is useful in networks where there is an existing firewall that will remain in place,
but you wish to use the SonicWALL’s UTM services as a sensor.

Network Security Appliance

E7500

SonicWALL NSA Appliance

HP HCM/
NIM + Server

ISP

Third-party Firewall

Router

HP ProCurve
Switch

Wireless
Client

Desktop
Client

File
Server

Email
Server

LAN Connection
X1 WAN Connection
X0-LAN/ L2B Mode

In this deployment the WAN interface and zone are configured for the internal network’s
addressing scheme and attached to the internal network. The X2 port is Layer 2 bridged to the
LAN port – but it won’t be attached to anything. The X0 LAN port is configured to a second,
specially programmed port on the HP ProCurve switch. This special port is set for mirror mode
– it will forward all the internal user and server ports to the “sniff” port on the SonicWALL. This
allows the SonicWALL to analyze the entire internal network’s traffic, and if any traffic triggers
the UTM signatures it will immediately trap out to the PCM+/NIM server via the X1 WAN
interface, which then can take action on the specific port from which the threat is emanating.

SonicOS 5.8.1 Administrator Guide

217

Network > Interfaces

To configure this deployment, navigate to the Network > Interfaces page and click on the
configure icon for the X2 interface. On the X2 Settings page, set the IP Assignment to ‘Layer
2 Bridged Mode’ and set the Bridged To: interface to ‘X0’. Select the checkbox for Only sniff
traffic on the bridge-pair. Click OK to save and activate the change.

Next, go to the Network > Interfaces page and click on the configure icon for the X1 WAN
interface. On the X1 Settings page, assign it a unique IP address for the internal LAN segment
of your network – this may sound wrong, but this will actually be the interface from which you
manage the appliance, and it is also the interface from which the appliance sends its SNMP
traps as well as the interface from which it gets UTM signature updates. Click OK.

You must also modify the firewall rules to allow traffic from the LAN to WAN, and from the WAN
to the LAN, otherwise traffic will not pass successfully.
Connect the span/mirror switch port to X0 on the SonicWALL, not to X2 (in fact X2 isn’t plugged
in at all), and connect X1 to the internal network. Use care when programming the ports that
are spanned/mirrored to X0.

218

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

Configuring Interfaces
This section is divided into:
•

“Configuring the Static Interfaces” on page 219

•

“Configuring Interfaces in Transparent Mode” on page 221

•

“Configuring Wireless Interfaces” on page 223

•

“Configuring a WAN Interface” on page 225

•

“Configuring the NSA Expansion Pack Module Interface (NSA 2400MX and 250M only)” on
page 229

•

“Configuring Link Aggregation and Port Redundancy” on page 238

•

“Configuring Routed Mode” on page 242

•

“Configuring the U0 External 3G/Modem Interface” on page 243

•

“Configuring VLAN Subinterfaces” on page 246

•

“Configuring Layer 2 Bridge Mode” on page 247

•

“Configuring IPS Sniffer Mode” on page 258

Configuring the Static Interfaces
Static means that you assign a fixed IP address to the interface.
Step 1

Click on the Configure icon
in the Configure column for the Interface you want to
configure. The Edit Interface window is displayed.
•

You can configure X0 through X8, depending on the number of interfaces on your
appliance.

•

If you want to create a new zone, select Create new zone. The Add Zone window is
displayed. See “Network > Zones” on page 283 for instructions on adding a zone.

Step 2

Select a zone to assign to the interface. You can select LAN, WAN, DMZ, WLAN, or a custom
zone.

Step 3

Select Static from the IP Assignment menu.

Step 4

Enter the IP address and subnet mask of the zone in the IP Address and Subnet Mask fields.

Note

You cannot enter an IP address that is in the same subnet as another zone.

Step 5

Enter any optional comment text in the Comment field. This text is displayed in the Comment
column of the Interface table.

Step 6

If you want to enable remote management of the SonicWALL security appliance from this
interface, select the supported management protocol(s): HTTP, HTTPS, SSH, Ping, SNMP,
and/or SSH.
To allow access to the WAN interface for management from another zone on the same
appliance, access rules must be created. See “Allowing WAN Primary IP Access from the LAN
Zone” on page 615 for more information.

Step 7

If you want to allow selected users with limited management rights to log in to the security
appliance, select HTTP and/or HTTPS in User Login.

Step 8

Click OK.

SonicOS 5.8.1 Administrator Guide

219

Network > Interfaces

Note

The administrator password is required to regenerate encryption keys after changing the
SonicWALL security appliance’s address.

Configuring Advanced Settings for the Interface
If you need to force an Ethernet speed, duplex and/or MAC address, click the Advanced tab.

The Ethernet Settings section allows you to manage the Ethernet settings of links connected
to the SonicWALL. Auto Negotiate is selected by default as the Link Speed because the
Ethernet links automatically negotiate the speed and duplex mode of the Ethernet connection.
If you want to specify the forced Ethernet speed and duplex, select one of the following options
from the Link Speed menu:
•

1000 Mbps - Full Duplex

•

100 Mbps - Full Duplex

•

100 Mbps - Half Duplex

•

10 Mbps - Full Duplex

•

10 Mbps - Half Duplex

You can choose to override the Default MAC Address for the Interface by selecting Override
Default MAC Address and entering the MAC address in the field.
Check Enable Multicast Support to allow multicast reception on this interface.

Caution

220

If you select a specific Ethernet speed and duplex, you must force the connection speed and
duplex from the Ethernet card to the SonicWALL security appliance as well.

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

Configuring Interfaces in Transparent Mode
Transparent Mode enables the SonicWALL security appliance to bridge the WAN subnet onto
an internal interface. To configure an interface for transparent mode, complete the following
steps:
Step 1

Click on the Configure icon in the Configure column for Unassigned Interface you want to
configure. The Edit Interface window is displayed.

Step 2

Select an interface.
•

If you select a configurable interface, select LAN or DMZ for Zone.

•

If you want to create a new zone for the configurable interface, select Create a new zone.
The Add Zone window is displayed. See “Network > Zones” on page 283 for instructions
on adding a zone.

Step 3

Select Transparent Mode from the IP Assignment menu.

Step 4

From the Transparent Range menu, select an address object that contains the range of IP
addresses you want to have access through this interface. The address range must be within
the WAN zone and must not include the WAN interface IP address. If you do not have an
address object configured that meets your needs:
a. In the Transparent Range menu, select Create New Address Object.
b. In the Add Address Object window, enter a name for the address range.
a. For Zone Assignment, select WAN.
b. For Type, select:
•

Host if you want only one network device to connect to this interface.

•

Range to specify a range of IP addresses by entering beginning and ending value
of the range.

•

Network to specify a subnet by entering the beginning value and the subnet mask.
The subnet must be within the WAN address range and cannot include the WAN
interface IP address.

SonicOS 5.8.1 Administrator Guide

221

Network > Interfaces

c. Enter the IP address of the host, the beginning and ending address of the range, or the

IP address and subnet mask of the network.
d. Click OK to create the address object and return to the Edit Interface window.

See “Network > Address Objects” on page 299 for more information.
Step 5

Enter any optional comment text in the Comment field. This text is displayed in the Comment
column of the Interface table.

Step 6

If you want to enable remote management of the SonicWALL security appliance from this
interface, select the supported management protocol(s): HTTP, HTTPS, SSH, Ping, SNMP,
and/or SSH.
To allow access to the WAN interface for management from another zone on the same
appliance, access rules must be created. See “Allowing WAN Primary IP Access from the LAN
Zone” on page 615 for more information.

Step 7

If you want to allow selected users with limited management rights to log directly into the
security appliance through this interface, select HTTP and/or HTTPS in User Login.

Step 8

Click OK.

Note

The administrator password is required to regenerate encryption keys after changing the
SonicWALL security appliance’s address.

Configuring Advanced Settings for the Interface
If you need to force an Ethernet speed, duplex and/or MAC address, click the Advanced tab.
The Ethernet Settings section allows you to manage the Ethernet settings of links connected
to the SonicWALL. Auto Negotiate is selected by default as the Link Speed because the
Ethernet links automatically negotiate the speed and duplex mode of the Ethernet connection.
If you want to specify the forced Ethernet speed and duplex, select one of the following options
from the Link Speed menu:
•

1000 Mbps - Full Duplex ()

•

100 Mbps - Full Duplex

•

100 Mbps - Half Duplex

•

10 Mbps - Full Duplex

•

10 Mbps - Half Duplex

You can choose to override the Default MAC Address for the Interface by selecting Override
Default MAC Address and entering the MAC address in the field.
Check Enable Multicast Support to allow multicast reception on this interface.

Caution

222

If you select a specific Ethernet speed and duplex, you must force the connection speed and
duplex from the Ethernet card to the SonicWALL security appliance as well.

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

Configuring Wireless Interfaces
A Wireless interface is an interface that has been assigned to a Wireless zone and is used to
support SonicWALL SonicPoint secure access points.
Step 1

Click on the Configure icon
in the Configure column for the Interface you want to
configure. The Edit Interface window is displayed.

Step 2

In the Zone list, select WLAN or a custom Wireless zone.

Step 3

Enter the IP address and subnet mask of the zone in the IP Address and Subnet Mask fields.

Note

The upper limit of the subnet mask is determined by the number of SonicPoints you select
in the SonicPoint Limit field. If you are configuring several interfaces or subinterfaces as
Wireless interfaces, you may want to use a smaller subnet (higher) to limit the number of
potential DHCP leases available on the interface. Otherwise, if you use a class C subnet
(subnet mask of 255.255.255.0) for each Wireless interface you may exceed the limit of
DHCP leases available on the security appliance.

Step 4

In the SonicPoint Limit field, select the maximum number of SonicPoints allowed on this
interface.
•

This value determines the highest subnet mask you can enter in the Subnet Mask field.
The following table shows the subnet mask limit for each SonicPoint Limit selection and
the number of DHCP leases available on the interface if you enter the maximum allowed
subnet mask.

•

Available Client IPs assumes 1 IP for the SonicWALL gateway interface, in addition to the
presence of the maximum number of SonicPoints allowed on this interface, each
consuming an IP address.

SonicPoints per Interface Maximum Subnet Mask

Total Usable
IP addresses

Available
Client IPs

No SonicPoints

30 bits – 255.255.255.252

2

2

2 SonicPoints

29 bits – 255.255.255.248

6

3

4 SonicPoints

29 bits – 255.255.255.248

6

1

8 SonicPoints

28 bits – 255.255.255.240

14

5

16 SonicPoints
(NSA 240)

27 bits – 255.255.255.224

30

13

32 SonicPoints
(NSA 2400)

26 bits – 255.255.255.192

62

29

48 SonicPoints
(NSA 3400)

25 bits - 255.255.255.128

126

61

64 SonicPoints
(NSA 4500, 5000)

25 bits - 255.255.255.128

126

61

96 SonicPoints
(NSA E5500)

24 bits - 255.255.255.0

190

93

128 SonicPoints
(NSA E6500, NSA E7500)

23 bits - 255.255.254.0

254

125

SonicOS 5.8.1 Administrator Guide

223

Network > Interfaces

Note

The above table depicts the maximum subnet mask sizes allowed. You can still use classfull subnetting (class A, class B, or class C) or any variable length subnet mask that you wish
on WLAN interfaces. You are encouraged to use a smaller subnet mask (e.g. 24-bit class C
- 255.255.255.0 - 254 total usable IPs), thus allocating more IP addressing space to clients
if you have the need to support larger numbers of wireless clients.

Step 5

Enter any optional comment text in the Comment field. This text is displayed in the Comment
column of the Interface table.

Step 6

If you want to enable remote management of the SonicWALL security appliance from this
interface, select the supported management protocol(s): HTTP, HTTPS, SSH, Ping, SNMP,
and/or SSH.
To allow access to the WAN interface for management from another zone on the same
appliance, access rules must be created. See “Allowing WAN Primary IP Access from the LAN
Zone” on page 615 for more information.

Step 7

If you want to allow selected users with limited management rights to log in to the security
appliance, select HTTP and/or HTTPS in User Login.

Step 8

Click OK.

Configuring Advanced Settings for the Interface
If you need to force an Ethernet speed, duplex and/or MAC address, click the Advanced tab.

The Ethernet Settings section allows you to manage the Ethernet settings of links connected
to the SonicWALL. Auto Negotiate is selected by default as the Link Speed because the
Ethernet links automatically negotiate the speed and duplex mode of the Ethernet connection.
If you want to specify the forced Ethernet speed and duplex, select one of the following options
from the Link Speed menu:

Warning

•

1000 Mbps - Full Duplex

•

100 Mbps - Full Duplex

•

100 Mbps - Half Duplex

•

10 Mbps - Full Duplex

•

10 Mbps - Half Duplex

If you select a specific Ethernet speed and duplex, you must force the connection speed
and duplex from the Ethernet card to the SonicWALL security appliance as well.
You can choose to override the Default MAC Address for the Interface by selecting Override
Default MAC Address and entering the MAC address in the field.
Check Enable Multicast Support to allow multicast reception on this interface.

224

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

On SonicWALL NSA series appliances, select the Enable 802.1p tagging checkbox to tag
information passing through this interface with 802.1p priority information for Quality of Service
(QoS) management. Packets sent through this interface are tagged with VLAN id=0 and carry
802.1p priority information. In order to make use of this priority information, devices connected
to this interface should support priority frames. QoS management is controlled by access rules
on the Firewall > Access Rules page. For information on QoS and bandwidth management,
see “Firewall Settings > QoS Mapping” on page 751.

Configuring a WAN Interface
Configuring the WAN interface enables Internet connect connectivity. You can configure up to
two WAN interfaces on the SonicWALL security appliance.
Step 1

Click on the Edit
icon in the Configure column for the Interface you want to configure.
The Edit Interface window is displayed.

Step 2

If you’re configuring an Unassigned Interface, select WAN from the Zone menu. If you selected
the Default WAN Interface, WAN is already selected in the Zone menu.

Step 3

Select one of the following WAN Network Addressing Mode from the IP Assignment menu.
Depending on the option you choose from the IP Assignment menu, complete the
corresponding fields that are displayed after selecting the option.
•

Static - configures the SonicWALL for a network that uses static IP addresses.

•

DHCP - configures the SonicWALL to request IP settings from a DHCP server on the
Internet. NAT with DHCP Client is a typical network addressing mode for cable and DSL
customers.

•

PPPoE - uses Point to Point Protocol over Ethernet (PPPoE) to connect to the Internet. If
desktop software and a username and password is required by your ISP, select NAT with
PPPoE. This protocol is typically found when using a DSL modem.

•

PPTP - uses PPTP (Point to Point Tunneling Protocol) to connect to a remote server. It
supports older Microsoft Windows implementations requiring tunneling connectivity.

SonicOS 5.8.1 Administrator Guide

225

Network > Interfaces

•

Note

Step 4

L2TP - uses IPsec to connect a L2TP (Layer 2 Tunneling Protocol) server and encrypts all
data transmitted from the client to the server. However, it does not encrypt network traffic
to other destinations.

For Windows clients, L2TP is supported by Windows 2000 and Windows XP. If you are
running other versions of Windows, you must use PPTP as your tunneling protocol.
If you want to enable remote management of the SonicWALL security appliance from this
interface, select the supported management protocol(s): HTTP, HTTPS, SSH, Ping, SNMP,
and/or SSH. You can also select HTTP for management traffic. However, bear in mind that
HTTP traffic is less secure than HTTPS.
To allow access to the WAN interface for management from another zone on the same
appliance, access rules must be created. See “Allowing WAN Primary IP Access from the LAN
Zone” on page 615 for more information.

Step 5

If you want to allow selected users with limited management rights to log directly into the
security appliance from this interface, select HTTP and/or HTTPS in User Login.

Step 6

Check Add rule to enable redirect from HTTP to HTTPS, if you want an HTTP connection
automatically redirected to a secure HTTPS connection to the SonicWALL security appliance
management interface.

Step 7

After completing the WAN configuration for your Network Addressing Mode, click OK.

Configuring the Advanced Settings for the WAN Interface
The Advanced tab includes settings for forcing an Ethernet speed and duplex, overriding the
Default MAC address, setting up bandwidth management, and creating a default NAT policy
automatically.

226

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

Ethernet Settings
If you need to force an Ethernet speed, duplex and/or MAC address, click the Advanced tab.
The Ethernet Settings section allows you to manage the Ethernet settings of links connected
to the SonicWALL. Auto Negotiate is selected by default as the Link Speed because the
Ethernet links automatically negotiate the speed and duplex mode of the Ethernet connection.
If you want to specify the forced Ethernet speed and duplex, select one of the following options
from the Link Speed menu:
•

1000 Mbps - Full Duplex

•

100 Mbps - Full Duplex

•

100 Mbps - Half Duplex

•

10 Mbps - Full Duplex

•

10 Mbps - Half Duplex

You can choose to override the Default MAC Address for the Interface by selecting Override
Default MAC Address and entering the MAC address in the field.

Caution

If you select a specific Ethernet speed and duplex, you must force the connection
speed and duplex from the Ethernet card to the SonicWALL as well.

Check Enable Multicast Support to allow multicast reception on this interface.
On SonicWALL NSA series appliances, check Enable 802.1p tagging to tag information
passing through this interface with 802.1p priority information for Quality of Service (QoS)
management. Packets sent through this interface are tagged with VLAN id=0 and carry 802.1p
priority information. In order to make use of this priority information, devices connected to this
interface should support priority frames. QoS management is controlled by access rules on the
Firewall > Access Rules page. For information on QoS and bandwidth management, see
“Allowing WAN Primary IP Access from the LAN Zone” on page 615.
You can also specify any of these additional Ethernet Settings:
•

Interface MTU - Specifies the largest packet size that the interface can forward without
fragmenting the packet.

•

Fragment non-VPN outbound packets larger than this Interface’s MTU - Specifies all
non-VPN outbound packets larger than this Interface’s MTU be fragmented. Specifying the
fragmenting of VPN outbound packets is set in the VPN > Advanced page.

•

Ignore Don’t Fragment (DF) Bit - Overrides DF bits in packets.

•

Do not send ICMP Fragmentation Needed for outbound packets over the Interface
MTU - blocks notification that this interface can receive fragmented packets.

Bandwidth Management
SonicOS Enhanced can apply bandwidth management to both egress (outbound) and ingress
(inbound) traffic on the interfaces in the WAN zone. Outbound bandwidth management is done
using Class Based Queuing. Inbound Bandwidth Management is done by implementing ACK
delay algorithm that uses TCP’s intrinsic behavior to control the traffic.
Class Based Queuing (CBQ) provides guaranteed and maximum bandwidth Quality of Service
(QoS) for the SonicWALL security appliance. Every packet destined to the WAN interface is
queued in the corresponding priority queue. The scheduler then dequeues the packets and
transmits it on the link depending on the guaranteed bandwidth for the flow and the available
link bandwidth.

SonicOS 5.8.1 Administrator Guide

227

Network > Interfaces

Use the Bandwidth Management section of the Edit Interface screen to enable or disable the
ingress and egress bandwidth management. Egress and Ingress available link bandwidth can
be used to configure the upstream and downstream connection speeds in kilobits per second.

Note

The Bandwidth Management settings are applied to all interfaces in the WAN zone, not just
to the interface being configured.
•

Enable Egress Bandwidth Management - Enables outbound bandwidth management.
– Available Interface Egress Bandwidth (Kbps) - Specifies the available bandwidth for

WAN interfaces in Kbps.
•

Enable Ingress Bandwidth Management - Enables inbound bandwidth management.

•

Available Interface Ingress Bandwidth (Kbps) - Specifies the available bandwidth for WAN
interfaces in Kbps

If you are configuring the WAN interface with a PPPoE, PPTP, or L2TP IP Assignment, a
Protocol tab appears in the WAN interface configuration window. Depending on the protocol
selected, settings acquired and client settings can be configured. Perform the steps below to
configure the Protocol settings:

228

Step 1

In the Settings Acquired section, enter your SonicWALL IP Address, Subnet Mask (PPPoE
only), Gateway Address, DNS Server1, and DNS Server2.

Step 2

If you are using PPTP or L2TP, click the OK button. Your Protocol configuration is complete.

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

If you are using PPPoE, a Client Settings section displays in the Protocol tab:

Step 3

If you want PPPoE to disconnect after a specific time period, Click the Inactivity Disconnect
checkbox and enter the time period (in minutes).

Step 4

If you want to use LCP echo packets for server keep-alive, click the Strictly use LCP echo
packets for server keep-alive checkbox.

Step 5

If you want the PPPoE client to reconnect to the server when traffic is not sent for a specific
time period, enter the time period (in minutes) in the text field. This checkbox is selected by
default.

Step 6

Click the OK button

Configuring the NSA Expansion Pack Module Interface (NSA 2400MX and 250M only)
The SonicWALL NSA 2400MX and NSA 250M security appliances support the following
optional NSA Expansion Pack modules:
•

1-Port ADSL (RJ-11) Annex A module

•

1-Port ADSL (RJ-45) Annex B module

•

1-Port T1/E1 module

•

2-Port LAN Bypass module

•

2-Port SFP module

•

4-Port Gigabit Ethernet module (SonicWALL NSA 2400MX)

•

4-Port Gigabit Ethernet module (SonicWALL NSA 250M series)

These interfaces are listed in the Interface Settings table as the Mx interfaces.

Caution

Before attempting to insert and configure the module, you must power off the appliance.
Once the appliance has been powered down, remove the rear module plate cover and insert
the expansion module.Tighten the screws to secure the module, then power on the
appliance.
Log into the SonicWALL management interface. You can now begin configuring the desired
expansion module. The following sections describe how to configure the
•

“Configuring the ADSL Expansion Module” on page 230

•

“Configuring the T1/E1 Module” on page 233

•

“Configuring the LAN Bypass Module” on page 236

•

“Configuring the 2 Port SFP or 4 Port Gigabit Ethernet Modules (NSA 2400MX and NSA
250M)” on page 237

SonicOS 5.8.1 Administrator Guide

229

Network > Interfaces

Configuring the ADSL Expansion Module
ADSL is an acronym for Asymmetric Digital Subscriber Line (or Loop). The line is asymmetric
because, when connected to the ISP, the upstream and downstream speeds of transmission
are different. The DSL technology allows non-voice services (data) to be provided on regular
single copper wire-pair POTS connections (such as your home phone line). It allows voice calls
and data to pass through simultaneously by using higher band frequencies for data
transmission.
The SonicWALL ADSL module cards support only one subscriber ADSL line (one port). Two
types of ADSL module cards are supported:
•

1 Port ADSL (RJ-11) Annex A – ADSL over plain old telephone service (POTS) with a
downstream rate of 12.0 Mbit/s and an upstream rate of 1.3 Mbit/s.

•

1 Port ADSL (RJ-45) Annex B – ADSL over an Integrated Services Digital Network (ISDN)
with a downstream rate of 12.0 Mbit/s and an ups.tream rate of 1.8 Mbit/s.

The following ADSL standards are supported
Standard Name

Common Name

T1.413

ADSL

G.992.1

ADSL G.DMT

G.992.2

ADSL Lite (G. Lite)

G.992.3

ADSL2

G.992.5

ADSL2+M with Annex M and Annex L

The ADSL module card uses 2 LEDs to indicate connectivity status. The upper green LED is
the ADSL link. Its status is as follows:
•

OFF - No link

•

ON - ADSL link is active

The lower green LED shows the system and ADSL module activity.
•

If it is OFF, there is no activity.

•

If it displays a slow blink rate, it signifies activity on system management interface.

•

If it displays a fast blink rate, there is data activity on ADSL line.

The ADSL module card is detected on boot, and assigned an interface name of M0 or M1. The
interface name is based to it based on the expansion slot hosting the module card. You will see
the assigned entry when you log into the Network Interfaces page.

230

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

The ADSL interface never unassigned. When plugged in, it is always present in the WAN zone
and zone assignment cannot be modified by the administrator

Click on the Configure
icon to the right of the interface entry. You will see a menu with
three tabs: General, Advanced, and DSL Settings. The DSL Settings tab allows you to
configure ISP-specific settings for the ADSL connection.

It displays the configurable DSL fields:
Virtual Path Identifier (VPI)
Virtual Channel Identifier (VCI)
Multiplexing Method (LLC or VC)
The values for these parameters should match the settings on the ISP DSLAM, and are
provided by the ISP. These values vary from one ISP to another, and from country to country.
The SNWL default uses the most common values in the USA. The VPI and VCI settings are
used to create the Permanent Virtual Circuit (PVC) from the NSA2400MX to the ISP DSLAM.
When finished configuring these ISP settings, click OK.
The Ethernet-specific settings on the Advanced tab, even if set, do not apply to the ADSL
module. The Link Speed field in the Advanced tab has a fixed "N/A" selection, since it does not
apply to ADSL. The ADSL link speed can't be customized but is predetermined by the DSL
Provider.
The standard WAN ethernet settings are not affected by the presence of the ADSL module.

SonicOS 5.8.1 Administrator Guide

231

Network > Interfaces

When the ADSL module is first plugged in, it should be added to the WAN Load Balancing
default group so that the ADSL module can be used to handle default route traffic. Go to the
Failover and LB screen and click the Configure
icon to edit the settings.

232

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

On the General menu, add the ADSL interface to the Load Balancing group. If the default
primary WAN, X1, is unused or unconfigured, it can be removed for a cleaner interface
configuration.

When done, click OK, and the ADSL module will be added to the group.

Configuring the T1/E1 Module

The 1-port T1/E1 Module provides the connection of a T1 or E1 (digitally multiplexed
telecommunications carrier system) circuit to a SonicWALL appliance using an RJ-45 jack.
The SonicWALL T1/E1 module fully supports Point-to-Point Protocol (PPP) and Cisco HDLC
encapsulation, and can connect to Cisco routers and HP ProCurve devices.

Note

Only one T1/E1 module can be configured on each appliance.

SonicOS 5.8.1 Administrator Guide

233

Network > Interfaces

To configure the T1/E1 Module, perform the following tasks:
Step 1

Click on the Edit
icon in the Configure column for the Interface of the expansion module
you want to configure. The Edit Interface window is displayed.

The General tab allows you to set up the type of encapsulation: PPP or HDLC, as well as the
management interface type and level of user security login. The Zone setting is disabled.

234

Step 2

Select the desired type of encapsulation: PPP, HDLC, or Cisco HDLC. If you select a type of
encapsulation other than PPP, you will need to assign the IP address and netmask.

Step 3

If HDLC or Cisco HDLC is selected, assign the IP address and subnet mask for the network
mask assigned to the subnet.These are auto-filled for you, but you can change them if desired.

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

If you want to enable remote management of the SonicWALL security appliance from this
interface, select the supported management protocol(s): HTTP, HTTPS, SSH, Ping, SNMP,
and/or SSH. You can also select HTTP for management traffic. However, bear in mind that
HTTP traffic is less secure than HTTPS. You can also set the level of security (HTTP or HTTPS)
at this time.
Step 4

Click on the Advanced Tab.

You will see two radio buttons, one for T1 and one for E1. Only one button should be selected
at a time. Different Line Coding, Framing and Encapsulation configuration choices are offered,
depending on the button.
Step 5

Select the Clock Source: Internal or External. This selection is the same for both T1 and E1.

Step 6

Select the Line Coding option:

Step 7

Step 8

•

When T1 is selected the choices are: B8ZS, AMI

•

When E1 is selected the choices are: HDB3, AMI

Select the Framing configuration:
•

When T1 is selected the choices are: D4 (SF), ESF

•

When E1 is selected the choices are: FAS, MFAS

Select the DSO speed: 56 KB or 64KB (default).
If desired, you can specify the Data DSO range.
For T1, the range is 1 to 24 (default)
For E1, the range is 1 to 31
Each number can be individually set. For example, “5 to 15”, “1 to 1”, 1 to 20” are valid settings.

SonicOS 5.8.1 Administrator Guide

235

Network > Interfaces

Step 9

Line Build Out is available with T1. The options are: 0.0 dB, -7.5 dB, -15 dB, -22.5 dB.
CRC is configured with an enable/disable check-box. When T1 is selected, the check-box is
labeled CRC6, when E1 is selected the check-box is labeled CRC4.
You can also choose to enable multicast.

Step 10 When finished with configuration, click OK.

The T1/E1 module interface will be added to the pool of available WAN interfaces

Configuring the LAN Bypass Module
This module allows you to perform a physical bypass of the firewall when the interface is
bridged to another interface with LAN bypass capability. This allows network traffic to continue
flowing if an unrecoverable firewall error occurs.
Step 1

Click on the Edit
icon in the Configure column for the Interface of the expansion module
you want to configure. The Edit Interface window is displayed. The Bypass option is only
displayed if an interface capable of performing the bridge is present.

Step 2

The window shows the LAN interface, and has a checkbox “Engage Physical ByPass on
Malfunction” to enable the physical bypass feature. This is only displayed when the interface
is bridged to another interface capable of performing the LAN bypass. Enabling this checkbox
means that the packets between the bridged pairs will not fail, even if the firmware or NSA
appliance fails.
If the checkbox is not enabled, the ports will behave like normal Ethernet ports.
Click OK to configure the interface.

236

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

Configuring the 2 Port SFP or 4 Port Gigabit Ethernet Modules (NSA 2400MX and NSA 250M)
Step 1

Click on the Edit
icon in the Configure column for the Interface of the expansion module
you want to configure. The Edit Interface window is displayed.

Step 2

If you’re configuring an Unassigned Interface, you can select any zone from the Zone menu.
LAN is already selected in the Zone menu.

Select one of the following LAN Network Addressing Modes from the IP Assignment menu.
•

Static - configures the interface for a network that uses static IP addresses.

•

Transparent - configures the interface to use interfaces as the top level of the management
hierarchy and span multiple interfaces.

Depending on the option you choose from the IP Assignment menu, complete the
corresponding fields that are displayed after selecting the option.
Step 3

Assign the IP address and subnet mask for the network mask assigned to the subnet.These are
auto-filled for you, but you can change them if desired.

Step 4

If you want to enable remote management of the SonicWALL security appliance from this
interface, select the supported management protocol(s): HTTP, HTTPS, SSH, Ping, SNMP,
and/or SSH. You can also select HTTP for management traffic. However, bear in mind that
HTTP traffic is less secure than HTTPS. You can also use a checkbox to add a rule to redirect
from HTTP to HTTPS to enforce security on the interface.

Step 5

Click OK to configure the interface.

SonicOS 5.8.1 Administrator Guide

237

Network > Interfaces

Configuring the Advanced Settings for the Module Interface

The Advanced tab includes settings for forcing an Ethernet speed and duplex, overriding the
Default MAC address, enabling multicast support on the interface, and enabling 802.1p
tagging. Packets sent out with 802.1p tagging are tagged VLAN id=0 and carry 802,1p priority
information. Devices connected to this interface need to support priority frames.

Configuring Additional Interfaces
Step 6

Each expansion module interface must be individually configured. These initially appear as
unassigned interfaces.

Step 7

Click on the Edit

icon in the Configure column for the Interface you want to configure.

For each interface, on the General tab of the Edit Interface window, select LAN from the Zone
menu. Fill in the desired IP assignment. The subnet will be assigned for you. Add the desired
management options and click Okay. Then configure the Advanced settings.

Configuring Link Aggregation and Port Redundancy
Both Link Aggregation and Port Redundancy are configured on the Advanced tab of the Edit
Interface window in the SonicOS UI.

Note

238

•

“Link Aggregation” on page 239 - Groups multiple Ethernet interfaces together forming a
single logical link to support greater throughput than a single physical interface could
support. This provides the ability to send multi-gigabit traffic between two Ethernet
domains.

•

“Port Redundancy” on page 240 - Configures a single redundant port for any physical
interface that can be connected to a second switch to prevent a loss of connectivity in the
event that either the primary interface or primary switch fail.

Link Aggregation and Port Redundancy are only supported on SonicWALL E-class
appliances.

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

Link Aggregation
Link Aggregation is used to increase the available bandwidth between the firewall and a switch
by aggregating up to four interfaces into a single aggregate link, referred to as a Link
Aggregation Group (LAG). All ports in an aggregate link must be connected to the same switch.
The firewall uses a round-robin algorithm for load balancing traffic across the interfaces in a
Link Aggregation Group. Link Aggregation also provides a measure of redundancy, in that if one
interface in the LAG goes down, the other interfaces remain connected.
Link Aggregation is referred to using different terminology by different vendors, including Port
Channel, Ether Channel, Trunk, and Port Grouping.
Link Aggregation failover

SonicWALL provides multiple methods for protecting against loss of connectivity in the case of
a link failure, including High Availability (HA), Load Balancing Groups (LB Groups), and now
Link Aggregation. If all three of these features are configured on a firewall, the following order
of precedence is followed in the case of a link failure:
1.

High Availability

2.

Link Aggregation

3.

Load Balancing Groups

HA takes precedence over Link Aggregation. Because each link in the LAG carries an equal
share of the load, the loss of a link on the Active firewall will force a failover to the Idle firewall
(if all of its links remain connected). Physical monitoring needs to be configured only on the
primary aggregate port.
When Link Aggregation is used with a LB Group, Link Aggregation takes precedence. LB will
take over only if all the ports in the aggregate link are down.
Link Aggregation Limitations
•

Currently only static addressing is supported for Link Aggregation

•

The Link Aggregation Control Protocol (LACP) is currently not supported

Link Aggregation Configuration

To configure Link Aggregation, perform the following tasks:
1.

On the Network > Interfaces page, click the configure icon for the interface that is to be
designated the master of the Link Aggregation Group. The Edit Interface window displays.

SonicOS 5.8.1 Administrator Guide

239

Network > Interfaces

Note

Note

2.

Click on the Advanced tab.

3.

In the Redundant/Aggregate Ports pulldown menu, select Link Aggregation.

4.

The Aggregate Port option is displayed with a checkbox for each of the currently
unassigned interfaces on the firewall. Select up to three other interfaces to assign to the
LAG.

After an interface is assigned to a Link Aggregation Group, its configuration is governed by
the Link Aggregation master interface and it cannot be configured independently. In the
Interface Settings table, the interface's zone is displayed as "Aggregate Port" and the
configuration icon is removed.
5.

Set the Link Speed for the interface to Auto-Negotiate.

6.

Click OK.

Link Aggregation requires a matching configuration on the Switch. The switch's method of
load balancing will very depending on the vendor. Consult the documentation for the switch
for information on configuring Link Aggregation. Remember that it may be referred to as Port
Channel, Ether Channel, Trunk, or Port Grouping.

Port Redundancy
Port Redundancy provides a simple method for configuring a redundant port for a physical
Ethernet port. This is a valuable feature, particularly in high-end deployments, to protect
against switch failures being a single point of failure.
When the primary interface is active, it processes all traffic to and from the interface. If the
primary interface goes down, the backup interface takes over all outgoing and incoming traffic.
The backup interface assumes the MAC address of the primary interface and sends the
appropriate gratuitous ARP on a failover event. When the primary interface comes up again, it
resumes responsibility for all traffic handling duties from the backup interface.
In a typical Port Redundancy configuration, the primary and backup interfaces are connected
to different switches. This provides for a failover path in case the primary switch goes down.
Both switches must be on the same Ethernet domain. Port Redundancy can also be configured
with both interfaces connected to the same switch.

240

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

Port Redundancy Failover

SonicWALL provides multiple methods for protecting against loss of connectivity in the case of
a link failure, including High Availability (HA), Load Balancing Groups (LB Groups), and now
Port Redundancy. If all three of these features are configured on a firewall, the following order
of precedence is followed in the case of a link failure:
1.

Port Redundancy

2.

HA

3.

LB Group

When Port Redundancy is used with HA, Port Redundancy takes precedence. Typically an
interface failover will cause an HA failover to occur, but if a redundant port is available for that
interface, then an interface failover will occur but not an HA failover. If both the primary and
backup redundant ports go down, then an HA failover will occur (assuming the backup firewall
has the corresponding port active).
When Port Redundancy is used with a LB Group, Port Redundancy again takes precedence.
Any single port (primary or backup) failures are handled by Port Redundancy just like with HA.
When both the ports are down then LB kicks in and tries to find an alternate interface.
Port Redundancy Configuration

To configure Port Redundancy, perform the following tasks:

Note

1.

On the Network > Interfaces page, click the configure icon for the interface that is to be
designated the master of the Link Aggregation Group. The Edit Interface window displays.

2.

Click on the Advanced tab.

3.

In the Redundant/Aggregate Ports pulldown menu, select Port Redundancy.

4.

The Redundant Port pulldown menu is displayed, with all of the currently unassigned
interfaces available. Select one of the interfaces.

After an interface is selected as a Redundant Port, its configuration is governed by the
primary interface and it can not be configured independently. In the Interface Settings table,
the interface's zone is displayed as "Redundant Port" and the configuration icon is removed.
5.

Set the Link Speed for the interface to Auto-Negotiate.

6.

Click OK.

SonicOS 5.8.1 Administrator Guide

241

Network > Interfaces

Configuring Routed Mode
Routed Mode provides an alternative for NAT for routing traffic between separate public IP
address ranges. Consider the following topology where the firewall is routing traffic across two
public IP address ranges:
•

10.50.26.0/24

•

172.16.6.0/24

By enabling Routed Mode on the interface for the 172.16.6.0 network, all inbound and outbound
traffic will be routed to the WAN interface configured for the 10.50.26.0 network.
To configure Routed Mode, perform the following steps:

242

1.

Navigate to the Network > Interfaces page.

1.

Click on the configure icon for the appropriate interface. The Edit Interface window
displays.

2.

Click on the Advanced tab.

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

3.

Under the Expert Mode Settings heading, select the Use Routed Mode - Add NAT Policy
to prevent outbound\inbound translation checkbox to enable Routed Mode for the
interface.

4.

In the Set NAT Policy's outbound\inbound interface to pulldown menu, select the WAN
interface that is to be used to route traffic for the interface.

5.

Click OK.

The firewall then creates two “No-NAT” policies for both the configured interface and the
selected WAN interface. These policies override any more general Many to One NAT policies
that may be configured for the interfaces.

Configuring the U0 External 3G/Modem Interface
The SonicWALL TZ 200 security appliances support an external 3G/mobile or analog modem
interface. This interface is listed at the bottom of the Interface Settings table as the U0
interface. A number of the settings for the external interface can be configured from the
Network > Interfaces page, but it can be more thoroughly configured using the pages on the
3G or Modem tab in the left-side navigation bar.
For complete information on configuring a 3G or analog modem external interface, see “3G/
Modem” on page 431.

Specifying the WAN Connection Model

Note

The WAN Connection Model drop-down menu is only displayed when the U0 interface is
configured for a 3G/mobile external interface. This menu item is not displayed when the U0
interface is configured for an analog modem.
To configure the WAN connection model, navigate to the Network > Interfaces page and
select one of the following options in the WAN Connection Model drop-down menu:
•

3G only - The WAN interface is disabled and the 3G interface is used exclusively.

•

Ethernet only - The 3G interface is disabled and the WAN interface is used exclusively.

•

Ethernet with 3G Failover - The WAN interface is used as the primary interface and the
3G interface is disabled. If the WAN connection fails, the 3G interface is enabled and a 3G
connection is automatically initiated.

For a detailed explanation of the behavior of the Ethernet with 3G Failover setting see
“Understanding 3G Connection Models” on page 434.

SonicOS 5.8.1 Administrator Guide

243

Network > Interfaces

Configuring SonicWALL PortShield Interfaces
PortShield architecture enables you to configure some or all of the LAN ports into separate
security contexts, providing protection not only from the WAN and DMZ, but between devices
inside your network as well. In effect, each context has its own wire-speed PortShield that
enjoys the protection of a dedicated, deep packet inspection firewall.
PortShield is supported on SonicWALL TZ Series and NSA 240 appliances.

Tip

Zones can always be applied to multiple interfaces in the Network > Interfaces page, even
without the use of PortShield groupings. However, these interfaces will not share the same
network subnet unless they are grouped using PortShield.
You can assign any combination of ports into a PortShield interface. All ports you do not assign
to a PortShield interface are assigned to the LAN interface.

244

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

To configure a PortShield interface, perform the following steps:
Step 1

Click on the Network > Interfaces page.

Step 2

Click the Configure button for the interface you want to configure. The Edit Interface window
displays.

Step 3

In the Zone pulldown menu, select on a zone type option to which you want to map the
interface.

SonicOS 5.8.1 Administrator Guide

245

Network > Interfaces

Note

You can add PortShield interfaces only to Trusted, Public, and Wireless zones.

Step 4

In the IP Assignment pulldown menu, select PortShield Switch Mode.

Step 5

In the PortShield to pulldown menu, select the interface you want to map this port to. Only
ports that match the zone you have selected are displayed.

Configuring VLAN Subinterfaces
VLAN subinterfaces are supported on SonicWALL NSA series appliances. When you add a
VLAN subinterface, you need to assign it to a zone, assign it a VLAN Tag, and assign it to a
physical interface. Based on your zone assignment, you configure the VLAN subinterface the
same way you configure a physical interface for the same zone.

Adding a virtual interface
Step 1

In the left-navigation menu click on Network and then Interfaces to display the
Network > Interfaces page.

Step 2

At the bottom of the Interface Settings table, click Add Interface. The Edit Interface window
displays.

Step 3

Select a zone to assign to the interface. You can select LAN, WAN, DMZ, WLAN, or a custom
zone. The zone assignment does not have to be the same as the parent (physical) interface. In
fact, the parent interface can even remain Unassigned.
Your configuration choices for the network settings of the subinterface depend on the zone
you select.

246

•

LAN, DMZ, or a custom zone of Trusted type: Static or Transparent

•

WLAN or a custom Wireless zone: static IP only (no IP Assignment list).

Step 4

Assign a VLAN tag (ID) to the subinterface. Valid VLAN ID’s are 1 to 4095, although some
switches reserve VLAN 1 for native VLAN designation. You will need to create a VLAN
subinterface with a corresponding VLAN ID for each VLAN you wish to secure with your security
appliance.

Step 5

Declare the parent (physical) interface to which this subinterface will belong. There is no perinterface limit to the number of subinterfaces you can assign – you may assign subinterfaces
up to the system limit.

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

Step 6

Configure the subinterface network settings based on the zone you selected. See the interface
configuration instructions earlier in this chapter:
– “Configuring the Static Interfaces” on page 219
– “Configuring Advanced Settings for the Interface” on page 220
– “Configuring Interfaces in Transparent Mode” on page 221
– “Configuring Wireless Interfaces” on page 223
– “Configuring a WAN Interface” on page 225
– “Configuring SonicWALL PortShield Interfaces” on page 244
– “Configuring VLAN Subinterfaces” on page 246

Step 7

Select the management and user-login methods for the subinterface.

Step 8

Click OK.

Configuring Layer 2 Bridge Mode
See the following sections:
•

“Configuration Task List for Layer 2 Bridge Mode” on page 247

•

“Configuring Layer 2 Bridge Mode Procedure” on page 253

•

“VLAN Integration with Layer 2 Bridge Mode” on page 255

•

“VPN Integration with Layer 2 Bridge Mode” on page 258

Configuration Task List for Layer 2 Bridge Mode
•

Choose a topology that suits your network

•

“Configuring the Common Settings for L2 Bridge Mode Deployments” section on page 248
– License UTM services
– Disable DHCP server
– Configure and enable SNMP and HTTP/HTTPS management
– Enable syslog
– Activate UTM services on affected zones
– Create firewall access rules
– Configure log settings
– Configure wireless zone settings

•

“Configuring the Primary Bridge Interface” section on page 254
– Select the zone for the Primary Bridge Interface
– Activate management
– Activate security services

•

“Configuring the Secondary Bridge Interface” section on page 255
– Select the zone for the Secondary Bridge Interface
– Activate management
– Activate security services

SonicOS 5.8.1 Administrator Guide

247

Network > Interfaces

•

Apply security services to the appropriate zones

Configuring the Common Settings for L2 Bridge Mode Deployments
The following settings need to be configured on your SonicWALL UTM appliance prior to using
it in most of the Layer 2 Bridge Mode topologies.

Licensing Services
When the appliance is successfully registered, go to the System > Licenses page and click
Synchronize under Manage Security Services Online. This will contact the SonicWALL
licensing server and ensure that the appliance is properly licensed.
To check licensing status, go to the System > Status page and view the license status of all
the UTM services (Gateway Anti-Virus, Anti-Spyware, and Intrusion Prevention).

Disabling DHCP Server
When using a SonicWALL UTM appliance in Layer 2 Bridge Mode in a network configuration
where another device is acting as the DHCP server, you must first disable its internal DHCP
engine, which is configured and running by default. On the Network > DHCP Server page,
clear the Enable DHCP Server check box, and then click on the Accept button at the top of
the screen.

Configuring SNMP Settings
On the System > Administration page, make sure the checkbox next to Enable SNMP is
checked, and then click on the Accept button at the top of the screen.

248

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

Then, click the Configure button. On the SNMP Settings page, enter all the relevant
information for your UTM appliance: the GET and TRAP SNMP community names that the
SNMP server expects, and the IP address of the SNMP server. Click OK to save and activate
the changes.

Enabling SNMP and HTTPS on the Interfaces
On the Network > Interfaces page, enable SNMP and HTTP/HTTPS on the interface through
which you will be managing the appliance.

SonicOS 5.8.1 Administrator Guide

249

Network > Interfaces

Enabling Syslog
On the Log > Syslog page, click on the Add button and create an entry for the syslog server.
Click OK to save and activate the change.

Activating UTM Services on Each Zone
On the Network > Zones page, for each zone you will be using, make sure that the UTM
services are activated.

Then, on the Security Services page for each UTM service, activate and configure the settings
that are most appropriate for your environment.
An example of the Gateway Anti-Virus settings is shown below:

250

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

An example of the Intrusion Prevention settings is shown below:

An example of the Anti-Spyware settings is shown below:

SonicOS 5.8.1 Administrator Guide

251

Network > Interfaces

Creating Firewall Access Rules
If you plan to manage the appliance from a different zone, or if you will be using a server such
as the HP PCM+/NIM server for management, SNMP, or syslog services, create access rules
for traffic between the zones. On the Firewall > Access Rules page, click on the icon for the
intersection of the zone of the server and the zone that has users and servers (your
environment may have more than one of these intersections). Create a new rule to allow the
server to communicate with all devices in that zone.

Configuring Log Settings
On the Log > Categories page, set the Logging Level to Informational and the Alert Level
to Critical. Click Accept to save and activate the change.

Then, go to the Log > Name Resolution page and set the Name Resolution Method to DNS
then NetBios. Click Accept to save and activate the change.

252

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

Configuring Wireless Zone Settings
In the case where you are using a HP PCM+/NIM system, if it will be managing a HP ProCurve
switch on an interface assigned to a WLAN/Wireless zone, you will need to deactivate two
features, otherwise you will not be able to manage the switch. Go to the Network > Zones page
and select your Wireless zone. On the Wireless tab, clear the checkboxes next to Only allow
traffic generated by a SonicPoint and WiFiSec Enforcement. Click OK to save and activate
the change.

Configuring Layer 2 Bridge Mode Procedure
Refer to the “L2 Bridge Interface Zone Selection” section on page 201 for choosing a topology
that best suits your network. In this example, we will be using a topology that most closely
resembles the Simple L2 Bridge Topology.
Choose an interface to act as the Primary Bridge Interface. Refer to the “L2 Bridge Interface
Zone Selection” section on page 201 for information in making this selection. In this example,
we will use X1 (automatically assigned to the Primary WAN):

SonicOS 5.8.1 Administrator Guide

253

Network > Interfaces

Configuring the Primary Bridge Interface
Step 1

Select the Network tab, Interfaces folder from the navigation panel.

Step 2

Click the Configure

Step 3

Configure the interface with a Static IP address (e.g. 192.168.0.12).

Note

icon in the right column of the X1 (WAN) interface.

The Primary Bridge Interface must have a Static IP assignment.

Step 4

Configure the default gateway. This is required for the security appliance itself to reach the
Internet. (This applies only to WAN interfaces.)

Step 5

Configure the DNS server. (This applies only to WAN interfaces.)

Step 6

Configure management (HTTP, HTTPS, Ping, SNMP, SSH, User Logins, HTTP Redirects).

Step 7

Click OK.

Choose an interface to act as the Secondary Bridge Interface. Refer to the L2 Bridge Interface
Zone Selection for information in making this selection. In this example, we will use X0
(automatically assigned to the LAN):

254

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

Configuring the Secondary Bridge Interface
Step 1

On the Network > Interfaces page, click the Configure
(LAN) interface.

icon in the right column of the X0

Step 2

In the IP Assignment drop-down list, select Layer 2 Bridged Mode.

Step 3

In the Bridged to drop-down list, select the X1 interface.

Step 4

Configure management (HTTP, HTTPS, Ping, SNMP, SSH, User Logins, HTTP Redirects).

Step 5

You may optionally enable the Block all non-IPv4 traffic setting to prevent the L2 bridge from
passing non-IPv4 traffic.
VLAN Filtering (on SonicWALL NSA series appliances)
•

You may also optionally navigate to the VLAN Filtering tab to control VLAN traffic through
the L2 bridge. By default, all VLANs are allowed:
– Select Block listed VLANs (blacklist) from the drop-down list and add the VLANs you

wish to block from the left pane to the right pane. All VLANs added to the right pane will
be blocked, and all VLANs remaining in the left pane will be allowed.
– Select Allow listed VLANs (whitelist) from the drop-down list and add the VLANs you

wish to explicitly allow from the left pane to the right pane. All VLANs added to the right
pane will be allowed, and all VLANs remaining in the left pane will be blocked.
Step 6

Click OK.
The Network > Interfaces page displays the updated configuration:
You may now apply security services to the appropriate zones, as desired. In this example, they
should be applied to the LAN, WAN, or both zones.

VLAN Integration with Layer 2 Bridge Mode
VLANs are supported on SonicWALL NSA series appliances. When a packet with a VLAN tag
arrives on a physical interface, the VLAN ID is evaluated to determine if it is supported. The
VLAN tag is stripped, and packet processing continues as it would for any other traffic. A
simplified view of the inbound and outbound packet path includes the following potentially
reiterative steps:
•

IP validation and reassembly

•

Decapsulation (802.1q, PPP)

•

Decryption

•

Connection cache lookup and management

•

Route policy lookup

•

NAT Policy lookup

•

Access Rule (policy) lookup

•

Bandwidth management

•

NAT translation

•

Advanced Packet Handling (as applicable)
– TCP validation
– Management traffic handling
– Content Filtering

SonicOS 5.8.1 Administrator Guide

255

Network > Interfaces

– Transformations and flow analysis (on SonicWALL NSA series appliances): H.323, SIP,

RTSP, ILS/LDAP, FTP, Oracle, NetBIOS, Real Audio, TFTP
– IPS and GAV

At this point, if the packet has been validated as acceptable traffic, it is forwarded to its
destination. The packet egress path includes:
•

Encryption

•

Encapsulation

•

IP fragmentation

On egress, if the route policy lookup determines that the gateway interface is a VLAN
subinterface, the packet is tagged (encapsulated) with the appropriate VLAN ID header. The
creation of VLAN subinterfaces automatically updates the SonicWALL’s routing policy table:

The auto-creation of NAT policies, Access Rules with regard to VLAN subinterfaces behave
exactly the same as with physical interfaces. Customization of the rules and policies that
govern the traffic between VLANs can be performed with customary SonicOS ease and
efficiency.

256

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

When creating a zone (either as part of general administration, or as a step in creating a
subinterface), a checkbox will be presented on the zone creation page to control the autocreation of a GroupVPN for that zone. By default, only newly created Wireless type zones will
have ‘Create GroupVPN for this zone’ enabled, although the option can be enabled for other
zone types by selecting the checkbox during creation.

Management of security services between VLAN subinterfaces is accomplished at the zone
level. All security services are configurable and applicable to zones comprising physical
interfaces, VLAN subinterfaces, or combinations of physical and VLAN subinterfaces.
Gateway Anti-Virus and Intrusion Prevention Services between the different workgroups can
easily be employed with the use of VLAN segmentation, obviating the need for dedicated
physical interfaces for each protected segment.
VLAN support enables organizations to offer meaningful internal security (as opposed to simple
packet filtering) between various workgroups, and between workgroups and server farms
without having to use dedicated physical interfaces on the SonicWALL.
Here the ability to assign VLAN subinterfaces to the WAN zone, and to use the WAN client
mode (only Static addressing is supported on VLAN subinterfaces assigned to the WAN zone)
is illustrated, along with the ability to support WAN Load Balancing and failover. Also
demonstrated is the distribution of SonicPoints throughout the network by means of connecting
them to access mode VLAN ports on workgroup switches. These switches are then backhauled
to the core switch, which then connects all the VLANs to the appliance via a trunk link.

SonicOS 5.8.1 Administrator Guide

257

Network > Interfaces

VPN Integration with Layer 2 Bridge Mode
When configuring a VPN on an interface that is also configured for Layer 2 Bridge mode, you
must configure an additional route to ensure that incoming VPN traffic properly traverses the
SonicWALL security appliance. Navigate to the Network > Routing page, scroll to the bottom
of the page, and click on the Add button. In the Add Route Policy window, configure the route
as follows:
•

Source: ANY

•

Destination: custom-VPN-address-object (This is the address object for the local VPN
tunnel IP address range.)

•

Service: ANY

•

Gateway: 0.0.0.0

•

Interface: X0

Configuring IPS Sniffer Mode
To configure the SonicWALL NSA appliance for IPS Sniffer Mode, you will use two interfaces
in the same zone for the L2 Bridge-Pair. You can use any interfaces except the WAN interface.
For this example, we will use X2 and X3 for the Bridge-Pair, and configure them to be in the
LAN zone. The WAN interface (X1) is used by the SonicWALL appliance for access to the
SonicWALL Data Center as needed. The mirrored port on the switch will connect to one of the
interfaces in the Bridge-Pair.
This section contains the following topics:
•

“Configuration Task List for IPS Sniffer Mode” on page 258

•

“Configuring the Primary Bridge Interface” on page 259

•

“Configuring the Secondary Bridge Interface” on page 259

•

“Enabling and Configuring SNMP” on page 260

•

“Configuring Security Services (Unified Threat Management)” on page 262

•

“Configuring Logging” on page 262

•

“Connecting the Mirrored Switch Port to a IPS Sniffer Mode Interface” on page 262

•

“Connecting and Configuring the WAN Interface to the Data Center” on page 262

Configuration Task List for IPS Sniffer Mode
•

Configure the Primary Bridge Interface
– Select LAN as the Zone for the Primary Bridge Interface
– Assign a static IP address

•

Configure the Secondary Bridge Interface
– Select LAN as the Zone for the Secondary Bridge Interface
– Enable the L2 Bridge to the Primary Bridge interface

258

•

Enable SNMP and configure the IP address of the SNMP manager system where traps can
be sent

•

Configure Security Services (UTM) for LAN traffic

•

Configure logging alert settings to “Alert” or below

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

•

Connect the mirrored port on the switch to either one of the interfaces in the Bridge-Pair

•

Connect and configure the WAN to allow access to dynamic signature data over the
Internet

Configuring the Primary Bridge Interface
Step 1

Select the Network tab, Interfaces folder from the navigation panel.

Step 2

Click the Configure icon in the right column of interface X2.

Step 3

In the Edit Interface dialog box on the General tab, select LAN from the Zone drop-down list.
Note that you do not need to configure settings on the Advanced or VLAN Filtering tabs.

Step 4

For IP Assignment, select Static from the drop-down list.

Step 5

Configure the interface with a static IP Address (e.g. 10.1.2.3). The IP address you choose
should not collide with any of the networks that are seen by the switch.

Note

The Primary Bridge Interface must have a static IP assignment.

Step 6

Configure the Subnet Mask.

Step 7

Type in a descriptive comment.

Step 8

Select management options for the interface (HTTP, HTTPS, Ping, SNMP, SSH, User Logins,
HTTP Redirects).

Step 9

Click OK.

Configuring the Secondary Bridge Interface
Our example continues with X3 as the secondary bridge interface.
Step 1

Select the Network tab, Interfaces folder from the navigation panel.

Step 2

Click the Configure icon in the right column of the X3 interface.

SonicOS 5.8.1 Administrator Guide

259

Network > Interfaces

Step 3

In the Edit Interface dialog box on the General tab, select LAN from the Zone drop-down list.
Note that you do not need to configure settings on the Advanced or VLAN Filtering tabs.

Step 4

In the IP Assignment drop-down list, select Layer 2 Bridged Mode.

Step 5

In the Bridged to drop-down list, select the X2 interface.

Step 6

Do not enable the Block all non-IPv4 traffic setting if you want to monitor non-IPv4 traffic.

Step 7

Select Never route traffic on this bridge-pair to ensure that the traffic from the mirrored
switch port is not sent back out onto the network. (The Never route traffic on this bridge-pair
setting is known as Captive-Bridge Mode.)

Step 8

Select Only sniff traffic on this bridge-pair to enable sniffing or monitoring of packets that
arrive on the L2 Bridge from the mirrored switch port.

Step 9

Select Disable stateful-inspection on this bridge-pair to allow TCP connections to pass
through the SonicWALL even if the device has not seen a valid and complete TCP handshake
sequence. This can be used for networks employing asymmetric packet paths for incoming and
outgoing traffic in which the SonicWALL does not see all traffic of the TCP flow. Use of this setting
is not recommended as it limits the SonicWALL’s ability to enforce TCP stateful and other
protections for the secured network.

Step 10 Configure management (HTTP, HTTPS, Ping, SNMP, SSH, User Logins, HTTP Redirects).
Step 11 Click OK.

Enabling and Configuring SNMP
When SNMP is enabled, SNMP traps are automatically triggered for many events that are
generated by SonicWALL Security Services such as Intrusion Prevention and Gateway AntiVirus.
More than 50 IPS and GAV events currently trigger SNMP traps. The SonicOS Log Event
Reference Guide contains a list of events that are logged by SonicOS, and includes the SNMP
trap number where applicable. The guide is available online at
http://www.sonicwall.com/us/Support.html by typing Log Event into the Search field at the top
of the page.

260

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

To determine the traps that are possible when using IPS Sniffer Mode with Intrusion Prevention
enabled, search for Intrusion in the table found in the Index of Log Event Messages section in
the SonicOS Log Event Reference Guide. The SNMP trap number, if available for that event,
is printed in the SNMP Trap Type column of the table.
To determine the possible traps with Gateway Anti-Virus enabled, search the table for Security
Services, and view the SNMP trap number in the SNMP Trap Type column.
To enable and configure SNMP:
Step 1

Select the System tab, Administration folder from the navigation panel.

Step 2

Scroll down to the Advanced Management section.

Step 3

Select the Enable SNMP checkbox. The Configure button becomes active.

Step 4

Click Configure. The SNMP Settings dialog box is displayed.

Step 5

In the SNMP Settings dialog box, for System Name, type the name of the SNMP manager
system that will receive the traps sent from the SonicWALL.

Step 6

Enter the name or email address of the contact person for the SNMP Contact

Step 7

Enter a description of the system location, such as “3rd floor lab”.

Step 8

Enter the system’s asset number.

Step 9

For Get Community Name, type the community name that has permissions to retrieve SNMP
information from the SonicWALL, e.g. public.

Step 10 For Trap Community Name, type the community name that will be used to send SNMP traps

from the SonicWALL to the SNMP manager, e.g. public.
Step 11 For the Host fields, type in the IP address(es) of the SNMP manager system(s) that will receive

the traps.
Step 12 Click OK.

SonicOS 5.8.1 Administrator Guide

261

Network > Interfaces

Configuring Security Services (Unified Threat Management)
The settings that you enable in this section will control what type of malicious traffic you detect
in IPS Sniffer Mode. Typically you will want to enable Intrusion Prevention, but you may also
want to enable other Security Services such as Gateway Anti-Virus or Anti-Spyware.
To enable Security Services, your SonicWALL must be licensed for them and the signatures
must be downloaded from the SonicWALL Data Center. For complete instructions on enabling
and configuring IPS, GAV, and Anti-Spyware, see the Security Services section in this guide.

Configuring Logging
You can configure logging to record entries for attacks that are detected by the SonicWALL.
To enable logging, perform the following steps:
Step 1

Select the Log tab, Categories folder from the navigation panel.

Step 2

Under Log Categories, select All Categories in the View Style drop-down list.

Step 3

In the Attacks category, enable the checkboxes for Log, Alerts, and Syslog.

Step 4

Click Apply.

Connecting the Mirrored Switch Port to a IPS Sniffer Mode Interface
Use a standard Cat-5 Ethernet cable to connect the mirrored switch port to either interface in
the Bridge-Pair. Network traffic will automatically be sent from the switch to the SonicWALL
where it can be inspected.
Consult the switch documentation for instructions on setting up the mirrored port.

Connecting and Configuring the WAN Interface to the Data Center
Connect the WAN port on the SonicWALL, typically port X1, to your gateway or to a device with
access to the gateway. The SonicWALL communicates with the SonicWALL Data Center
automatically. For detailed instructions on configuring the WAN interface, see “Configuring a
WAN Interface” on page 225.

Configuring Wire Mode
Adding to the broad collection of traditional modes of SonicOS interface operation, including all
LAN modes (Static, NAT, Transparent Mode, L2 Bridge Mode, Portshield Switch Mode), and all
WAN modes (Static, DHCP, PPPoE, PPTP, and L2TP), SonicOS 5.8 introduces Wire-Mode,
which provides four new methods non-disruptive, incremental insertion into networks.
Restrict analysis at resource limit

262

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

Table 1

Wire Mode Settings

Wire Mode Setting Description
Bypass Mode

Bypass Mode allows for the quick and relatively non-interruptive
introduction of Wire Mode into a network. Upon selecting a point of
insertion into a network (e.g. between a core switch and a perimeter
firewall, in front of a VM server farm, at a transition point between data
classification domains) the SonicWALL security appliance is inserted
into the physical data path, requiring a very short maintenance window.
One or more pairs of switch ports on the appliance are used to forward
all packets across segments at full line rates. While Bypass Mode does
not offer any inspection or firewalling, this mode allows the administrator
to physically introduce the SonicWALL security appliance into the
network with a minimum of downtime and risk, and to obtain a level of
comfort with the newly inserted component of the networking and
security infrastructure. The administrator can then transition from
Bypass Mode to Inspect or Secure Mode instantaneously through a
simple user-interface driven reconfiguration.

Inspect Mode

Inspect Mode extends Bypass Mode without functionally altering the
low-risk, zero-latency packet path. Packets continue to pass through the
SonicWALL security appliance, but they are also mirrored to the multicore RF-DPI engine for the purposes of passive inspection,
classification, and flow reporting. This reveals the appliance’s
Application Intelligence and threat detection capabilities without any
actual intermediate processing.
When Inspect Mode is selected, the Restrict analysis at resource limit
option specifies whether all traffic is inspected. When this option is
enabled (which is the default), the appliance scans the maximum
number of packets it can process. The remaining packets are allowed to
pass without inspection. If this option is disabled, traffic will be throttled
in the flow of traffic exceeds the firewalls inspection ability.

Note

Disabling the Restrict analysis at resource limit option will
reduce throughput if the rate of traffic exceeds the appliance’s
ability to scan all traffic.

SonicOS 5.8.1 Administrator Guide

263

Network > Interfaces

Table 1

Wire Mode Settings

Wire Mode Setting Description

264

Secure Mode

Secure Mode is the progression of Inspect Mode, actively interposing
the SonicWALL security appliance’s multi-core processors into the
packet processing path. This unleashes the inspection and policy
engines’ full-set of capabilities, including Application Intelligence and
Control, Intrusion Prevention Services, Gateway and Cloud-based AntiVirus, Anti-Spyware, and Content Filtering. Secure Mode affords the
same level of visibility and enforcement as conventional NAT or L2
Bridge mode deployments, but without any L3/L4 transformations, and
with no alterations of ARP or routing behavior. Secure Mode thus
provides an incrementally attainable NGFW deployment requiring no
logical and only minimal physical changes to existing network designs.

Tap Mode

Tap Mode provides the same visibility as Inspect Mode, but differs from
the latter in that it ingests a mirrored packet stream via a single switch
port on the SonicWALL security appliance, eliminating the need for
physically intermediated insertion. Tap Mode is designed for use in
environments employing network taps, smart taps, port mirrors, or SPAN
ports to deliver packets to external devices for inspection or collection.
Like all other forms of Wire Mode, Tap Mode can operate on multiple
concurrent port instances, supporting discrete streams from multiple
taps.

SonicOS 5.8.1 Administrator Guide

Network > Interfaces

To summarize the key functional differences between modes of interface configuration:
Table 2

Functionality of the Different Wire Mode Settings

Bypass
Mode

Inspect Secure Tap
Mode
Mode
Mode

L2 Bridge, Transparent,
NAT, Route Modes

Active/Active Clustering 1 No

No

No

No

No

Application Control

No

No

Yes

No

Yes

Application Visibility

No

Yes

Yes

Yes

Yes

1

No

No

No

No

Yes

Comprehensive
Anti-Spam Service 1

No

No

No

No

Yes

Content Filtering

No

No

Yes

No

Yes

No

No

No

No

Yes 2

DPI Detection

No

Yes

Yes

Yes

Yes

DPI Prevention

No

No

Yes

No

Yes

No

No

No

No

Yes

Yes

Yes

Yes

Yes

Yes

No

No

No

No

No

SPI

No

Yes

Yes

Yes

Yes

TCP Handshake
Enforcement 4

No

No

No

No

Yes

Virtual Groups 1

No

No

No

No

Yes

ARP/Routing/NAT

DHCP Server

1

DPI-SSL1
High-Availability

1

Link-State Propagation

3

1. These functions or services are unavailable on interfaces configured in Wire Mode, but remain available
on a system-wide level for any interfaces configured in other compatible modes of operation.
2. Not available in L2 Bridge Mode.
3.Link State Propagation is a feature whereby interfaces in a Wire-Mode pair will mirror the link-state
triggered by transitions of their partners. This is essential to proper operations in redundant path
networks, in particular.
4. Disabled by design in Wire Mode to allow for failover events occurring elsewhere on the network to be
supported when multiple Wire-Mode paths, or when multiple SonicWALL security appliance units are in use
along redundant or asymmetric paths.

Note

When operating in Wire-Mode, the SonicWALL security appliance’s dedicated
“Management” interface will be used for local management. To enable remote management
and dynamic security services and application intelligence updates, a WAN interface
(separate from the Wire-Mode interfaces) must be configured for Internet connectivity. This
is easily done given that SonicOS supports interfaces in mixed-modes of almost any
combination.
To configure an interface for Wire Mode, perform the following steps:
1.

On the Network > Interfaces page, click the Configure button for the interface you want to
configure for Wire Mode.

2.

In the Zone pulldown menu, select LAN.

SonicOS 5.8.1 Administrator Guide

265

Network > Interfaces

3.

To configure the Interface for Tap Mode, in the Mode / IP Assignment pulldown menu,
select Tap Mode (1-Port Tap) and click OK.

4.

To configure the Interface for Wire Mode, in the Mode / IP Assignment pulldown menu,
select Wire Mode (2-Port Wire).

5.

In the Wire Mode Type pulldown menu, select the appropriate mode:
– Bypass Mode (via Internal Switch / Relay)
– Inspect Mode (Passive DPI of Mirrored Traffic)
– Secure Mode (Active DPI of Inline Traffic)

6.

Note

Disabling the Restrict analysis at resource limit option will reduce throughput if the rate
of traffic exceeds the appliance’s ability to scan all traffic.
7.

Note

In the Paired Interface pulldown menu, select the interface that will connect to the
upstream firewall. The paired interfaces must be of the same type (two 1 GB interfaces or
two 10 GB interfaces).

Only unassigned interfaces are available in the Paired Interface pulldown menu. To make
an interface unassigned, click on the Configure button for it, and in the Zone pulldown menu,
select Unassigned.
8.

266

When Inspect Mode is selected, the Restrict analysis at resource limit option is
displayed. It is enabled by default. When this option is enabled, the appliance scans the
maximum number of packets it can process. The remaining packets are allowed to pass
without inspection. If this option is disabled, traffic will be throttled in the flow of traffic
exceeds the firewalls inspection ability.

Click OK.

SonicOS 5.8.1 Administrator Guide

CHAPTER 16
Chapter 16:

Configuring PortShield Interfaces

Network > PortShield Groups
PortShield architecture enables you to configure some or all of the LAN ports into separate
security contexts, providing protection not only from the WAN and DMZ, but between devices
inside your network as well. In effect, each context has its own wire-speed PortShield that enjoy
the protection of a dedicated, deep packet inspection firewall.
PortShield is supported on SonicWALL TZ Series and NSA 240 appliances.

Tip

Zones can always be applied to multiple interfaces in the Network > Interfaces page, even
without the use of PortShield groupings. However, these interfaces will not share the same
network subnet unless they are grouped using PortShield.
You can assign any combination of ports into a PortShield interface. All ports you do not assign
to a PortShield interface are assigned to the LAN interface.

SonicOS 5.8.1 Administrator Guide

267

Network > PortShield Groups

The Network > PortShield Groups page allows you to manage the assignments of ports to
PortShield interfaces.

Static Mode and Transparent Mode
A PortShield interface is a virtual interface with a set of ports assigned to it. There are two IP
assignment methods you can deploy to create PortShield interfaces. They are Static and
Transparent modes. The following two sections describe each.

Working in Static Mode
When you create a PortShield interface in Static Mode, you manually create an explicit address
to be applied to the PortShield interface. All ports mapped to the interface are identified by this
address. Static mode is available on interfaces assigned to Trusted, Public, or Wireless zones.

Note

When you create a PortShield interface in Static Mode, make sure the IP address you assign
to the interface is not already in use by another PortShield interface.

Working in Transparent Mode
Transparent Mode addressing allows for the WAN subnetwork to be shared by the current
interface using Address Object assignments. The interface’s IP address is the same as the
WAN interface IP address. Transparent mode is available on interfaces assigned to Trusted
and Public Zones.

268

SonicOS 5.8.1 Administrator Guide

Network > PortShield Groups

Note

Make sure the IP address you assign to the PortShield interface is within the WAN
subnetwork.
When you create a PortShield interface in Transparent Mode, you create a range of addresses
to be applied to the PortShield interface. You include these addresses in one entity called an
Address Object. Address Objects allow for entities to be defined one time and to be re-used in
multiple referential instances throughout the SonicOS interface. When you create a PortShield
interface using an address object, all ports mapped to the interface are identified by any of the
addresses specified in the address range.

Note

Each statically addressed PortShield interface must be on a unique subnetwork. You can
not overlap PortShield interfaces across multiple subnetworks.

Configuring PortShield Groups
There are several ways to configure PortShield groups:
•

“Configuring PortShield Interfaces from the Network > Interfaces Page” on page 269

•

“Configuring PortShield Interfaces from the Network > PortShield Groups Page” on
page 270

•

“Configuring PortShield Interfaces with the PortShield Wizard” on page 272

Configuring PortShield Interfaces from the Network > Interfaces Page
To configure a PortShield interface, perform the following steps:
1.

Click on the Network > Interfaces page.

SonicOS 5.8.1 Administrator Guide

269

Network > PortShield Groups

Note

2.

Click the Configure button for the interface you want to configure. The Edit Interface
window displays.

3.

In the Zone pulldown menu, select on a zone type option to which you want to map the
interface.

You can add PortShield interfaces only to Trusted, Public, and Wireless zones.
4.

In the IP Assignment pulldown menu, select PortShield Switch Mode.

5.

In the PortShield to pulldown menu, select the interface you want to map this port to. Only
ports that match the zone you have selected are displayed.

Configuring PortShield Interfaces from the Network > PortShield Groups Page
The Network > PortShield Groups page displays a graphical representation of the current
configuration of PortShield interfaces.

270

•

Interfaces in black are not part of a PortShield group.

•

Interfaces in yellow have been selected to be configured

SonicOS 5.8.1 Administrator Guide

Network > PortShield Groups

•

Interfaces that are the same color (other than black or yellow) are part of a PortShield
group, with the master interface having a white outline around the color.

•

Interfaces that are greyed out cannot be added to a PortShield group.

On the Network > PortShield Groups page, you can manually group ports together using the
graphical PortShield Groups interface. Grouping ports allows them to share a common network
subnet as well as common zone settings.

Note

Interfaces must be configured before being grouped with PortShield.
To configure PortShield groups, perform the following steps:
1.

In the graphic, select the interface(s) you want to configure as part of a PortShield group.
The interfaces will turn yellow.

2.

Click the Configure button.

In the Port Enabled pulldown menu, select whether you want to enable or disable the
interfaces.
In the PortShield Interface pulldown menu, select which interface you want to assign as the
master interface for these PortShield interfaces.
In the Link Speed pulldown menu, select the link speed for the interfaces.

SonicOS 5.8.1 Administrator Guide

271

Network > PortShield Groups

Configuring PortShield Interfaces with the PortShield Wizard
The PortShield Wizard quickly and easily guides you through several common PortShield group
configurations. To use the PortShield wizard, perform the following steps:
1.

Click the Wizards button on the top right of the SonicOS UI and select PortShield
Interface Wizard. Click Next.

Mousing over the i symbol displays a summary of the current port assignment.

2.
•

272

Select one of the four PortShield group options:
Basic WAN/LAN Switch

SonicOS 5.8.1 Administrator Guide

Network > PortShield Groups

•

WAN/OPT/LAN Switch

•

WAN/LAN/HA

Note

•

In the WAN/LAN/HA scenario, when High Availability is not enabled, the X6 port is
assigned to the LAN zone.

WAN/LAN/LAN2 Switch

3.

Click Next.

4.

The wizard displays a summary of the configuration changes it is about to make.

5.

Click Apply.

SonicOS 5.8.1 Administrator Guide

273

Network > PortShield Groups

274

SonicOS 5.8.1 Administrator Guide

CHAPTER 17
Chapter 17:

Setting Up Failover and Load Balancing

Network > Failover & Load Balancing
This chapter contains the following sections:
•

“Failover and Load Balancing” on page 275

•

“Load Balancing Statistics” on page 278

•

“Multiple WAN (MWAN)” on page 279

Failover and Load Balancing
For Failover & Load Balancing (LB), up to four WAN members are supported:
•

Primary WAN Ethernet Interface

•

Alternate WAN #1

•

Alternate WAN #2

•

Alternate WAN #3

The Primary WAN Ethernet Interface has the same meaning as the previous firmware’s
concept of “Primary WAN.” It is the highest ranked WAN interface in the LB group. The
Alternate WAN #1 corresponds to “Secondary WAN,” it has a lower rank than the Primary
WAN, but has a higher rank than the next two alternates. The others, Alternate WAN #2 and
Alternate WAN #3, are new, with Alternate WAN #3 being the lowest ranked among the four
WAN members of the LB group.
The Failover and Load Balancing settings are described below:
•

Enable Load Balancing—This option must be enabled for the user to access the LB
Groups and LB Statistics section of the Failover & Load Balancing configuration. If
disabled, no options for Failover & Load Balancing are available to be configured.

•

Respond to Probes—When enabled, the appliance can reply to probe request packets
that arrive on any of the appliance’s interfaces.

SonicOS 5.8.1 Administrator Guide

275

Network > Failover & Load Balancing

•

Any TCP-SYN to Port—This option is available when the Respond to Probes option is
enabled. When selected, the appliance will only respond to TCP probe request packets
having the same packet destination address TCP port number as the configured value.

Load Balancing Members and Groups
LB Members added to a LB Group take on certain “roles.” A member can only work in one of
the following roles:
•

Primary—Only one member can be the Primary per Group. This member always appears
first or at the top of the Member List. Note that although a group can be configured with an
empty member list, it is impossible to have members without a Primary.

•

Alternate—More than one member can be an Alternate, however, it is not possible to have
a Group of only Alternate members.

•

Last-Resort—Only one member can be designed as Last-Resort. Last-Resort can only be
configured with other group members.

Each member in a group has a rank. Members are displayed in descending order of rank. The
rank is determined by the order of interfaces as they appear in the Member List for the group.
The order is important in determining the usage preferences of the Interfaces, as well as the
level of precedence within the group. Thus, no two interfaces within a group will have the same
or equal rank; each Interface will have a distinct rank.

276

SonicOS 5.8.1 Administrator Guide

Network > Failover & Load Balancing

General Tab
To configure the Group Member Rank settings, click the Configure icon of the Group you wish
to configure on the Network > Failover & LB page. The General tab screen displays.

The General tab allows the user to do modify the following settings:
•

Display name—Edit the display name of the Group

•

Type (or method) of LB—Choose the type of LB from the dropdown list (Basic Active/
Passive Failover, Round Robin, Spillover-Based, or Percentage-Based).
– Basic Active/Passive Failover—The four WAN interfaces use ‘rank’ to determine the

order of preemption when the Preempt checkbox has been enabled. Only a higherranked interface can preempt an Active WAN interface.
– Round Robin—This option now allows the user to re-order the WAN interfaces for

Round Robin selection. The order is as follows: Primary WAN, Alternate WAN #1,
Alternate WAN #2, and Alternate WAN #3; the Round Robin will then repeat back to the
Primary WAN and continue the order.
– Spillover—The bandwidth threshold applies to the Primary WAN. Once the threshold

is exceeded, new traffic flows are allocated to the Alternates in a Round Robin manner.
Once the Primary WAN bandwidth goes below the configured threshold, Round Robin
stops, and outbound new flows will again be sent out only through the Primary WAN.
Note that existing flows will remain associated with the Alternates (since they are
already cached) until they timeout normally.
– Ratio—There are now four fields so that percentages can be set for each WAN in the

LB group. To avoid problems associated with configuration errors, please ensure that
the percentage correctly corresponds to the WAN interface it indicates.
•

Add/delete member interfaces—Members can be added by selecting a displayed
interface from the “Group Members:” column, and then clicking the Add>> button. Note that
the interface listed at the top of the list is the Primary. Members can be deleted from the
“Selected:” column by selecting the displayed interface, and then clicking the Remove>>
button.

SonicOS 5.8.1 Administrator Guide

277

Network > Failover & Load Balancing

Note

The Interface Rank does not specify the operation that will be performed on the individual
member. The operation that will be performed is specified by the Group Type.

Probing Tab
When Logical probing is enabled, test packets can be sent to remote probe targets to verify
WAN path availability. A new option has been provided to allow probing through the additional
WAN interfaces: Alternate WAN #3 and Alternate WAN #4.

Note

VLANs for alternate WANs do not support QoS or VPN termination.
To configure the probing options for a specific Group, click the Configure icon of the Group
you wish to configure on the Network > Failover & LB page. Then, click the Probing tab.

The Probing tab allows the user to modify the following settings:
•

Check Interface—The interval of health checks in units of seconds

•

Deactivate Interface—After a series of failed health checks, the interface sets to “Failover”

•

Reactivate Interface—After a series of successful health checks, the interface sets to
“Available”

•

Probe responder.global.sonicwall.com on all interfaces in this group—Enable this
checkbox to automatically set Logical/Probe Monitoring on all interfaces in the Group.
When enabled, this sends TCP probe packets to the global SNWL host that responds to
SNWL TCP packets, responder.global.sonicwall.com, using a target probe destination
address of 204.212.170.23:50000. Once this checkbox is selected, the rest of the probe
configuration will automatically enable built-in settings. The same probe will be applied to
all four WAN Ethernet interfaces. Note that the Dialup WAN probe setting also defaults to
the built-in settings.

Load Balancing Statistics
The Load Balancing Statistics table displays the following LB group statistics for the
SonicWALL:

278

•

Total Connections

•

New Connection

•

Current Ratio

•

Average Ratio

•

Total Unicast Bytes

•

Rx Unicast

•

Rx Bytes

SonicOS 5.8.1 Administrator Guide

Network > Failover & Load Balancing

•

Tx Unicast

•

Tx Bytes

•

Throughput (KB/s)

•

Throughput (Kbits/s)

In the Display Statistics for pulldown menu, select which LB group you want to view statistics
for.
Click the Clear Statistic button on the bottom right of the Network > Failover & LB page to
clear information from the Load Balancing Statistics table.

Multiple WAN (MWAN)
The Multiple WAN (MWAN) feature allows the administrator to configure all but one of the
appliance's interface for WAN network routing (one interface must remain configured for the
LAN zone for local administration). All of the WAN interfaces can be probed using the SNWL
Global Responder host.

Network Interfaces
The Network Interfaces page allows more than two WAN interfaces to be configured for routing.
It is possible to configure WAN interfaces in the Network Interfaces page, but not include them
in the Failover & LB. Only the Primary WAN Ethernet Interface is required to be part of the LB
group whenever LB has been enabled. Any WAN interface that does not belong to the LB group
is not included in the LB function, but performs normal WAN routing functions.

Note

A virtual WAN interface may belong to the LB group. However, prior to using within the LB
group, please ensure that the virtual WAN network is fully routable like that of a physical
WAN.

SonicOS 5.8.1 Administrator Guide

279

Network > Failover & Load Balancing

Routing the Default & Secondary Default Gateways
Because the gateway address objects previously associated with the Primary WAN and
Secondary WAN are now deprecated, user-configured Static Routes need to be re-created in
order to use the correct gateway address objects associated with the WAN interfaces. This will
have to be configured manually as part of the firmware upgrade procedure.

The old address object Default Gateway corresponds to the default gateway associated with
the Primary WAN in the LB group. The Secondary Default Gateway corresponds to the default
gateway associated with Alternate WAN #1.

Note

280

After re-adding the routes, delete the old ones referring to the Default and Secondary
Default Gateways.

SonicOS 5.8.1 Administrator Guide

Network > Failover & Load Balancing

DNS
When DNS name resolution issues are encountered with this firmware, you may need to select
the Specify DNS Servers Manually option and set the servers to Public DNS Servers (ICANN
or non-ICANN).

Note

Depending on your location, some DNS Servers may respond faster than others. Verify that
these servers work correctly from your installation prior to using your SonicWALL appliance.

SonicOS 5.8.1 Administrator Guide

281

Network > Failover & Load Balancing

282

SonicOS 5.8.1 Administrator Guide

CHAPTER 18
Chapter 18:

Configuring Zones

Network > Zones
This section contains the following subsections:
•

“How Zones Work” on page 284

•

“The Zone Settings Table” on page 287

•

“Adding and Configuring Zones” on page 288

•

“Deleting a Zone” on page 289

•

“Configuring a Zone for Guest Access” on page 290

•

“Configuring the WLAN Zone” on page 293

A zone is a logical grouping of one or more interfaces designed to make management, such as
the definition and application of Access Rules, a simpler and more intuitive process than
following strict physical interface scheme. Zone-based security is a powerful and flexible
method of managing both internal and external network segments, allowing the administrator
to separate and protect critical internal network resources from unapproved access or attack.
A network security zone is simply a logical method of grouping one or more interfaces with
friendly, user-configurable names, and applying security rules as traffic passes from one zone
to another zone. Security zones provide an additional, more flexible, layer of security for the
firewall. With the zone-based security, the administrator can group similar interfaces and apply
the same policies to them, instead of having to write the same policy for each interface.
For more information on configuring interfaces, see “Network > Interfaces” on page 183.
SonicOS Enhanced zones allows you to apply security policies to the inside of the network. This
allows the administrator to do this by organizing network resources to different zones, and
allowing or restricting traffic between those zones. This way, access to critical internal
resources such as payroll servers or engineering code servers can be strictly controlled.
Zones also allow full exposure of the NAT table to allow the administrator control over the traffic
across the interfaces by controlling the source and destination addresses as traffic crosses
from one zone to another. This means that NAT can be applied internally, or across VPN

SonicOS 5.8.1 Administrator Guide

283

Network > Zones

tunnels, which is a feature that users have long requested. SonicWALL security appliances can
also drive VPN traffic through the NAT policy and zone policy, since VPNs are now logically
grouped into their own VPN zone.

How Zones Work
An easy way to visualize how security zones work is to imagine a large new building, with
several rooms inside the building, and a group of new employees that do not know their way
around the building. This building has one or more exits, which can be thought of as the WAN
interfaces. The rooms within the building have one or more doors, which can be thought of as
interfaces. These rooms can be thought of as zones inside each room are a number of people.
The people are categorized and assigned to separate rooms within the building. People in each
room going to another room or leaving the building, must talk to a doorperson on the way out
of each room. This doorperson is the inter-zone/intra-zone security policy, and the
doorperson’s job to consult a list and make sure that the person is allowed to go to the other
room, or to leave the building. If the person is allowed (i.e. the security policy lets them), they
can leave the room via the door (the interface).
Upon entering the hallway, the person needs to consult with the hallway monitor to find out
where the room is, or where the door out of the building is located. This hallway monitor
provides the routing process because the monitor knows where all the rooms are located, and
how to get in and out of the building. The monitor also knows the addresses of any of the remote
offices, which can be considered the VPNs. If the building has more than one entrance/exit
(WAN interfaces), the hallway monitor can direct people to use the secondary entrance/exit,
depending upon how they’ve been told to do so (i.e. only in an emergency, or to distribute the
traffic in and out of the entrance/exits). This function can be thought of as WAN Load Balancing.
There are times that the rooms inside the building have more than one door, and times when
there are groups of people in the room who are not familiar with one another. In this example,
one group of people uses only one door, and another group uses the other door, even though
groups are all in the same room. Because they also do not recognize each other, in order to
speak with someone in another group, the users must ask the doorperson (the security policy)
to point out which person in the other group is the one with whom they wish to speak. The
doorperson has the option to not let one group of people talk to the other groups in the room.
This is an example of when zones have more than one interface bound to them, and when intrazone traffic is not allowed.
Sometimes, people will wish to visit remote offices, and people may arrive from remote offices
to visit people in specific rooms in the building. These are the VPN tunnels. The hallway and
doorway monitors check to see if this is allowed or not, and allow traffic through. The

284

SonicOS 5.8.1 Administrator Guide

Network > Zones

doorperson can also elect to force people to put on a costume before traveling to another room,
or to exit, or to another remote office. This hides the true identity of the person, masquerading
the person as someone else. This process can be thought of as the NAT policy.

Predefined Zones
The predefined zones on your the SonicWALL security appliance depend on the device.The
predefined security zones on the SonicWALL security appliance are not modifiable and are
defined as follows:

Note

•

WAN: This zone can consist of either one or two interfaces. If you’re using the security
appliance’s WAN failover capability, you need to add the second Internet interface to the
WAN zone.

•

LAN: This zone can consist of one to five interfaces, depending on your network design.
Even though each interface will have a different network subnet attached to it, when
grouped together they can be managed as a single entity.

•

DMZ: This zone is normally used for publicly accessible servers. This zone can consist of
one to four interfaces, depending on you network design.

•

VPN: This virtual zone is used for simplifying secure, remote connectivity. It is the only zone
that does not have an assigned physical interface.

•

MULTICAST: This zone provides support for IP multicasting, which is a method for sending
IN packets from a single source simultaneously to multiple hosts.

•

WLAN: This zone provides support to SonicWALL SonicPoints. When assigned to the Opt
port, it enforces SonicPoint Enforcement, automatically dropping all packets received from
non-SonicPoint devices. The WLAN zone supports SonicPoint Discovery Protocol (SDP) to
automatically poll for and identify attached SonicPoints. It also supports SonicWALL Simple
Provisioning Protocol to configure SonicPoints using profiles.

Even though you may group interfaces together into one security zone, this does not
preclude you from addressing a single interface within the zone.

Security Types
Each zone has a security type, which defines the level of trust given to that zone. There are five
security types:
•

Trusted: Trusted is a security type that provides the highest level of trust—meaning that
the least amount of scrutiny is applied to traffic coming from trusted zones. Trusted security
can be thought of as being on the LAN (protected) side of the security appliance. The LAN
zone is always Trusted.

•

Encrypted: Encrypted is a security type used exclusively by the VPN zone. All traffic to and
from an Encrypted zone is encrypted.

•

Wireless: Wireless is a security type applied to the WLAN zone or any zone where the only
interface to the network consists of SonicWALL SonicPoint devices. Wireless security type
is designed specifically for use with SonicPoint devices. Placing an interface in a Wireless
zone activates SDP (SonicWALL Discovery Protocol) and SSPP (SonicWALL Simple
Provisioning Protocol) on that interface for automatic discovery and provisioning of
SonicPoint devices. Only traffic that passes through a SonicPoint is allowed through a
Wireless zone; all other traffic is dropped.

SonicOS 5.8.1 Administrator Guide

285

Network > Zones

Note

•

Public: A Public security type offers a higher level of trust than an Untrusted zone, but a
lower level of trust than a Trusted zone. Public zones can be thought of as being a secure
area between the LAN (protected) side of the security appliance and the WAN
(unprotected) side. The DMZ, for example, is a Public zone because traffic flows from it to
both the LAN and the WAN. By default traffic from DMZ to LAN is denied. But traffic from
LAN to ANY is allowed. This means only LAN initiated connections will have traffic between
DMZ and LAN. The DMZ will only have default access to the WAN, not the LAN.

•

Untrusted: The Untrusted security type represents the lowest level of trust. It is used by
both the WAN and the virtual Multicast zone. An Untrusted zone can be thought of as being
on the WAN (unprotected) side of the security appliance.By default, traffic from Untrusted
zones is not permitted to enter any other zone type without explicit rules, but traffic from
every other zone type is permitted to Untrusted zones.

When creating custom zones, the security type can be set to either Trusted, Public, or
Wireless.

Allow Interface Trust
The Allow Interface Trust setting in the Add Zone window automates the creation of Access
Rules to allow traffic to flow between the interface of a zone instance. For example, if the LAN
zone has both the LAN and X3 interfaces assigned to it, checking Allow Interface Trust on
the LAN zone creates the necessary Access Rules to allow hosts on these interfaces to
communicate with each other.

Enabling SonicWALL Security Services on Zones
You can enable SonicWALL Security Services for traffic across zones. For example, you can
enable SonicWALL Intrusion Prevention Service for incoming and outgoing traffic on the WLAN
zone to add more security for internal network traffic. You can enable the following SonicWALL
Security Services on zones:

286

•

Enforce Content Filtering Service – Enforces content filtering on multiple interfaces in the
same Trusted, Public and WLAN zones. After enabling this, select the appropriate CFS
Policy in the pulldown menu.

•

Enforce Client AV Enforcement Service – Enforces anti-virus protection on multiple
interfaces in the same Trusted, Public or WLAN zones.

•

Enable Gateway Anti-Virus Service – Enforces gateway anti-virus protection on multiple
interfaces in the same Trusted, Public or WLAN zones.

•

Enable IPS – Enforces intrusion detection and prevention on multiple interfaces in the
same Trusted, Public or WLAN zones.

•

Enable App Control Service – Enforces App Control to create network policy object-based
control rules to filter network traffic flows.

•

Enable Anti-Spyware Service – Enforces anti-spyware detection and prevention on
multiple interfaces in the same Trusted, Public or WLAN zones.

•

Enforce Global Security Clients – Requires users on this zone to use the Global Security
client for desktop security.

•

Create Group VPN – Creates a GroupVPN policy for the zone, which is displayed in the
VPN Policies table on the VPN > Settings page. You can customize the GroupVPN policy
on the VPN > Settings page. If you uncheck Create Group VPN, the GroupVPN policy is
removed from the VPN > Settings page.

SonicOS 5.8.1 Administrator Guide

Network > Zones

•

Enable SSL Control – Requires inspection of all new SSL connections initiated from the
zone. Note that SSL Control must first be enabled globally on the Firewall > SSL Control
page. For more information, see “Firewall Settings > SSL Control” on page 777.

•

Enable SSLVPN Access – Enables users to establish SSL VPN connections to this zone.
For more information, see “SSL VPN” on page 931.

The Zone Settings Table
The Zone Settings table displays a listing of all the SonicWALL security appliance default
predefined zones as well as any zones you create.

The table displays the following status information about each zone configuration:
•

Name: Lists the name of the zone. The predefined LAN, WAN, WLAN, VPN, and
Encrypted zone names cannot be changed.

•

Security Type: Displays the security type: Trusted, Untrusted, Public, Wireless, or
Encrypted.

•

Member Interfaces: Displays the interfaces that are members of the zone.

•

Interface Trust: A check mark indicates the Allow Interface Trust setting is enabled for
the zone.

•

Content Filtering: A check mark indicates SonicWALL Content Filtering Service is enabled
for traffic coming in and going out of the zone.

•

Client Anti-Virus: A check mark indicates SonicWALL Client Anti-Virus is enabled for
traffic coming in and going out of the zone. SonicWALL Client Anti-Virus manages an antivirus client application on all clients on the zone.

•

Gateway Anti-Virus: A check mark indicates SonicWALL Gateway Anti-Virus is enabled
for traffic coming in and going out of the zone. SonicWALL Gateway Anti-Virus manages
the anti-virus service on the SonicWALL appliance.

•

Anti-Spyware Service - A check mark indicates SonicWALL Anti-Spyware detection and
prevention is enabled for traffic through interfaces in the zone.

•

IPS: A check mark indicates SonicWALL Intrusion Prevention Service is enabled for traffic
coming in and going out of the zone.

•

Enable App Control Service – A check mark indicates App Control is enabled for traffic
coming in and gout out of the zone.

SonicOS 5.8.1 Administrator Guide

287

Network > Zones

•

Enforce Global Security Clients – A check mark indicates users on this zone are required
to use the Global Security client for desktop security.

•

Enable SSL Control – A check mark indicates inspection of all new SSL connections
initiated from the zone is required.

•

Enable SSLVPN Access – A check mark indicates SSL VPN access is enabled to this
zone.

•

Configure: Clicking the configure
icon displays the Edit Zone window. Clicking the
delete icon
deletes the zone. The delete icon is dimmed for the predefined zones. You
cannot delete these zones.

Adding and Configuring Zones
To add a new zone, click Add under the Zone Settings table. The Add Zone window is
displayed. To modify an exisiting zone, click the configure
icon for the zone.

288

SonicOS 5.8.1 Administrator Guide

Network > Zones

To configure the zone, perform the following steps:
Step 1

Type a name for the new zone in the Name field.

Step 2

Select a security type Trusted, Public or Wireless from the Security Type menu. Use Trusted
for zones that you want to assign the highest level of trust, such as internal LAN segments. Use
Public for zones with a lower level of trust requirements, such as a DMZ interface. Use
Wireless for the WLAN interface.

Step 3

If you want to allow intra-zone communications, select Allow Interface Trust. If not, select the
Allow Interface Trust checkbox.

Step 4

Select which of the following SonicWALL Security Services you want to enforce on the zone:
– SonicWALL Content Filtering Service – Enforces content filtering on multiple

interfaces in the same Trusted, Public and WLAN zones. To apply a Content Filtering
Service (CFS) policy to the zone, select the policy from the CFS Policy pull-down
menu.
– SonicWALL Enforce Client Anti-Virus Service – Enforces Client Anti-Virus

protection on multiple interfaces in the same Trusted, Public or WLAN zones, using the
SonicWALL Client Anti-Virus client on your network hosts.
– Enable Gateway Anti-Virus Service – Enforces gateway anti-virus protection on your

SonicWALL security appliance for all clients connecting to this zone. SonicWALL
Gateway Anti-Virus manages the anti-virus service on the SonicWALL appliance.
– Enable Intrusion Protection Service (IPS) – Enforces intrusion detection and

prevention on multiple interfaces in the same Trusted, Public or WLAN zones.
– Enable App Control Service – Enforces App Control to create network policy object-

based control rules to filter network traffic flows.
– Enable Anti-Spyware Service – Enforces anti-spyware detection and prevention on

multiple interfaces in the same Trusted, Public or WLAN zones.
– Enforce Global Security Clients – Requires users on this zone to use the Global

Security client for desktop security.
– Create Group VPN – Automatically creates a SonicWALL GroupVPN Policy for this

zone. You can customize the GroupVPN Policy in the VPN > Settings page.

Caution

Unsetting the Create Group VPN checkbox will remove any corresponding GroupVPN
policy.
– Enable SSL Control – Enables SSL Control on the zone. All new SSL connections

initiated from that zone will now be subject to inspection. Note that SSL Control must
first be enabled globally on the Firewall > SSL Control page. For more information,
see “Firewall Settings > SSL Control” on page 777.
– Enable SSLVPN Access – Enables users to establish SSL VPN connections to this

zone. For more information, see “SSL VPN” on page 931.
Step 5

Click OK. The new zone is now added to the SonicWALL security appliance.

Deleting a Zone
You can delete a user-created zone by clicking the delete icon
in the Configure column.
The Delete icon is unavailable for the predefined zones. You cannot delete these zones. Any
zones that you create can be deleted.

SonicOS 5.8.1 Administrator Guide

289

Network > Zones

Configuring a Zone for Guest Access
SonicWALL User Guest Services providesd network administrators with an easy solution for
creating wired and wireless guest passes and/or locked-down Internet-only network access for
visitors or untrusted network nodes. This functionality can be extended to wireless or wired
users on the WLAN, LAN, DMZ, or public/semi-public zone of your choice.
To configure Guest Services feature:

290

Step 1

Navigate to the Network > Zones page in the SonicOS management interface.

Step 2

Click the Configure button for the zone you wish to add Guest Services to.

SonicOS 5.8.1 Administrator Guide

Network > Zones

Step 3

Click the Guest Services tab.

Step 4

Choose from the following configuration options for Guest Services:

– Enable Guest Services - Enables guest services on the WLAN zone.
– Enable inter-guest communication - Allows guests to communicate directly with

other users who are connected to this zone.
– Bypass AV Check for Guests - Allows guest traffic to bypass Anti-Virus protection.

SonicOS 5.8.1 Administrator Guide

291

Network > Zones

– Enable External Guest Authentication - Requires guests connecting from the device

or network you select to authenticate before gaining access. This feature, based on
Lightweight Hotspot Messaging (LHM) is used for authenticating Hotspot users and
providing them parametrically bound network access.

Note

Refer to the SonicWALL Lightweight Hotspot Messaging Tech Note available at the
SonicWALL documentation Web site http://www.sonicwall.com/us/Support.html for
complete configuration of the Enable External Guest Authentication feature.
– Custom Authentication Page - Redirects users to a custom authentication page when

they first connect to the network. Click Configure to set up the custom authentication
page. Enter either a URL to an authentication page or a custom challenge statement in
the text field, and click OK.
– Post Authentication Page - Directs users to the page you specify immediately after

successful authentication. Enter a URL for the post-authentication page in the field.
– Bypass Guest Authentication - Allows the Guest Services feature to integrate into

environments already using some form of user-level authentication. This feature
automates the authentication process, allowing wireless users to reach Guest Services
resources without requiring authentication. This feature should only be used when
unrestricted Guest Service access is desired, or when another device upstream is
enforcing authentication.
– Redirect SMTP traffic to - Redirects SMTP traffic incoming on this zone to an SMTP

server you specify. Select the address object to redirect traffic to.
– Deny Networks - Blocks traffic to the networks you name. Select the subnet, address

group, or IP address to block traffic to.
– Pass Networks - Allows traffic through the Guest Service-enabled zone to the

networks you select.
– Max Guests - Specifies the maximum number of guest users allowed to connect to this

zone. The default setting is 10.
Special Guest Services Features for Wireless Zones
– Enable Dynamic Address Translation (DAT) - Guest Services provides spur of the

moment “hotspot” access to wireless-capable guests and visitors. For easy
connectivity, Guest Services allows wireless users to authenticate and associate,
obtain IP settings, and authenticate using any Web-browser. Without DAT, if a guest
user is not a DHCP client, but instead has static IP settings incompatible with the
Wireless WLAN network settings, network connectivity is prevented until the user’s
settings change to compatible values. Dynamic Address Translation (DAT) is a form of
Network Address Translation (NAT) that allows the system to support any IP
addressing scheme for guest users. For example, the Wireless WLAN interface is
configured with its default address of 172.16.31.1, and one guest client has a static IP
address of 192.168.0.10 and a default gateway of 192.168.0.1, while another has a
static IP address of 10.1.1.10 and a gateway of 10.1.1.1, and DAT enables network
communication for both of these clients.
Step 5

292

Click OK to apply these settings to this zone.

SonicOS 5.8.1 Administrator Guide

Network > Zones

Configuring the WLAN Zone
Step 1

Click the Edit icon

for the WLAN zone. The Edit Zone window is displayed.

Step 2

In the General tab, select the Allow Interface Trust setting to automate the creation of Access
Rules to allow traffic to flow between the interfaces of a zone instance. For example, if the LAN
zone has both the LAN and X3 interfaces assigned to it, checking Allow Interface Trust on
the LAN zone creates the necessary Access Rules to allow hosts on these interfaces to
communicate with each other.

Step 3

Select any of the following settings to enable the SonicWALL Security Services on the WLAN
zone:
– Enforce Content Filtering Service - Enforces content filtering on multiple interfaces

in the same Trusted, Public and WLAN zones.
– Enforce Client Anti-Virus Service - Enforces managed anti-virus protection on

multiple interfaces in the same Trusted, Public or WLAN zones. SonicWALL Client AntiVirus manages an anti-virus client application on all clients on the zone.
– Enable Gateway Anti-Virus - Enforces gateway anti-virus protection on multiple

interfaces in the same Trusted, Public or WLAN zones. SonicWALL Gateway Anti-Virus
manages the anti-virus service on the SonicWALL appliance.
– Enable IPS - Enforces intrusion detection and prevention on multiple interfaces in the

same Trusted, Public or WLAN zones.

SonicOS 5.8.1 Administrator Guide

293

Network > Zones

– Enable Anti-Spyware Service - Enforces anti-spyware detection and prevention on

multiple interfaces in the same Trusted, Public or WLAN zones.
– Create Group VPN - creates a GroupVPN policy for the zone, which is displayed in the

VPN Policies table on the VPN > Settings page. You can customize the GroupVPN
policy on the VPN > Settings page. If you uncheck Create Group VPN, the GroupVPN
policy is removed from the VPN > Settings page.

294

Step 4

Click the Wireless tab.

Step 5

In the Wireless Settings section, check Only allow traffic generated by a SonicPoint to
allow only traffic from SonicWALL SonicPoints to enter the WLAN zone interface. This allows
maximum security of your WLAN. Uncheck this option if you want to allow any traffic on your
WLAN zone regardless of whether or not it is from a wireless connection.

SonicOS 5.8.1 Administrator Guide

Network > Zones

Tip

Step 6

Uncheck Only allow traffic generated by a SonicPoint and use the zone on a wired
interface to allow guest services on that interface.
Select SSL VPN Enforcement to require that all traffic that enters into the WLAN zone be
authenticated through a SonicWALL SSL VPN appliance.

SonicOS 5.8.1 Administrator Guide

295

Network > Zones

Step 7

In the SSL VPN Server list, select an address object to direct traffic to the SonicWALL SSL
VPN appliance. You can select:
– Create new address object...
– Default Gateway
– Secondary Default Gateway
– X0 IP
– X1 IP
– X2 IP
– X3 IP
– X4 IP
– X5 IP

Step 8

In the SSL VPN Service list, select the service or group of services you want to allow for clients
authenticated through the SSL VPN.

Step 9

Under the SonicPoint Settings heading, select the SonicPoint Provisioning Profile you
want to apply to all SonicPoints connected to this zone. Whenever a SonicPoint connects to
this zone, it will automatically be provisioned by the settings in the SonicPoint Provisioning
Profile, unless you have individually configured it with different settings.

Step 10 Select Only allow traffic generated by a SonicPoint to block non-SonicPoint wireless traffic.

Note

For Guest Services configuration information, see the “Configuring a Zone for Guest
Access” on page 290.

Step 11 Click OK to apply these settings to the WLAN zone.

296

SonicOS 5.8.1 Administrator Guide

CHAPTER 19
Chapter 19:

Configuring DNS Settings

Network > DNS
The Domain Name System (DNS) is a distributed, hierarchical system that provides a method
for identifying hosts on the Internet using alphanumeric names called fully qualified domain
names (FQDNs) instead of using difficult to remember numeric IP addresses.
The Network > DNS page allows you to manually configure your DNS settings, if necessary.

SonicOS 5.8.1 Administrator Guide

297

Network > DNS

In the DNS Settings section, select Specify DNS Servers Manually and enter the IP
address(es) into the DNS Server fields. Click Accept to save your changes. To use the DNS
Settings configured for the WAN zone, select Inherit DNS Settings Dynamically from the
WAN Zone. Click Accept to save your changes.

DNS Rebinding Attack Prevention
DNS rebinding is a DNS-based attack on code embedded in web pages. Normally requests
from code embedded in web pages (JavScript, Java and Flash) are bound to the web-site they
are originating from (see Same Origin Policy). A DNS rebinding attack can be used to improve
the ability of JavaScript based malware to penetrate private networks, and subvert the
browser's same-origin policy.
DNS rebinding attackers register a domain which is delegated to a DNS server they control.
The server is configured to respond with a very short TTL parameter which prevents the result
from being cached. The first response contains IP address of the server hosting the malicious
code. Any subsequent requests contain IP addresses from private (RFC 1918) network,
presumably behind a firewall, being target of the attacker. Because both are fully valid DNS
responses, they authorize the sandbox script to access hosts in a private network. By iterating
addresses in these short-term but still valid DNS replies the script is able to scan the network
and perform other malicious activities.
Select the Enable DNS Rebinding Attack Prevention checkbox.
From the Action pulldown menu, select an action to perform when a DNS rebinding attack is
detected:
•

0 - Log

•

1 - Log & return RFC 1035 query REFUSED reply

•

2 - Log & drop the reply

Allowed Domains FQDN Address Object/Group containing allowed domain-names (e.g.
*.sonicwall.com) for which locally connected/routed subnets should be considered legal
responses

298

SonicOS 5.8.1 Administrator Guide

CHAPTER 20
Chapter 20:

Configuring Address Objects

Network > Address Objects
Address Objects are one of four object classes (Address, User, Service, and Schedule) in
SonicOS Enhanced. These Address Objects allow for entities to be defined one time, and to be
re-used in multiple referential instances throughout the SonicOS interface. For example, take
an internal Web-Server with an IP address of 67.115.118.80. Rather than repeatedly typing in
the IP address when constructing Access Rules or NAT Policies, Address Objects allow you to
create a single entity called “My Web Server” as a Host Address Object with an IP address of
67.115.118.80. This Address Object, “My Web Server” can then be easily and efficiently
selected from a drop-down menu in any configuration screen that employs Address Objects as
a defining criterion.

Types of Address Objects
Since there are multiple types of network address expressions, there are currently the following
Address Objects types:
•

Host – Host Address Objects define a single host by its IP address. The netmask for a Host
Address Object will automatically be set to 32-bit (255.255.255.255) to identify it as a single
host. For example, “My Web Server” with an IP address of “67.115.118.110” and a default
netmask of “255.255.255.255”

•

Range – Range Address Objects define a range of contiguous IP addresses. No netmask
is associated with Range Address Objects, but internal logic generally treats each member
of the specified range as a 32-bit masked Host object. For example “My Public Servers”
with an IP address starting value of “67.115.118.66” and an ending value of
“67.115.118.90”. All 25 individual host addresses in this range would be comprised by this
Range Address Object.

•

Network – Network Address Objects are like Range objects in that they comprise multiple
hosts, but rather than being bound by specified upper and lower range delimiters, the
boundaries are defined by a valid netmask. Network Address Objects must be defined by
the network’s address and a corresponding netmask. For example “My Public Network” with
a Network Value of “67.115.118.64” and a Netmask of “255.255.255.224” would comprise
addresses from 67.115.118.64 through to 67.115.118.95. As a general rule, the first
address in a network (the network address) and the last address in a network (the
broadcast address) are unusable.

SonicOS 5.8.1 Administrator Guide

299

Network > Address Objects

•

MAC Address – MAC Address Objects allow for the identification of a host by its hardware
address or MAC (Media Access Control) address. MAC addresses are uniquely assigned
to every piece of wired or wireless networking device by their hardware manufacturers, and
are intended to be immutable. MAC addresses are 48-bit values that are expressed in 6
byte hex-notation. For example “My Access Point” with a MAC address of
“00:06:01:AB:02:CD”. MAC addresses are resolved to an IP address by referring to the
ARP cache on the security appliance MAC address objects are used by various
components of Wireless configurations throughout SonicOS.

•

FQDN Address – FQDN address objects allow for the identification of a host by its Fully
Qualified Domain Names (FQDN), such as 'www.sonicwall.com'. FQDNs are be resolved
to their IP address (or IP addresses) using the DNS server configured on the security
appliance. Wildcard entries are supported through the gleaning of responses to queries
sent to the sanctioned DNS servers.

Address Object Groups
SonicOS Enhanced has the ability to group Address Objects into Address Object Groups.
Groups of Address Objects can be defined to introduce further referential efficiencies. Groups
can comprise any combination of Host, Range, or Network Address Objects. MAC address
Objects should be grouped separately, although they can safely be added to Groups of IPbased Address Objects, where they will be ignored when their reference is contextually
irrelevant (e.g. in a NAT Policy). For example “My Public Group” can contain Host Address
Object “My Web Server” and Range Address Object “My Public Servers”, effectively
representing IP addresses 67.115.118.66 to 67.115.118.90 and IP address 67.115.118.110.

Creating and Managing Address Objects
The Network > Address Objects page allows you to create and manage your Address
Objects.

300

SonicOS 5.8.1 Administrator Guide

Network > Address Objects

You can view Address Objects in the following ways using the View Style menu:
•

All Address Objects - displays all configured Address Objects.

•

Custom Address Objects - displays Address Objects with custom properties.

•

Default Address Objects - displays Address Objects configured by default on the
SonicWALL security appliance.

Sorting Address Objects allows you to quickly and easily locate Address Objects configured on
the SonicWALL security appliance.

Note

An Address Object must be defined before configuring NAT Policies, Access Rules, and
Services.

Navigating and Sorting the Address Objects and Address Groups Entries
The Address Objects and Address Groups tables provides easy pagination for viewing a large
number of address objects and groups. You can navigate a large number of entries listed in the
Address Objects or Address Groups tables by using the navigation control bar located at the
top right of the tables. Navigation control bar includes four buttons. The far left button displays
the first page of the table. The far right button displays the last page. The inside left and right
arrow buttons moved the previous or next page respectively.
You can enter the policy number (the number listed before the policy name in the # Name
column) in the Items field to move to a specific entry. The default table configuration displays
50 entries per page. You can change this default number of entries for tables on the System >
Administration page.
You can sort the entries in the table by clicking on the column header. The entries are sorted
by ascending or descending order. The arrow to the right of the column entry indicates the
sorting status. A down arrow means ascending order. An up arrow indicates a descending
order.

Default Address Objects and Groups
The Default Address Objects view displays the default Address Objects and Address
Groups for your SonicWALL security appliance. The Default Address Objects entries cannot
be modified or deleted. Therefore, the Edit and Delete icons are dimmed.

SonicOS 5.8.1 Administrator Guide

301

Network > Address Objects

Adding an Address Object
To add an Address Object, click Add button under the Address Objects table in the All
Address Objects or Custom Address Objects views to display the Add Address Object
window.

Step 1

Enter a name for the Network Object in the Name field.

Step 2

Select Host, Range, Network, MAC, or FQDN from the Type menu.
– If you select Host, enter the IP address and netmask in the IP Address and Netmask

fields.

– If you selected Range, enter the starting and ending IP addresses in the Starting IP

Address and Ending IP Address fields.

– If you selected Network, enter the network IP address and netmask in the Network and

Netmask fields.

302

SonicOS 5.8.1 Administrator Guide

Network > Address Objects

– If you selected MAC, enter the MAC address and netmask in the Network and MAC

Address field.

– If you selected FQDN, enter the domain name for the individual site or range of sites

(with a wildcard) in the FQDN field.

Step 3

Select the zone to assign to the Address Object from the Zone Assignment menu.

Editing or Deleting an Address Object
To edit an Address Object, click the edit icon
in the Configure column in the Address
Objects table. The Edit Address Object window is displayed, which has the same settings as
the Add Address Object window.
To delete an Address Object, click the Delete icon in the Configure column for the Address
Object you want to delete. A dialog box is displayed asking you to confirm the deletion. Click
OK to delete the Address Object. To delete multiple active Address Objects, select them and
click the Delete button.

SonicOS 5.8.1 Administrator Guide

303

Network > Address Objects

Creating Group Address Objects
As more and more Address Objects are added to the SonicWALL security appliance, you can
simplify managing the addresses and access policies by creating groups of addresses.
Changes made to the group are applied to each address in the group. To add a Group of
Address Objects, complete the following steps:
Step 1

Click Add Group to display the Add Address Object Group window.

Step 2

Create a name for the group in the Name field.

Step 3

Select the Address Object from the list and click the right arrow. It is added to the group.
Clicking while pressing the Ctrl key allows you to select multiple objects.

Step 4

Click OK.

Tip

To remove an address or subnet from the group, select the IP address or subnet in the right
column and click the left arrow. The selected item moves from the right column to the left
column.

Editing or Deleting Address Groups
To edit a group, click the edit icon
in the Configure column of the Address Groups table.
The Edit Address Object Group window is displayed. Make your changes and then click OK.
To delete a group, click on the Delete icon in the Configure column to delete an individual
Address Group. A dialog box is displayed asking you to confirm the deletion. Click OK to delete
the Address Group. To delete multiple active Address Groups, select them and click the Delete
button.

Public Server Wizard
SonicOS Enhanced includes the Public Server Wizard to automate the process of configuring
the SonicWALL security appliance for handling public servers. For example, if you have an email and Web server on your network for access from users on the Internet.
The Public Server Wizard allows you to select or define the server type (HTTP, FTP, Mail),
the private (external) address objects, and the public (internal) address objects. Once the
server type, private and public network objects are configured, the wizard creates the correct
NAT Policies and Access Rule entries on the security appliance for the server. You can use the
SonicWALL Management Interface for additional configuration options.

304

SonicOS 5.8.1 Administrator Guide

Network > Address Objects

See Part 21, Wizards for more information on configuring the SonicWALL security appliance
using wizards.

Working with Dynamic Addresses
From its inception, SonicOS Enhanced has used Address Objects (AOs) to represent IP
addresses in most areas throughout the user interface. Address Objects come in the following
varieties:
•

Host – An individual IP address, netmask and zone association.

•

MAC (original) – Media Access Control, or the unique hardware address of an Ethernet
host. MAC AOs were originally introduced in SonicOS 2.5 and were used for:
– Identifying SonicPoints
– Allowing hosts to bypass Guest Services authentication
– Authorizing the BSSID (Basic Service Set Identifier, or WLAN MAC) of wireless access

points detected during wireless scans.
MAC AOs were originally not allowable targets in other areas of the management
interface, such as Access Rules, so historically they could not be used to control a
host’s access by its hardware address.
•

Range – A starting and ending IP address, inclusive of all addresses in between.

•

Group – A collection of Address Objects of any assortment of types. Groups may contain
other Groups, Host, MAC, Range, or FQDN Address Objects.

SonicOS Enhanced 3.5 redefined the operation of MAC AOs, and introduces Fully Qualified
Domain Name (FQDN) AOs:
•

MAC – SonicOS Enhanced 3.5. and higher will resolve MAC AOs to an IP address by
referring to the ARP cache on the SonicWALL.

•

FQDN – Fully Qualified Domain Names, such as ‘www.reallybadWebsite.com’, will be
resolved to their IP address (or IP addresses) using the DNS server configured on the
SonicWALL. Wildcard entries are supported through the gleaning of responses to queries
sent to the sanctioned DNS servers.

While more effort is involved in creating an Address Object than in simply entering an IP
address, AOs were implemented to complement the management scheme of SonicOS
Enhanced, providing the following characteristics:
•

Zone Association – When defined, Host, MAC, and FQDN AOs require an explicit zone
designation. In most areas of the interface (such as Access Rules) this is only used
referentially. The functional application are the contextually accurate populations of
Address Object drop-down lists, and the area of “VPN Access” definitions assigned to
Users and Groups; when AOs are used to define VPN Access, the Access Rule autocreation process refers to the AO’s zone to determine the correct intersection of VPN [zone]
for rule placement. In other words, if the “192.168.168.200 Host” Host AO, belonging to the
LAN zone was added to “VPN Access” for the “Trusted Users” User Group, the autocreated Access Rule would be assigned to the VPN LAN zone.

•

Management and Handling – The versatilely typed family of Address Objects can be easily
used throughout the SonicOS Enhanced interface, allowing for handles (e.g. from Access
Rules) to be quickly defined and managed. The ability to simply add or remove members
from Address Object Groups effectively enables modifications of referencing rules and
policies without requiring direct manipulation.

•

Reusability – Objects only need to be defined once, and can then be easily referenced as
many times as needed.

SonicOS 5.8.1 Administrator Guide

305

Network > Address Objects

Key Features of Dynamic Address Objects
The term Dynamic Address Object (DAO) describes the underlying framework enabling MAC
and FQDN AOs. By transforming AOs from static to dynamic structures Firewall > Access
Rules can automatically respond to changes in the network.

Note

306

Initially, SonicOS Enhanced versions 4.0, 5.0, and 5.1 will only support Dynamic Address
Objects within Access Rules. Future versions of SonicOS Enhanced might introduce DAO
support to other subsystem, such as NAT, VPN, etc.

SonicOS 5.8.1 Administrator Guide

Network > Address Objects

FQDN wildcard FQDN Address Objects support wildcard entries, such as “*.somedomainname.com”, by first
support
resolving the base domain name to all its defined host IP addresses, and then by constantly
actively gleaning DNS responses as they pass through the firewall.
For example, creating an FQDN AO for “*.myspace.com” will first use the DNS servers configured
on the firewall to resolve “myspace.com” to 63.208.226.40, 63.208.226.41, 63.208.226.42, and
63.208.226.43 (as can be confirmed by nslookup myspace.com or equivalent). Since most DNS
servers do not allow zone transfers, it is typically not possibly to automatically enumerate all the
hosts in a domain. Instead, the SonicWALL will look for DNS responses coming from sanctioned
DNS servers as they traverse the firewall. So if a host behind the firewall queries an external DNS
server which is also a configured/defined DNS server on the SonicWALL, the SonicWALL will
parse the response to see if it matches the domain of any wildcard FQDN AOs.
Note

Sanctioned DNS servers are those DNS servers configured for use by the SonicWALL firewall. The
reason that responses from only sanctioned DNS servers are used in the wildcard learning process
is to protect against the possibility of FQDN AO poisoning through the use of unsanctioned DNS
servers with deliberately incorrect host entries. Future versions of SonicOS Enhanced might offer
the option to support responses from all DNS server. The use of sanctioned DNS servers can be
enforced with the use of Access Rules, as described later in the “Enforcing the use of sanctioned
servers on the network” section.

To illustrate, assume the firewall is configured to use DNS servers 4.2.2.1 and 4.2.2.2, and is
providing these DNS servers to all firewalled client via DHCP. If firewalled client-A performs a DNS
query against 4.2.2.1 or 4.2.2.2 for “vids.myspace.com”, the response will be examined by the
firewall, and will be matched to the defined “*.myspace.com” FQDN AO. The result
(63.208.226.224) will then be added to the resolved values of the “*.myspace.com” DAO.
Note

If the workstation, client-A, in the example above had resolved and cached vids.myspace.com prior
to the creation of the “*.myspace.com” AO, vids.myspace.com would not be resolved by the
firewall because the client would use its resolver’s cache rather than issuing a new DNS request.
As a result, the firewall would not have the chance to learn about vids.myspace.com, unless it was
resolved by another host. On a Microsoft Windows workstation, the local resolver cache can be
cleared using the command ipconfig /flushdns. This will force the client to resolve all FQDNs,
allowing the firewall to learn them as they are accessed.

Wildcard FQDN entries will resolve all hostnames within the context of the domain name, up to
256 entries per AO. For example, “*.sonicwall.com” will resolve www.sonicwall.com,
software.sonicwall.com, licensemanager.sonicwall.com, to their respective IP addresses, but it
will not resolve sslvpn.demo.sonicwall.com because it is in a different context; for
sslvpn.demo.sonicwall.com to be resolved by a wildcard FQDN AO, the entry
“*.demo.sonicwall.com” would be required, and would also resolve
sonicos-enhanced.demo.sonicwall.com, csm.demo.sonicwall.com,
sonicos-standard.demo.sonicwall.com, etc.
Note

FQDN
resolution
using DNS

Wildcards only support full matches, not partial matches. In other words, “*.sonicwall.com” is a
legitimate entry, but “w*.sonicwall.com”, “*w.sonicwall.com”, and “w*w.sonicwall.com” are not.
A wildcard can only be specified once per entry, so “*.*.sonicwall.com”, for example, will not be
functional.

FQDN Address Objects are resolved using the DNS servers configured on the SonicWALL in the
Network > DNS page. Since it is common for DNS entries to resolve to multiple IP addresses, the
FQDN DAO resolution process will retrieve all of the addresses to which a host name resolves,
up to 256 entries per AO. In addition to resolving the FQDN to its IPs, the resolution process will
also associate the entry’s TTL (time to live) as configured by the DNS administrator. TTL will then
be honored to ensure the FQDN information does not become stale.

SonicOS 5.8.1 Administrator Guide

307

Network > Address Objects

Feature

Benefit

FQDN entry
caching

Resolved FQDN values will be cached in the event of resolution attempt failures subsequent to
initial resolution. In other words, if “www.moosifer.com” resolves to 71.35.249.153 with a TTL of
300, but fails to resolve upon TTL expiry (for example, due to temporary DNS server
unavailability), the 71.35.249.153 will be cached and used as valid until resolution succeeds, or
until manually purged. Newly created FQDN entries that never successfully resolve, or entries that
are purged and then fail to resolve will appear in an unresolved state.

MAC Address
resolution
using live ARP
cache data

When a node is detected on any of the SonicWALL’s physical segments through the ARP
(Address Resolution Protocol) mechanism, the SonicWALL’s ARP cache is updated with that
node’s MAC and IP address. When this update occurs, if a MAC Address Objects referencing that
node’s MAC is present, it will instantly be updated with the resolved address pairing. When a node
times out of the ARP cache due to disuse (e.g. the host is no longer L2 connected to the firewall)
the MAC AO will transition to an “unresolved” state.

MAC Address
Object
multi-homing
support

MAC AOs can be configured to support multi-homed nodes, where multi-homed refers to nodes
with more than one IP address per physical interface. Up to 256 resolved entries are allowed per
AO. This way, if a single MAC address resolves to multiple IPs, all of the IP will be applicable to
the Access Rules, etc. that refer to the MAC AO.

Automatic and MAC AO entries are automatically synchronized to the SonicWALL’s ARP cache, and FQDN AO
manual refresh entries abide by DNS entry TTL values, ensuring that the resolved values are always fresh. In
addition to these automatic update processes, manual Refresh and Purge capabilities are
processes
provided for individual DAOs, or for all defined DAOs.
FQDN
resolution
using DNS

FQDN Address Objects are resolved using the DNS servers configured on the SonicWALL in the
Network > DNS page. Since it is common for DNS entries to resolve to multiple IP addresses, the
FQDN DAO resolution process will retrieve all of the addresses to which a host name resolves,
up to 256 entries per AO. In addition to resolving the FQDN to its IPs, the resolution process will
also associate the entry’s TTL (time to live) as configured by the DNS administrator. TTL will then
be honored to ensure the FQDN information does not become stale.

Enforcing the use of sanctioned servers on the network
Although not a requirement, it is recommended to enforce the use of authorized or sanctioned
servers on the network. This practice can help to reduce illicit network activity, and will also
serve to ensure the reliability of the FQDN wildcard resolution process. In general, it is good
practice to define the endpoints of known protocol communications when possible. For
example:
•

308

Create Address Object Groups of sanctioned servers (e.g. SMTP, DNS, etc.)

SonicOS 5.8.1 Administrator Guide

Network > Address Objects

•

Create Access Rules in the relevant zones allowing only authorized SMTP servers on your
network to communicate outbound SMTP; block all other outbound SMTP traffic to prevent
intentional or unintentional outbound spamming.

•

Create Access Rules in the relevant zones allowing authorized DNS servers on your
network to communicate with all destination hosts using DNS protocols (TCP/UDP 53). Be
sure to have this rule in place if you have DNS servers on your network, and you will be
configuring the restrictive DNS rule that follows.

•

Create Access Rules in the relevant zones allowing Firewalled Hosts to only communicate
DNS (TCP/UDP 53) with sanctioned DNS servers; block all other DNS access to prevent
communications with unauthorized DNS servers.

•

Unsanctioned access attempts will then be viewable in the logs.

SonicOS 5.8.1 Administrator Guide

309

Network > Address Objects

Using MAC and FQDN Dynamic Address Objects
MAC and FQDN DAOs provide extensive Access Rule construction flexibility. MAC and FQDN
AOs are configured in the same fashion as static Address Objects, that is from the Network >
Address Objects page. Once created, their status can be viewed by a mouse-over of their
appearance, and log events will record their addition and deletion.

Dynamic Address Objects lend themselves to many applications. The following are just a few
examples of how they may be used. Future versions of SonicOS Enhanced may expand their
versatility even further.

Blocking All Protocol Access to a Domain using FQDN DAOs
There might be instances where you wish to block all protocol access to a particular destination
IP because of non-standard ports of operations, unknown protocol use, or intentional traffic
obscuration through encryption, tunneling, or both. An example would be a user who has set
up an HTTPS proxy server (or other method of port-forwarding/tunneling on “trusted” ports like
53, 80, 443, as well as nonstandard ports, like 5734, 23221, and 63466) on his DSL or cable
modem home network for the purpose of obscuring his traffic by tunneling it through his home
network. The lack of port predictability is usually further complicated by the dynamic addressing
of these networks, making the IP address equally unpredictable.
Since these scenarios generally employ dynamic DNS (DDNS) registrations for the purpose of
allowing users to locate the home network, FQDN AOs can be put to aggressive use to block
access to all hosts within a DDNS registrar.

Note

A DDNS target is used in this example for illustration. Non-DDNS target domains can be
used just as well.
Assumptions
•

The SonicWALL firewall is configured to use DNS server 10.50.165.3, 10.50.128.53.

•

The SonicWALL is providing DHCP leases to all firewalled users. All hosts on the network
use the configured DNS servers above for resolution.
– DNS communications to unsanctioned DNS servers can optionally be blocked with

Access Rules, as described in the ‘Enforcing the use of sanctioned servers on the
network’ section.
•

The DSL home user is registering the hostname moosifer.dyndns.org with the DDNS
provider DynDNS. For this session, the ISP assigned the DSL connection the address
71.35.249.153.
– A wildcard FQDN AO is used for illustration because other hostnames could easily be

registered for the same IP address. Entries for other DDNS providers could also be
added, as needed.

310

SonicOS 5.8.1 Administrator Guide

Network > Address Objects

Step 1 – Create the FQDN Address Object
•

From Network > Address Objects, select Add and create the following Address Object:

•

When first created, this entry will resolve only to the address for dyndns.org, e.g.
63.208.196.110.

Step 2 – Create the Firewall Access Rule
•

Note

From the Firewall > Access Rules page, LAN->WAN zone intersection, Add an Access
Rule as follows:

Rather than specifying ‘LAN Subnets’ as the source, a more specific source could be
specified, as appropriate, so that only certain hosts are denied access to the targets.
•

When a host behind the firewall attempts to resolve moosifer.dyndns.org using a
sanctioned DNS server, the IP address(es) returned in the query response will be
dynamically added to the FQDN AO.

•

Any protocol access to target hosts within that FQDN will be blocked, and the access
attempt will be logged:

SonicOS 5.8.1 Administrator Guide

311

Network > Address Objects

Using an Internal DNS Server for FQDN-based Access Rules
It is common for dynamically configured (DHCP) network environments to work in combination
with internal DNS servers for the purposes of dynamically registering internal hosts – a common
example of this is Microsoft’s DHCP and DNS services. Hosts on such networks can easily be
configured to dynamically update DNS records on an appropriately configured DNS server (for
example, see the Microsoft Knowledgebase article “How to configure DNS dynamic updates in
Windows Server 2003” at http://support.microsoft.com/kb/816592/en-us).
The following illustrates a packet dissection of a typical DNS dynamic update process, showing
the dynamically configured host 10.50.165.249 registering its full hostname
bohuymuth.moosifer.com with the (DHCP provided) DNS server 10.50.165.3:

In such environments, it could prove useful to employ FQDN AOs to control access by
hostname. This would be most applicable in networks where hostnames are known, such as
where hostname lists are maintained, or where a predictable naming convention is used.

Controlling a Dynamic Host’s Network Access by MAC Address
Since DHCP is far more common than static addressing in most networks, it is sometimes
difficult to predict the IP address of dynamically configured hosts, particularly in the absence of
dynamic DNS updates or reliable hostnames. In these situations, it is possible to use MAC
Address Objects to control a host’s access by its relatively immutable MAC (hardware) address.
Like most other methods of access control, this can be employed either inclusively, for
example, to deny access to/for a specific host or group of hosts, or exclusively, where only a
specific host or group of hosts are granted access, and all other are denied. In this example,
we will illustrate the latter.
Assuming you had a set of DHCP-enabled wireless clients running a proprietary operating
system which precluded any type of user-level authentication, and that you wanted to only allow
these clients to access an application-specific server (e.g. 10.50.165.2) on your LAN. The
WLAN segment is using WPA-PSK for security, and this set of clients should only have access

312

SonicOS 5.8.1 Administrator Guide

Network > Address Objects

to the 10.50.165.2 server, but to no other LAN resources. All other wireless clients should not
be able to access the 10.50.165.2 server, but should have unrestricted access everywhere
else.
Step 1 – Create the MAC Address Objects
•

From Network > Address Objects, select Add and create the following Address Object
(multi-homing optional, as needed):

•

Once created, if the hosts are present in the SonicWALL’s ARP cache, they will be resolved
immediately, otherwise they will appear in an unresolved state in the Address Objects table
until they are activated and are discovered through ARP:

•

Create an Address Object Group comprising the Handheld devices:

SonicOS 5.8.1 Administrator Guide

313

Network > Address Objects

Step 2 – Create the Firewall Access Rules

Note

•

To create access rules, navigate to the Firewall > Access Rules page, click on the All
Rules radio button, and scroll to the bottom of the page and click the Add button.

•

Create the following four access rules:

Setting

Access Rule 1

Access Rule 2

Access Rule 3

Access Rule 4

From Zone

WLAN

WLAN

WLAN

WLAN

To Zone

LAN

LAN

LAN

LAN

Service

MediaMoose Services MediaMoose Services Any

Any

Source

Handheld Devices

Any

Handheld Devices

Any

Destination

10.50.165.3

10.50.165.3

Any

Any

Users allowed All

All

All

All

Schedule

Always on

Always on

Always on

Always on

The ‘MediaMoose Services’ service is used to represent the specific application used by the
handheld devices. The declaration of a specific service is optional, as needed.

Bandwidth Managing Access to an Entire Domain
Streaming media is one of the most profligate consumers of network bandwidth. But trying to
control access, or manage bandwidth allotted to these sites is difficult because most sites that
serve streaming media tend to do so off of large server farms. Moreover, these sites frequently
re-encode the media and deliver it over HTTP, making it even more difficult to classify and
isolate. Manual management of lists of servers is a difficult task, but wildcard FQDN Address
Objects can be used to simplify this effort.
Step 1 – Create the FQDN Address Object
•

From Network > Address Objects, select Add and create the following Address Object:

Upon initial creation, youtube.com will resolve to IP addresses 208.65.153.240,
208.65.153.241, 208.65.153.242, but after an internal host begins to resolve hosts for all of the
elements within the youtube.com domain, the learned host entries will be added, such as the
entry for the v87.youtube.com server (208.65.154.84).

314

SonicOS 5.8.1 Administrator Guide

Network > Address Objects

Step 2 – Create the Firewall Access Rule
•

Note

From the Firewall > Access Rules page, LAN->WAN zone intersection, add an Access
Rule as follows:

If you do not see the Bandwidth tab, you can enable bandwidth management by declaring
the bandwidth on your WAN interfaces. For more information on BWM, refer to the
Configuring QoS and BWM document at: http://www.sonicwall.com/support/pdfs/
configuring_qos_and_bwm.pdf
•

The BWM icon will appear within the Access Rule table indicating that BWM is active, and
providing statistics. Access to all *.youtube.com hosts, using any protocol, will now be
cumulatively limited to 2% of your total available bandwidth for all user sessions.

SonicOS 5.8.1 Administrator Guide

315

Network > Address Objects

316

SonicOS 5.8.1 Administrator Guide

CHAPTER 21
Chapter 21:

Configuring Firewall Services

Network > Services
SonicOS Enhanced supports an expanded IP protocol support to allow users to create services
and access rules based on these protocols. See “Supported Protocols” on page 318 for a
complete listing of support IP protocols.
Services are used by the SonicWALL security appliance to configure network access rules for
allowing or denying traffic to the network. The SonicWALL security appliance includes Default
Services. Default Services are predefined services that are not editable. And you can also
create Custom Services to configure firewall services to meet your specific business
requirements.

Selecting All Services from View Style displays both Custom Services and Default
Services.

SonicOS 5.8.1 Administrator Guide

317

Network > Services

Default Services Overview
The Default Services view displays the SonicWALL security appliance default services in the
Services table and Service Groups table. The Service Groups table displays clusters of
multiple default services as a single service object. You cannot delete or edit these predefined
services. The Services table displays the following attributes of the services:
•

Name—The name of the service.

•

Protocol—The protocol of the service.

•

Port Start—The starting port number for the service.

•

Port End—The ending port number for the service.

•

Configure—Displays the unavailable Edit
and Delete
icon (default services
cannot be edited or deleted, you will need to add a new service for the Edit and Delete icons
to become available).

Services that apply to common applications are grouped as Default Service Groups. These
groups cannot be changed or deleted. Clicking on the + to the left of the Default Service Groups
entry, displays all the individual Default Services included in the group. For example, the DNS
(Name Service) entry has two services labelled DNS (Name Service) TCP for port 53 and DNS
(Name Service) UDP for port 53. These multiple entries with the same name are grouped
together, and are treated as a single service. Default Services Groups cannot be edited or
deleted.

Custom Services Configuration Task List
The following list provides configuration tasks for Custom Services:
•

Adding Custom Services

•

Editing Custom Services

•

Deleting Custom Services

•

Adding Custom Services Groups

•

Editing Custom Services Groups

•

Deleting Custom Services Groups

Supported Protocols
The following IP protocols are available for custom services:

318

•

ICMP (1)—(Internet Control Message Protocol) A TCP/IP protocol used to send error and
control messages.

•

IGMP (2)—(Internet Group Management Protocol) The protocol that governs the
management of multicast groups in a TCP/IP network.

•

TCP (6)—(Transmission Control Protocol) The TCP part of TCP/IP. TCP is a transport
protocol in TCP/IP. TCP ensures that a message is sent accurately and in its entirety.

•

UDP (17)—(User Datagram Protocol) A protocol within the TCP/IP protocol suite that is
used in place of TCP when a reliable delivery is not required.

•

GRE (47)—(Generic Routing Encapsulation) A tunneling protocol used to encapsulate a
wide variety of protocol packet types inside IP tunnels, creating a virtual point-to-point link
to firewalls or routing devices over an IP Internetwork.

SonicOS 5.8.1 Administrator Guide

Network > Services

•

ESP (50)—(Encapsulated Security Payload) A method of encapsulating an IP datagram
inside of another datagram employed as a flexible method of data transportation by IPsec.

•

AH (51)—(Authentication Header) A security protocol that provides data authentication and
optional anti-relay services. AH is embedded in the data to be protected (a full IP
datagram).

•

EIGRP (88)—(Enhanced Interior Gateway Routing Protocol) Advanced version of IGRP.
Provides superior convergence properties and operating efficiency, and combines the
advantages of link state protocols with those of distance vector protocols.

•

OSPF (89)—(Open Shortest Path First) A routing protocol that determines the best path for
routing IP traffic over a TCP/IP network based on distance between nodes and several
quality parameters. OSPF is an interior gateway protocol (IGP), which is designed to work
within an autonomous system. It is also a link state protocol that provides less router to
router update traffic than the RIP protocol (distance vector protocol) that it was designed to
replace.

•

PIMSM (103)—(Protocol Independent Multicast Sparse Mode) One of two PIM operational
modes (dense and sparse). PIM sparse mode tries to constrain data distribution so that a
minimal number of routers in the network receive it. Packets are sent only if they are
explicitly requested at the RP (rendezvous point). In sparse mode, receivers are widely
distributed, and the assumption is that downstream networks will not necessarily use the
datagrams that are sent to them. The cost of using sparse mode is its reliance on the
periodic refreshing of explicit join messages and its need for RPs.

•

L2TP (115)—(Layer 2 Tunneling Protocol) A protocol that allows a PPP session to run over
the Internet. L2TP does not include encryption, but defaults to using IPsec in order to
provide virtual private network (VPN) connections from remote users to the corporate LAN.

Adding Custom Services for Predefined Service Types
You can add a custom service for any of the predefined service types:
Protocol

IP Number

ICMP

1

TCP

6

UDP

17

GRE

47

IPsec ESP

50

IPsec AH

51

IGMP

2

EIGRP

88

OSPF

89

PIM SM

103

L2TP

115

SonicOS 5.8.1 Administrator Guide

319

Network > Services

All custom services you create are listed in the Custom Services table. You can group custom
services by creating a Custom Services Group for easy policy enforcement. If a protocol is
not listed in the Default Services table, you can add it to the Custom Services table by clicking
Add.

Step 1

Enter the name of the service in the Name field.

Step 2

Select the type of IP protocol from the Protocol pull-down menu.

Step 3

Enter the Port Range or IP protocol Sub Type depending on your IP protocol selection:
– For TCP and UDP protocols, specify the Port Range. You will not need to specify a Sub

Type.
– On SonicWALL NSA series appliances, for ICMP, IGMP, OSPF and PIMSM protocols,

select from the Sub Type pull-down menu for sub types.
– For the remaining protocols, you will not need to specify a Port Range or Sub Type.
Step 4

Click OK. The service appears in the Custom Services table.
Click the Enable Logging checkbox to disable or enable the logging of the service activities.

Adding Custom IP Type Services
Using only the predefined IP types, if the security appliance encounters traffic of any other IP
Protocol type it drops it as unrecognized. However, there exists a large and expanding list of
other registered IP types, as governed by IANA (Internet Assigned Numbers Authority): http://
www.iana.org/assignments/protocol-numbers, so while the rigid practice of dropping lesscommon (unrecognized) IP Type traffic is secure, it was functionally restrictive.
SonicOS Enhanced 3.5 and newer, with its support for Custom IP Type Service Objects, allows
an administrator to construct Service Objects representing any IP type, allowing Firewall
Access Rules to then be written to recognize and control IPv4 traffic of any type.

320

SonicOS 5.8.1 Administrator Guide

Network > Services

Note

The generic service Any will not handle Custom IP Type Service Objects. In other words,
simply defining a Custom IP Type Service Object for IP Type 126 will not allow IP Type 126
traffic to pass through the default LAN > WAN Allow rule.

It will be necessary to create an Access Rules specifically containing the Custom IP Type
Service Object to provide for its recognition and handling, as illustrated below.

Example
Assume an administrator needed to allow RSVP (Resource Reservation Protocol - IP Type 46)
and SRP (Spectralink™ Radio Protocol – IP type 119) from all clients on the WLAN zone
(WLAN Subnets) to a server on the LAN zone (for example, 10.50.165.26), the administrator
would be able to define Custom IP Type Service Objects to handle these two services:
Step 1

From the Network > Services page, Click on the Go to Service Objects link at the top right
of page to jump to the Services section.

Step 2

Click Add.

Step 3

Name the Service Objects accordingly.

Step 4

Select Custom IP Type from the Protocol drop-down list.

Step 5

Enter the protocol number for the Custom IP Type. Port ranges are not definable for or
applicable to Custom IP types.

Note

Attempts to define a Custom IP Type Service Object for a predefined IP type will not be
permitted, and will result in an error message.

Step 6

Click OK

Step 7

From the Network > Services page, Service Group section, select Add Group.

SonicOS 5.8.1 Administrator Guide

321

Network > Services

Step 8

Add a Service Group composed of the Custom IP Types Services.

Step 9

From Firewall > Access Rules > WLAN > LAN, select Add.

Step 10 Define an Access Rules allowing myServices from WLAN Subnets to the 10.50.165.26

Address Object.

Note

Select your zones, Services and Address Objects accordingly. It may be necessary to create
an Access Rule for bidirectional traffic; for example, an additional Access Rule from the LAN
> WLAN allowing myServices from 10.50.165.26 to WLAN Subnets.

Step 11 Click OK

IP protocol 46 and 119 traffic will now be recognized, and will be allowed to pass from WLAN
Subnets to 10.50.165.26.

Editing Custom Services
Click the Edit icon
under Configure to edit the service in the Edit Service window, which
includes the same configuration settings as the Add Service window.

Deleting Custom Services
Click the Delete icon
to delete an individual custom service. You can delete all custom
services by clicking the Delete button.

322

SonicOS 5.8.1 Administrator Guide

Network > Services

Adding a Custom Services Group
You can add custom services and then create groups of services, including default services, to
apply the same policies to them. For instance, you can allow SMTP and POP3 traffic only during
certain hours or days of the week by adding the two services as a Custom Service Group. To
create a Custom Services Group, click Add Group.

Step 1

Enter a name for the custom group in the name field.

Step 2

Select individual services from the list in the left column. You can also select multiple services
by pressing the Ctrl key and clicking on the services.

Step 3

Click - > to add the services to the group.

Step 4

To remove services from the group, select individual services from the list in right column. You
can also select multiple services by pressing the Ctrl key on your keyboard and clicking on the
services.

Step 5

Click < - to remove the services.

Step 6

When you are finished, click OK to add the group to Custom Services Groups.
Clicking + on the left of a Custom Service Group name, expands the display to show all the
individual Custom Services, Default Services, and Custom Services Groups included in the
Custom Service Group entry.

Editing Custom Services Groups
Click the Edit icon
under Configure to edit the custom service group in the Edit Service
Group window, which includes the same configuration settings as the Add Service Group
window.

Deleting Custom Services Groups
Click the Delete icon
to delete the individual custom service group entry. You can delete
all custom service groups by clicking the Delete button.

SonicOS 5.8.1 Administrator Guide

323

Network > Services

324

SonicOS 5.8.1 Administrator Guide

CHAPTER 22
Chapter 22:

Configuring Routes

Network > Routing
If you have routers on your interfaces, you can configure static routes on the SonicWALL
security appliance on the Network > Routing page. You can create static routing policies that
create static routing entries that make decisions based upon source address, source netmask,
destination address, destination netmask, service, interface, gateway and metric. This feature
allows for full control of forwarding based upon a large number of user-defined variables. This
chapter contains the following sections:
•

“Route Advertisement” on page 326

•

“Route Policies” on page 327

•

“Advanced Routing Services (OSPF and RIP)” on page 332

•

“Configuring Advanced Routing Services” on page 339

SonicOS 5.8.1 Administrator Guide

325

Network > Routing

Route Advertisement
The SonicWALL security appliance uses RIPv1 or RIPv2 to advertise its static and dynamic
routes to other routers on the network. Changes in the status of VPN tunnels between the
SonicWALL security appliance and remote VPN gateways are also reflected in the RIPv2
advertisements. Choose between RIPv1 or RIPv2 based on your router’s capabilities or
configuration. RIPv1 is an earlier version of the protocol that has fewer features, and it also
sends packets via broadcast instead of multicast. RIPv2 packets are backwards-compatible
and can be accepted by some RIPv1 implementations that provide an option of listening for
multicast packets. The RIPv2 Enabled (broadcast) selection broadcasts packets instead of
multicasting packets is for heterogeneous networks with a mixture of RIPv1 and RIPv2 routers.

Route Advertisement Configuration
To enable Route Advertisement for an Interface, follow these steps:

326

Step 1

Click the Edit
icon in the Configure column for the interface. The Route Advertisement
Configuration window is displayed.

Step 2

Select one of the following types of RIP Advertisements:
•

Disabled - Disables RIP advertisements.

•

RIPv1 Enabled - RIPv1 is the first version of Routing Information Protocol.

•

RIPv2 Enabled (multicast) - To send route advertisements using multicasting (a single
data packet to specific notes on the network).

•

RIPv2 Enabled (broadcast) - To send route advertisements using broadcasting (a single
data packet to all nodes on the network).

SonicOS 5.8.1 Administrator Guide

Network > Routing

Step 3

In the Advertise Default Route menu, select Never, or When WAN is up, or Always.

Step 4

Enable Advertise Static Routes if you have static routes configured on the SonicWALL
security appliance, enable this feature to exclude them from Route Advertisement.

Step 5

Enable Advertise Remote VPN Networks if you want to advertise VPN networks.

Step 6

Enter a value in seconds between advertisements broadcasted over a network in the Route
Change Damp Time (seconds) field. The default value is 30 seconds. A lower value
corresponds with a higher volume of broadcast traffic over the network. The Route Change
Damp Time (seconds) setting defines the delay between the time a VPN tunnel changes state
(up or down) and the time the change is advertised with RIP. The delay, in seconds, prevents
ambiguous route advertisements sent as a result of temporary change in the VPN tunnel status.

Step 7

Enter the number of advertisements that a deleted route broadcasts until it stops in the Deleted
Route Advertisements (0-99) field. The default value is 1.

Step 8

Enter a value from 1 to 15 in the Route Metric (1-15) field. This is the number of times a packet
touches a router from the source IP address to the destination IP address.

Step 9

If RIPv2 is selected from the Route Advertisements menu, you can enter a value for the route
tag in the RIPv2 Route Tag (4 HEX Digits) field. This value is implementation-dependent and
provides a mechanism for routers to classify the originators of RIPv2 advertisements. This field
is optional.

Step 10 If you wan to enable RIPv2 authentication, select one of the following options from the RIPv2

Authentication menu:
•

User defined - Enter 4 hex digits in the Authentication Type (4 hex digits) field. Enter 32
hex digits in the Authentication Data (32 Hex Digits) field.

•

Cleartext Password - Enter a password in the Authentication Password (Max 16 Chars)
field. A maximum of 16 characters can be used to define a password.

•

MD5 Digest - Enter a numerical value from 0-255 in the Authentication Key-Id (0-255) field.
Enter a 32 hex digit value for the Authentication Key (32 hex digits) field, or use the
generated key.

Step 11 Click OK.

Route Policies
SonicOS Enhanced provides Policy Based Routing (PBR) to provide more flexible and granular
traffic handling capabilities. The following sections describe PBR:
•

“Policy Based Routing” on page 328

•

“Route Policies Table” on page 328

•

“Static Route Configuration” on page 329

•

“Probe-Enabled Policy Based Routing Configuration” on page 330

•

“A Route Policy Example” on page 330

SonicOS 5.8.1 Administrator Guide

327

Network > Routing

Policy Based Routing
A simple static routing entry specifies how to handle traffic that matches specific criteria, such
as destination address, destination mask, gateway to forward traffic, the interface that gateway
is located, and the route metric. This method of static routing satisfies most static requirements,
but is limited to forwarding based only on destination addressing.
Policy Based Routing (PBR) allows you to create extended static routes to provide more flexible
and granular traffic handling capabilities. SonicOS Enhanced PBR allows for matching based
upon source address, source netmask, destination address, destination netmask, service,
interface, and metric. This method of routing allows for full control of forwarding based upon a
large number of user defined variables.
A metric is a weighted cost assigned to static and dynamic routes. Metrics have a value
between 0 and 255. Lower metrics are considered better and take precedence over higher
costs. SonicOS Enhanced adheres to Cisco defined metric values for directly connected
interfaces, statically encoded routes, and all dynamic IP routing protocols.

Metric Value

Description

1

Static Route

5

EIGRP Summary

20

External BGP

90

EIGRP

100

IGRP

110

OSPF

115

IS-IS

120

RIP

140

EGP

170

External EIGRP

Internal

BGP

Route Policies Table
You can change the view your route policies in the Route Policies table by selecting one of the
view settings in the View Style menu.

328

SonicOS 5.8.1 Administrator Guide

Network > Routing

All Policies displays all the routing policies including Custom Policies and Default Policies.
Initially, only the Default Policies are displayed in the Route Policies table when you select
All Policies from the View Style menu.
The Route Policies table provides easy pagination for viewing a large number of routing
policies. You can navigate a large number of routing policies listed in the Route Policies table
by using the navigation control bar located at the top right of the Route Policies table.
Navigation control bar includes four buttons. The far left button displays the first page of the
table. The far right button displays the last page. The inside left and right arrow buttons moved
the previous or next page respectively.
You can enter the policy number (the number listed before the policy name in the # Name
column) in the Items field to move to a specific routing policy. The default table configuration
displays 50 entries per page. You can change this default number of entries for tables on the
System > Administration page.
You can sort the entries in the table by clicking on the column header. The entries are sorted
by ascending or descending order. The arrow to the right of the column entry indicates the
sorting status. A down arrow means ascending order. An up arrow indicates a descending
order.

Static Route Configuration
In SonicOS Enhanced, a static route is configured through a basic route policy. To configure a
static route, complete the following steps:
Step 1

Scroll to the bottom of the Network > Routing page and click on the Add button. The Add
Route Policy window is displayed.

Step 2

From the Source menu, select the source address object for the static route, or select Create
new address object to dynamically create a new address object.

Step 3

From the Destination menu, select the destination address object.

Step 4

From the Service menu, select a service object. For a generic static route that allows all traffic
types, simply select Any.

Step 5

From the Gateway menu, select the gateway address object to be used for the route.

Step 6

From the Interface menu, select the interface to be used for the route.

SonicOS 5.8.1 Administrator Guide

329

Network > Routing

Step 7

Enter the Metric for the route. The default metric for static routes is one. For more information
on metrics, see the “Policy Based Routing” section on page 328

Step 8

(Optional) Select the Disable route when the interface is disconnected checkbox to have
the route automatically disabled when the interface is disconnected.

Step 9

(Optional) The Allow VPN path to take precedence option allows you to create a backup route
for a VPN tunnel. By default, static routes have a metric of one and take precedence over VPN
traffic. The Allow VPN path to take precedence option gives precedence over the route to
VPN traffic to the same destination address object. This results in the following behavior:
•

When a VPN tunnel is active: static routes matching the destination address object of the
VPN tunnel are automatically disabled if the Allow VPN path to take precedence option
is enabled. All traffic is routed over the VPN tunnel to the destination address object.

•

When a VPN tunnel goes down: static routes matching the destination address object of
the VPN tunnel are automatically enabled. All traffic to the destination address object is
routed over the static routes.

Step 10 The Probe, Disable route when probe succeeds, and Probe default state is UP options are

used to configure Probe-Enabled Policy Based Routing. See the following “Probe-Enabled
Policy Based Routing Configuration” section on page 330 for information on their configuration.
Step 11 Click OK to add the route.

Probe-Enabled Policy Based Routing Configuration
When configuring a static route, you can optionally configure a Network Monitor policy for the
route. When a Network Monitor policy is used, the static route is dynamically disabled or
enabled, based on the state of the probe for the policy.
Step 1

Configure the static route as described in “Static Route Configuration” on page 329.

Step 2

In the Probe pulldown menu select the appropriate Network Monitor object or select Create
New Network Monitor object... to dynamically create a new object. For more information, see
“Network > Network Monitor” on page 425.

Step 3

Typical configurations will not check the Disable route when probe succeeds checkbox,
because typically administrators will want to disable a route when a probe to the route’s
destination fails. This option is provided to give administrators added flexibility for defining
routes and probes.

Step 4

Select the Probe default state is UP to have the route consider the probe to be successful (i.e.
in the “UP” state) when the attached Network Monitor policy is in the “UNKNOWN” state. This
is useful to control the probe-based behavior when a unit of a High Availability pair transitions
from “IDLE” to “ACTIVE,” because this transition sets all Network Monitor policy states to
“UNKNOWN.”

Step 5

Click OK to apply the configuration.

A Route Policy Example
The following example walks you through creating a route policy for two simultaneously active
WAN interfaces. For this example, a secondary WAN interface needs to be setup on the X3
interface and configured with the settings from your ISP. Next, configure the security appliance
for load balancing by checking the Enable Load Balancing on the

330

SonicOS 5.8.1 Administrator Guide

Network > Routing

Network > WAN Failover & LB page. For this example, choose Per Connection RoundRobin as the load balancing method in the Network > WAN Failover & LB page. Click Accept
to save your changes on the Network > WAN Failover & LB page.
Step 1

Click the Add button under the Route Policies table. The Add Route Policy window is
displayed.

Step 2

Create a routing policy that directs all LAN Subnet sources to Any destinations for HTTP
service out of the X1 Default Gateway via the X1 interface by selecting these settings from the
Source, Destination, Service, Gateway and Interface menus respectively. Use the default 1
in the Metric field and enter force http out primary into the Comment field. Click OK.

Step 3

Create a second routing policy that directs all LAN Subnet sources to Any destinations for
Telnet service out of the X3 Default Gateway via the X3 interface by selecting these settings
from the Source, Destination, Service, Gateway and Interface menus respectively. Use the
default 1 in the Metric field and enter force telnet out backup into the Comment field. Click
OK.

Note

Do not enable the Allow VPN path to take precedence option for these routing policies.
The Allow VPN path to take precedence option gives precedence over the route to VPN
traffic to the same destination address object. This option is used for configuring static
routes as backups to VPN tunnels. See the “Static Route Configuration” section on page 329
for more information.
These two policy-based routes force all sources from the LAN subnet to always go out the
primary WAN when using any HTTP-based application, and forces all sources from the LAN
subnet to always go out the backup WAN when using any Telnet-based application.
To test the HTTP policy-based route, from a computer attached to the LAN interface, access
the public Web site http://www.whatismyip.com and http://whatismyip.everdot.org. Both sites
display the primary WAN interface’s IP address and not the secondary WAN interface.
To test the Telnet policy-based route, telnet to route-server.exodus.net and when logged in,
issue the who command. It displays the IP address (or resolved FQDN) of the WAN IP address
of the secondary WAN interface and not the primary WAN interface.

SonicOS 5.8.1 Administrator Guide

331

Network > Routing

Advanced Routing Services (OSPF and RIP)
In addition to Policy Based Routing and RIP advertising, SonicOS Enhanced offers the option
of enabling Advanced Routing Services (ARS). Advanced Routing Services provides full
advertising and listening support for the Routing Information Protocol (RIPv1 - RFC1058) and
(RIPv2 - RFC2453), and Open Shortest Path First (OSPFv2 – RFC2328). Advanced Routing
Service should only be enabled by those environments requiring support for either or both of
these dynamic routing protocols.
RIP and OSPF are Interior Gateway Protocols (IGP) that are both widely used by networks of
various sizes to automate the process of route distribution. RIP is commonly used within
smaller networks, while OSPF is used by larger networks, although network size should not be
the only factor used to determine the appropriateness of one protocol over the other – network
speed, interoperability requirements, and relative overall complexity, for example, should also
be considered. RIPv1 and RIPv2 are both supported by ARS, the largest differences between
the two being that RIPv2 supports VLSM (Variable Length Subnet Masks), authentication, and
routing updates. The following table illustrates the major differences between RIPv1, RIPv2,
and OSPFv2:

332

RIPv1

RIPv2

OSPFv2

Protocol metrics

Distance Vector

Distance Vector

Link State

Maximum Hops

15

15

Unlimited

Routing table
updates

Full table
broadcast
periodically,
slower
convergence

Full table
broadcast or
multicast
periodically,
slower
convergence

Link state
advertisement
multicasts,
triggered by
changes, fast
convergence

Subnet Sizes
Supported

Only class-based
(a/b/c) subnets
support

Class-based only

VLSM

Autonomous
system topology

Indivisible and flat

Indivisible and flat

Area based,
allowing for
segmentation and
aggregation

SonicOS 5.8.1 Administrator Guide

Network > Routing

•

Protocol Type – Distance Vector protocols such as RIP base routing metrics exclusively on
hop counts, while Link state protocols such as OSPF consider the state of the link when
determining metrics. For example, OSPF determines interface metrics by dividing its
reference bandwidth (100mbits by default) by the interface speed – the faster the link, the
lower the cost and the more preferable the path. Consider the following example network:

In the above sample network, if Host A wanted to reach Host B, with RIP, the lowest cost
route would be from Router A to Router B, across the relatively slow 64kbps link. With
OSPF, the cost from Router A to Router B would be 1562, while the cost from Router A to
Router C to Router D to Router B would be 364 (see the Cost section in OSPF concepts
later), making it the preferred route.
•

Maximum Hops – RIP imposes a hop count of 15 to help prevent routing loops which can
occur when bad (e.g. stale) routing information is broadcast and propagated through a
network either due to misconfiguration, or slow convergence. Consider if the link between
Router D and Router E failed in the diagram above, and there were no safeguards in place:

•

Router A’s routing information states that it can reach Network E through Router B or
Router C with a metric of 3.

•

When the link between Router D and Router E fail, and Router A broadcasts its routing
information, Router B and Router C determine that they can reach Network E through
Router A with a metric of 4.

•

Router B and Router C broadcast this information, and it is received by Router D which then
determines it can reach Network E through Router B or Router C with a metric of 5.

•

This loop continues until the hop count of 16 (infinity) is reached.
Other measures against this sort of situation are also commonly employed by RIP,
including:

•

Split-Horizon – A preventative mechanism where routing information learned through an
interface is not sent back out the same interface. This generally works well on broadcast
links, but not on non-broadcast links such as Frame Relay, where a single link can
commonly be used to reach two separate autonomous systems.

•

Poison reverse – Also known as route poisoning, an extension of split-horizon where a
network is advertised with a metric of 16 (unreachable), helping to ensure that incorrect
alternative routes aren’t propagated.

SonicOS 5.8.1 Administrator Guide

333

Network > Routing

OSPF does not have to impose a hop count limit because it does not advertise entire
routing tables, rather it generally only sends link state updates when changes occur.
This is a significant advantage in larger networks in that it converges more quickly,
produces less update traffic, and supports an unlimited number of hops.
•

Routing table updates – As mentioned above, the practice of sending an entire routing table
introduces the problems of slower convergences, higher bandwidth utilization, and
increased potential for stale routing information. RIPv1 broadcasts its entire routing table
at a prescribed interval (usually every 30 seconds), RIPv2 can either broadcast or
multicast, and OSPF multicasts only link state updates whenever a change to the network
fabric occurs. OSPF has a further advantage of using designated routers (DR) in forming
adjacencies in multiple-access networks (more on these concepts later) so that updates do
not have to be sent to the entire network.

•

Subnet sizes supported – RIPv1 was first implemented when networks were strictly class
A, class B, and class C (and later D and E):

•

Class A – 1.0.0.0 to 126.0.0.0 (0.0.0.0 and 127.0.0.0 are reserved)
– Leftmost bit 0; 7 network bits; 24 host bits
– 0nnnnnnn hhhhhhhh hhhhhhhh hhhhhhhh (8-bit classful netmask)
– 126 Class A networks, 16,777,214 hosts each

•

Class B - 128.0.0.0 to 191.255.0.0
– Leftmost bits 10; 14 network bits; 16 host bits
– 10nnnnnn nnnnnnnn hhhhhhhh hhhhhhhh (16-bit classful netmask)
– 16,384 Class B networks, 65,532 hosts each

•

Class C – 192.0.0.0 to 223.255.255.0
– Leftmost bits 110; 21 network bits; 8 host bits
– 110nnnnn nnnnnnnn nnnnnnnn hhhhhhhh (24-bit classful netmask)
– 2,097,152 Class Cs networks, 254 hosts each

•

Class D - 225.0.0.0 to 239.255.255.255 (multicast)
– Leftmost bits 1110; 28 multicast address bits
– 1110mmmm mmmmmmmm mmmmmmmm mmmmmmmm

•

Class E - 240.0.0.0 to 255.255.255.255 (reserved)
– Leftmost bits 1111; 28 reserved address bits
– 1111rrrr rrrrrrrr rrrrrrrr rrrrrrrr

This method of address allocation proved to be very inefficient because it provided no
flexibility, neither in the way of segmentation (subnetting) or aggregation (supernetting,
or CIDR – classless inter-domain routing) by means of VLSM – variable length subnet
masks.
VLSM, supported by RIPv2 and OSPF, allows for classless representation of networks
to break larger networks into smaller networks:
For example, take the classful 10.0.0.0/8 network, and assign it a /24 netmask. This
subnetting allocates an additional 16-bits from the host range to the network range
(24-8=16). To calculate the number of additional networks this subnetting provides,
raise 2 to the number of additional bits: 2^16=65,536. Thus, rather than having a
single network with 16.7 million hosts (usually more than most LAN’s require) it is
possible to have 65,536 networks, each with 254 usable hosts.
VLSM also allows for route aggregation (CIDR):

334

SonicOS 5.8.1 Administrator Guide

Network > Routing

For example, if you had 8 class C networks: 192.168.0.0/24 through 192.168.7.0/
24, rather than having to have a separate route statement to each of them, it would
be possible to provide a single route to 192.168.0.0/21 which would encompass
them all.
This ability, in addition to providing more efficient and flexible allocation of IP address
space, also allows routing tables and routing updates to be kept smaller.
•

Autonomous system topologies – An autonomous system (AS) is a collection of routers that
are under common administrative control, and that share the same routing characteristics.
When a group of autonomous systems share routing information, they are commonly
referred to as a confederation of autonomous systems. (RFC1930 and RFC975 address
these concepts in much greater detail). In simple terms, an AS is a logical distinction that
encompasses physical network elements based on the commonness of their
configurations.
With regard to RIP and OSPF, RIP autonomous systems cannot be segmented, and all
routing information must be advertised (broadcast) through the entire AS. This can become
difficult to manage and can result in excessive routing information traffic. OSPF, on the
other hand, employs the concept of Areas, and allows for logically, manageable
segmentation to control the sharing of information within an AS. OSPF areas begin with the
backbone area (area 0 or 0.0.0.0), and all other areas must connect to this backbone area
(although there are exceptions). This ability to segment the routing AS helps to ensure that
it never becomes too large to manage, or too computationally intensive for the routers to
handle.

OSPF Terms
OSPF is substantially more complicated to configure and maintain than RIP. The following
concepts are critical to understanding an OSPF routing environment:
•

Link state – As it pertains to OSPF, a link is an egress interface on a router, and the state
describes characteristics of that interface, such as its cost. Link states are sent in the form
of Link State Advertisements (LSA) which are contained within Link State Update (LSU)
packets, one of five types of OSPF packets.

•

Cost – A quantification of the overhead required to send a packet along a particular link.
Cost is calculated by dividing a reference bandwidth (usually 100mbit, or 10^8 bit) by an
interface’s speed. The lower the cost, the more preferable the link. Some common path
costs:
Interface

Divided by 10^8 (100mbit) = OSPF Cost

Fast Ethernet

1

Ethernet

10

T1 (1.544mbit)

64

DSL (1mbit)

100

DSL (512kbps) 200

•

64kbps

1562

56kbps

1785

Area – The network comprising the group of OSPF routers intended to share a common
Link State Database. OSPF networks are built around the backbone area (area 0, or
0.0.0.0) and all other areas must connect to the backbone area (unless virtual links are

SonicOS 5.8.1 Administrator Guide

335

Network > Routing

used, which is generally discouraged). Area assignment is interface specific on an OSPF
router; in other words, a router with multiple interfaces can have those interfaces configured
for the same or different areas.
•

Neighbors – OSPF routers on a common network segment have the potential to become
neighbors by means of sending Hello packets. Hello packets act as a form of advertisement
and identification, and if two OSPF routers share a common set of certain characteristics,
they will become neighbors upon seeing their own router ID in the other router’s Hello
packet. Hello packets are also used in the DR (Designated Router) and BDR (Backup
Designated Router) election process. For two routers to become neighbors, the
characteristics that they must have in common are:
– Area-ID – An area ID identifies an OSPF area with a 32-bit value, and is generally

represented in an IP address format. OSPF requires at a minimum the backbone area,
area 0 (or 0.0.0.0) for operation.
– Authentication – Authentication types can generally be set to none, simple text, or MD5.

When using simple text, it should only be used for identification purposes, since it is
sent in the clear. For security, MD5 should be used.
– Timer intervals – ‘Hello’ and ‘Dead’ intervals must be the same. The Hello interval

specifies the number of seconds between Hello packets (as a Keepalive function), and
the Dead interval specifies the number of seconds after which a router will be
considered unavailable if a Hello is not received.
– Stub area flag – A Stub area is an area that only requires a single point of egress, and

therefore does not require a full list of external link advertisements. The stub area flag
on two potential neighbors must be the same to avoid inappropriate link state
exchanges. Another factor that affects neighboring is the kind of network. OSPF
recognizes three network types:

336

•

Broadcast – For example, Ethernet. In broadcast networks, neighboring can be
established with all other routers in the broadcast domain.

•

Point to Point – For example, serial links. In point to point (or point to multipoint)
networks, neighboring can be established with the router at the other end of the link.

•

NBMA (non-broadcast multiple access) – For example, frame relay. In NBMA
networks, neighbors must be explicitly declared.

•

Link State Database – The Link State Database is composed of the LSA’s sent and
received by neighboring OSPF routers that have created adjacencies within an area. The
database, once complete, will contain all the link state information for a given area, at which
time the Shortest Path First (SPF) algorithm will be applied to determine the optimal route
to all connected networks based on cost. The SPF algorithm employs the Dijkstra
pathfinding algorithm, which essentially regards all routers as vertices in a graph, and
computes the cost between each vertex.

•

Adjacencies – OSPF routers exchange LSA’s with adjacent routers to create the LSDB.
Adjacencies are created in different fashions depending on the network type (see
Neighbors section above). Generally, the network type is broadcast (e.g. Ethernet) so
adjacencies are formed by the exchanging OSPF packets in a handshake-like fashion (see
OSPF Packet types below). To minimize the amount of information exchanged between
adjacent routers, segments (broadcast domains) with multiple OSPF routers elect a
Designated Router (DR) and a Backup Designated Router (BDR) using Hello packets.

•

DR (Designated Router) – On multi-access segments, OSPF routers elect a DR and a BDR,
and all other routers on the segment create adjacencies with the DR and the BDR. DR
election is based on a router’s OSPF Priority, which is a configurable value from 0 (not
eligible for DR) to 255. The router with the highest priority becomes the DR. In the event of
a priority tie, the router with the highest Router ID (based on interface addressing) wins.
Once a router is the DR, its role is uncontested, until it becomes unavailable.

SonicOS 5.8.1 Administrator Guide

Network > Routing

LSA’s are then exchanged within LSU’s across these adjacencies rather than between
each possible pairing combination of routers on the segment. Link state updates are sent
by non-DR routers to the multicast address 225.0.0.6, the RFC1583 assigned ‘OSPFIGP
Designated Routers’ address. They are also flooded by DR routers to the multicast address
225.0.0.5 ‘OSPFIGP All Routers’ for all routers to receives the LSA’s.

•

OSPF Packet types – The five types of OSPF packets are:
– Hello (OSPF type 1) – Sent at a certain interval to establish and maintain relationships

with neighboring OSPF routers, and elect Designated Routers. (Sent during the
initialization and the 2-WAY phases on LSDB synchronization).
– Database Description (OSPF type 2) – Sent between OSPF routers during the creation

of an adjacency. During the Exstart phase of LSDB synchronization, DD packets
establish an ISN (initial sequence number) used to track LSA’s, and they establish a
master/slave relationship between neighboring OSPF routers. In the Exchange phase
of LSDB synchronization, they contain short versions of Link State Advertisements.
Because DD exchanges can span multiple packets, they are exchanged in a poll
(master) and response (slave) fashion to ensure completeness.
– Link State Request (OSPF type 3) – During the Loading phase of LSDB

synchronization, LSR packets are sent to request database updates from a neighbor.
This is the final step in the establishment of an adjacency.
– Link State Update (OSPF type 4) – Sent in response to Link State Requests, LSU

packets flood adjacencies with Link State Advertisements to achieve LSDB
synchronization.
– Link State Acknowledgement (OSPF type 5) – To ensure reliability of LSA flooding, all

updates are acknowledged.
•

Link State Advertisements (LSA) – There are 7 types of LSA’s:
– Type 1 (Router Link Advertisements) - Sent by an OSPF router to describe the links to

each area to which it belongs. Type 1 LSA’s are only flooded into a router’s area.
– Type 2 (Network Links Advertisements) – Sent by the DR for an area describing the set

of routers within the network. Type 2 LSA’s are only flooded into a router’s area.
– Type 3 (Summary Link Advertisements) – Sent across areas by ABR’s (Area Border

Routers) to describe the networks within an area. Type 3 LSA’s are also used for route
aggregation purposes, and are not sent to Totally Stubby Areas.
– Type 4 (AS Summary Link Advertisements) – Sent across areas by ABR’s to describe

networks within a different AS. Type 4 LSA’s are not sent to Stub Areas.

SonicOS 5.8.1 Administrator Guide

337

Network > Routing

– Type 5 (AS External Link Advertisements) – Sent by ASBR (Autonomous System

Boundary Routers) to describe routes to networks in a different AS. Type 5 LSA’s are
net sent to Stub Areas. There are two types of External Link Advertisements:
•

External Type 1 - Type 1 packets add the internal link cost to the external link cost
when calculating a link’s metric. A Type 1 route is always preferred over a Type 2
route to the same destination.

•

External Type 2 - Type 2 packets only use the external link cost to determine the
metric. Type 2 is generally used when there is only one path to an external AS.

– Type 6 (Multicast OSPF) - Spooky. See RFC1584.
– Type 7 (NSSA AS External Link Advertisements) – Sent by ASBR’s that are part of an

NSSA (see ‘Stub Area’).

338

•

Stub Area – A stub area is an area that only requires one path, rather than an optimal path.
This can be an area with only a single point of egress, or it can be an area where SPF
optimization is not necessary. All routers in a stub area must be configured as stub routers,
and rather than receiving the full state database, and computing the SPF tree, they will
receive only a summary link information. There are different type of stub area:

•

Stub area – The standard stub area receives all LSA’s except for LSA type 5 (AS External
Link advertisement). This helps to keep the LSDB smaller, and reduces the computational
overhead on the router.

•

Totally Stubby Area – A special type of stub area into which LSA types 3 (Summary Links),
4 (AS Summary Links) and 5 are not passed. Only intra-area routes, and a default route are
advertised into totally stubby areas.

•

NSSA (Not So Stubby Area) – Described by RFC3101, NSSA is a hybrid stub area that
allows external routes to be flooded within the NSSA area using type 7 LSA’s (NSSA AS
External Routes), but does not accept type 5 LSA’s from other areas. NSSA’s are useful
when connecting a remote site running a different IGP (such as RIP) to an OSPF site,
where the remote site’s routes do not need to be distributed back to the main OSPF site.
An NSSA ABR (Area Border Router) also has the ability to translate type 7 to type 5 LSA’s
(this is possible only from the SonicOS Enhanced CLI).

•

Router Types – OSPF recognizes 4 types of routers, based on their roles:

•

IR (Internal Router) - A router whose interfaces are all contained within the same area. An
internal router’s LSDB only contains information about its own area.

SonicOS 5.8.1 Administrator Guide

Network > Routing

•

ABR (Area Border Router) – A router with interfaces in multiple areas. An ABR maintains
LSDB’s for each area to which it is connected, one of which is typically the backbone.

•

Backbone Router – A router with an interface connected to area 0, the backbone.

•

ASBR (Autonomous System Boundary Router) – A router with an interface connected to a
non-OSPF AS (such as a RIP network) which advertises external routing information from
that AS into the OSPF AS.

Configuring Advanced Routing Services
The following sections describe how to configure advanced routing:

Note

•

“Configuring RIP” on page 340

•

“Configuring OSPF” on page 341

•

“Configuring Advanced Routing for Tunnel Interfaces” on page 345

ARS is a fully featured multi-protocol routing suite. The sheer number of configurable
options and parameters provided is incongruous with the simplicity of a graphical user
interface. Rather than limiting the functionality of ARS, an abbreviated representation of its
capabilities has been rendered in the GUI, providing control over the most germane routing
features, while the full command suite is available via the CLI. The ARS CLI can be
accessed from an authenticated CLI session, and contains 3 modules:
•

route ars-nsm – The Advanced Routing Services Network Services Module. This
component provides control over core router functionality, such as interface bindings and
redistributable routes.

•

route ars-rip – The RIP module. Provides control over the RIP router.

•

route ars-ospf – The OSPF module. Provides control over the OSPF router.
In general, all of the functionality needed to integrate the SonicWALL into most RIP and
OSPF environments is available through the Web-based GUI. The additional capabilities of
the CLI will make more advanced configurations possible. Please refer to the appendix for
the full set of ARS CLI commands.

By default, Advanced Routing Services are disabled, and must be enabled to be made
available. At the top of the Network > Routing page, is a pull-down menu for Routing mode.
When you select Use Advanced Routing, the top of the Network > Routing page will look as
follows:

SonicOS 5.8.1 Administrator Guide

339

Network > Routing

The operation of the RIP and OSPF routing protocols is interface dependent. Each interface
and virtual subinterface can have RIP and OSPF settings configured separately, and each
interface can run both RIP and OSPF routers.
Configure RIP and OSPF for default routes received from Advanced Routing protocols as
follows:

Configuring RIP
To configure RIP routing on an interface, select the
(Configure) icon in the interface’s row
under the “Configure RIP” column. This will launch the RIP Configuration window.

RIP Modes
•

Disabled – RIP is disabled on this interface

•

Send and Receive – The RIP router on this interface will send updates and process
received updates.

•

Send Only – The RIP router on this interface will only send updates, and will not process
received updates. This is similar to the basic routing implementation.

•

Receive Only – The RIP router on this interface will only process received updates.

•

Passive – The RIP router on this interface will not process received updates, and will only
send updates to neighboring RIP routers specified with the CLI ‘neighbor’ command. This
mode should only be used when configuring advanced RIP options from the ars-rip CLI.

Receive (Available in ‘Send and Receive’ and ‘Receive Only’ modes)

340

•

RIPv1 – Receive only broadcast RIPv1 packets.

•

RIPv2 – Receive only multicast RIPv2 packets. RIPv2 packets are sent by multicast,
although some implementations of RIP routers (including basic routing on SonicWALL
devices) have the ability to send RIPv2 in either broadcast or multicast formats.

SonicOS 5.8.1 Administrator Guide

Network > Routing

Note

Be sure the device sending RIPv2 updates uses multicast mode, or the updates will not be
processed by the ars-rip router.

Send (Available in ‘Send and Receive’ and ‘Send Only’ modes)
•

RIPv1 – Send broadcast RIPv1 packets.

•

RIPv2 - v1 compatible – Send multicast RIPv2 packets that are compatible with RIPv1.

•

RIPv2 – Send multicast RIPv2 packets.

Split Horizon – Enabling Split Horizon will suppress the inclusion of routes sent in updates to
routers from which they were learned. This is a common RIP mechanism for preventing routing
loops. See the ‘maximum hops’ entry at the start of Advanced Routing Services section.
Poisoned Reverse – Poison reverse is an optional mode of Split Horizon operation. Rather than
suppressing the inclusion of learned routes, the routes are sent with a metric of infinity (16) thus
indicating that they are unreachable. See the ‘maximum hops’ entry at the start of Advanced
Routing Services section.
Use Password – Enables the use of a plain-text password on this interface, up to 16 alphanumeric characters long, for identification.
Default Metric – Used to specify the metric that will be used when redistributing routes from
other (Default, Static, Connected, OSPF, or VPN) routing information sources. The default
value (undefined) is 1 and the maximum is 15.
Administrative Distance – The administrative distance value is used by routers in selecting a
path when there is more than one route to a destination, with the smaller distance being
preferred. The default value is 120, minimum is 1, and maximum is 255.
Originate Default Route – This checkbox enables or disables the advertising of the
SonicWALL’s default route into the RIP system.
Redistribute Static Routes – Enables or disables the advertising of static (Policy Based
Routing) routes into the RIP system. The metric can be explicitly set for this redistribution, or it
can use the value (default) specified in the ‘Default Metric’ setting.
Redistribute Connected Networks - Enables or disables the advertising of locally connected
networks into the RIP system. The metric can be explicitly set for this redistribution, or it can
use the value (default) specified in the ‘Default Metric’ setting.
Redistribute OSPF Routes - Enables or disables the advertising of routes learned via OSPF
into the RIP system. The metric can be explicitly set for this redistribution, or it can use the value
(default) specified in the ‘Default Metric’ setting.
Redistribute Remote VPN Networks - Enables or disables the advertising of static (Policy
Based Routing) routes into the RIP system. The metric can be explicitly set for this
redistribution, or it can use the value (default) specified in the ‘Default Metric’ setting.
Routes learned via RIP will appear in the Route Policies table as OSPF or RIP route.

Configuring OSPF
Note

OSPF design concepts are beyond the scope of this document. The following section
describes how to configure a SonicWALL to integrate into an OSPF network, be it existing
or newly implemented, but it does not offer design guidelines. For terms used throughout
this section, refer to the ‘OSPF Terms’ section above.

SonicOS 5.8.1 Administrator Guide

341

Network > Routing

Consider the following simple example network:

The diagram illustrates an OSPF network where the backbone (area 0.0.0.0) comprises the X0
interface on the SonicWALL and the int1 interface on Router A. Two additional areas, 0.0.0.1
and 100.100.100.100 are connected, respectively, to the backbone via interface int2 on ABR
Router A, and via the X4:100 VLAN subinterface on the SonicWALL.
To configure OSPF routing on the X0 and the X4:100 interfaces, select the
(Configure) icon
in the interface’s row under the “Configure OSPF” column. This will launch the following
window:

342

SonicOS 5.8.1 Administrator Guide

Network > Routing

OSPFv2 Setting
•

Disabled – OSPF Router is disabled on this interface

•

Enabled – OSPF Router is enabled on this interface

•

Passive – The OSPF router is enabled on this interface, but only advertises connected
networks using type 1 LSA’s (Router Link Advertisements) into the local area. This is
different from the ‘Redistribute Connected Networks’ options, which would cause the OSPF
router to behave as an ASBR, and to use type 5 LSA’s (AS External Link Advertisement) to
flood the advertisements into all non-stub areas. See the ‘OSPF Terms’ section for more
information.

Dead Interval – The period after with an entry in the LSDB is removed if not Hello is received.
The default is 40 seconds, with a minimum of 1 and a maximum on 65,535. Be sure this value
agrees with the other OSPF routers on the segment for successful neighbor establishment.
Hello Interval – The period of time between Hello packets. The default is 10 seconds, with a
minimum of 1 and a maximum on 65,535. Be sure this value agrees with the other OSPF routers
on the segment for successful neighbor establishment.
Authentication - Be sure this setting agrees with the other OSPF routers on the segment for
successful neighbor establishment.
•

Disabled – No authentication is used on this interface.

•

Simple Password – A plain-text password is used for identification purposes by the OSPF
router on this interface.

•

Message Digest – An MD5 hash is used to securely identify the OSPF router on this
interface.

OSPF Area – The OSPF Area can be represented in either IP or decimal notation. For example,
you may represent the area connected to X4:100 as either 100.100.100.100 or 1684300900.
OSPFv2 Area Type – See the ‘OSPF Terms’ section above for a more detailed description of
these settings.
•

Normal – Receives and sends all applicable LSA types.

•

Stub Area – Does not receive type 5 LSA’s (AS External Link Advertisements).

•

Totally Stubby Area – Does not receive LSA types 3, 4, or 5.

•

Not So Stubby Area – Receives type 7 LSA’s (NSSA AS External Routes).

Interface Cost – Specifies the overhead of sending packets across this interface. The default
value is 10, generally used to indicate an Ethernet interface. The minimum value is 1 (e.g. Fast
Ethernet) and the maximum value is 65,535 (e.g. pudding).
Router Priority – The router priority value is used in determining the Designated Router (DR)
for a segment. The higher the value, the higher the priority. In the event of a priority tie, the
Router ID will act as the tie-breaker. Setting a value of 0 makes the OSPF router on this
interface ineligible for DR status. The default value is 1, and the maximum value is 255.
OSPF Router ID – The Router ID can be any value, represented in IP address notation. It is
unrelated to the any of the IP addresses on the SonicWALL, and can be set to any unique value
within your OSPF network.
ABR Type – Allows for the specification of the topology with which this OSPF router will be
participating, for the sake of compatibility. The options are:
•

Standard – Full RFC2328 compliant ABR OSPF operation.

•

Cisco – For interoperating with Cisco’s ABR behavior, which expects the backbone to be
configured and active before setting the ABR flag.

SonicOS 5.8.1 Administrator Guide

343

Network > Routing

•

IBM – For interoperating with IBM’s ABR behavior, which expects the backbone to be
configured before settings the ABR flag.

•

Shortcut – A ‘shortcut area’ enables traffic to go through the non-backbone area with a
lower metric whether or not the ABR router is attached to area 0.

Default Metric – Used to specify the metric that will be used when redistributing routes from
other (Default, Static, Connected, RIP, or VPN) routing information sources. The default value
(undefined) is 1 and the maximum is 16,777,214.
Originate Default Route – Controls the advertising of the SonicWALL security appliance’s
default route into the OSPF system on this interface. The options are:

Note

•

Never – Disables advertisement of the default route into the OSPF system.

•

When WAN is up – Advertises the default route into the OSPF system when the WAN is
online. The default route is always advertised as an External Type 2 using LSA Type 5.

•

Always – Enables advertisement of the default route into the OSPF system. The default
route is always advertised as an External Type 2 using LSA Type 5.

The following applies to all Redistributed routes: The metric can be explicitly set for this
redistribution, or it can use the value (default) specified in the ‘Default Metric’ setting. An
optional route tag value can be added to help other routers identify this redistributed route
(the default tag value is 0). The redistributed route advertisement will be an LSA Type 5, and
the type may be selected as either Type 1 (adds the internal link cost) or Type 2 (only uses
the external link cost).
Redistribute Static Routes – Enables or disables the advertising of static (Policy Based
Routing) routes into the OSPF system.
Redistribute Connected Networks - Enables or disables the advertising of locally connected
networks into the OSPF system.
Redistribute RIP Routes - Enables or disables the advertising of routes learned via RIP into the
OSPF system.
Redistribute Remote VPN Networks - Enables or disables the advertising of static (Policy
Based Routing) routes into the RIP system.
The Routing Protocols section will show the status of all active OSPF routers by interface.

The
and
Status LED’s indicate whether or not there are active neighbors, and can be
moused over for more detail.
The Routing Policies section will show routes learned by OSPF as OSPF or RIP Routes.

344

SonicOS 5.8.1 Administrator Guide

Network > Routing

Configuring Advanced Routing for Tunnel Interfaces
In SonicOS versions 5.6 and higher, VPN Tunnel Interfaces can be configured for advanced
routing. To do so, you must enable advanced routing for the tunnel interface on the Advanced
tab of its configuration. See “Adding a Tunnel Interface” on page 906 for more information.
After you have enabled advanced routing for a Tunnel Interface, it is displayed in the list with
the other interfaces in the Advanced Routing table on the Network > Routing page.

To configure Advanced Routing options, click on the Configure RIP or Configure OSPF icon
for the Tunnel Interface you wish to configure.
The RIP and OSPF configurations for Tunnel Interfaces are very similar to the configurations
for traditional interfaces with the addition of two new options that are listed at the bottom of the
RIP or OSPF configuration window under a new Global Unnumbered Configuration heading.

Global Unnumbered Configuration
Because Tunnel Interfaces are not physical interfaces and have no inherent IP address, they
must “borrow” the IP address of another interface. Therefore, the advanced routing
configuration for a Tunnel Interface includes the following options for specifying the source and
destination IP addresses for the tunnel:
•

Note

The borrowed IP address must be a static IP address.
•

Note

IP Address Borrowed From - The interface whose IP address is used as the source IP
address for the Tunnel Interface.

Remote IP Address - The IP address of the remote peer to which the Tunnel Interface is
connected. In the case of a SonicWALL-to-SonicWALL configuration with another Tunnel
Interface, this should be the IP address of the borrowed interface of the Tunnel Interface
on the remote peer.

The IP Address Borrowed From and Remote IP Address values apply to both RIP and
OSPF for the Tunnel Interface. Changing one of these values in in RIP will change the value
in OSPF and vice versa.

SonicOS 5.8.1 Administrator Guide

345

Network > Routing

Guidelines for Configuring Tunnel Interfaces for Advanced Routing
The following guidelines will ensure success when configuring Tunnel Interfaces for advanced
routing:

Tip

•

The borrowed interface must have a static IP address assignment.

•

The borrowed interface cannot have RIP or OSPF enabled on its configuration.

SonicWALL recommends creating a VLAN interface that is dedicated solely for use as the
borrowed interface. This avoids conflicts when using wired connected interfaces.
•

The IP address of the borrowed interface should be from a private address space, and
should have a unique IP address in respect to any remote Tunnel Interface endpoints.

•

The Remote IP Address of the endpoint of the Tunnel Interface should be in the same
network subnet as the borrowed interface.

•

The same borrowed interface may be used for multiple Tunnel Interfaces, provided that the
Tunnel interfaces are all connected to different remote devices.

•

When more than one Tunnel Interface on an appliance is connected to the same remote
device, each Tunnel Interface must use a unique borrowed interface.

Depending on the specific circumstances of your network configuration, these guidelines may
not be essential to ensure that the Tunnel Interface functions properly. But these guidelines are
SonicWALL best practices that will avoid potential network connectivity issues.

346

SonicOS 5.8.1 Administrator Guide

CHAPTER 23
Chapter 23:

Configuring NAT Policies

Network > NAT Policies
This chapter contains the following sections:
•

“NAT Policies Table” on page 348

•

“NAT Policy Settings Explained” on page 349

•

“NAT Policies Q&A” on page 351

The Network Address Translation (NAT) engine in SonicOS Enhanced allows users to define
granular NAT polices for their incoming and outgoing traffic. By default, the SonicWALL security
appliance has a preconfigured NAT policy to allow all systems connected to the X0 interface to
perform Many-to-One NAT using the IP address of the X1 interface, and a policy to not perform
NAT when traffic crosses between the other interfaces. This chapter explains how to set up the
most common NAT policies.
Understanding how to use NAT policies starts with an the construction of an IP packet. Every
packet contains addressing information that allows the packet to get to its destination, and for
the destination to respond to the original requester. The packet contains (among other things)
the requester’s IP address, the protocol information of the requestor, and the destination’s IP
address. The NAT Policies engine in SonicOS Enhanced can inspect the relevant portions of
the packet and can dynamically rewrite the information in specified fields for incoming, as well
as outgoing traffic.
You can add up to 512 NAT Policies on a SonicWALL security appliance running SonicOS
Enhanced, and they can be as granular as you need. It is also possible to create multiple NAT
policies for the same object – for instance, you can specify that an internal server use one IP
address when accessing Telnet servers, and to use a totally different IP address for all other
protocols. Because the NAT engine in SonicOS Enhanced supports inbound port forwarding, it
is possible to hide multiple internal servers off the WAN IP address of the SonicWALL security
appliance. The more granular the NAT Policy, the more precedence it takes.

SonicOS 5.8.1 Administrator Guide

347

Network > NAT Policies

NAT Policies Table
The NAT Policies table allows you to view your NAT Policies by Custom Policies, Default
Policies, or All Policies.

Tip

Before configuring NAT Policies, be sure to create all Address Objects associated with the
policy. For instance, if you are creating a One-to-One NAT policy, be sure you have Address
Objects for your public and private IP addresses.

Tip

By default, LAN to WAN has a NAT policy predefined on the SonicWALL.

Navigating and Sorting NAT Policy Entries
You can change the view your route policies in the NAT Policies table by selecting one of the
view settings in the View Style menu. All Policies displays all the routing policies including
Custom Policies and Default Policies. Initially, only the Default Policies are displayed in the
Route Policies table when you select All Policies from the View Style menu.
The NAT Policies table provides easy pagination for viewing a large number of VPN policies.
You can navigate a large number of VPN policies listed in the Route Policies table by using
the navigation control bar located at the top right of the Route Policies table. Navigation control
bar includes four buttons. The far left button displays the first page of the table. The far right
button displays the last page. The inside left and right arrow buttons moved the previous or next
page respectively.
You can enter the policy number (the number listed in the # column) in the Items field to move
to a specific VPN policy. The default table configuration displays 50 entries per page. You can
change this default number of entries for tables on the System > Administration page.
You can sort the entries in the table by clicking on the column header. The entries are sorted
by ascending or descending order. The arrow to the right of the column entry indicates the
sorting status. A down arrow means ascending order. An up arrow indicates a descending
order.
Moving your pointer over the Comment icon in the Configure column of NAT Policies table
displays the comments entered in the Comments field of the Add NAT Policy window.
Moving your pointer over the Statistics icon in the Configure column of NAT Policies table
displays traffic statistics for the NAT policy.
Clicking the Delete icon
deletes the NAT Policy entry. If the icon is dimmed, the NAT Policy
is a default entry and you cannot delete it.

348

SonicOS 5.8.1 Administrator Guide

Network > NAT Policies

NAT Policy Settings Explained
The following explains the settings used to create a NAT policy entry in the Add NAT Policy or
Edit NAT Policy windows.

Click the Add button in the Network > NAT Policies page to display the Add NAT Policy
window to create a new NAT policy or click the Edit icon in the Configure column for the NAT
policy you want to edit to display the Edit NAT Policy window.
•

Original Source: This drop-down menu setting is used to identify the Source IP
address(es) in the packet crossing the SonicWALL security appliance, whether it is across
interfaces, or into/out-of VPN tunnels. You can use the default Address Objects in SonicOS
Enhanced, or you can create your own Address Objects. These entries can be single host
entries, address ranges, or IP subnets.

•

Translated Source: This drop-down menu setting is what the SonicWALL security
appliance translates the specified Original Source to as it exits the SonicWALL security
appliance, whether it is to another interface, or into/out-of VPN tunnels. You can use the
default Address Objects in SonicOS Enhanced, or you can create your own Address
Objects entries. These entries can be single host entries, address ranges, or IP subnets.

•

Original Destination: This drop-down menu setting is used to identify the Destination IP
address(es) in the packet crossing the SonicWALL security appliance, whether it be across
interfaces, or into/out-of VPN tunnels. When creating outbound NAT polices, this entry is
usually set to Any since the destination of the packet is not being changed, but the source
is being changed. However, these Address Object entries can be single host entries,
address ranges, or IP subnets.

•

Translated Destination: This drop-down menu setting is what the SonicWALL translates
the specified Original Destination to as it exits the SonicWALL security appliance, whether
it is to another interface, or into/out-of VPN tunnels. When creating outbound NAT polices,
this entry is usually set to Original, since the destination of the packet is not being changed,
but the source is being changed. However, these Address Objects entries can be single
host entries, address ranges, or IP subnets.

•

Original Service: This drop-down menu setting is used to identify the IP service in the
packet crossing the SonicWALL security appliance, whether it is across interfaces, or into/
out-of VPN tunnels. You can use the default services on the SonicWALL, or you can create
your own entries. For many NAT policies, this field is set to Any, as the policy is only altering
source or destination IP addresses.

SonicOS 5.8.1 Administrator Guide

349

Network > NAT Policies

350

•

Translated Service: This drop-down menu setting is what the SonicWALL security
appliance translates the Original Service to as it exits the SonicWALL security appliance,
whether it be to another interface, or into/out-of VPN tunnels. You can use the default
services in the SonicWALL security appliance, or you can create your own entries. For
many NAT Policies, this field is set to Original, as the policy is only altering source or
destination IP addresses.

•

Inbound Interface: This drop-down menu setting is used to specify the entry interface of
the packet. When dealing with VPNs, this is usually set to Any, since VPN tunnels aren’t
really interfaces.

•

Outbound Interface: This drop-down is used to specify the exit interface of the packet
once the NAT policy has been applied. This field is mainly used for specifying which WAN
interface to apply the translation to. Of all fields in NAT policy, this one has the most
potential for confusion. When dealing with VPNs, this is usually set to Any, since VPN
tunnels aren’t really interfaces. Also, as noted in the Quick Q&A’ section of this chapter,
when creating inbound 1-2-1 NAT Policies where the destination is being remapped from a
public IP address to a private IP address, this field must be set to Any.

•

Comment: This field can be used to describe your NAT policy entry. The field has a 32character limit, and once saved, can be viewed in the main Network > NAT Policies page
by running the mouse over the text balloon next to the NAT policy entry. Your comment
appears in a pop-up window as long as the mouse is over the text balloon.

•

Enable NAT Policy: By default, this box is checked, meaning the new NAT policy is
activated the moment it is saved. To create a NAT policy entry but not activate it
immediately, uncheck this box.

•

Create a reflective policy: When you check this box, a mirror outbound or inbound NAT
policy for the NAT policy you defined in the Add NAT Policy window is automatically
created.

SonicOS 5.8.1 Administrator Guide

Network > NAT Policies

NAT Policies Q&A
Why is it necessary to specify ‘Any’ as the destination interface for inbound 1-2-1
NAT policies?
It may seem counter-intuitive to do this, given that other types of NAT policies require you to
specify the destination interface, but for this type of NAT policy, this is what is necessary. The
SonicWALL security appliance uses this field during the NAT Policy lookup and validates it
against the packet that it receives, but if this is set to some internal interface such as LAN, the
lookup fails because at that point, the SonicWALL security appliance does not know that the
packet is going to LAN. It is not until after the SonicWALL security appliance performs the NAT
Policy lookup that it knows that the packet is going to LAN. At the precise time that the
SonicWALL security appliance does the NAT Policy lookup, the packet looks like it is going from
WAN -> WAN (or whatever interface it is coming in on), since doing a route lookup on the NAT
Public address returns the Public interface.

Can I manually order the NAT Polices?
No, the SonicWALL security appliance automatically orders them, depending on the granularity
of the rule. This means that you can create NAT policy entries for the same objects, if each
policy has more granularity than the existing policy. For example, you can create a NAT policy
to translate all LAN systems to the WAN IP address, then create a policy saying that a specific
system on that LAN use a different IP address, and additionally, create a policy saying that
specific use another IP address when using HTTP.

Can I Have Multiple NAT Policies for the Same Objects?
Yes – please read the section above.

What are the NAT ‘System Policies’?
On the Network > NAT Policies page, notice a radio button labeled System Polices. If you
choose this radio button, the NAT Polices page displays all of the default, auto-created NAT
policies for the SonicWALL security appliance. These policies are default settings for the
SonicWALL security appliance to operate properly, and cannot be deleted. For this reason, they
are listed in their own section, in order to make the user-created NAT policies easier to browse.
If you wish to see user-created NAT policies along with the default NAT policies, simply check
the radio button next to ‘All Policies’.

Can I Write NAT Policies for VPN Traffic?
Yes, this is possible if both sides of the VPN tunnel are SonicWALL security policies running
SonicOS Enhanced firmware. Please refer to the technote SonicOS Enhanced NAT VPN
Overlap for instructions on how to perform NAT on traffic entering and exiting VPN tunnels.
Available at
http://www.sonicwall.com/us/Support.html.

SonicOS 5.8.1 Administrator Guide

351

Network > NAT Policies

Why Do I Have to Write Two Policies for 1-2-1 Traffic?
With the new NAT engine, it is necessary to write two policies – one to allow incoming requests
to the destination public IP address to reach the destination private IP address (uninitiated
inbound), and one to allow the source private IP address to be remapped to the source public
IP address (initiated outbound). It takes a bit more work, but it is a lot more flexible.

NAT Load Balancing Overview
This section provides an introduction to the NAT Load Balancing feature. It contains the
following subsections:
•

“NAT LB Mechanisms” on page 353

•

“Which NAT LB Method Should I Use?” on page 354

•

“Caveats” on page 354

•

“Details of Load Balancing Algorithms” on page 354

Network Address Translation (NAT) & Load Balancing (LB) provides the ability to balance
incoming traffic across multiple, similar network resources. Do not confuse this with the WAN
ISP & LB feature on the SonicWALL appliance. While both features can be used in conjunction,
WAN ISP & LB is used to balance outgoing traffic across two ISP connections, and NAT LB is
primarily used to balance incoming traffic.
Load Balancing distributes traffic among similar network resources so that no single server
becomes overwhelmed, allowing for reliability and redundancy. If one server becomes
unavailable, traffic is routed to available resources, providing maximum uptime.
This document details how to configure the necessary NAT, load balancing, health check,
logging, and firewall rules to allow systems from the public Internet to access a Virtual IP (VIP)
that maps to one or more internal systems, such as Web servers, FTP servers, or SonicWALL
SSL VPN appliances. This Virtual IP may be independent of the SonicWALL appliance or it may
be shared, assuming the SonicWALL appliance itself is not using the port(s) in question.
Please note that the load balancing capability in SonicOS Enhanced firmware versions 4.0 and
higher, while fairly basic, will satisfy the requirements for many customer network deployments.
Customers with environments needing more granular load balancing, persistence, and healthcheck mechanisms are advised to use a dedicated third-party load balancing appliance (prices
run from US$4,000 to US$25,000 per device).

352

SonicOS 5.8.1 Administrator Guide

Network > NAT Policies

NAT LB Mechanisms
NAT load balancing is configured on the Advanced tab of a NAT policy.

Note

This tab can only be activated when a group is specified in one of the drop-down fields on
the General tab of a NAT Policy. Otherwise, the NAT policy defaults to Sticky IP as the NAT
method.
SonicOS offers the following NAT methods:
•

Sticky IP – Source IP always connects to the same Destination IP (assuming it is alive).
This method is best for publicly hosted sites requiring connection persistence, such as Web
applications, Web forms, or shopping cart applications. This is the default mechanism, and
is recommended for most deployments.

•

Round Robin – Source IP cycles through each live load-balanced resource for each
connection. This method is best for equal load distribution when persistence is not required.

•

Block Remap/Symmetrical Remap – These two methods are useful when you know the
source IP addresses/networks (e.g. when you want to precisely control how traffic from one
subnet is translated to another).

•

Random Distribution – Source IP connects to Destination IP randomly. This method is
useful when you wish to randomly spread traffic across internal resources.

•

NAT Method – This drop-down allows the user to specify one of five load balancing
methods: Sticky IP, Round Robin, Block Remap, Symmetric Remap, or Random
Distribution. For most purposes, Sticky IP is preferred.

•

Enable Probing – When checked, the SonicWALL will use one of two methods to probe
the addresses in the load-balancing group, using either a simple ICMP ping query to
determine if the resource is alive, or a TCP socket open query to determine if the resource
is alive. Per the configurable intervals, the SonicWALL can direct traffic away from a nonresponding resource, and return traffic to the resource once it has begun to respond again.

SonicOS 5.8.1 Administrator Guide

353

Network > NAT Policies

Which NAT LB Method Should I Use?
Requirement

Deployment Example

NAT LB Method

Distribute load on server equally External/ Internal servers (i.e. Web, FTP,
without need for persistence
etc.)

Round Robin

Indiscriminate load balancing
without need for persistence

External/ Internal servers (i.e. Web, FTP,
etc.)

Random
Distribution

Requires persistence of client
connection

E-commerce site, Email Security, SSL VPN Sticky IP
appliance

(Any publicly accessible servers requiring
persistence)
Precise control of remap of source LAN to DMZ Servers
Block Remap
network to a destination range
E-mail Security, SSL VPN
Precise control of remap of source Internal Servers (i.e. Intranets or Extranets) Symmetrical
network and destination network
Remap

Caveats
•

The NAT Load Balancing Feature is only available in SonicOS Enhanced 4.0 and higher.

•

Only two health-check mechanisms at present (ICMP ping and TCP socket open).

•

No higher-layer persistence mechanisms at present (Sticky IP only).

•

No “sorry-server” mechanism at present if all servers in group are not responding.

•

No “round robin with persistence” mechanism at present.

•

No “weighted round robin” mechanism at present.

•

No method for detecting if resource is strained, at present.

•

While there is no limit to the number of internal resources the SonicWALL appliance can
load-balance to, and there no limit to the number of hosts it can monitor, abnormally large
load-balancing groups (25+resources) may impact performance.

Details of Load Balancing Algorithms
This appendix describes how the SonicWALL security appliance applies the load balancing
algorithms:
•

Round Robin - Source IP connects to Destination IP alternately

•

Random Distribution - Source IP connects to Destination IP randomly

•

Sticky IP - Source IP connects to same Destination IP

•

Block Remap - Source network is divided by size of the Destination pool to create logical
segments

•

Symmetrical Remap - Source IP maps to Destination IP (for example, 10.1.1.10 ->
192.168.60.10.)

Sticky IP Algorithm
Source IP is modulo with the size of the server cluster to determine the server to remap it to.
The following two examples show how the Sticky IP algorithm works.

354

SonicOS 5.8.1 Administrator Guide

Network > NAT Policies

Example one - Mapping to a network:
192.168.0.2 to 192.168.0.4
Translated Destination = 10.50.165.0/30 (Network)
Packet Source IP = 192.168.0.2
192.168.0.2 = C0A80002 = 3232235522 = 11000000101010000000000000000010
(IP -> Hex -> Dec -> Binary)
Sticky IP Formula = Packet Src IP = 3232235522 [modulo] TransDest Size = 2
= 3232235522 [modulo] 2
=0
(2 divides into numerator evenly. There is no remainder, thus 0)
Stickyt IP Formula yields offset of 0.
Destination remapping to 10.50.165.1.
Example two - Mapping to a IP address range:
192.168.0.2 to 192.168.0.4
Translated Destination = 10.50.165.1 -10.50.165.3 (Range)
Packet Src IP = 192.168.0.2
192.168.0.2 = C0A80002 = 3232235522 = 11000000101010000000000000000010
(IP -> Hex -> Dec -> Binary)
Sticky IP Formula = Packet Src IP = 3232235522 [modulo] TransDest Size = 3
= 3232235522 [modulo] 4
= 1077411840.6666667 - 1077411840
= 0.6666667 * 3
=2
Stickyt IP Formula yields offset of 2.
Destionation remapping to 10.50.165.3.

SonicOS 5.8.1 Administrator Guide

355

Network > NAT Policies

Creating NAT Policies
NAT policies allow you the flexibility to control Network Address Translation based on matching
combinations of Source IP address, Destination IP address, and Destination Services. Policybased NAT allows you to deploy different types of NAT simultaneously. This section contains
the following subsections:
•

“Creating a Many-to-One NAT Policy” on page 356

•

“Creating a Many-to-Many NAT Policy” on page 357

•

“Creating a One-to-One NAT Policy for Outbound Traffic” on page 358

•

“Creating a One-to-One NAT Policy for Inbound Traffic (Reflective)” on page 359

•

“Configuring One-to-Many NAT Load Balancing” on page 360

•

“Inbound Port Address Translation via One-to-One NAT Policy” on page 361

•

“Inbound Port Address Translation via WAN IP Address” on page 362

•

“Using NAT Load Balancing” on page 366

For this chapter, the examples use the following IP addresses as examples to demonstrate the
NAT policy creation and activation. You can use these examples to create NAT policies for your
network, substituting your IP addresses for the examples shown here:
•

192.168.10.0/24 IP subnet on interface X0

•

67.115.118.64/27 IP subnet on interface X1

•

192.168.30.0/24 IP subnet on interface X2

•

X0 IP address is 192.168.10.1

•

X1 IP address is 67.115.118.68

•

X2 ‘Sales’ IP address is 192.168.30.1

•

Web server’s “private” address at 192.168.30.200

•

Web server’s “public” address at 67.115.118.70

•

Public IP range addresses of 67.115.118.71 – 67.115.118.74

Creating a Many-to-One NAT Policy
Many-to-One is the most common NAT policy on a SonicWALL security appliance, and allows
you to translate a group of addresses into a single address. Most of the time, this means that
you’re taking an internal “private” IP subnet and translating all outgoing requests into the IP
address of the WAN interface of the SonicWALL security appliance (by default, the X1
interface), such that the destination sees the request as coming from the IP address of the
SonicWALL security appliance WAN interface, and not from the internal private IP address.
This policy is easy to set up and activate. From the Management Interface, go to the Network
> NAT Policies page and click on the Add button. The Add NAT Policy window is displayed
for adding the policy. To create a NAT policy to allow all systems on the X2 interface to initiate
traffic using the SonicWALL security appliance’s WAN IP address, choose the following from
the drop-down boxes:

356

•

Original Source: X2 Subnet

•

Translated Source: WAN Primary IP

•

Original Destination: Any

•

Translated Destination: Original

SonicOS 5.8.1 Administrator Guide

Network > NAT Policies

•

Original Service: Any

•

Translated Service: Original

•

Inbound Interface: X2

•

Outbound Interface: X1

•

Comment: Enter a short description

•

Enable NAT Policy: Checked

•

Create a reflective policy: Unchecked

When done, click on the OK button to add and activate the NAT Policy. This policy can be
duplicated for subnets behind the other interfaces of the SonicWALL security appliance – just
replace the Original Source with the subnet behind that interface, adjust the source interface,
and add another NAT policy.

Creating a Many-to-Many NAT Policy
The Many-to-Many NAT policy allows you to translate a group of addresses into a group of
different addresses. This allows the SonicWALL security appliance to utilize several addresses
to perform the dynamic translation. Thus allowing a much higher number of concurrent the
SonicWALL security appliance to perform up to a half-million concurrent connections across
the interfaces.
This policy is easy to set up and activate. You first need to go to the Network > Address
Objects and click on the Add button at the bottom of the screen. When the Add Address
Object window appears, enter in a description for the range in the Name field, choose Range
from the drop-down menu, enter the range of addresses (usually public IP addresses supplied
by your ISP) in the Starting IP Address and Ending IP Address fields, and select WAN as
the zone from the Zone Assignment menu. When done, click on the OK button to create the
range object.
Select Network > NAT Policies and click on the Add button. The Add NAT Policy window is
displayed. To create a NAT policy to allow the systems on the LAN interface (by default, the X0
interface) to initiate traffic using the public range addresses, choose the following from the
drop-down menus:
•

Original Source: LAN Primary Subnet

•

Translated Source: public_range

•

Original Destination: Any

•

Translated Destination: Original

•

Original Service: Any

•

Translated Service: Original

•

Inbound Interface: X0

•

Outbound Interface: X1

•

Comment: Enter a short description

•

Enable NAT Policy: Checked

•

Create a reflective policy: Unchecked

When done, click on the OK button to add and activate the NAT Policy. With this policy in place,
the SonicWALL security appliance dynamically maps outgoing traffic using the four available
IP addresses in the range we created.

SonicOS 5.8.1 Administrator Guide

357

Network > NAT Policies

You can test the dynamic mapping by installing several systems on the LAN interface (by
default, the X0 interface) at a spread-out range of addresses (for example, 192.168.10.10,
192.168.10.100, and 192.168.10.200) and accessing the public Website http://
www.whatismyip.com from each system. Each system should display a different IP address
from the range we created and attached to the NAT policy.

Creating a One-to-One NAT Policy for Outbound Traffic
One-to-One NAT for outbound traffic is another common NAT policy on a SonicWALL security
appliance for translating an internal IP address into a unique IP address. This is useful when
you need specific systems, such as servers, to use a specific IP address when they initiate
traffic to other destinations. Most of the time, a NAT policy such as this One-to-One NAT policy
for outbound traffic is used to map a server’s private IP address to a public IP address, and it
is paired with a reflective (mirror) policy that allows any system from the public Internet to
access the server, along with a matching firewall access rule that permits this. Reflective NAT
policies are covered in the next section.
This policy is easy to set up and activate. Select Network > Address Objects and click on the
Add button at the bottom of the screen. In the Add Address Object window, enter a description
for server’s private IP address in the Name field. Choose Host from the Type menu, enter the
server’s private IP address in the IP Address field, and select the zone that the server assigned
from the Zone Assignment menu. Click OK. Then, create another object in the Add Address
Object window for the server’s public IP address and with the correct values, and select WAN
from Zone Assignment menu. When done, click on the OK button to create the range object.
Next, select Network > NAT Policies and click on the Add button to display the Add NAT
Policy window. To create a NAT policy to allow the Web server to initiate traffic to the public
Internet using its mapped public IP address, choose the following from the drop-down menus:
•

Original Source: webserver_private_ip

•

Translated Source: webserver_public_ip

•

Original Destination: Any

•

Translated Destination: Original

•

Original Service: Any

•

Translated Service: Original

•

Inbound Interface: X2

•

Outbound Interface: X1

•

Comment: Enter a short description

•

Enable NAT Policy: Checked

•

Create a reflective policy: Checked (Cannot be applied when “Translated Destination:
Original” is selected)

When done, click on the OK button to add and activate the NAT Policy. With this policy in place,
the SonicWALL security appliance translates the server’s private IP address to the public IP
address when it initiates traffic out the WAN interface (by default, the X1 interface).
You can test the One-to-One mapping by opening up a Web browser on the server and
accessing the public Website http://www.whatismyip.com. The Website should display the
public IP address we attached to the private IP address in the NAT policy we just created.

358

SonicOS 5.8.1 Administrator Guide

Network > NAT Policies

Creating a One-to-One NAT Policy for Inbound Traffic (Reflective)
Note

If “Translated Destination: Original” is selected in the NAT Policy Settings, this section does
not apply because the “Create a reflective policy” checkbox is greyed out.
This is the mirror policy for the one created in the previous section when you check Create a
reflective policy. It allows you to translate an external public IP addresses into an internal
private IP address. This NAT policy, when paired with a ‘permit’ access policy, allows any
source to connect to the internal server using the public IP address; the SonicWALL security
appliance handles the translation between the private and public address. With this policy in
place, the SonicWALL security appliance translates the server’s public IP address to the private
IP address when connection requests arrive via the WAN interface (by default, the X1
interface).
Below, you create the entry as well as the rule to allow HTTP access to the server. You need
to create the access policy that allows anyone to make HTTP connections to the Web server
via the Web server’s public IP address.

Note

With previous versions of firmware, it was necessary to write rules to the private IP address.
This has been changed as of SonicOS Enhanced. If you write a rule to the private IP
address, the rule does not work.
Go to the Firewall > Access Rules page and choose the policy for the ‘WAN’ to ‘Sales’ zone
intersection (or, whatever zone you put your server in). Click on the ‘Add…’ button to bring up
the pop-up access policy screen. When the pop-up appears, enter in the following values:
•

Action: Allow

•

Service: HTTP

•

Source: Any

•

Destination: Webserver_public_ip

•

Users Allowed: All

•

Schedule: Always on

•

Logging: Checked

•

Comment: (Enter a short description)

When you are done, attempt to access the Web server’s public IP address using a system
located on the public Internet. You should be able to successfully connect. If not, review this
section, and the section before, and ensure that you have entered in all required settings
correctly.

SonicOS 5.8.1 Administrator Guide

359

Network > NAT Policies

Configuring One-to-Many NAT Load Balancing
One-to-Many NAT policies can be used to persistently load balance the translated destination
using the original source IP address as the key to persistence. For example, SonicWALL
security appliances can load balance multiple SonicWALL SSL VPN appliances, while still
maintaining session persistence by always balancing clients to the correct destination SSL
VPN. The following figure shows a sample topology and configuration.
Gateway SonicWALL Configuration
192.168.168.168/24
X0 (LAN):
10.0.0.2/16 (Gateway 10.0.0.1)
X1 (WAN):
X2 (SSL VPN): 192.168.200.1/24

Internet Host
217.8.9.10

SSl VPN AO Group “mySSLVPN”
192.168.200.10 host
192.168.200.20 host
192.168.200.30 host

Internet

Internet Host
66.1.2.3

Access Rule
WAN -> LAN Allow Any to Primary WAN IP : HTTPS

X1

NAT Policy
OrigSrc:
TransSrc:
OrigDst:
TransDst:
Service:

Internet Host
204.20.30.40

192.168.200.10

Any
Orig
WAN Primary IP
“mySSLVPN”
HTTPS

192.168.200.20
link/act
10/100

SSL-VPN 200

192.168.200.30

Server 1
192.168.168.10

SSL VPN (192.168.200.0/24)

Server 2
192.168.168.20

Server 3
192.168.168.30

LAN (192.168.168.0/24)

To configure One-to-Many NAT load balancing, first go to the Firewall > Access Rules page
and choose the policy for WAN to LAN. Click on the Add… button to bring up the pop-up
access policy screen. When the pop-up appears, enter in the following values:
•

Action: Allow

•

Service: HTTPS

•

Source: Any

•

Destination: WAN Primary IP

•

Users Allowed: All

•

Schedule: Always on

•

Comment: Descriptive text, such as SSLVPN LB

•

Logging: Checked

•

Allow Fragmented Packets: Unchecked

Next, create the following NAT policy by selecting Network > NAT Policies and clicking on the
Add... button:

360

•

Original Source: Any

•

Translated Source: Original

•

Original Destination: WAN Primary IP

SonicOS 5.8.1 Administrator Guide

Network > NAT Policies

•

Translated Destination: Select Create new address object... to bring up the Add
Address Object screen.
– Name: A descriptive name, such as mySSLVPN
– Zone assignment: LAN
– Type: Host
– IP Address: The IP addresses for the devices to be load balanced (in the topology

shown above, this is 192.168.200.10, 192.168.200.20, and 192.168.200.30.)
•

Original Service: HTTPS

•

Translated Service: HTTPS

•

Inbound Interface: Any

•

Outbound Interface: Any

•

Comment: Descriptive text, such as SSLVPN LB

•

Enable NAT Policy: Checked

•

Create a reflective policy: Unchecked

Inbound Port Address Translation via One-to-One NAT Policy
This type of NAT policy is useful when you want to conceal an internal server’s real listening
port, but provide public access to the server on a different port. In the example below, you
modify the NAT policy and rule created in the previous section to allow public users to connect
to the private Web server on its public IP address, but via a different port (TCP 9000), instead
of the standard HTTP port (TCP 80).
Step 1

Create a custom service for the different port. Go to the Firewall > Custom Services page and
select the Add button. When the pop-up screen appears, give your custom service a name such
as webserver_public_port, enter in 9000 as the starting and ending port, and choose TCP(6)
as the protocol. When done, click on the OK button to save the custom service.

Step 2

Modify the NAT policy created in the previous section that allowed any public user to connect
to the Web server on its public IP address. Go to the Network > NAT Policies menu and click
on the Edit button next to this NAT policy. The Edit NAT Policy window is displayed for editing
the policy. Edit the NAT policy so that it includes the following from the drop-down menus:
•

Original Source: Any

•

Translated Source: Original

•

Original Destination: webserver_public_ip

•

Translated Destination: webserver_private_ip

•

Original Service: webserver_public_port (or whatever you named it above)

•

Translated Service: HTTP

•

Inbound Interface: X1

•

Outbound Interface: Any

•

Comment: Enter a short description

•

Enable NAT Policy: Checked

•

Create a reflective policy: Unchecked

SonicOS 5.8.1 Administrator Guide

361

Network > NAT Policies

Note

Step 3

Make sure you chose Any as the destination interface, and not the interface that the server
is on. This may seem counter-intuitive, but it is actually the correct thing to do (if you try to
specify the interface, you get an error).
When finished, click on the OK button to add and activate the NAT Policy. With this policy in
place, the SonicWALL security appliance translates the server’s public IP address to the private
IP address when connection requests arrive from the WAN interface (by default, the X1
interface), and translates the requested protocol (TCP 9000) to the server’s actual listening port
(TCP 80).
Finally, you’re going to modify the firewall access rule created in the previous section to allow
any public user to connect to the Web server on the new port (TCP 9000) instead of the server’s
actual listening port (TCP 80).

Note

With previous versions of the SonicOS firmware, it was necessary to write rules to the
private IP address. This has been changed as of SonicOS Enhanced. If you write a rule to
the private IP address, the rule does not work.
Go to the Firewall > Access Rules section and choose the policy for the WAN to Sales zone
intersection (or, whatever zone you put your server in). Click on the Configure button to bring
up the previously created policy. When the pop-up appears, edit in the following values:
•

Action: Allow

•

Service: server_public_port (or whatever you named it above)

•

Source: Any

•

Destination: webserver_public_ip

•

Users Allowed: All

•

Schedule: Always on

•

Logging: checked

•

Comment: (enter a short description)

When you’re done, attempt to access the Web server’s public IP address using a system
located on the public Internet on the new custom port (example: http://67.115.118.70:9000).
You should be able to successfully connect. If not, review this section, and the section before,
and ensure that you have entered in all required settings correctly.

Inbound Port Address Translation via WAN IP Address
This is one of the more complex NAT policies you can create on a SonicWALL security
appliance running SonicOS Enhanced – it allows you to use the WAN IP address of the
SonicWALL security appliance to provide access to multiple internal servers. This is most
useful in situations where your ISP has only provided a single public IP address, and that IP
address has to be used by the SonicWALL security appliance’s WAN interface (by default, the
X1 interface).
Below, you create the programming to provide public access to two internal Web servers via
the SonicWALL security appliances WAN IP address; each is tied to a unique custom port. In
the following examples, you set up two, but it is possible to create more than these as long as
the ports are all unique.

362

SonicOS 5.8.1 Administrator Guide

Network > NAT Policies

In this section, we have five tasks to complete:
1.

Create two custom service objects for the unique public ports the servers respond on.

2.

Create two address objects for the servers’ private IP addresses.

3.

Create two NAT entries to allow the two servers to initiate traffic to the public Internet.

4.

Create two NAT entries to map the custom ports to the actual listening ports, and to map
the private IP addresses to the SonicWALL’s WAN IP address.

5.

Create two access rule entries to allow any public user to connect to both servers via the
SonicWALL’s WAN IP address and the servers’ respective unique custom ports.

Step 1

Create a custom service for the different port. Go to the Firewall > Custom Services page and
click on the Add button. When the pop-up screen appears, give your custom services names
such as servone_public_port and servtwo_public_port, enter in 9100 and 9200 as the
starting and ending port, and choose TCP(6) as the protocol. When done, click on the OK
button to save the custom services.

Step 2

Go to the Network > Address Objects and click on the Add button at the bottom of the page.
In the Add Address Objects window, enter in a description for server’s private IP addresses,
choose Host from the drop-down box, enter the server’s private IP addresses, and select the
zone that the servers are in. When done, click on the OK button to create the range object.

Step 3

Go to the Network > NAT Policies menu and click on the Add button. The Add NAT Policy
window is displayed. To create a NAT policy to allow the two servers to initiate traffic to the
public Internet using the SonicWALL security appliance’s WAN IP address, choose the
following from the drop-down boxes:
•

Original Source: servone_private_ip

•

Translated Source: WAN Primary IP

•

Original Destination: Any

•

Translated Destination: Original

•

Original Service: Any

•

Translated Service: Original

•

Inbound Interface: X2

•

Outbound Interface: X1

•

Comment: Enter a short description

•

Enable NAT Policy: Checked

•

Create a reflective policy: Unchecked

And:
•

Original Source: servtwo_private_ip

•

Translated Source: WAN Primary IP

•

Original Destination: Any

•

Translated Destination: Original

•

Original Service: Any

•

Translated Service: Original

•

Inbound Interface: X2

•

Outbound Interface: X1

•

Comment: Enter a short description

SonicOS 5.8.1 Administrator Guide

363

Network > NAT Policies

•

Enable NAT Policy: Checked

•

Create a reflective policy: Unchecked

When finished, click on the OK button to add and activate the NAT policies. With these policies
in place, the SonicWALL security appliance translates the servers’ private IP addresses to the
public IP address when it initiates traffic out the WAN interface (by default, the X1 interface).
Step 4

Go to the Network > NAT Policies menu and click on the Add button. The Add NAT Policy
window is displayed. To create the NAT policies to map the custom ports to the servers’ real
listening ports and to map the SonicWALL’s WAN IP address to the servers’ private addresses,
choose the following from the drop-down boxes:
•

Original Source: Any

•

Translated Source: Original

•

Original Destination: WAN Primary IP

•

Translated Destination: servone_private_ip

•

Original Service: servone_public_port

•

Translated Service: HTTP

•

Inbound Interface: X1

•

Outbound Interface: Any

•

Comment: Enter a short description

•

Enable NAT Policy: Checked

•

Create a reflective policy: Unchecked

And:
•

Original Source: Any

•

Translated Source: Original

•

Original Destination: WAN Primary IP

•

Translated Destination: servtwo_private_ip

•

Original Service: servtwo_public_port

•

Translated Service: HTTP

•

Source Interface: X1

•

Destination Interface: Any

•

Comment: Enter a short description

•

Enable NAT Policy: Checked

•

Create a reflective policy: Unchecked

Note

Make sure you choose Any as the destination interface, and not the interface that
the server is on. This may seem counter-intuitive, but it is actually the correct thing
to do (if you try to specify the interface, you get an error).

When finished, click on the OK button to add and activate the NAT policies. With these policies
in place, the SonicWALL security appliance translates the server’s public IP address to the
private IP address when connection requests arrive from the WAN interface (by default, the X1
interface).
Step 5

364

Create the access rules that allows anyone from the public Internet to access the two Web
servers using the custom ports and the SonicWALL security appliance’s WAN IP address.

SonicOS 5.8.1 Administrator Guide

Network > NAT Policies

Note

With previous versions of firmware, it was necessary to write rules to the private IP
address. This has been changed as of SonicOS 2.0 Enhanced. If you write a rule to
the private IP address, the rule does not work.

Go to the Firewall > Access Rules page and choose the policy for the ‘WAN’ to ‘Sales’ zone
intersection (or, whatever zone you put your serves in). Click on the ‘Add…’ button to bring up
the pop-up window to create the policies. When the pop-up appears, enter the following values:
•

Action: Allow

•

Service: servone_public_port (or whatever you named it above)

•

Source: Any

•

Destination: WAN IP address

•

Users Allowed: All

•

Schedule: Always on

•

Logging: checked

•

Comment: (enter a short description)

And:
•

Action: Allow

•

Service: servtwo_public_port (or whatever you named it above)

•

Source: Any

•

Destination: WAN IP address

•

Users Allowed: All

•

Schedule: Always on

•

Logging: checked

•

Comment: (enter a short description)

When you’re finished, attempt to access the Web servers via the SonicWALL’s WAN IP address
using a system located on the public Internet on the new custom port (example:
http://67.115.118.70:9100 and http://67.115.118.70:9200). You should be able to successfully
connect. If not, review this section, and the section before, and ensure that you have entered
in all required settings correctly.

SonicOS 5.8.1 Administrator Guide

365

Network > NAT Policies

Using NAT Load Balancing
This section contains the following subsections:
•

“NAT Load Balancing Topology” on page 366

•

“Prerequisites” on page 366

•

“Configuring NAT Load Balancing” on page 367

•

“Troubleshooting NAT Load Balancing” on page 368

NAT Load Balancing Topology
The following figure shows the topology for the NAT load balancing network.
X6

X6

X4

X2

X4

JASPER & DAISY
NSA E7500 HA PAIR
X0 LAN: 192.168.25.10/24
X1 WAN: 204.180.153.102/27
X4 DMZ: 192.168.200.2/24

X0

X2

X0

X3

X1

CONSOLE

PWR1 PWR2

TEST ALARM

E7500

HD

HA

X7

X5

L3 Switch
192.168.25.55/24

X5

X3

X1

X2

X0

CONSOLE

PWR1 PWR2

TEST ALARM

HD

X4

SRA EX7000

WAFFLE - SonicWALL SRA
192.168.200.1/24
https://sslvpn.vpntestlab.com
X5

BACON - SonicWALL CDP
192.168.25.75/24

Secure Remote Access

PWR1 PWR2

TEST ALARM

X4

REDFISH - WWW1
192.168.200.210/24
https://www.vpntestlab.com

X3

X1

X2

X0

HD

SRA EX7000

YOGURT - SonicWALL SRA
192.168.200.10/24
https://sslvpn.vpntestlab.com

JAMBALAYA - WWW1
192.168.200.220/24
https://www.vpntestlab.com

Prerequisites
The examples shown in the Tasklist section on the next few pages utilize IP addressing
information from a demo setup – please make sure and replace any IP addressing information
shown in the examples with the correct addressing information for your setup. Also note that
the interface names may be different.

Note

It is strongly advised that you enable logging for all categories, and enable name resolution
for logging.
To enable logging and alerting, log into the SonicWALL’s Management GUI, go to Log >
Categories, choose Debug from the drop-down next to Logging Level, chose All Categories
from the drop-down next to View Style, check the boxes in the title bar next to Log and Alerts
to capture all categories, and click on the Apply button in the upper right hand corner to save
and activate the changes. For an example, see the screenshot below. Debug logs should only
be used for initial configuration and troubleshooting, and it is advised that once setup is
complete, you set the logging level to a more appropriate level for your network environment.
To enable log name resolution, go to Log > Name Resolution, choose DNS then NetBIOS
from the Name Resolution Menu drop-down list, and click on the Apply button in the upper
right hand corner to save and activate the changes.

366

SonicOS 5.8.1 Administrator Guide

Network > NAT Policies

Configuring NAT Load Balancing
To configure NAT load balancing, you must complete the following tasks:
1.

Create address objects.

2.

Create address group.

3.

Create inbound NAT LB Policy.

4.

Create outbound NAT LB Policy.

5.

Create Firewall Rule.

6.

Verify and troubleshoot the network if necessary.

To complete this configuration, perform the following steps:
Step 1

Create Network Objects -- Go to the Network > Address Objects page in the Management
GUI and create the network objects for both of the internal Web servers, and the Virtual IP (VIP)
on which external users will access the servers.

Step 2

Create Address Group -- Now create an address group named www_group and add the two
internal server address objects you just created.

Step 3

Create Inbound NAT Rule for Group -- Now create a NAT rule to allow anyone attempting to
access the VIP to get translated to the address group you just created, using Sticky IP as the
NAT method.

Note
Step 4

Note

Do not save the NAT rule just yet.
Set LB Type and Server Liveliness Method -- On the Advanced tab of the NAT policy
configuration control, you can specify that the object (or group of objects, or group of groups)
be monitored via ICMP ping or by checking for TCP sockets opened. For this example, we are
going to check to see if the server is up and responding by monitoring TCP port 80 (which is
good, since that is what people are trying to access). You can now click on the OK button to
save and activate the changes.

Before you go any further, check the logs and the status page to see if the resources have
been detected and have been logged as online. Two alerts will appear as Firewall Events
with the message “Network Monitor: Host 192.160.200.220 is online” (with your IP
addresses). If you do not see these two messages below, check the steps above.

Step 5

Create Outbound NAT Rule for LB Group -- Write a NAT rule to allow the internal servers to
get translated to the VIP when accessing resources out the WAN interface (by default, the X1
interface).

Step 6

Create Firewall Rule for VIP -- Write a firewall rule to allow traffic from the outside to access
the internal Web servers via the VIP.

Step 7

Test Your Work – From a laptop outside the WAN, connect via HTTP to the VIP using a Web
browser.

Note

If you wish to load balance one or more SSL VPN Appliances, repeat steps 1-7, using
HTTPS instead as the allowed service.

SonicOS 5.8.1 Administrator Guide

367

Network > NAT Policies

Troubleshooting NAT Load Balancing
If the Web servers do not seem to be accessible, go to the Firewall > Access Rules page and
mouseover the Statistics icon.
If the rule is configured incorrectly you will not see any Rx or TX Bytes; if it is working, you will
see these increment with each successful external access of the load balanced resources.
You can also check the Firewall > NAT Policies page and mouseover the Statistics icon. If
the policy is configured incorrectly you will not see any Rx or TX Bytes; if it is working, you will
see these increment with each successful external access of the load balanced resources.
Finally, check the logs and the status page to see if there are any alerts (noted in yellow) about
the Network Monitor noting hosts that are offline; it may be that all of your load balancing
resources are not reachable by the SonicWALL appliance and that the probing mechanism has
marked them offline and out of service. Check the load balancing resources to ensure that they
are functional and check the networking connections between them and the SonicWALL
appliance.

368

SonicOS 5.8.1 Administrator Guide

CHAPTER 24
Chapter 24:

Managing ARP Traffic

Network > ARP
ARP (Address Resolution Protocol) maps layer 3 (IP addresses) to layer 2 (physical or MAC
addresses) to enable communications between hosts residing on the same subnet. ARP is a
broadcast protocol that can create excessive amounts of network traffic on your network. To
minimize the broadcast traffic, an ARP cache is maintained to store and reuse previously
learned ARP information.
Simplified NSA ARP Table
LAN IP 192.168.168.168
MAC 00:06:81:04:00:E4
Network Security Appliance

NSA

DMZ/CTP IP 192.168.50.1
MAC 00:06:01:04:00:E5
WAN IP 66.178.222.123 (ISP assgined)

Internet

192.168.168.7
192.168.168.5

192.168.50.1

192.168.168.x/24
LAN
192.168.50.5

192.168.50.10

192.168.50.x/24
DMZ

WAN

SonicOS 5.8.1 Administrator Guide

369

Network > ARP

Static ARP Entries
The Static ARP feature allows for static mappings to be created between layer 2 MAC
addresses and layer 3 IP addresses, but also provides the following capabilities:

•

Publish Entry - Enabling the Publish Entry option in the Add Static ARP window causes
the SonicWALL device to respond to ARP queries for the specified IP address with the
specified MAC address. This can be used, for example, to have the SonicWALL device
reply for a secondary IP address on a particular interface by adding the MAC address of
the SonicWALL. See the Secondary Subnet section that follows.

•

Bind MAC Address - Enabling the Bind MAC Address option in the Add Static ARP
window binds the MAC address specified to the designated IP address and interface. This
can be used to ensure that a particular workstation (as recognized by the network card's
unique MAC address) can only the used on a specified interface on the SonicWALL. Once
the MAC address is bound to an interface, the SonicWALL will not respond to that MAC
address on any other interface. It will also remove any dynamically cached references to
that MAC address that might have been present, and it will prohibit additional (non-unique)
static mappings of that MAC address.

•

Update IP Address Dynamically - The Update IP Address Dynamically setting in the
Add Static ARP window is a sub-feature of the Bind MAC Address option. This allows for
a MAC address to be bound to an interface when DHCP is being used to dynamically
allocate IP addressing. Enabling this option will blur the IP Address field, and will populate
the ARP Cache with the IP address allocated by the SonicWALL's internal DHCP server,
or by the external DHCP server if IP Helper is in use.

Secondary Subnets with Static ARP
The Static ARP feature allows for secondary subnets to be added on other interfaces, and
without the addition of automatic NAT rules.

370

SonicOS 5.8.1 Administrator Guide

Network > ARP

Adding a Secondary Subnet using the Static ARP Method
Step 1

Add a 'published' static ARP entry for the gateway address that will be used for the secondary
subnet, assigning it the MAC address of the SonicWALL interface to which it will be connected.

Step 2

Add a static route for that subnet, so that the SonicWALL regards it as valid traffic, and knows
to which interface to route that subnet's traffic.

Step 3

Add Access Rules to allow traffic destined for that subnet to traverse the correct network
interface.

Step 4

Optional: Add a static route on upstream device(s) so that they know which gateway IP to use
to reach the secondary subnet.
Consider the following network example:
Simplified NSA ARP Table
LAN IP 192.168.168.168
MAC 00:06:81:04:00:E4
Network Security Appliance

NSA

DMZ/CTP IP 192.168.50.1
MAC 00:06:01:04:00:E5
WAN IP 66.178.222.123 (ISP assgined)

Internet

192.168.168.7
192.168.168.5

192.168.50.1

192.168.168.x/24
LAN
192.168.50.5

192.168.50.10

192.168.50.x/24
DMZ

WAN

To support the above configuration, first create a published static ARP entry for 192.168.50.1,
the address which will serve as the gateway for the secondary subnet, and associate it with the
appropriate LAN interface. From the Network > ARP page, select the Add button in the Static
ARP Entries section, and add the following entry:

SonicOS 5.8.1 Administrator Guide

371

Network > ARP

The entry will appear in the table.

Navigate to the Network > Routing page, and add a static route for the 192.168.50.0/24
network, with the 255.255.255.0 subnet mask on the X3 Interface.
To allow the traffic to reach the 192.168.50.0/24 subnet, and to allow the 192.168.50.0/24
subnet to reach the hosts on the LAN, navigate to the Firewall > Access Rules page, and add
appropriate Access Rules to allow traffic to pass.

Navigating and Sorting the ARP Cache Table
The ARP Cache table provides easy pagination for viewing a large number of ARP entries. You
can navigate a large number of ARP entries listed in the ARP Cache table by using the
navigation control bar located at the top right of the ARP Cache table.

The navigation control bar includes four buttons. The far left button displays the first page of
the table. The far right button displays the last page. The inside left and right arrow buttons
moved the previous or next page respectively.
You can enter the policy number (the number listed before the policy name in the # Name
column) in the Items field to move to a specific ARP entry. The default table configuration
displays 50 entries per page. You can change this default number of entries for tables on the
System > Administration page.
You can sort the entries in the table by clicking on the column header. The entries are sorted
by ascending or descending order. The arrow to the right of the column entry indicates the
sorting status. A down arrow means ascending order. An up arrow indicates a descending
order.

Navigating and Sorting the ARP Cache Table Entries
The ARP Cache table provides easy pagination for viewing a large number of ARP entries. You
can navigate a large number of ARP entries listed in the ARP Cache table by using the
navigation control bar located at the top right of the ARP Cache table. Navigation control bar
includes four buttons. The far left button displays the first page of the table. The far right button
displays the last page. The inside left and right arrow buttons moved the previous or next page
respectively.

372

SonicOS 5.8.1 Administrator Guide

Network > ARP

You can enter the policy number (the number listed before the policy name in the # Name
column) in the Items field to move to a specific ARP entry. The default table configuration
displays 50 entries per page. You can change this default number of entries for tables on the
System > Administration page.
You can sort the entries in the table by clicking on the column header. The entries are sorted
by ascending or descending order. The arrow to the right of the column entry indicates the
sorting status. A down arrow means ascending order. An up arrow indicates a descending
order.

Flushing the ARP Cache
It is sometimes necessary to flush the ARP cache if the IP address has changed for a device
on the network. Since the IP address is linked to a physical address, the IP address can change
but still be associated with the physical address in the ARP Cache. Flushing the ARP Cache
allows new information to be gathered and stored in the ARP Cache. Click Flush ARP Cache
to clear the information.
To configure a specific length of time for the entry to time out, enter a value in minutes in the
ARP Cache entry time out (minutes) field.

SonicOS 5.8.1 Administrator Guide

373

Network > ARP

374

SonicOS 5.8.1 Administrator Guide

CHAPTER 25
Chapter 25:

Configuring MAC-IP Anti-Spoof

Network > MAC-IP Anti-Spoof
This chapter describes how to plan, design, implement, and MAC-IP Anti-Spoof protection in
SonicWALL SonicOS Enhanced. This chapter contains the following sections:
•

“MAC-IP Anti-Spoof Protection Overview” section on page 375

•

“Configuring MAC-IP Anti-Spoof Protection” section on page 376

MAC-IP Anti-Spoof Protection Overview
MAC and IP address-based attacks are increasingly common in today’s network security
environment. These types of attacks often target a Local Area Network (LAN) and can originate
from either outside or inside a network. In fact, anywhere internal LANs are somewhat exposed,
such as in office conference rooms, schools, or libraries, could provide an opening to these
types of attacks. These attacks also go by various names: man-in-the-middle attacks, ARP
poisoning, SPITS. The MAC-IP Anti-Spoof feature lowers the risk of these attacks by providing
administrators with different ways to control access to a network, and by eliminating spoofing
attacks at OSI Layer 2/3.
The effectiveness of the MAC-IP Anti-Spoof feature focuses on two areas. The first is
admission control which allows administrators the ability to select which devices gain access
to the network. The second area is the elimination of spoofing attacks, such as denial-of-service
attacks, at Layer 2. To achieve these goals, two caches of information must be built: the MACIP Anti-Spoof Cache, and the ARP Cache.
The MAC-IP Anti-Spoof cache validates incoming packets and determines whether they are to
be allowed inside the network. An incoming packet’s source MAC and IP addresses are looked
up in this cache. If they are found, the packet is allowed through. The MAC-IP Anti-Spoof cache
is built through one or more of the following sub-systems:
•

DHCP Server-based leases (SonicWALL’s - DHCP Server)

•

DHCP relay-based leases (SonicWALL’s - IP Helper)

•

Static ARP entries

•

User created static entries

The ARP Cache is built through the following subsystems:

SonicOS 5.8.1 Administrator Guide

375

Network > MAC-IP Anti-Spoof

•

ARP packets; both ARP requests and responses

•

Static ARP entries from user-created entries

•

MAC-IP Anti-Spoof Cache

The MAC-IP Anti-Spoof subsystem achieves egress control by locking the ARP cache, so
egress packets (packets exiting the network) are not spoofed by a bad device or by unwanted
ARP packets. This prevents a firewall from routing a packet to the unintended device, based
on mapping. This also prevents man-in-the-middle attacks by refreshing a client’s own MAC
address inside its ARP cache.

Configuring MAC-IP Anti-Spoof Protection
This section contains the following subsections:
•

“Interface Settings” section on page 376

•

“Anti-Spoof Cache” section on page 378

•

“Spoof Detect List” section on page 380

•

“Extension to IP Helper” section on page 382

Interface Settings
To edit MAC-IP Anti-Spoof settings within the Network Security Appliance management
interface, go to the Network > MAC-IP Anti-spoof page.

376

SonicOS 5.8.1 Administrator Guide

Network > MAC-IP Anti-Spoof

To configure settings for a particular interface, click Configure icon for the desired interface.

The Settings window is now displayed for the selected interface. In this window, the following
settings can be enabled or disabled by clicking on the corresponding checkbox. Once your
setting selections for this interface are complete, click OK. The following options are available:
•

Enable: To enable the MAC-IP Anti-Spoof subsystem on traffic through this interface

•

Static ARP: Allows the Anti-Spoof cache to be built from static ARP entries

•

DHCP Server: Allows the Anti-Spoof cache to be built from active DHCP leases from the
SonicWALL DHCP server

•

DHCP Relay: Allows the Anti-Spoof cache to be built from active DHCP leases, from the
DHCP relay, based on IP Helper. To learn about changes to IP Helper, see “Extension to IP
Helper” section on page 382.

•

ARP Lock: Locks ARP entries for devices listed in the MAC-IP Anti-Spoof cache. This
applies egress control for an interface through the MAC-IP Anti-Spoof configuration, and
adds MAC-IP cache entries as permanent entries in the ARP cache. This controls ARP
poisoning attacks, as the ARP cache is not altered by illegitimate ARP packets.

•

ARP Watch: Enables generation of unsolicited unicast ARP responses towards the client’s
machine for every MAC-IP cache entry on the interface. This process helps prevent manin-the-middle attacks.

•

Enforce Anti-Spoof: Enables ingress control on the interface, blocking traffic from devices
not listed in the MAC-IP Anti-Spoof cache.

•

Spoof Detection List: Logs all devices that fail to pass Anti-spoof cache and lists them in
the Spoof Detected List.

•

Allow Management: Allows through all packets destined for the appliance’s IP address,
even if coming from devices currently not listed in the Anti-Spoof cache.

SonicOS 5.8.1 Administrator Guide

377

Network > MAC-IP Anti-Spoof

Once the settings have been adjusted, the interface’s listing will be updated on the MAC-IP
Anti-Spoof panel. The green circle with white check mark icons denote which settings have
been enabled.

Note

The following interfaces are excluded from the MAC-IP Anti-Spoof list: Non-ethernet
interfaces, port-shield member interfaces, Layer 2 bridge pair interfaces, high availability
interfaces, and high availability data interfaces.

Anti-Spoof Cache
The MAC-IP Anti-Spoof Cache lists all the devices presently listed as “authorized” to access
the network, and all devices marked as “blacklisted” (denied access) from the network. To add
a device to the list, click the Add button.

A window is now displayed that allows for manual entry of the IP and MAC addresses for the
device. Enter the information in the provided fields. You may also select to approve or blacklist
the routing device. Checking the router setting allows all traffic coming from behind this device.
Blacklisting the device will cause packets to be blocked from this device, irrespective of its IP
address. Once your entries have been made, click OK to return to the main panel.

378

SonicOS 5.8.1 Administrator Guide

Network > MAC-IP Anti-Spoof

If you need to edit a static Anti-Spoof cache entry, select the checkbbox to the left of the IP
address, then click the pencil icon, under the “Configure” column, on the same line.
Single, or multiple, static anti-spoof cache entries can be deleted. To do this, select the “delete
checkbox” next to each entry, then click the “Delete” button.
To clear cache statistics, select the desired devices, then click “Clear Stats.”
If you wish to see the most recent available cache information, click the “Refresh” button.

Note

Some packet types are bypassed even though the MAC-IP Anti-Spoof feature is enabled: 1)
Non-IP packets, 2) DHCP packets with source IP as 0, 3) Packets from a VPN tunnel, 4)
Packets with invalid unicast IPs as their source IPs, and 5) Packets from interfaces where
the Management status is not enabled under anti-spoof settings.

SonicOS 5.8.1 Administrator Guide

379

Network > MAC-IP Anti-Spoof

Spoof Detect List
The Spoof Detect List displays devices that failed to pass the ingress anti-spoof cache check.
Entries on this list can be added as a static anti-spoof entry. To do this, click on the pencil icon,
under the “Add” column, for the desired device. An alert message window will open, asking if
you wish to add this static entry. Click “OK” to proceed, on “Cancel” to return to the Spoof
Detected List.

Entries can be flushed from the list by clicking the “Flush” button. The name of each device can
also be resolved using NetBios, by clicking the “Resolve” button.

Users can identify a specific device(s) by using the table “Filter” function.

To identify a device, users must fill in the available field, specifying either the device’s IP
address, iface, MAC address, or name. The field must be filled using the appropriate syntax for
operators:

380

SonicOS 5.8.1 Administrator Guide

Network > MAC-IP Anti-Spoof

Operator
Value with a type

String

AND
OR
Negative
Mixed

Syntax Options
•

Ip=1.1.1.1 or ip=1.1.1.0/24

•

Mac=00:01:02:03:04:05

•

Iface=x1

•

X1

•

00:01

•

Tst-mc

•

1.1.

•

Ip=1.1.1.1;iface=x1

•

Ip=1.1.1.0/24;iface=x1;just-string

•

Ip=1.1.1.1,2.2.2.2,3.3.3.0/24

•

Iface=x1,x2,x3

•

!ip=1.1.1.1;!just-string

•

!iface=x1,x2

•

Ip=1.1.1.1,2.2.2.2;mac=00:01:02:03:04:05;
just-string;!iface=x1,x2

SonicOS 5.8.1 Administrator Guide

381

Network > MAC-IP Anti-Spoof

Extension to IP Helper
In order to support leases from the DHCP relay subsystem of IP Helper, the following changes
have been made in the IP Helper panel, located at Network > IP Helper:
•

As part of the DHCP relay logic, IP Helper learns leases exchanged between clients and
the DHCP server, then saves them into flash memory.

•

These learned leases are synched to the idle firewall, as part of the IP Helper state sync
messages.

MAC and IP address bindings from the leases are transferred into the MAC-IP Anti-Spoof
cache.

382

SonicOS 5.8.1 Administrator Guide

CHAPTER 26
Chapter 26:

Setting Up the DHCP Server

Network > DHCP Server
This chapter contains the following sections:
•

“DHCP Server Options Overview” on page 384

•

“Multiple DHCP Scopes per Interface” on page 385

•

“Configuring the DHCP Server” on page 387

•

“DHCP Server Lease Scopes” on page 388

•

“Current DHCP Leases” on page 388

•

“Configuring Advanced DHCP Server Options” on page 389

•

“Configuring DHCP Server for Dynamic Ranges” on page 393

•

“Configuring Static DHCP Entries” on page 396

•

“Configuring DHCP Generic Options for DHCP Lease Scopes” on page 399

•

“DHCP Option Numbers” on page 400

SonicOS 5.8.1 Administrator Guide

383

Network > DHCP Server

The SonicWALL security appliance includes a DHCP (Dynamic Host Configuration Protocol)
server to distribute IP addresses, subnet masks, gateway addresses, and DNS server
addresses to your network clients. The Network > DHCP Server page includes settings for
configuring the SonicWALL security appliance’s DHCP server.

You can use the SonicWALL security appliance’s DHCP server or use existing DHCP servers
on your network. If your network uses its own DHCP servers, make sure the Enable DHCP
Server checkbox is unchecked.
The number of address ranges and IP addresses the SonicWALL DHCP server can assign
depends on the model, operating system, and licenses of the SonicWALL security appliance.
The table below shows maximum allowed DHCP leases for SonicWALL security appliances.
Platform

Maximum DHCP Leases

NSA 3500, NSA 4500

1,024 leases

NSA 5000, E5500, E6500, E7500

4,096 leases

DHCP Server Options Overview
This section provides an introduction to DHCP server options feature. This section contains the
following subsections:
•

“What Is the SonicWALL DHCP Server Options Feature?” on page 384

•

“Benefits” on page 385

•

“How Does the SonicWALL DHCP Server Options Feature Work?” on page 385

•

“Supported Standards” on page 385

What Is the SonicWALL DHCP Server Options Feature?
The SonicWALL DHCP server options feature provides support for DHCP options, also known
as vendor extensions, as defined primarily in RFCs 2131 and 2132. DHCP options allow users
to specify additional DHCP parameters in the form of predefined, vendor-specific information
that is stored in the options field of a DHCP message. When the DHCP message is sent to

384

SonicOS 5.8.1 Administrator Guide

Network > DHCP Server

clients on the network, it provides vendor-specific configuration and service information. The
“DHCP Option Numbers” on page 400 provides a list of DHCP options by RFC-assigned option
number.

Benefits
The SonicWALL DHCP server options feature provides a simple interface for selecting DHCP
options by number or name, making the DHCP configuration process quick, easy, and
compliant with RFC-defined DHCP standards.

How Does the SonicWALL DHCP Server Options Feature Work?
The SonicWALL DHCP server options feature allows definition of DHCP options using a dropdown menu based on RFC-defined option numbers, allowing administrators to easily create
DHCP objects and object groups, and configure DHCP generic options for dynamic and static
DHCP lease scopes. Once defined, the DHCP option is included in the options field of the
DHCP message, which is then passed to DHCP clients on the network, describing the network
configuration and service(s) available.

Supported Standards
The SonicWALL DHCP server options feature supports the following standards:
•

RFC 2131 - Dynamic Host Configuration Protocol

•

RFC 2132 - DHCP Options and BOOTP Vendor Extensions

Multiple DHCP Scopes per Interface
The following sections provide an overview of the Multiple DHCP Scopes per Interface feature:
•

“What are Multiple DHCP Scopes per Interface?” on page 385

•

“Benefits of Multiple DHCP Scopes” on page 385

•

“How Do Multiple DHCP Scopes per Interface Work?” on page 386

What are Multiple DHCP Scopes per Interface?
Often, DHCP clients and server(s) reside on the same IP network or subnet, but sometimes
DHCP clients and their associated DHCP server(s) do not reside on the same subnet. The
Multiple DHCP Scopes per Interface feature allows one DHCP server to manage different
scopes for clients spanning multiple subnets.

Benefits of Multiple DHCP Scopes
Efficiency – A single DHCP server can provide IP addresses for clients spanning multiple
subnets.
Compatible with DHCP over VPN – The processing of relayed DHCP messages is handled
uniformly, regardless of whether it comes from a VPN tunnel or a DHCP relay agent.
Multiple Scopes for Site-to-Site VPN – When using an internal DHCP server, a remote subnet
could be configured using scope ranges that differ from the LAN/DMZ subnet. The scope range
for the remote subnet is decided by the “Relay IP Address” set in the remote gateway.

SonicOS 5.8.1 Administrator Guide

385

Network > DHCP Server

Multiple Scopes for Group VPN – When using an internal DHCP server, a SonicWALL GVC
client could be configured using scope ranges that differ from the LAN/DMZ subnet. The scope
range for the SonicWALL GVC client is decided by the “Relay IP Address (Optional)” set in the
central gateway.
Compatible with Conflict Detection – Currently, the SonicWALL DHCP server performs
server-side conflict detection when this feature is enabled. The advantage of server-side
conflict detection is that it detects conflicts even when the DHCP client does not run client-side
conflict detection. However, if there are a lot of DHCP clients on the network, server-side
conflict detection can result in longer waits for a full IP address allocation to complete. Conflict
Detection (and Network Pre-Discovery) are not performed for an IP address which belongs to
a “relayed” subnet scope. The DHCP server only performs a conflict detection ICMP check for
a subnet range attached to its interface.

How Do Multiple DHCP Scopes per Interface Work?
Normally, a DHCP client initiates an address allocating procedure by sending a Broadcast
DHCP Discovery message. Since most routes do not forward broadcast packets, this method
requires DHCP clients and server(s) to reside on the same IP network or subnet.
When DHCP clients and their associated DHCP server are not on the same subnet, some type
of third-party agent (BOOTP relay agent, IP Helper, etc.) is required to transfer DHCP
messages between clients and server. The DHCP relay agent populates the giaddr field with
its ingress interface IP address and then forwards it to the configured DHCP server. When the
DHCP server receives the message, it examines the giaddr field to determine if it has a DHCP
scope that could be used to supply an IP address lease to the client.
Figure 26:1 Multiple Subnets Sharing One DHCP Server

The Multiple DHCP Scopes per Interface feature provides security enhancements to protect
against potential vulnerabilities inherent in allowing wider access to the DHCP server. The
DHCP Advanced Setting page provides security with a new tab for Trusted Agents where
trusted DHCP relay agents can be specified. The DHCP server discards any messages relayed
by agents which are not in the list.

386

SonicOS 5.8.1 Administrator Guide

Network > DHCP Server

Figure 26:2 Trusted DHCP Relay Agents

Configuring the DHCP Server
If you want to use the SonicWALL security appliance’s DHCP server, select Enable DHCP
Server on the Network > DHCP Server page.
The following DHCP server options can be configured:
•

Select Enable Conflict Detection to turn on automatic DHCP scope conflict detection on
each zone.

Compatible with Conflict Detection – Currently, the SonicWALL DHCP server performs
server-side conflict detection when this feature is enabled. The advantage of server-side
conflict detection is that it detects conflicts even when the DHCP client does not run client-side
conflict detection. However, if there are a lot of DHCP clients on the network, server-side
conflict detection can result in longer waits for a full IP address allocation to complete.
•

Select Enable DHCP Server Network Pre-Discovery to have the DHCP server scan for
other DHCP server networks. The following options can be modified to customize the
performance of DHCP server network pre-discovery:
– DHCP Server Conflict Detect Period: Sets how often the DHCP server scans for other

networks. The default is 300 seconds.
– Number of DHCP resources to discover: Sets the number of DHCP networks that are

scanned for. The default is 10.
– Timeout for conflicted resource to be rechecked: Sets the duration of time after

which conflicted resources are re-checked. The default is 1800 seconds.
– Timeout for available resource to be rechecked: Sets the duration of time after

which avialable resources are re-checked. The default is 600 seconds.

Note

Conflict detection and network pre-discovery are not performed for an IP address which
belongs to a “relayed” subnet scope. The DHCP server only performs a conflict detection
ICMP check for a subnet range attached to its interface.

SonicOS 5.8.1 Administrator Guide

387

Network > DHCP Server

To configure Option Objects, Option Groups, and Trusted Agents, click the Advanced button.
For detailed information on configuring these features, see “Configuring Advanced DHCP
Server Options” on page 389.

Configuring DHCP Server Persistence
DHCP server persistence is the ability of the firewall save DHCP lease information and to
provide the client with a predictable IP address that does not conflict with another use on the
network, even after a client reboot.
DHCP server persistence works by storing DHCP lease information periodically to flash
memory. This ensures that users have predicable IP addresses and minimizes the risk of IP
addressing conflicts after a reboot.
DHCP server persistence provides a seamless experience when a user reboots a workstation.
The DHCP lease information is saved, and the user retains the same workstation IP address.
When a firewall is restarted, usually due to maintenance or an upgrade, DHCP server
persistence provides the following benefits:
•

IP address uniqueness: Lease information is stored in flash memory, so the risk of
assigning the same IP address to multiple users is nullified.

•

Ease of use: By saving the lease information in the flash memory, the user’s connections
are automatically restored.

To configure DHCP Server Persistance, select the Enable DHCP Server Persistence
checkbox. Optionally, you can modify how often the DHCP server stores DHCP lease
information by modifying the DHCP Server Persistence Monitoring Interval field. The default
is 5 minutes.

DHCP Server Lease Scopes
The DHCP Server Lease Scopes table displays the currently configured DHCP IP ranges. The
table shows:
•

Type: Dynamic or Static.

•

Lease Scope: The IP address range, for example 172.16.31.2 - 172.16.31.254.

•

Interface: The Interface the range is assigned to.

•

Details: Detailed information about the lease, displayed as a tool tip when you hover the
mouse pointer over the Details
icon.

•

Enable: Check the box in the Enable column to enable the DHCP range. Uncheck it to
disable the range.

•

Configure: Click the configure icon

to configure the DHCP range.

Current DHCP Leases
The current DHCP lease information is displayed in the Current DHCP Leases table. Each
binding entry displays the IP Address, the Ethernet Address, and the Type of binding
(Dynamic, Dynamic BOOTP, or Static BOOTP).
To delete a binding, which frees the IP address on the DHCP server, click the Delete icon
next to the entry. For example, use the Delete icon
to remove a host when it has been
removed from the network, and you need to reuse its IP address.

388

SonicOS 5.8.1 Administrator Guide

Network > DHCP Server

Configuring Advanced DHCP Server Options
•

“Configuring DHCP Option Objects” on page 389

•

“Configuring DHCP Option Groups” on page 390

•

“Configuring a Trusted DHCP Relay Agent Address Group” on page 391

•

“Enabling Trusted DHCP Relay Agents” on page 392

The “DHCP Option Numbers” on page 400 provides a list of DHCP options by RFC-assigned
option number.

Configuring DHCP Option Objects
To configure DHCP option objects, perform the following steps:
Step 1

In the left-hand navigation panel, navigate to Network > DHCP Server.

Step 2

Under DHCP Server Settings, click the Advanced button. The DHCP Advanced Settings page
displays. The Option Objects tab is selected by default.

Step 3

Click the Add Option button. The Add DHCP Option Objects page displays.

Step 4

Type a name for the option in the Option Name field.

SonicOS 5.8.1 Administrator Guide

389

Network > DHCP Server

Step 5

From the Option Number drop-down list, select the option number that corresponds to your
DHCP option. For a list of option numbers and names, refer to “DHCP Option Numbers” on
page 400.

Step 6

Optionally check the Option Array box to allow entry of multiple option values in the Option
Value field.

Step 7

The option type displays in the Option Type drop-down menu. If only one option type is
available, for example, for Option Number 2 (Time Offset), the drop-down menu will be greyed
out. If there are multiple option types available, for example, for Option Number 77 (User Class
Information), the drop-down menu will be functional.

Step 8

Type the option value, for example, an IP address, in the Option Value field. If Option Array
is checked, multiple values may be entered, separated by a semi-colon (;).

Step 9

Click OK. The object will display in the Option Objects list.

Configuring DHCP Option Groups
To configure DHCP option groups, perform the following steps:

390

Step 1

In the left-hand navigation panel, navigate to Network > DHCP Server.

Step 2

Under DHCP Server Settings, click the Advanced button. The DHCP Advanced Settings page
displays.

Step 3

Click the Option Groups tab.

Step 4

Click the Add Group button. The Add DHCP Option Group page displays.

SonicOS 5.8.1 Administrator Guide

Network > DHCP Server

Step 5

Enter a name for the group in the Name field.

Step 6

Select an option object from the left column and click the -> button to add it to the group. To
select multiple option objects at the same time, hold the Ctrl key while selecting the option
objects.

Step 7

Click OK. The group displays in the Option Groups list.

Configuring a Trusted DHCP Relay Agent Address Group
To configure the Default Trusted Relay Agent List Address Group, you must first configure
an Address Object for each trusted relay agent, then add these Address Objects to the Default
Trusted Relay Agent List Address Group or to a custom Address Group.
Configuration of Address Objects or Address Groups is performed on the Network > Address
Objects page.
To configure Address Objects for the trusted relay agents and to configure the Default Trusted
Relay Agent List Address Group or a custom Address Group, perform the following steps:
Step 1

In the left-hand navigation panel, navigate to Network > Address Objects.

Step 2

Under Address Objects, click the Add button.

Step 3

In the Add Address Object window, fill in the fields with the appropriate values for the DHCP
relay agent and then click Add. Repeat as necessary to add more relay agents. For more
information about configuring address objects, see “Creating and Managing Address Objects”
on page 300.

Step 4

Do one of the following:
a.

Under Address Groups, to add the relay agent Address Objects to the Default Trusted
Relay Agent List Address Group, click the Configure icon in the row for it.
Select the desired Address Objects from the list on the left and click the right-arrow button
to move them to the list on the right. When finished, click OK.

b.

To add the relay agent Address Objects to a new, custom Address Group, click Add Group
under Address Groups.
Type a descriptive name for the Address Group into the Name field, and then select the
desired Address Objects from the list on the left and click the right-arrow button to move
them to the list on the right. When finished, click OK.

SonicOS 5.8.1 Administrator Guide

391

Network > DHCP Server

Enabling Trusted DHCP Relay Agents
In the DHCP Advanced Settings page, you can enable the Trusted Relay Agent List option
using the Default Trusted Relay Agent List Address Group or create another Address Group
using existing Address Objects.
To enable the Trusted Relay Agent List option and select the desired Address Group, perform
the following steps:
Step 1

In the left-hand navigation panel, navigate to the Network > DHCP Server page.

Step 2

Under DHCP Server Settings, click the Advanced button.

Step 3

On the DHCP Advanced Settings page, click the Trusted Agents tab.

Step 4

Select the Enable Trusted DHCP Relay Agent List checkbox. The Trusted Relay Agent List
drop-down list becomes available. The drop-down list includes all existing address groups as
well as the Create new Address Object Group option.

Step 5

To use the Default Trusted Relay Agent List Address Group or another existing Address
Group, select it from the drop-down list.

Step 6

To create a custom Address Group for this option, select Create new Address Object Group.
The Add Address Object Group window displays. Perform the following steps:
a.

Fill in the Name field with a descriptive name for the Address Group.

b.

Select the desired Address Objects in the left-hand list and move them to the list on the
right by clicking the right-arrow button.

c.

Click OK.
In the DHCP Advanced Settings window, the new Address Group is displayed in the
Trusted Relay Agent List drop-down list. The new Address Group is now available on the
Network > Address Objects page, and can be edited or deleted there.

Step 7

392

On the DHCP Advanced Settings page, click OK to enable the Trusted Relay Agent List
option with the selected Address Group.

SonicOS 5.8.1 Administrator Guide

Network > DHCP Server

Configuring DHCP Server for Dynamic Ranges
Because SonicOS Enhanced allows multiple DHCP scopes per interface, there is no
requirement that the subnet range is attached to the interface when configuring DHCP scopes.
To configure DHCP server for dynamic IP address ranges, follow these instructions:
Step 1

In the Network > DHCP Server page, at the bottom of the DHCP Server Lease Scopes table,
click Add Dynamic. The Dynamic Ranges Configuration window is displayed.

General Settings
Step 2

In the General page, make sure the Enable this DHCP Scope checkbox is selected if you want
to enable this range.

Step 3

To populate the Range Start, Range End, Default Gateway, and Subnet Mask fields with
default values for a certain interface, select the Interface Pre-Populate checkbox near the
bottom of the page and choose the interface from the drop-down list. The populated IP
addresses are in the same private subnet as the selected interface.

Note

To select an interface from the Interface menu, it must first be fully configured and it must
be of the zone type, LAN, WLAN, or DMZ, or be a VLAN sub-interface.

Step 4

Use the populated IP address range entries in the Range Start and Range End fields or type
in your own IP address range.

Step 5

Type the number of minutes an IP address is used before it is issued another IP address in the
Lease Time (minutes) field. 1440 minutes (24 hours) is the default value.

Step 6

Use the populated gateway address or type the IP address of the gateway into the Default
Gateway field.

Step 7

Use the populated subnet mask or type the gateway subnet mask into the Subnet Mask field.

Step 8

Select Allow BOOTP Clients to use Range if you have BOOTP Clients on your network.

SonicOS 5.8.1 Administrator Guide

393

Network > DHCP Server

BOOTP stands for bootstrap protocol, which is a TCP/IP protocol and service that allows
diskless workstations to obtain their IP address, other TCP/IP configuration information, and
their boot image file from a BOOTP server.

DNS/WINS Settings
Step 9

Click the DNS/WINS tab to continue configuring the DHCP Server feature.

Step 10 If you have a domain name for the DNS server, type it in the Domain Name field.
Step 11 Inherit DNS Settings Dynamically using SonicWALL’s DNS Settings automatically

populates the DNS and WINS settings with the settings in the Network > DNS page. This option
is selected by default.
Step 12 If you do not want to use the SonicWALL security appliance network settings, select Specify

Manually, and type the IP address of your DNS Server in the DNS Server 1 field. You can
specify two additional DNS servers.
Step 13 If you have WINS running on your network, type the WINS server IP address(es) in the WINS

Server 1 field. You can add an additional WINS server.

394

SonicOS 5.8.1 Administrator Guide

Network > DHCP Server

Advanced Settings
Step 14 Click on the Advanced tab. The Advanced tab allows you to configure the SonicWALL DHCP

server to send Cisco Call Manager information to VoIP clients on the network.

Step 15 Under VoIP Call Managers, enter the IP address or FQDN of your VoIP Call Manager in the

Call Manager 1 field. You can add two additional VoIP Call Manager addresses.
Step 16 Under Network Boot Settings, in the Next Server field, enter the IP address of the PXE boot

server (TFTP server) that a PXE client uses during the next stage of the boot process.
The fields under Network Boot Settings are used in a Pre-boot Execution Environment (PXE),
in which the client boots up using files obtained over a network interface. The PXE client
obtains the IP address and name of the PXE boot server, and the boot file name, from the
DHCP server.
When using these options, select PXE under DHCP Generic Options.
Step 17 In the Boot File field, type in the name of the boot file that the PXE client can get over TFTP

from the PXE boot server.
Step 18 In the Server Name field, type in the DNS host name of the PXE boot server (TFTP server).
Step 19 For information on configuring DHCP Generic Options see “Configuring DHCP Generic Options

for DHCP Lease Scopes” on page 399.
Step 20 Click OK to add the settings to the SonicWALL security appliance.
Step 21 Click Accept for the settings to take effect on the SonicWALL security appliance.

For more information on VoIP support features on the SonicWALL security appliance, see “VoIP
Overview” on page 805.

SonicOS 5.8.1 Administrator Guide

395

Network > DHCP Server

Configuring Static DHCP Entries
Static entries are IP addresses assigned to servers requiring permanent IP settings. Because
SonicOS Enhanced allows multiple DHCP scopes per interface, there is no requirement that
the subnet range is attached to the interface when configuring DHCP scopes.
To configure static entries, follow these steps:
Step 1

In the Network > DHCP Server page, at the bottom of the DHCP Server Lease Scopes table,
click Add Static. The Static Entry Configuration window is displayed.

General Settings

396

Step 2

In the General tab, make sure the Enable this DHCP Scope is checked, if you want to enable
this entry.

Step 3

Enter a name for the static DNS entry in the Entry Name field.

Step 4

Type the device IP address in the Static IP Address field.

Step 5

Type the device Ethernet (MAC) address in the Ethernet Address field.

Step 6

Type the number of minutes an IP address is used before it is issued another IP address in the
Lease Time (minutes) field. 1440 minutes (24 hours) is the default value.

SonicOS 5.8.1 Administrator Guide

Network > DHCP Server

Step 7

Note

To populate the Default Gateway and Subnet Mask fields with default values for a certain
interface, select the Interface Pre-Populate checkbox near the bottom of the page and choose
the interface from the drop-down list. The populated IP addresses are in the same private
subnet as the selected interface.

To select an interface from the Interface menu, it must first be fully configured and it must
be of the zone type, LAN, WLAN, or DMZ, or be a VLAN sub-interface.

Step 8

Use the populated gateway address or type the IP address of the gateway into the Default
Gateway field.

Step 9

Use the populated subnet mask or type the gateway subnet mask into the Subnet Mask field.

DNS/WINS Settings
Step 10 Click the DNS/WINS tab to continue configuring the DHCP Server feature.

Step 11 If you have a domain name for the DNS Server, type it in the Domain Name field.
Step 12 Inherit DNS Settings Dynamically from the SonicWALL’s DNS settings is selected by

default. When selected, the DNS Server IP fields are unavailable.
Step 13 If you do not want to use the SonicWALL security appliance network settings, select Specify

Manually, and type the IP address of your DNS Server in the DNS Server 1 field. You can
specify two additional DNS servers.
Step 14 If you have WINS running on your network, type the WINS server IP address(es) in the WINS

Server 1 field. You can specify an additional WINS server.

SonicOS 5.8.1 Administrator Guide

397

Network > DHCP Server

Advanced Settings
Step 15 Click on the Advanced tab. The Advanced tab allows you to configure the SonicWALL DHCP

server to send Cisco Call Manager information to VoIP clients on the network.

Step 16 Enter the IP address or FQDN of your VoIP Call Manager in the Call Manager 1 field. You can

add two additional VoIP Call Manager addresses.
Step 17 Under Network Boot Settings, in the Next Server field, enter the IP address of the PXE boot

server (TFTP server) that a PXE client uses during the next stage of the boot process.
The fields under Network Boot Settings are used in a Pre-boot Execution Environment (PXE),
in which the client boots up using files obtained over a network interface. The PXE client
obtains the IP address and name of the PXE boot server, and the boot file name, from the
DHCP server.
When using these options, select PXE under DHCP Generic Options.
Step 18 In the Boot File field, type in the name of the boot file that the PXE client can get over TFTP

from the PXE boot server.
Step 19 In the Server Name field, type in the DNS host name of the PXE boot server (TFTP server).
Step 20 For information on configuring DHCP Generic Options see “Configuring DHCP Generic Options

for DHCP Lease Scopes” on page 399.
Step 21 Click OK to add the settings to the SonicWALL.
Step 22 Click Accept for the settings to take effect on the SonicWALL.

For more information on VoIP support features on the SonicWALL security appliance, see “VoIP
Overview” on page 805.

398

SonicOS 5.8.1 Administrator Guide

Network > DHCP Server

Configuring DHCP Generic Options for DHCP Lease Scopes
This section provides configuration tasks for DHCP generic options for lease scopes.

Note

Before generic options for a DHCP lease scope can be configured, a static or dynamic
DHCP server lease scope must be created.
The “DHCP Option Numbers” on page 400 provides a list of DHCP options by RFC-assigned
option number.
To configure DHCP generic options for DHCP server lease scopes, perform the following tasks:

Step 1

If modifying an existing DHCP lease scope, locate the lease scope under DHCP Server Lease
Scopes on the Network > DHCP Server page and click the Configure icon, then click the
Advanced tab. If creating a new DHCP lease scope, click the Advanced tab.

Step 2

Select a DHCP option or option group in the DHCP Generic Option Group drop-down menu.
When the Network Boot Settings fields are configured for use with PXE, select PXE here.

Step 3

To always use DHCP options for this DHCP server lease scope, check the box next to Send
Generic options always.

Step 4

Click OK.

SonicOS 5.8.1 Administrator Guide

399

Network > DHCP Server

DHCP Option Numbers
This section provides a list of RFC-defined DHCP option numbers and descriptions:

400

Option
Number Name

Description

2

Time Offset

Time offset in seconds from UTC

3

Router

N/4 router addresses

4

Time Servers

N/4 time server addresses

5

Name Servers

N/4 IEN-116 server addresses

6

DNS Servers

N/4 DNS server addresses

7

Log Servers

N/4 logging server addresses

8

Cookie Servers

N/4 quote server addresses

9

LPR Servers

N/4 printer server addresses

10

Impress Servers

N/4 impress server addresses

11

RLP Servers

N/4 RLP server addresses

12

Host Name

Hostname string

13

Boot File Size

Size of boot file in 512 byte chunks

14

Merit Dump File

Client to dump and name of file to dump to

15

Domain Name

The DNS domain name of the client

16

Swap Server

Swap server addresses

17

Root Path

Path name for root disk

18

Extension File

Patch name for more BOOTP info

19

IP Layer Forwarding

Enable or disable IP forwarding

20

Src route enabler

Enable or disable source routing

21

Policy Filter

Routing policy filters

22

Maximum DG
Reassembly Size

Maximum datagram reassembly size

23

Default IP TTL

Default IP time-to-live

24

Path MTU Aging
Timeout

Path MTU aging timeout

25

MTU Plateau

Path MTU plateau table

26

Interface MTU Size

Interface MTU size

27

All Subnets Are Local

All subnets are local

28

Broadcast Address

Broadcast address

29

Perform Mask
Discovery

Perform mask discovery

30

Provide Mask to Others Provide mask to others

31

Perform Router
Discovery

Perform router discovery

32

Router Solicitation
Address

Router solicitation address

SonicOS 5.8.1 Administrator Guide

Network > DHCP Server

Option
Number Name

Description

33

Static Routing Table

Static routing table

34

Trailer Encapsulation

Trailer encapsulation

35

ARP Cache Timeout

ARP cache timeout

36

Ethernet Encapsulation

Ethernet encapsulation

37

Default TCP Time to
Live

Default TCP time to live

38

TCP Keepalive Interval

TCP keepalive interval

39

TCP Keepalive Garbage TCP keepalive garbage

40

NIS Domain Name

NIS domain name

41

NIS Server Addresses

NIS server addresses

42

NTP Servers Addresses NTP servers addresses

43

Vendor Specific
Information

Vendor specific information

44

NetBIOS Name Server

NetBIOS name server

45

NetBIOS Datagram
Distribution

NetBIOS datagram distribution

46

NetBIOS Node Type

NetBIOS node type

47

NetBIOS Scope

NetBIOS scope

48

X Window Font Server

X window font server

49

X Window Display
Manager

X window display manager

50

Requested IP address

Requested IP address

51

IP Address Lease Time

IP address lease time

52

Option Overload

Overload “sname” or “file”

53

DHCP Message Type

DHCP message type

54

DHCP Server
Identification

DHCP server identification

55

Parameter Request List Parameter request list

56

Message

DHCP error message

57

DHCP Maximum
Message Size

DHCP maximum message size

58

Renew Time Value

DHCP renewal (T1) time

59

Rebinding Time Value

DHCP rebinding (T2) time

60

Client Identifier

Client identifier

61

Client Identifier

Client identifier

62

Netware/IP Domain
Name

Netware/IP domain name

63

Netware/IP sub Options Netware/IP sub options

64

NIS+ V3 Client Domain
Name

NIS+ V3 client domain name

SonicOS 5.8.1 Administrator Guide

401

Network > DHCP Server

Option
Number Name

402

Description

65

NIS+ V3 Server Address NIS+ V3 server address

66

TFTP Server Name

TFTP server name

67

Boot File Name

Boot file name

68

Home Agent Addresses Home agent addresses

69

Simple Mail Server
Addresses

Simple mail server addresses

70

Post Office Server
Addresses

Post office server addresses

71

Network News Server
Addresses

Network news server addresses

72

WWW Server
Addresses

WWW server addresses

73

Finger Server
Addresses

Finger server addresses

74

Chat Server Addresses

Chat server addresses

75

StreetTalk Server
Addresses

StreetTalk server addresses

76

StreetTalk Directory
Assistance Addresses

StreetTalk directory assistance addresses

77

User Class Information

User class information

78

SLP Directory Agent

Directory agent information

79

SLP Service Scope

Service location agent scope

80

Rapid Commit

Rapid commit

81

FQDN, Fully Qualified
Domain Name

Fully qualified domain name

82

Relay Agent Information Relay agent information

83

Internet Storage Name
Service

Internet storage name service

84

Undefined

N/A

85

Novell Directory Servers Novell Directory Services servers

86

Novell Directory Server
Tree Name

Novell Directory Services server tree name

87

Novell Directory Server
Context

Novell Directory Services server context

88

BCMCS Controller
Domain Name List

CMCS controller domain name list

89

BCMCS Controller IPv4
Address List

BCMCS controller IPv4 address list

90

Authentication

Authentication

91

Undefined

N/A

92

Undefined

N/A

93

Client System

Client system architecture

SonicOS 5.8.1 Administrator Guide

Network > DHCP Server

Option
Number Name

Description

94

Client Network Device
Interface

Client network device interface

95

LDAP Use

Lightweight Directory Access Protocol

96

Undefined

N/A

97

UUID/GUID Based
Client Identifier

UUID/GUID-based client identifier

98

Open Group’s User
Authentication

Open group’s user authentication

99

Undefined

N/A

100

Undefined

N/A

101

Undefined

N/A

102

Undefined

N/A

103

Undefined

N/A

104

Undefined

N/A

105

Undefined

N/A

106

Undefined

N/A

107

Undefined

N/A

108

Undefined

N/A

109

Autonomous System
Number

Autonomous system number

110

Undefined

111

Undefined

112

NetInfo Parent Server
Address

NetInfo parent server address

113

NetInfo Parent Server
Tag

NetInfo parent server tag

114

URL:

URL

115

Undefined

N/A

116

Auto Configure

DHCP auto-configuration

117

Name Service Search

Name service search

118

Subnet Collection

Subnet selection

119

DNS Domain Search
List

DNS domain search list

120

SIP Servers DHCP
Option

SIP servers DHCP option

121

Classless Static Route
Option

Classless static route option

122

CCC, CableLabs Client
Configuration

CableLabs client configuration

123

GeoConf

GeoConf

SonicOS 5.8.1 Administrator Guide

403

Network > DHCP Server

404

Option
Number Name

Description

124

Vendor-Identifying
Vendor Class

Vendor-identifying vendor class

125

Vendor Identifying
Vendor Specific

Vendor-identifying vendor specific

126

Undefined

N/A

127

Undefined

N/A

128

TFTP Server IP Address TFTP server IP address for IP phone software load

129

Call Server IP Address

Call server IP address

130

Discrimination String

Discrimination string to identify vendor

131

Remote Statistics
Server IP Address

Remote statistics server IP address

132

802.1Q VLAN ID

IEEE 802.1Q VLAN ID

133

802.1Q L2 Priority

IEEE 802.1Q layer 2 priority

134

Diffserv Code Point

Diffserv code point for VoIP signalling and media
streams

135

HTTP Proxy For Phone
Applications

HTTP proxy for phone-specific applications

136

Undefined

N/A

137

Undefined

N/A

138

Undefined

N/A

139

Undefined

N/A

140

Undefined

N/A

141

Undefined

N/A

142

Undefined

N/A

143

Undefined

N/A

144

Undefined

N/A

145

Undefined

N/A

146

Undefined

N/A

147

Undefined

N/A

148

Undefined

N/A

149

Undefined

N/A

150

TFTP Server Address,
Etherboot, GRUB
Config

TFTP server address, Etherboot, GRUB
configuration

151

Undefined

152

Undefined

N/A

153

Undefined

N/A

154

Undefined

N/A

155

Undefined

N/A

156

Undefined

N/A

SonicOS 5.8.1 Administrator Guide

Network > DHCP Server

Option
Number Name

Description

157

Undefined

N/A

158

Undefined

N/A

159

Undefined

N/A

160

Undefined

N/A

161

Undefined

N/A

162

Undefined

N/A

163

Undefined

N/A

164

Undefined

N/A

165

Undefined

N/A

166

Undefined

N/A

167

Undefined

N/A

168

Undefined

N/A

169

Undefined

N/A

170

Undefined

N/A

171

Undefined

N/A

172

Undefined

N/A

173

Undefined

N/A

174

Undefined

N/A

175

Ether Boot

Ether Boot

176

IP Telephone

IP telephone

177

Ether Boot PacketCable Ether Boot PacketCable and CableHome
and CableHome

178

Undefined

N/A

179

Undefined

N/A

180

Undefined

N/A

181

Undefined

N/A

182

Undefined

N/A

183

Undefined

N/A

184

Undefined

N/A

185

Undefined

N/A

186

Undefined

N/A

187

Undefined

N/A

188

Undefined

N/A

189

Undefined

N/A

190

Undefined

N/A

191

Undefined

N/A

192

Undefined

N/A

193

Undefined

N/A

SonicOS 5.8.1 Administrator Guide

405

Network > DHCP Server

406

Option
Number Name

Description

194

Undefined

N/A

195

Undefined

N/A

196

Undefined

N/A

197

Undefined

N/A

198

Undefined

N/A

199

Undefined

N/A

200

Undefined

N/A

201

Undefined

N/A

202

Undefined

N/A

203

Undefined

N/A

204

Undefined

N/A

205

Undefined

N/A

206

Undefined

N/A

207

Undefined

N/A

208

pxelinux.magic (string)
= 241.0.116.126

pxelinux.magic (string) = 241.0.116.126

209

pxelinux.configfile (text) pxelinux.configfile (text)

210

pxelinux.pathprefix
(text)

pxelinux.pathprefix (text)

211

pxelinux.reboottime

pxelinux.reboottime

212

Undefined

N/A

213

Undefined

N/A

214

Undefined

N/A

215

Undefined

N/A

216

Undefined

N/A

217

Undefined

N/A

218

Undefined

N/A

219

Undefined

N/A

220

Subnet Allocation

Subnet allocation

221

Virtual Subnet
Allocation

Virtual subnet selection

222

Undefined

N/A

223

Undefined

N/A

224

Private Use

Private use

225

Private Use

Private use

226

Private Use

Private use

227

Private Use

Private use

228

Private Use

Private use

229

Private Use

Private use

SonicOS 5.8.1 Administrator Guide

Network > DHCP Server

Option
Number Name

Description

230

Private Use

Private use

231

Private Use

Private use

232

Private Use

Private use

233

Private Use

Private use

234

Private Use

Private use

235

Private Use

Private use

236

Private Use

Private use

237

Private Use

Private use

238

Private Use

Private use

239

Private Use

Private use

240

Private Use

Private use

241

Private Use

Private use

242

Private Use

Private use

243

Private Use

Private use

244

Private Use

Private use

245

Private Use

Private use

246

Private Use

Private use

247

Private Use

Private use

248

Private Use

Private use

249

Private Use

Private use

250

Private Use

Private use

251

Private Use

Private use

252

Private Use

Private use

253

Private Use

Private use

254

Private Use

Private use

SonicOS 5.8.1 Administrator Guide

407

Network > DHCP Server

408

SonicOS 5.8.1 Administrator Guide

CHAPTER 27
Chapter 27:

Using IP Helper

Network > IP Helper
Many User Datagram Protocols (UDP) rely on broadcaset/multicast to find its respective server,
usually requiring their servers to be present on the same broadcast subnet.To support cases
where servers lie on different subnets than clients, a mechanism is needed to forward these
UDP broadcasts/multicasts to those subnets. This mechanism is referred to as UDP broadcast
forwarding. IP Helper helps broadcast/multicast packets to cross a firewall’s interface and be
forwarded to other interfaces based on policy. For more information on IP Helper, refer to the
IP Helper technote at:
http://www.sonicwall.com/us/support/2134_3424.html

IP Helper Settings
•

Enable IP Helper - Enables IP Helper features.

•

Enable DHCP Support - Enables DHCP forwarding from the SonicWALL security
appliance to your central DHCP server. If the DHCP server has been enabled, the message
“DHCP Server has been enabled. To edit this setting, click here.” is displayed. Clicking
the link displays the Network > DHCP Server page.

SonicOS 5.8.1 Administrator Guide

409

Network > IP Helper

Caution

The SonicWALL DHCP Server feature must be disabled before you can enable DHCP
Support on the IP Helper. The Enable DHCP Support checkbox is greyed out until the
DHCP Server setting is disabled.
•

Enable NetBIOS Support - Enables NetBIOS broadcast forwarding. NetBIOS is required
to allow Windows operating systems to browse for resources on a network.

IP Helper Policies
IP Helper Policies allow you to forward DHCP and NetBIOS broadcasts from one interface to
another interface.

Note

The IP Helper is not supported for WAN interfaces or for interfaces that are configured for
NAT.

Adding an IP Helper Policy for DHCP

410

Step 1

Click the Add button under the IP Helper Policies table. The Add IP Helper Policy window is
displayed.

Step 2

The policy is enabled by default. To configure the policy without enabling it, clear the Enabled
check box.

Step 3

Select DHCP from the Protocol menu.

Step 4

Select a source interface or zone from the From menu.

Step 5

Select a destination Address Group or Address Object from the To menu or select Create a
new network to create a new Address Object.

Step 6

Enter an optional comment in the Comment field.

Step 7

Click OK to add the policy to the IP Helper Policies table.

SonicOS 5.8.1 Administrator Guide

Network > IP Helper

Adding an IP Helper Policy for NetBIOS
Step 1

Click the Add button under the IP Helper Policies table. The Add IP Helper Policy window is
displayed.

Step 2

The policy is enabled by default. To configure the policy without enabling it, clear the Enabled
check box.

Step 3

Select NetBIOS from the Protocol menu.

Step 4

Select a source Address Group or Address Object from the From menu. Select Create a new
network to create a new Address Object.

Step 5

Select a destination Address Group or Address Object from the To menu, or select Create a
new network to create a new Address Object.

Step 6

Enter an optional comment in the Comment field.

Step 7

Click OK to add the policy to the IP Helper Policies table.

Editing an IP Helper Policy
Click the Edit
icon in the Configure column of the IP Helper Policies table to display the
Edit IP Helper window, which includes the same settings as the Add IP Helper Policy window.

Deleting IP Helper Policies
Click the Delete icon
to delete the individual IP Helper policy entry. Click the Delete button
to delete all the selected IP Helper policies in the IP Helper Policies table.

Enhanced IP Helper
IP Helper extends the previous version’s Forwarding Plane to support User-defined protocols
and extended policies. As a result, IP Helper’s UI has been completely redesigned. IP Helper
also offers better control on existing NetBIOS/DHCP relay applications.
Some of the built-in applications that have been extended include:
•

DHCP—UDP port number 67/68

•

Net-Bios NS—UDP port number 137

•

Net-Bios Datagram—UDP port number 138

•

DNS—UDP port number 53

•

Time Service—UDP port number 37

•

Wake on LAN (WOL)

•

mDNS—UDP port number 5353; multicast address 224.0.0.251

Each protocol has the following configurable options:
•

Name—The name of the protocols. Note that these are case sensitive and must be unique.

•

Port 1/2—The unique UDP port number.

•

Translate IP—Translation of the source IP while forwarding a packet.

•

Timeout—IP Helper cache timeout in seconds at an increment of 10.

SonicOS 5.8.1 Administrator Guide

411

Network > IP Helper

•

Raw Mode—Unidirectional forwarding that does not create an IP Helper cache. This is
suitable for most of the user-defined protocols that are used for discovery, for example
WOL/mDNS.

Figure 27:3 Enhanced IP Helper UI

Each protocol has the following configurable options:

412

•

Name—The name of the protocols. Note that these are case sensitive and must be unique.

•

Port 1/2—The unique UDP port number.

•

Translate IP—Translation of the source IP while forwarding a packet.

•

Timeout—IP Helper cache timeout in seconds at an increment of 10.

•

Raw Mode—Unidirectional forwarding that does not create an IP Helper cache. This is
suitable for most of the user-defined protocols that are used for discovery, for example
WOL/mDNS.

SonicOS 5.8.1 Administrator Guide

Network > IP Helper

Adding User-Defined Protocols
Click the Add button on the lower left side of the protocol list table. The following fields must
be configured in order to add a protocol.

•

Name—Create a unique case-sensitive name.

•

Port 1/2—The unique UDP port numbers.

•

Timeout—This is optional. IP Helper cache timeout in seconds at an increment of 10. If not
specified, a default value of 30 seconds is selected.

•

IP Translation—When selected, the firewall translates the source IP of the forwarded
packet.

•

Raw Mode—When selected, IP Helper does not create a cache; Unidirectional forwarding
is supported.

Editing User-Defined Protocols
A user-defined protocol can be deleted by selecting the Delete button next to that protocol. The
user can also select the leftmost checkbox of the desired protocol, then click the Delete button,
located on the lower left side of the table.

Retrieving Counters
By hovering the cursor over a protocol or policy’s “Statistics” image, the counter appears,
displaying the traffic status for that protocol.

SonicOS 5.8.1 Administrator Guide

413

Network > IP Helper

Displaying IP Helper Cache from TSR
The TSR will show all the IP Helper caches, current policies, and protocols:
#IP_HELPER_START
IP Helper
-----IP Helper Global Run-time Data------IP Helper is OFF
IP Helper - DHCP Relay is OFF
IP Helper - Netbios Relay is OFF
Total Number Of Fwded Packets

:0

Total Number Of Dropped Packets

:0

Total Number Of Passed Packets

:0

Total Number Of Unknown Packets

:0

Total Number Of record create failure

:0

Total Number Of element create failure

:0User-defined

-----IP Helper Applications ------Name: DHCP
Port: 67, 68, Max Record: 4000, Status: OFF
CanBeDel: NO, ChangeIp: 1, Raw: NO
Max Element: 8000, Timeout: 3, index: 1, proto: 1,
Record Count: 0, Element Count: 0,
Fwded: 0, Dropped: 0, Passed: 0
Name: NetBIOS
Port: 138, 137, Max Record: 4000, Status: OFF
CanBeDel: NO, ChangeIp: 1, Raw: NO
Max Element: 8000, Timeout: 4, index: 2, proto: 1,
Record Count: 0, Element Count: 0,
Fwded: 0, Dropped: 0, Passed: 0
Name: DNS
Port: 53, 0, Max Record: 8000, Status: OFF
CanBeDel: NO, ChangeIp: 1, Raw: NO
Max Element: 16000, Timeout: 3, index: 3, proto: 1,
Record Count: 0, Element Count: 0,
Fwded: 0, Dropped: 0, Passed: 0
Name: TIME
Port: 37, 0, Max Record: 8000, Status: OFF
CanBeDel: NO, ChangeIp: 1, Raw: NO
Max Element: 16000, Timeout: 3, index: 4, proto: 1,
Record Count: 0, Element Count: 0,
Fwded: 0, Dropped: 0, Passed: 0
Name: WOL
Port: 7, 9, Max Record: 8000, Status: OFF
CanBeDel: NO, ChangeIp: 1, Raw: YES
Max Element: 16000, Timeout: 3, index: 5, proto: 1,
Record Count: 0, Element Count: 0,
Fwded: 0, Dropped: 0, Passed: 0
Name: mDNS
Port: 5353, 0, Max Record: 8000, Status: OFF
CanBeDel: NO, ChangeIp: 1, Raw: YES
Max Element: 16000, Timeout: 3, index: 6, proto: 1,
Record Count: 0, Element Count: 0,
Fwded: 0, Dropped: 0, Passed: 0
----------GEN APP Relay Policy--------------------------------------------Record Table---------------------------Record(hash)[ClientIP, ClientIf, ClientMac, Proto, Vpn, transId, Age(pkts)]
Elmnt(hash)[serverIp, serverIf, srcIp, dhcpMac, transId, Vpn, proto(fm,to)]
------------------------------------------------------------------------------------DHCP Relay Policy------------------NETBIOS Relay Policy-----------#IP_HELPER_END

414

SonicOS 5.8.1 Administrator Guide

Network > IP Helper

mDNS Forwarding
In order to enable Apple support for iRemote, iTunes, and Apple TV, the mDNS protocol must
be enabled. A policy is needed to forward these packets. The following graphic illustrates the
process of how Enhanced IP Helper works with mDNS Forwarding:

SonicOS 5.8.1 Administrator Guide

415

Network > IP Helper

To configure SonicOS to support mDNS, perform the following steps:

416

Step 1

Navigate to the Network > IP Helper page.

Step 2

Select the Enable IP Helper checkbox.

Step 3

In the Relay Protocols section, click the Enable checkbox for mDNS.

Step 4

In the Policies section, click the Add... button.

Step 5

Click the Protocol drop-down menu, then select mDNS.

Step 6

Click the From: drop-down menu, then select the source interface.

Step 7

Click the To: drop-down menu, then select the destination subnet.

Step 8

Click the OK button.

SonicOS 5.8.1 Administrator Guide

CHAPTER 28
Chapter 28:

Setting Up Web Proxy Forwarding

Network > Web Proxy
A Web proxy server intercepts HTTP requests and determines if it has stored copies of the
requested Web pages. If it does not, the proxy completes the request to the server on the
Internet, returning the requested information to the user and also saving it locally for future
requests. Setting up a Web proxy server on a network can be cumbersome, because each
computer on the network must be configured to direct Web requests to the server.
If you have a proxy server on your network, instead of configuring each computer’s Web
browser to point to the proxy server, you can move the server to the WAN or DMZ and enable
Web Proxy Forwarding using the settings on the Network > Web Proxy page. The SonicWALL
security appliance automatically forwards all Web proxy requests to the proxy server without
requiring all the computers on the network to be configured.

SonicOS 5.8.1 Administrator Guide

417

Network > Web Proxy

Configuring Automatic Proxy Forwarding (Web Only)
Note

The proxy server must be located on the WAN or DMZ; it can not be located on the LAN.
To configure a Proxy Web sever, select the Network > Web Proxy page.

Step 1

Connect your Web proxy server to a hub, and connect the hub to the SonicWALL security
appliance WAN or DMZ port.

Step 2

Type the name or IP address of the proxy server in the Proxy Web Server (name or IP
address) field.

Step 3

Type the proxy IP port in the Proxy Web Server Port field.

Step 4

To bypass the Proxy Servers if a failure occurs, select the Bypass Proxy Servers Upon Proxy
Server Failure check box.

Step 5

Select Forward DMZ Client Requests to Proxy Server if you have clients configured on the
DMZ.

Step 6

Click Accept. Once the SonicWALL security appliance has been updated, a message
confirming the update is displayed at the bottom of the browser window.

Bypass Proxy Servers Upon Proxy Failure
If a Web proxy server is specified on the Firewall > Web Proxy page, selecting the Bypass
Proxy Servers Upon Proxy Server Failure check box allows clients behind the SonicWALL
security appliance to bypass the Web proxy server in the event it becomes unavailable. Instead,
the client’s browser accesses the Internet directly as if a Web proxy server is not specified.

418

SonicOS 5.8.1 Administrator Guide

CHAPTER 29
Chapter 29:

Configuring Dynamic DNS

Network > Dynamic DNS
Dynamic DNS (DDNS) is a service provided by various companies and organizations that
allows for dynamic changing IP addresses to automatically update DNS records without manual
intervention. This service allows for network access using domain names rather than IP
addresses, even when the target’s IP addresses change. For example, is a user has a DSL
connection with a dynamically assigned IP address from the ISP, the user can use DDNS to
register the IP address, and any subsequent address changes, with a DDNS service provider
so that external hosts can reach it using an unchanging domain name.
Dynamic DNS implementations change from one service provider to another. There is no strict
standard for the method of communication, for the types of records that can be registered, or
for the types of services that can be offered. Some providers offer premium versions of their
services, as well, for a fee. As such, supporting a particular DDNS provider requires explicit
interoperability with that provider's specific implementation.
Most providers strongly prefer that DDNS records only be updated when IP address changes
occur. Frequent updates, particularly when the registered IP address is unchanged, may be
considered abuse by providers, and could result in your DDNS account getting locked out.
Please refer to the use policies posted on the provider's pages, and abide by the guidelines.
SonicWALL does not provide technical support for DDNS providers - the providers themselves
must be contacted.

SonicOS 5.8.1 Administrator Guide

419

Network > Dynamic DNS

Supported DDNS Providers
Not all services and features from all providers are supported, and the list of supported
providers is subject to change. SonicOS currently supports the following services from four
Dynamic DNS providers:
•

Dyndns.org - SonicOS requires a username, password, Mail Exchanger, and Backup MX
to configure DDNS from Dyndns.org.

•

Changeip.com - A single, traditional Dynamic DNS service requiring only username,
password, and domain name for SonicOS configuration.

•

No-ip.com - Dynamic DNS service requiring only username, password, and domain name
for SonicOS configuration. Also supports hostname grouping.

•

Yi.org - Dynamic DNS service requiring only username, password, and domain name for
SonicOS configuration. Requires that an RR record be created on the yi.org administrative
page for dynamic updates to occur properly.

Additional Services offered by Dynamic DNS Providers
Some common additional services offered by Dynamic DNS providers include:
•

Wildcards - allows for wildcard references to sub-domains. For example, if you register
yourdomain.dyndns.org, your site would be reachable at *.yourdomain.dyndyn.org, e.g.
server.yourdomain.dyndyn.org, www.yourdomain.dyndyn.org, ftp.yourdomain.dyndyn.org,
etc.

•

Mail Exchangers - Creates MX record entries for your domain so that SMTP servers can
locate it via DNS and send mail. Note: inbound SMTP is frequently blocked by ISPs - please
check with your provider before attempting to host a mail server.

•

Backup MX (offered by dyndns.org, yi.org) - Allows for the specification of an alternative
IP address for the MX record in the event that the primary IP address is inactive.

•

Groups - Allows for the grouping of hosts so that an update can be performed once at the
group level, rather than multiple times for each member.

•

Off-Line IP Address - Allows for the specification of an alternative address for your
registered hostnames in the event that the primary registered IP is offline.

Configuring Dynamic DNS
Using any Dynamic DNS service begins with settings up an account with the DDNS service
provider (or providers) of your choice. It is possible to use multiple providers simultaneously.
Refer to the links for the various providers listed above. The registration process normally
involves a confirmation email from the provider, with a final acknowledgment performed by
visiting a unique URL embedded in the confirmation email. After logging in to the selected
provider's page, you should visit the administrative link (typically 'add' or 'manage'), and create
your host entries. This must be performed prior to attempting to use the dynamic DNS client on
SonicOS. The Network > Dynamic DNS page provides the settings for configuring the
SonicWALL security appliance to use your DDNS service.

420

SonicOS 5.8.1 Administrator Guide

Network > Dynamic DNS

To configure Dynamic DNS on the SonicWALL security appliance, perform these steps:
Step 1

From the Network > Dynamic DNS page, click the Add button. The Add DDNS Profile window
is displayed.

Step 2

If Enable this DDNS Profile is checked, the profile is administratively enabled, and the
SonicWALL security appliance takes the actions defined in the Online Settings section on the
Advanced tab.

Step 3

If Use Online Settings is checked, the profile is administratively online.

Step 4

Enter a name to assign to the DDNS entry in the Profile Name field. This can be any value
used to identify the entry in the Dynamic DNS Settings table.

Step 5

In the Profile page, select the Provider from the drop-down list at the top of the page.
DynDNS.org and changeip.com use HTTPS, while yi.org and no-ip.com use HTTP. This
example uses DynDNS.org. Dyndns.org requires the selection of a service. This example
assumes you have created a dynamic service record with dyndns.org.

Step 6

Enter your dyndns.org username and password in the User Name and Password fields.

Step 7

Enter the fully qualified domain name (FQDN) of the hostname you registered with dyndns.org.
Make sure you provide the same hostname and domain as you configured.

Step 8

Optionally, select a WAN interface in the Bound to pulldown to assign this DDNS profile to that
specific WAN interface. This allows administrators who are configuring multiple-WAN load
balancing to advertise a predictable IP address to the DDNS service. By default, this is set to
ANY, which means the profile is free to use any of the WAN interfaces on the appliance.

Step 9

When using DynDNS.org, select the Service Type from the drop-down list that corresponds to
your type of service through DynDNS.org. The options are:
– Dynamic - A free Dynamic DNS service.
– Custom - A managed primary DNS solution that provides a unified primary/secondary

DNS service and a Web-based interface. Supports both dynamic and static IP
addresses.

SonicOS 5.8.1 Administrator Guide

421

Network > Dynamic DNS

– Static - A free DNS service for static IP addresses.
Step 10 When using DynDNS.org, you may optionally select Enable Wildcard and/or configure an MX

entry in the Mail Exchanger field. Check Backup MX if this is the backup mail exchanger.
Step 11 Click the Advanced tab. You can typically leave the default settings on this page.

Step 12 The On-line Settings section provides control over what address is registered with the

dynamic DNS provider. The options are:
– Let the server detect IP Address - The dynamic DNS provider determines the IP

address based upon the source address of the connection. This is the most common
setting.
– Automatically set IP Address to the Primary WAN Interface IP Address - This will

cause the SonicWALL device to assert its WAN IP address as the registered IP
address, overriding auto-detection by the dynamic DNS server. Useful if detection is not
working correctly.
– Specify IP Address manually - Allows for the IP address to be registered to be

manually specified and asserted.
Step 13 The Off-line Settings section controls what IP address is registered with the dynamic DNS

service provider if the dynamic DNS entry is taken off-line locally (disabled) on the SonicWALL.
The options are:
– Do nothing - the default setting. This allows the previously registered address to

remain current with the dynamic DNS provider.
– Use the Off-Line IP address previously configured at Providers site - If your provider

supports manual configuration of Off-Line Settings, you can select this option to use
those settings when this profile is taken administratively offline.
Step 14 Click OK.

422

SonicOS 5.8.1 Administrator Guide

Network > Dynamic DNS

Dynamic DNS Settings Table
The Dynamic DNS Settings table provides a table view of configured DDNS profiles.
Dynamic DNS Settings table includes the following columns:
•

Profile Name - The name assigned to the DDNS entry during its creation. This can be any
value, and is used only for identification.

•

Domain - The fully qualified domain name (FQDN) of the DDNS entry.

•

Provider - The DDNS provider with whom the entry is registered.

•

Status - The last reported/current status of the DDNS entry. Possible states are:
– Online - The DDNS entry is administratively online. The current IP setting for this entry

is shown with a timestamp.
– Taken Offline Locally - The DDNS entry is administratively offline. If the entry is

Enabled, the action configured in the Offline Settings section of the Advanced tab is
taken.
– Abuse - The DDNS provider has considered the type or frequency of updates to be

abusive. Please check with the DDNS provider's guidelines to determine what is
considered abuse.
– No IP change - abuse possible - A forced update without an IP address change is

considered by some DDNS providers to be abusive. Automatic updates will only occur
when address or state changes occur. Manual or forced should only be made when
absolutely necessary, such as when registered information is incorrect.
– Disabled - The account has been disabled because of a configuration error or a policy

violation. Check the profile's settings, and verify the DDNS account status with the
provider.
– Invalid Account - The account information provided is not valid. Check the profile's

settings, and verify the DDNS account status with the provider.
– Network Error - Unable to communicate with the DDNS provider due to a suspected

network error. Verify that the provider is reachable and online. Try the action again
later.
– Provider Error - The DDNS provider is unable to perform the requested action at this

time. Check the profile's settings, and verify the DDNS account status with the provider.
Try the action again later.
– Not Donator Account - Certain functions provided from certain provider, such as

offline address settings, are only available to paying or donating subscribers. Please
check with the provider for more details on which services may require payment or
donation.
•

Enabled - When selected, this profile is administratively enabled, and the SonicWALL will
take the Online Settings action that is configured on the Advanced tab. This setting can
also be controlled using the Enable this DDNS Profile checkbox in the entry's Profile tab.
Deselecting this checkbox will disable the profile, and no communications with the DDNS
provider will occur for this profile until the profile is again enabled.

•

Online - When selected, this profile is administratively online. The setting can also be
controlled using the Use Online Settings checkbox on the entry's Profile tab. Deselecting
this checkbox while the profile is enabled will take the profile offline, and the SonicWALL
will take the
Offline Settings action that is configured on the Advanced tab.

•

Configure - Includes the edit
icon for configuring the DDNS profile settings, and the
delete
icon for deleting the DDNS profile entry.

SonicOS 5.8.1 Administrator Guide

423

Network > Dynamic DNS

424

SonicOS 5.8.1 Administrator Guide

CHAPTER 30
Chapter 30:

Configuring Network Monitor

Network > Network Monitor
The Network > Network Monitor page provides a flexible mechanism for monitoring network
path viability. The results and status of this monitoring are displayed dynamically on the
Network Monitor page, and are also provided to affected client components and logged in the
system log.
Each custom NM policy defines a destination Address Object to be probed. This Address
Object may be a Host, Group, Range, or FQDN. When the destination Address Object is a
Group, Range or FQDN with multiple resolved addresses, Network Monitor probes each probe
target and derives the NM Policy state based on the results.
\

The Status column elements displays the status of the network connection to the target:
•

Green indicates that the policy status is UP.

•

Red indicates that the policy status is DOWN.

•

Yellow indicates that the policy status is UNKNOWN.

SonicOS 5.8.1 Administrator Guide

425

Network > Network Monitor

You can view details of the probe status by hovering your mouse over the green, red, or yellow
light for a policy.

The following information is displayed in the probe status:

426

•

The percent of successful probes.

•

The number of resolved probe targets.

•

The total number of probes sent.

•

The total number of successful probe responses received.

•

A list of resolved probe targets, and their status.

SonicOS 5.8.1 Administrator Guide

Network > Network Monitor

Adding a Network Monitor Policy
To add a network monitor policy on the SonicWALL security appliance, perform these steps:
Step 1

From the Network > Network Monitor page, click the Add button. The Add Network Monitor
Policy window is displayed.

Step 2

Enter the following information to define the network monitor policy:
•

Name - Enter a description of the Network Monitor policy.

•

Probe Target - Select the Address Object or Address Group to be the target of the policy.
Address Objects may be Hosts, Groups, Ranges, or FQDNs object. Objects within a Group
object may be Host, Range, or FQDN Address Objects. You can dynamically create a new
address object by selecting Create New Address Object.

•

Probe Type - Select the appropriate type of probe for the network monitor policy:
– Ping (ICMP) - This probe uses the route table to find the egress interface and next-hop

for the defined probe targets. A Ping echo-request is sent out the egress interface with
the source IP address of the egress interface. An echo response must return on the
same interface within the specified Response Timeout time limit for the ping to be
counted as successful.
– TCP - This probe uses the route table to find the egress interface and next-hop for the

defined probe targets. A TCP SYN packet is sent to the probe target with the source IP
address of the egress interface. A successful response will be counted independently
for each probe target when the target responds with either a SYN/ACK or RST via the

SonicOS 5.8.1 Administrator Guide

427

Network > Network Monitor

same interface within the Response Timeout time window. When a SYN/ACK is
received, a RST is sent to close the connection. If a RST is received, no response is
returned.
– Ping (ICMP) - Explicit Route - This probe bypasses the route table and uses the

source IP address of the interface specified in the Outbound Interface pulldown menu
to send a Ping to the targets. If a Next Hop Gateway is not specified, the probe assumes
that the targets are directly connected to the Outbound Interface's network.
– TCP - Explicit Route - This probe bypasses the route table and uses the source IP

address of the interface specified in the Outbound Interface pulldown menu to send a
TCP SYN packet to the targets. If a Next Hop Gateway is not specified, the probe
assumes that the targets are directly connected to the Outbound Interface's network.
When a SYN/ACK is received, a RST is sent to close the connection. If a RST is
received, no response is returned.
– Next Hop Gateway - Manually specifies the next hop that is used from the outbound

interface to reach the probe target. This option must be configured for Explicit Route
policies. For non-Explicit Route policies, the probe uses the appliance’s route table to
determine the egress interface to reach the probe target.If a Next Hop Gateway is not
specified, the probe assumes that the targets are directly connected to the Outbound
Interface's network.

Step 3

•

Outbound Interface - Manually specifies which interface is used to send the probe. This
option must be configured for Explicit Route policies. For non-Explicit Route policies, the
probe uses the appliance’s route table to determine the egress interface to reach the probe
target.

•

Port - Specifies the destination port of target hosts for TCP probes. A port is not specified
for Ping probes.

Optionally, you can adjust the following thresholds for the probes:
•

Probe hosts every - The number of seconds between each probe. This number cannot be
less than the Reply time out field.

•

Reply time out - The number of seconds the Network Monitor waits for a response for each
individual probe before a missed-probe will be counted for the specific probe target. The
Reply time out cannot exceed the Probe hosts every field.

•

Probe state is set to DOWN after - The number of consecutive missed probes that triggers
a host state transition to DOWN.

•

Probe state is set to UP after - The number of consecutive successful probes that triggers
a host state transition to UP.

•

All Hosts Must Respond - Selecting this checkbox specifies that all of the probe target
Host States must be UP before the Policy State can transition to UP. If not checked, the
Policy State is set to UP when any of the Host States are UP.

Step 4

Optionally, you can enter a descriptive comment about the policy in the Comment field.

Step 5

Click Add to submit the Network Monitor policy.

Configuring Probe-Enabled Policy Based Routing
When configuring a static route, you can optionally configure a Network Monitor policy for the
route. When a Network Monitor policy is used, the static route is dynamically disabled or
enabled, based on the state of the probe for the policy. For more information, see “ProbeEnabled Policy Based Routing Configuration” on page 330.

428

SonicOS 5.8.1 Administrator Guide

PART 5
Part 5:

SonicOS 5.8.1 Administrator Guide

3G/Modem

429

430

SonicOS 5.8.1 Administrator Guide

CHAPTER 31
Chapter 31:

3G/Modem Selection

3G/Modem
SonicWALL UTM appliances with a USB extension port can support either an external 3G
interface or analog modem interface. When the appliance does not detect an external interface,
a 3G/Modem tab is displayed in the left-side navigation bar.

SonicOS 5.8.1 Administrator Guide

431

3G/Modem

Selecting the 3G/Modem Status
By default, the SonicWALL UTM appliance will attempt to auto-detect whether a connected
external device is a 3G interface or an analog modem interface. You can manually specify
which type of interface you want to configure on the 3G/Modem > Settings page.

The 3G/Modem Device Type pulldown menu provides the following options:

432

•

Auto-detect - The appliance attempts to determine if the device is a 3G or analog modem.

•

3G/Mobile - Manually configures a 3G interface. See “3G” on page 433 for information on
configuring a 3G interface.

•

Analog Modem - Manually configures an analog modem interface. See “Modem” on
page 455 for information on configuring an analog modem.

SonicOS 5.8.1 Administrator Guide

CHAPTER 32
Chapter 32:

Configuring 3G

3G
This chapter describes how to configure the 3G wireless WAN interface on the SonicWALL
UTM appliance. It contains the following sections:
•

“3G Overview” on page 433

•

“3G > Status” on page 440

•

“3G > Settings” on page 440

•

“3G > Advanced” on page 442

•

“3G > Connection Profiles” on page 444

•

“3G > Data Usage” on page 450

•

“Other 3G Configuration Tasks” on page 450

•

“3G Glossary” on page 451

3G Overview
This section provides an overview of 3G. It contains the following sections:
•

“What is 3G?” on page 433

•

“Understanding 3G Connection Models” on page 434

•

“Understanding 3G Failover” on page 435

•

“3G PC Card Support” on page 438

•

“3G Wireless WAN Service Provider Support” on page 439

What is 3G?
Some SonicWALL security appliances support 3G (Third Generation) Wireless WAN
connections that utilize data connections over 3G Cellular networks. The 3G connection can be
used for:
•

WAN Failover to a connection that is not dependent on wire or cable.

SonicOS 5.8.1 Administrator Guide

433

3G

•

Temporary networks where a pre-configured connection may not be available, such as
trade-shows and kiosks.

•

Mobile networks, where the SonicWALL appliance is based in a vehicle.

•

Primary WAN connection where wire-based connections are not available and 3G Cellular
is.

Wireless Wide Area Networks provide untethered remote network access through the use of
mobile or cellular data networks. While legacy cellular networks, such as GSM, were only able
to provide data rates of about 14 Kbps, today's emerging 3G technologies (such as UMTS and
HSDPA) provide theoretical data rates of up to 10 Mbps, rivaling many wired technologies.
The cellular networks powering Wireless Wide Area Networking have been evolving very
quickly, and as a result comprise many different implementations. Fundamentally, they fall into
two protocols:
•

GSM - Global System for Mobile Communication - The most widely used protocol
outside of the Americas. GSM is often regarded as less susceptible to signal degradation
indoors. Although GSM is used both in the Americas and the rest of the world, the American
implementation operates on a different frequency, and interoperability is not guaranteed
unless explicitly supported by the equipment.

•

CDMA - Code Division Multiple Access - The most widely used protocol in the Americas.
CDMA has capacity advantages over GSM, but congestion tends to reduce its operating
range.

Understanding 3G Connection Models
The WAN Connection Model setting provides flexible control over WAN connectivity on
SonicWALL appliances with 3G. Accessible from the Network > Interfaces page of the
management interface, the WAN Connection Model settings allows the administrator to
precisely control the behavior of the 3G connection. The three settings are as follows:
•

3G Only – For use when the 3G is the only WAN connection in use on the appliance.

•

Ethernet Only – For use when the 3G is to be disabled. The Ethernet WAN (the WAN port,
OPT port, or both) is the only WAN connection in use on the appliance.

•

Ethernet with 3G Failover – For use when both the 3G and the Ethernet WAN (the WAN
port, OPT port, or both) are to serve as WAN connections on the appliance.

In addition to the WAN Connection Model setting, the following changes were also introduced
in SonicOS Enhanced 3.6 (and later versions) to optimize the operation of the 3G interface:

434

•

To more accurately reflect the operation of WAN load balancing and Failover sub-system,
the WAN Failover & LB page has been renamed to Ethernet LB.

•

Failover between the Ethernet WAN (the WAN port, OPT port, or both) and the 3G is
supported through the WAN Connection Model setting, but Load-balancing is currently
only supported on Ethernet WAN interfaces. 3G interface traffic statistics will continue to
be displayed in the WAN Load Balancing Statistics table on the Network > Ethernet LB
page.

•

The WAN Load-balancing and Failover sub-system is now permanently enabled for more
transparent support of the WAN Connection Model setting. This was previously controlled
by the Enable Load Balancing setting on the WAN Failover & LB page.

•

3G interface probe monitoring appears on the 3G > Settings page under the 3G Interface
Monitoring heading. (Ethernet WAN interface probe settings is unchanged on the Network
> Ethernet LB page under the WAN Interfaces Monitoring section.)

SonicOS 5.8.1 Administrator Guide

3G

Understanding 3G Failover
When the WAN Connection Model is set to Ethernet with 3G Failover, the WAN (Ethernet)
interface is the primary connection. If the WAN interface fails, the SonicWALL appliance fails
over to the 3G interface.

Internet

Internet

WWAN
(Failover)

wlan pc card
security
signal
on/act

link/act

lan wan opt

1

2

3

4

5

link/spd
activity

LAN

Note

Ethernet WAN
(Primary)

6

NSA 240

DMZ

It is important to note that the WAN-to-3G failover process is different for the three different
3G Connection Profile dial types: Persistent, Dial on Data, and Manual Dial.
The following sections describe the three different methods of WAN-to-3G failover:
•

“Persistent Connection 3G Failover” on page 436

•

“Dial on Data 3G Failover” on page 437

•

“Manual Dial 3G Failover” on page 438

SonicOS 5.8.1 Administrator Guide

435

3G

Persistent Connection 3G Failover
The following diagram depicts the sequence of events that occur when the WAN ethernet
connection fails and the 3G Connection Profile is configured for Persistent Connection.

Internet

Internet

WWAN
link/spd
activity

NSA 240

Ethernet
WAN

Primary Ethernet
connection re-established
(successive pings succeed)

1.

Primary Ethernet connection available – The Ethernet WAN interface is connected and
used as the primary connection. 3G is never connected while the Ethernet WAN interface
is available (unless an explicit route has been configured which specifies 3G as the
destination interface).

2.

Primary Ethernet connection fails – The 3G connection is initiated and remains in an
“always-on” state while the Ethernet WAN connection is down.
If a secondary Ethernet WAN (the OPT port) is configured, the appliance will first failover
to the secondary Ethernet WAN before failing over to the 3G. In this situation, 3G failover
will only occur when both the WAN and OPT paths are unavailable.

3.

Caution

436

Reestablishing Primary Ethernet Connectivity After Failover – When the Ethernet WAN
connection (either the WAN port or the OPT port, if so configured) becomes available again,
all LAN-to-WAN traffic is automatically routed back to the available Ethernet WAN
connection. This includes active connections and VPN connections. The 3G connection is
closed.

It is not recommended to configure a policy-based route that uses the 3G connection when
the WAN Connection Model is set for Ethernet with 3G Failover. If a policy-based route
is configured to use the 3G connection, the connection will remain up until the Maximum
Connection Time (if configured) is reached.

SonicOS 5.8.1 Administrator Guide

3G

Dial on Data 3G Failover
The following diagram depicts the sequence of events that occur when the WAN ethernet
connection fails and the 3G Connection Profile is configured for Dial on Data.

User/node attempts
LAN>WAN transfer with
“qualified” data

Caution

1.

Primary Ethernet connection available – The Ethernet WAN interface is connected and
used as the primary connection. 3G is never connected while the Ethernet WAN interface
is available (unless an explicit route has been configured which specifies 3G as the
destination interface).

2.

Primary Ethernet Connection Fails – The 3G connection is not established until
qualifying outbound data attempts to pass through the SonicWALL appliance.

3.

3G Connection Established – The 3G connection is established when the device or a
network node attempts to transfer qualifying data to the Internet. The 3G connection stays
enabled until the Maximum Connection Time (if configured) is reached.

4.

Reestablishing WAN Ethernet Connectivity After Failover – When an Ethernet WAN
connection becomes available again, all LAN-to-WAN traffic is automatically routed back to
the available Ethernet WAN connection. The 3G connection is closed.

It is not recommended to configure a policy-based route that uses the 3G connection when
the WAN Connection Model is set for Ethernet with 3G Failover. If a policy-based route
is configured to use the 3G connection, the connection will remain up until the Maximum
Connection Time (if configured) is reached.

SonicOS 5.8.1 Administrator Guide

437

3G

Manual Dial 3G Failover
The following diagram depicts the sequence of events that occur when the WAN ethernet
connection fails and the 3G Connection Profile is configured for Manual Dial.

Caution

It is not recommended to use a Manual Dial 3G Connection Profile when the WAN
Connection Model is set for Ethernet with 3G Failover. The Manual Dial 3G Connection
Profile is only intended to be used when the device's WAN Connection Model is set to 3G
Only in the Network > Interfaces page.

Administrator manually
connects WWAN using
SonicOS interface

1.

Primary Ethernet Connection Available - The Ethernet WAN is connected and used as
the primary connection. 3G is never connected while the Ethernet WAN connection is
available.

2.

Primary Ethernet Connection Fails - The 3G connection is not established until the
administrator manually enables the connection.

3.

3G Connection Established – A 3G connection is established when the administrator
manually enables the connection on the SonicWALL appliance. The 3G connection stays
enabled until the administrator manually disables the connection.

4.

Reestablishing WAN Ethernet Connectivity After Failover – Regardless of whether the
an Ethernet connection becomes available again, all LAN-to-WAN traffic will still use the
manually enabled 3G connection until the connection is manually disabled by the
administrator. After a manual disconnect, the available Ethernet connection will be used.

3G PC Card Support
To use the 3G interface you must have a 3G PC card and a contract with a wireless service
provider. Because both GSM and CDMA provide virtually the same performance, a 3G service
provider should be selected based primarily on the availability of supported hardware. SonicOS
Enhanced (3.6 and later versions) supports the 3G PC cards listed online at:
http://www.sonicwall.com/us/products/cardsupport.html

438

SonicOS 5.8.1 Administrator Guide

3G

3G Wireless WAN Service Provider Support
SonicOS Enhanced supports the following 3G Wireless network providers (this list is subject to
change):
•

Cingular Wireless

•

H3G

•

Sprint PCS Wireless

•

Verizon Wireless

•

Vodafone

•

Telecom Italia Mobile

•

Telefonica

•

T-Mobile

•

TDC Song

•

Orange

3G Prerequisites
Before configuring the 3G interface, you must complete the following prerequisites:

Note

•

Purchase a 3G service plan from a supported third-party wireless provider

•

Configure and activate your 3G PC card

•

Insert the 3G PC card into the SonicWALL appliance before powering on the SonicWALL
security appliance.

The 3G PC card should only be inserted or removed when the SonicWALL security
appliance is powered off.
For information on configuring these prerequisites, see the SonicWALL Getting Started Guide
for your model.
The following sections describe how to configure the 3G interface on the SonicWALL appliance:
•

“3G > Status” on page 440

•

“3G > Settings” on page 440

•

“3G > Advanced” on page 442

•

“3G > Connection Profiles” on page 444

•

“3G > Data Usage” on page 450

•

“Other 3G Configuration Tasks” on page 450

Most of the 3G settings can also be configured on the Network > Interfaces page. 3G
Connection Profiles can only be configured on the 3G > Connection Profiles page.

SonicOS 5.8.1 Administrator Guide

439

3G

3G > Status
The 3G > Status page displays the current status of 3G on the SonicWALL appliance. It
indicates the status of the 3G connection, the current active WAN interface, or the current
backup WAN interface. It also displays IP address information, DNS server addresses, the
current active dial up profile, and the current signal strength.
3G_settings

3G > Settings
On the 3G > Settings page, you can configure the following three settings:
•

“Connect on Data” on page 440

•

“Management/User Login” on page 441

•

“3G Interface Monitoring” on page 441

3G Device Type - Select whether you are using an a 3G/Mobile connection, an Analog
Modem, or Auto-detect.

Connect on Data
The Connect on Data Categories settings allow you to configure the 3G interface to
automatically connect to the 3G service provider when the SonicWALL appliance detects
specific types of traffic. The Connect on Data Categories include:

440

•

NTP packets

•

GMS Heartbeats

•

System log e-mails

•

AV Profile Updates

•

SNMP Traps

•

Licensed Updates

•

Firmware Update requests

SonicOS 5.8.1 Administrator Guide

3G

•

Syslog traffic

To configure the SonicWALL appliance for Connect on Data operation, you must select Dial on
Data as the Dial Type for the Connection Profile. See “3G > Connection Profiles” on page 444
for more details.

Management/User Login
The Management/User Login section must be configured to enable remote management of
the SonicWALL appliance over the 3G interface.

You can select any of the supported management protocol(s): HTTPS, Ping, and/or SNMP.
You can also select HTTP for management traffic. However, bear in mind that HTTP traffic is
less secure than HTTPS.
Select Add rule to enable redirect from HTTP to HTTPS to have the SonicWALL
automatically convert HTTP requests to HTTPS requests for added security. This option is only
available

3G Interface Monitoring
The 3G Interface Monitoring section enables administrators to configure the 3G interface to
monitor the connection to the service provider and automatically disable the 3G interface if the
3G connection fails. Interface monitoring is accomplished by probing a specified target at a set
interval.

Note

If the Probe Target is unable to contact the target device, the 3G interface is deactivated
and traffic is no longer sent to the 3G.

1.

In the Check interface every box, enter an interval between probes (in seconds). The
default value for this field is 5 seconds.

2.

In the Re-establish connection after box, enter the number of target probes that must be
missed before a 3G connection is re-established. The default value for this field is 2 missed
intervals.

SonicOS 5.8.1 Administrator Guide

441

3G

3.

In the Probe Type menu, select one of the following options:
– Probe succeeds when either Main Target or Alternate Target responds
– Probe succeeds when both Main Target and Alternative Target respond
– Probe succeeds when Main Target responds
– Succeeds Always (no probing)

4.

For both the Main Target and, when applicable, the Alternate Target configure the
following:
a. Select Ping (ICMP) or TCP from the Probe Target menu.
b. Enter the IP address of the main target device in the IP Address field.

Tip

To have the SonicWALL security appliance send 3G probes to the default gateway received
during 3G negotiation, leave the IP address field as 0.0.0.0.
c. If the probe target is using TCP, enter a port number in the Port field.

3G_advanced

3G > Advanced
The 3G > Advanced page is used to configure the following features:
•

“Remotely Triggered Dial-Out” on page 442

•

“Bandwidth Management” on page 443

•

“Connection Limit” on page 443

Remotely Triggered Dial-Out
Before configuring the Remotely Triggered Dial-Out feature, ensure that your configuration
meets the following prerequisites:
•

442

The 3G profile is configured for dial-on-data.

SonicOS 5.8.1 Administrator Guide

3G

•

The SonicWALL Security Appliance is configured to be managed using HTTPS, so that the
device can be accessed remotely.

•

It is recommended that you enter a value in the Enable Max Connection Time (minutes)
field. This field is located in the 3G Profile Configuration window on the Parameters tab.
See “3G > Connection Profiles” on page 444 for more information. If you do not enter a
value in this field, dial-out calls will remain connected indefinitely, and you will have to
manually terminate sessions by clicking the Disconnect button.

To configure Remotely Triggered Dial-Out, go the 3G > Advanced screen.
1.

Check the Enable Remotely Triggered Dial-Out checkbox.

2.

(Optional) To authenticate the remote call, check the Requires authentication checkbox
and enter the password in the Password: and Confirm Password: fields.

Bandwidth Management
The Bandwidth Management section allows the administrator to enable egress (outbound) or
ingress (inbound) bandwidth management services on the 3G interface.

Note

Bandwidth management is a service and must be registered. To configure the service,
navigate to the Application Firewall section of the user interface.

1.

Click the Enable Egress Bandwidth Management checkbox to enable bandwidth
management policy enforcement on outbound traffic.

2.

Click the Enable Ingress Bandwidth Management checkbox to enable bandwidth
management policy enforcement on inbound traffic.

3.

Select a Compression Multiplier from the drop-down list.

Connection Limit
The Connection Limit section allows the administrator to set a host/node limit on the 3G
connection. This feature is especially useful for deployments where the 3G connection is used
as an overflow or in load-balanced situations to avoid over-taxing the connection.
In the Max Hosts field, enter the maximum number of hosts to allow when this interface is
connected. The default value is “0”, which allows an unlimited number of nodes.

SonicOS 5.8.1 Administrator Guide

443

3G

3G_profiles

3G > Connection Profiles
Use the 3G > Connection Profiles to configure 3G connection profiles and set the primary and
alternate profiles.

Select the Primary 3G connection profile in the Primary Profile pulldown menu. Optionally, you
can select up to two alternate 3G profiles.
To create a 3G connection profile, perform the steps in the following sections:

444

•

“General Tab” on page 445

•

“Parameters Tab” on page 446

•

“IP Addresses Tab” on page 447

•

“Schedule Tab” on page 447

•

“Data Limiting Tab” on page 448

•

“Advanced Tab” on page 449

SonicOS 5.8.1 Administrator Guide

3G

General Tab
The General tab allows the administrator to configure general connection settings for the 3G
service provider. After selecting your country, service provider, and plan type, the rest of the
fields are automatically field for most service providers.
1.

On the 3G > Connection Profiles page, click on the Add button. The 3G Profile
Configuration window displays.

2.

Select the Country where the SonicWALL appliance is deployed.

3.

Select the Service Provider that you have created an account with. Note that only service
providers supported in the country you selected are displayed.

4.

In the Plan Type window, select the 3G plan you have subscribed to with the service
provider.
If your specific plan type is listed in the pulldown menu (many basic plans are labeled
simply as standard), the rest of the fields in the General tab are automatically provisioned.
Verify that these fields are correct and click on the Parameters tab.

5.

If your Plan Type is not listed in the pulldown menu, select Other.

6.

Enter a name for the 3G profile in the Profile Name field.

7.

Verify that the appropriate Connection Type is selected. Note that this field is automatically
provisioned for most service providers.

8.

Verify that the Dialed Number is correct. Note that the dialed number is *99# for most
Service Providers.

9.

Enter your username and password in the User Name, User Password, and Confirm User
Password fields, respectively.

10. Enter the Access Point Name in the APN field. APNs are required only by GPRS devices

and will be provided by the service provider.

SonicOS 5.8.1 Administrator Guide

445

3G

Parameters Tab
The Parameters tab allows the administrator to configure under what conditions the 3G service
connects. The three connection types are Persistent, Connect on Data, and Manual. The
mechanics of these connection types are described in the “Understanding 3G Connection
Models” section on page 434.
1.

Click on the Parameters tab.

2.

In the Dial Type pulldown menu, select whether the connection profile is a Persistent
Connection, Dial on Data, or Manual Dial.
For a detailed explanation of how the different Dial Types operate when the WAN
Connection Types is set for Ethernet with 3G Failover see “Understanding 3G Failover”
on page 435.

Note

446

To configure the SonicWALL appliance for remotely triggered dial-out, the Dial Type must
be Dial on Data. See “3G > Advanced” on page 442 for more information.
3.

Select the Enable Inactivity Disconnect (minutes) checkbox and enter a number in the
field to have the 3G connection disconnected after the specified number of minutes of
inactivity. Note that this option is not available if the Dial Type is Persistent Connection.

4.

Select the Enable Max Connection Time (minutes) checkbox and enter a number in the
field to have the 3G connection disconnected after the specified number of minutes,
regardless if the session is inactive or not. Enter a value in the Delay Before Reconnect
(minutes) to have the SonicWALL appliance automatically reconnect after the specified
number of minutes.

5.

Select the Dial Retries per Phone Number checkbox and enter a number in the field to
specify the number of times the SonicWALL appliance is to attempt to reconnect.

6.

Select the Delay Between Retries (seconds) checkbox and enter a number in the field to
specify the number of seconds between retry attempts.

SonicOS 5.8.1 Administrator Guide

3G

7.

Select the Disable VPN when Dialed checkbox to disable VPN connections over the 3G
interface.

IP Addresses Tab
The IP Addresses tab allows the administrator to configure dynamic or static IP addressing for
this interface. In most cases, this feature is set to Obtain an IP Address Automatically,
however, it is possible to configure manual IP addresses for both your gateway IP address and
one or more DNS server IP addresses if this is required by your service provider.
1.

Click on the IP Addresses tab.

By default, 3G connection profiles are configured to obtain IP addresses and DNS server
addresses automatically. To specify a static IP address, select the Use the following IP
Address radio box and enter the IP address in the field.
To manually enter DNS server addresses, select the Use the following IP Address radio
box and enter the IP addresses of the primary and secondary DNS servers in the fields.

Schedule Tab
The Schedule tab allows the administrator to limit 3G connections to specified times during
specific days of the week. This feature is useful for data plans where access is limited during
certain times of day, such as plans with free night/weekend minutes.

SonicOS 5.8.1 Administrator Guide

447

3G

Note

When this feature is enabled, if a the checkbox for a day is not selected, 3G access will be
denied for that entire day.
1.

Click on the Schedule tab.

2.

Select the Limit Times for Connection Profile checkbox to enable the scheduling feature
for this interface.

3.

Select the checkbox for each Day of Week you wish to allow access on.

4.

Enter the desired Start Time and End Time (in 24-hour format) for each day of the week.

Data Limiting Tab
The Data Limiting tab allows the administrator to limit data usage on a monthly basis. This
feature gives you the ability to track usage based on your 3G provider’s billing cycle and
disconnect when a given limit is reached.
1.

Tip

448

Click on the Data Limiting tab.

If your 3G account has a monthly data or time limit, it is strongly recommended that you
enable Data Usage Limiting.

SonicOS 5.8.1 Administrator Guide

3G

2.

Select the Enable Data Usage Limiting checkbox to have the 3G interface become
automatically disabled when the specified data or time limit has been reached for the
month.

3.

Select the day of the month to start tracking the monthly data or time usage in the Billing
Cycle Start Date pulldown menu.

4.

Enter a value in the Limit field and select the appropriate limiting factor: either GB, MB,
KB, or minutes.

5.

Click OK.

Advanced Tab
The Advanced tab allows the administrator to manually configure a chat script used during the
3G connection process. Configuring a chat script only necessary when there is a need to add
commands or special instructions to the standard dialup connection script.
1.

Click on the Advanced tab.

2.

Enter the connection chat script in the Chat Script field.

3.

Click OK.

SonicOS 5.8.1 Administrator Guide

449

3G

3G_data

3G > Data Usage
On the 3G > Data Usage page, you can monitor the amount of data transferred over the 3G
interface in the Data Usage table and view details of 3G sessions in the Session History table.

The Data Usage table displays the current data usage and online time for the current Year,
Month, Week, Day, and Billing Cycle. Billing cycle usage is only calculated if the Enable Data
Usage Limiting option is enabled on the 3G Connection Profile.
Click the appropriate Reset button to reset any of the data usage categories.

Note

The Data Usage table is only estimate of the current usage and should not be used to
calculate actual charges. Contact your Service Provider for accurate billing information.
The Session History table displays a summary of information about 3G sessions. To view
additional details about a specific session, place your mouse cursor over the Properties
balloon.

Other 3G Configuration Tasks

450

•

“Managing 3G Connections” on page 451

•

“Specifying the WAN Connection Model” on page 451

SonicOS 5.8.1 Administrator Guide

3G

Managing 3G Connections
To initiate a 3G connection, perform the following steps, click on the Manage button in the 3G
interface line on the Network > Interfaces page. The 3G Connection window displays. Click
the Connect button. The SonicWALL appliance attempts to connect to the 3G service provider.
To disconnect a 3G connection, click on the Manage button. The 3G Connection window
displays. Click Disconnect.

Specifying the WAN Connection Model
To configure the WAN connection model, navigate to the Network > Interfaces page and
select one of the following options in the WAN Connection Model pulldown menu:
•

3G only - The WAN interface is disabled and the 3G interface is used exclusively.

•

Ethernet only - The 3G interface is disabled and the WAN interface is used exclusively.

•

Ethernet with 3G Failover - The WAN interface is used as the primary interface and the
3G interface is disabled. If the WAN connection fails, the 3G interface is enabled and a 3G
connection is automatically initiated. See “Specifying the WAN Connection Model” on
page 243 for more information.

3G_glossary

3G Glossary
•

1xRTT - Single Carrier Radio Transmission Technology - The second generation of the
CDMA protocol, permitting many radios to simultaneously share the same frequency.
1xRTT was mostly deployed in the Americas, but is now undergoing an evolution to 1xEVDO by many operators.

•

1xEV-DO - Single Carrier Evolution Data Optimized (Also EV-DO) - The evolution of the
1xRTT protocol, EV-DO provides true 3G speeds, competing with UMTS, but remains most
widely used in the Americas. There are currently two revisions of EV-DO available: Rev. 0,
which provides data rates up to 2.4 Mbps, and Rev. A, with data rates up to 3.1 Mbps.

•

APN - Access Point Name - Designated the external connection point (access point) for
devices on a GPRS network. APN designation is only required by GPRS devices, and will
be provided by the network operator. APN uses a notation such as "general.t-mobile.uk",
"btmobile.bt.com" and "wap.cingular".

•

DMA - Code Division Multiple Access - A multiplexing technique that allows for multiple
concurrent accesses to a channel through the use of unique data encoding rather than time
or frequency based division of access. CDMA has capacity advantages over GSM, but
congestion tends to reduce its operating range. Also refers to Qualcomm's family of
protocols.

•

EDGE - Enhanced Data rates for GSM Evolution - Also known an Enhanced GRPS.
EDGE is an adaptive GPRS implementation employed by many GSM networks. It improves
upon GPRS by using up to 8 time-slots (as opposed to a maximum of 5) with a denser
modulation scheme for higher data rates. EDGE is regarded as a cost-saving interim GSM
protocol until more widespread adoption of UMTS is seen, and it is currently broadly
available in all worldwide geographies.

•

ESN - Electronic Serial Number - A 32 bit number used to uniquely identify stations on a
CDMA network. ESNs are the effective equivalent of GSM's IMEI scheme.

SonicOS 5.8.1 Administrator Guide

451

3G

•

Generation - WWAN protocols are divided by generation, such as 2G, 2.5G, and 3G, where
1G would be the original analog cellular networks. Generations advanced is usually
characterized by improvements in speed and capacity. Although 3G is most commonly
used to describe Wireless Wide Area Networking, 3G only refers to a single set of available
protocols. A list of popular protocols by generation:
– 1G - Analog
– 2G - GSM
– 2.5G - GPRS
– 2.75G - EDGE, 1xRTT
– 3G - UMTS, 1xEV-DO
– 3.5G - HSDPA

452

•

GPRS - General Packet Radio Service - An evolution of the GSM network that achieves
speed improvements through the use of unused TDMA channels. GPRS is divided by
incrementing classes, which define the number of time-slots and the data-rate per time-slot.
GPRS has an additional advantage over GSM in that it is a packet-switched technology,
meaning that stations only send data when there is data to send (rather than reserving the
entire channel as occurs in GSM's circuit-switched networks) thus making more efficient
use of available bandwidth. The process of connecting to a GPRS network generally
involves attachment to the network, followed by the construction and activation of a PDP
context, as performed by a series of AT commands. This process is largely automated by
SonicOS through the use of profiles, but also allows for manual PDP context construction.

•

GSM - Global System for Mobile Communication - TDMA based protocol that uses
digital channels for both signaling and speech, making it a well suited platform for data
communications, although at very low data rates. GSM competes as a protocol with
Qualcomm's CDMA, but remains the most popular worldwide protocol. GSM
implementations are often regarded as less susceptible to signal degradation indoors.
Although GSM is used both in the Americas and the rest of the world, the American
implementation operates on a different frequency, and interoperability is not guaranteed
unless explicitly supported by the equipment.

•

HSDPA - High Speed Downlink Packet Access - An evolution of UMTS (and thus of
GSM) based on W-CDMA technology. HSDPA can achieve very high data rates, with
subsequent phases targeting rates of up to 50 Mbps, but it is not currently very widely
adopted despite announcements of future support from many operators.

•

IMEI - International Mobile Equipment Identity - A unique 15 digit number assigned to
every GSM/UMTS device for the purposes of identifying the device (not the subscriber) on
the network. The subscriber on these networks is identified by the IMSI number, which is
stored on the SIM card.

•

IMSI - International Mobile Subscriber Identity - A unique 15 (or 14) digit number that
identifies subscribers on GSM/UMTS networks. The IMSI is stored on the subscriber's SIM,
and comprises a country code (as defined by ITU E.212), a network code (the network
operator), and a unique subscriber number.

•

PDP Context - Packet Data Protocol Context - A data structure representing the logical
association of a station on a GPRS network. The data structure comprises a CID (context
identifier), a PDP_Type (the protocol being used, e.g. IP), an APN (Access Point Name),
and optional a PDP_Addr (PDP Address) to identify the usable address space for the
connection. After a PDP Context is constructed, it must be activated.

•

SIM - Subscriber Identity Module - USIM (Universal SIM) in UMTS. A SIM, also known as
a Smart Card, stores unique subscriber information, including subscription and service
parameters as well as preferences and settings. SIMs are used by all GSM devices, and

SonicOS 5.8.1 Administrator Guide

3G

allow for a subscriber's identity to move from one GSM device to another. Many operators
lock their devices to prevent the use of other operator's SIM cards, but operators will
sometimes unlock their devices if certain conditions are met.
•

TDMA - Time Division Multiple Access - TDMA is used by most currently available GSM
networks. It allows multiple concurrent access to a frequency by dividing it into time-slots,
where each station takes turns transmitting. Since TDMA based technologies switch their
transmitters on and off rapidly (native TDMA switches at 50 Hz, GSM switches at 217 Hz),
radio frequency (RF) pollution is created. When the power output is high enough (such as
right before a call is received), these RF signals (particularly GSM's 217 Hz signal, which
is in the audible spectrum, even on really cheap computer speakers) can be picked up by
nearby amplification circuitry, producing a buzzing sound. So, don't put your GSM equipped
SonicWALL appliance on top of a stereo, and don't balance it on your head if you wear
hearing aids.

•

UMTS - Universal Mobile Telecommunication System - Employing W-CDMA
technology, UMTS is considered the evolution of GSM, and is sometimes referred to a
3GSM. UMTS is in fairly wide deployment worldwide, with the exception of the Americas,
where EDGE is favored, and where UMTS will likely be leapfrogged as GSM's successor
by HSDPA.

•

W-CDMA - Wideband Code Division Multiple Access - The technology underlying
UMTS, W-CDMA is an evolution of the GSM protocol. Referred to a Wideband because its
carrier channels are four times wider than then original CDMA standard (5 MHz versus 1.25
MHz).

SonicOS 5.8.1 Administrator Guide

453

3G

454

SonicOS 5.8.1 Administrator Guide

CHAPTER 33
Chapter 33:

Configuring Modem

modem

Modem
The following sections describe how to configure and use the modem functionality on a
SonicWALL UTM appliance:
•

“Modem > Status” on page 455

•

“Modem > Settings” on page 456

•

“Modem > Advanced” on page 457

•

“Modem > Connection Profiles” on page 459

Modem > Status
The Modem > Status page displays dialup connection information when the modem is active.
You create modem Connection Profiles in the Modem Profile Configuration window, which
you access from the Modem > Connection Profiles page.
In the Modem Status section, the current active network information from your ISP is displayed
when the modem is active:
•

WAN Gateway (Router) Address

•

WAN IP (NAT Public) Address

•

WAN Subnet Mask

•

DNS Server 1

•

DNS Server 2

•

DNS Server 3

•

Current Active Dial-Up Profile (id)

•

Current Connection Speed

SonicOS 5.8.1 Administrator Guide

455

Modem

If the modem is inactive, the Status page displays a list of possible reasons that your modem
is inactive. When the modem is active, the network settings from the ISP are used for WAN
access.

Modem > Settings
The Modem > Settings page allows you to configure modem settings, specify Connect on Data
categories, select management and user login options, and select the primary and alternate
modem profiles.

Modem Device Type - Select whether you are using an Analog Modem, a 3G/Mobile
connection, or Auto-detect.
Speaker Volume - Select whether you want the modem’s speaker turned on or off. The default
value is On.
Modem Initialization - Select Initialize Modem For Use In and select the country from the
drop-down menu. United States is selected by default. If the modem uses AT commands to
initialize, select Initialize Modem Using AT Commands. Enter any AT commands used for the
modem in the AT Commands (for modem initialization) field. AT commands are instructions
used to control a modem such as ATS7=30 (allows up to 30 seconds to wait for a dial tone),
ATS8=2 (sets the amount of time the modem pauses when it encounters a comma (“,”) in the
string).

Connect on Data Categories
The Connect on Data Categories settings allow you to specify the outbound data that is
detected before the modem dials the ISP. Outbound data does not need to originate from
computers on the LAN, but can also be packets generated by the SonicWALL security
appliance security applications.

456

SonicOS 5.8.1 Administrator Guide

Modem

The Connect on Data Categories include:
•

NTP packets

•

GMS Heartbeats

•

System log e-mails

•

AV Profile Updates

•

SNMP Traps

•

Licensed Updates

•

Firmware Update requests

•

Syslog traffic

Management/User Login
The Management/User Login section allows you to enable remote management of the
SonicWALL security appliance or user login from the Modem interface.

You can select any of the supported management protocol(s): HTTPS, Ping, SNMP and/or
SSH. You can also select HTTP for management traffic. However, bear in mind that HTTP
traffic is less secure than HTTPS.
Select Add rule to enable redirect from HTTP to HTTPS to allow the SonicWALL to
automatically convert HTTP requests to HTTPS requests for added security.

Modem > Advanced
The Modem > Advanced page is used to configure the Remotely Triggered Dial-Out feature,
which enables network administrators to remotely initiate a WAN modem connection from a
SonicWALL UTM appliance.

Remotely Triggered Dial-Out
The following process describes how a Remotely Triggered Dial-Out call functions:

Note

1.

The network administrator initiates a modem connection to the SonicWALL located at the
remote office.

2.

If the SonicWALL is configured to authenticate the incoming call, it prompts the network
administrator to enter a password. Once the call is authenticated, the SonicWALL
terminates the call.

After three incorrect password attempts, the SonicWALL terminates a Remotely Triggered
Dial-out authentication session. Each password attempt is allowed a maximum of 60
seconds. If a dial-out session is terminated, the SonicWALL can be called again for another
Remotely Triggered Dial-out authentication session.

SonicOS 5.8.1 Administrator Guide

457

Modem

Note

3.

The SonicWALL then initiates a modem connection to its dial-up ISP, based on the
configured dial profile.

4.

The network administrator accesses the SonicWALL web management interface to perform
the required tasks.

If LAN- to-WAN traffic on the SonicWALL generates a dial-out request at the same time as
a Remotely Triggered Dial-out session is being authenticated, the Remotely Triggered Dialout session is terminated and the SonicWALL initiates its own dial-out session.

Configuring Remotely Triggered Dial-Out
Before configuring the Remotely Triggered Dial-Out feature, ensure that your configuration
meets the following prerequisites:
•

The dial profile is configured for dial-on-data.

•

The SonicWALL Security Appliance is configured to be managed using HTTPS, so that the
device can be accessed remotely.

•

Enter a value in the Enable Max Connection Time (minutes) field. If you do not enter a
value in this field, dial-out calls will remain connected indefinitely, and you will have to
manually terminate sessions by clicking the Disconnect button.

To configure Remotely Triggered Dial-Out, go the Modem > Advanced screen.

1.

Check the Enable Remotely Triggered Dial-out checkbox.

2.

(Optional) To authenticate the remote call, check the Requires authentication checkbox
and enter the password in the Password: and Confirm Password: fields.

Bandwidth Management
The Bandwidth Management section allows the administrator to enable egress (outbound) or
ingress (inbound) bandwidth management services on the modem interface.

Note

Bandwidth management is a service and must be registered. To configure the service,
navigate to the Application Firewall section of the user interface.

1.

458

Click the Enable Egress Bandwidth Management checkbox to enable bandwidth
management policy enforcement on outbound traffic.

SonicOS 5.8.1 Administrator Guide

Modem

2.

Click the Enable Ingress Bandwidth Management checkbox to enable bandwidth
management policy enforcement on inbound traffic.

3.

Select a Compression Multiplier from the drop-down list.

Connection Limit
The Connection Limit section allows the administrator to set a host/node limit on the modem
connection. This feature is especially useful for deployments where the modem connection is
used as an overflow or in load-balanced situations to avoid over-taxing the connection.
In the Max Hosts field, enter the maximum number of hosts to allow when this interface is
connected. The default value is “0”, which allows an unlimited number of nodes.

Modem > Connection Profiles
The Modem > Connection Profiles page allows you to configure modem profiles on the
SonicWALL security appliance using your dial-up ISP information for the connection. Multiple
modem profiles can be used when you have a different profile for individual ISPs.

The current profile is displayed in the Connection Profiles table, which displays the following
profile information:
•
•
•
•

Name - The name you've assigned to the profile. You can use names such as Home, Office,
or Travel to distinguish different profiles from each other.
IP Address - The IP address of the Internet connection.
Connection Type - Displays Persistent, Connect on Data, or Manual Dial, depending on what
you selected in the Profile Configuration window for the profile.
Configure - Clicking the edit icon allows you to edit the profile. Clicking on the delete icon deletes the profile.

SonicOS 5.8.1 Administrator Guide

459

Modem

Configuring a Profile
1.

In the Modem > Connection Profiles page, click the Add button. The Modem Profile
Configuration window is displayed for configuring a dialup profile.

Once you create your profiles, you can then configure specify which profiles to use for WAN
failover or Internet access.
To configure your ISP settings, you must obtain your Internet information from your dial-up
Internet Service Provider.

Tip!

1.

In the General Settings page, enter a name for your dialup profile in the Profile Name
field.

2.

Enter the primary number used to dial your ISP in the Primary Dialed Number field.

If a specific prefix is used to access an outside line, such as 9, &, or, , enter the number as part of the primary
phone number.

460

3.

Enter the secondary number used to dial your ISP in the Secondary Dialed Number field
(optional).

4.

Enter your dial-up ISP user name in the User Name field.

5.

Enter the password provided by your dialup ISP in the User Password field.

6.

Confirm your dialup ISP password in the Confirm User Password field.

7.

If your ISP has given you a script that runs when you access your ISP connection, cut and
paste the script text in the Chat Script field. See the Information in “Chat Scripts” on
page 463 section for more information on using chat scripts.

SonicOS 5.8.1 Administrator Guide

Modem

8.

Click the ISP Address tab.

9.

In the ISP Address Setting section, select Obtain an IP Address Automatically if you do
not have a permanent dialup IP address from your ISP. If you have a permanent dialup IP
address from your ISP, select Use the following IP Address and enter the IP address in
the corresponding field.

10. If you obtain an IP address automatically for your DNS server(s), select Obtain an IP

Address Automatically. If your ISP has a specific IP address for the DNS server(s), select
Use the following IP Address and enter the IP address of the primary DNS server in the
corresponding field. You can also add a secondary DNS server address in the field below.
11. Click on the Parameters tab. Use the settings in the page to configure modem dialup

behavior.

12. In the Connect Type menu select one of the following options:

 Persistent Connection - By selecting Persistent Connection, the modem stays
connected unless you click the Disconnect button on the Network > Settings page. If
Enable Dial-Up Wan Failover is selected on the Network > WAN Failover & Load
Balancing page, the modem dials automatically when a WAN connection fails. If the
Primary Profile cannot connect, the modem uses the Alternate Profile 1 to dial an ISP.
 Connect on Data - Using Connect on Data requires that outbound data is detected before
the modem dials the ISP. Outbound data does not need to originate from computers on the
LAN, but can also be packets generated by the SonicWALL security appliance internal

SonicOS 5.8.1 Administrator Guide

461

Modem

applications such as AutoUpdate and Anti-Virus. If Enable WAN Failover is selected on the
Modem > Failover page, the pings generated by the probe can trigger the modem to dial
when no WAN Ethernet connection is detected. If the Primary Profile cannot connect, the
modem uses the Alternate Profile 1 to dial an ISP.
 Manual Connection - Selecting Manual Connection for a Primary Profile means that a
modem connection does not automatically occur. You must click the Connect button on the
Network > Settings page for the dialup connection to be established. Also, WAN Failover
does not automatically occur.
Caution

If you are configuring two dial-up profiles for WAN failover, the modem behavior should be
the same for each profile. For example, if your Primary Profile uses Persistent Connection,
your Secondary Profile should also use Persistent Connection.

Caution

If you enable Persistent Connection for the modem, the modem connection remains active
until the WAN Ethernet connection is reactivated or you force disconnection by clicking
Disconnect on the Configure page.
13. If you selected either Connect on Data or Manual Connection, enter the number of

minutes a dial-up connection is allowed to be inactive in the Enable Inactivity Disconnect
(minutes) field.
14. Select the connection speed from the Max Connection Speed (bps) menu. Auto is the

default setting as the SonicWALL security appliance automatically detects the connection
speed when it connects to the ISP or you can select a specific speed option from the menu.
15. Select Enable Max Connection Time (minutes) if the connection is terminated after the

specified time. Enter the number of minutes for the connection to be active. The value can
range from 0 to 1440 minutes. This feature does not conflict with the Inactivity Disconnect
setting. If both features are configured, the connection is terminated based on the shortest
configured time.
16. If you select Enable Max Connection Time (minutes), enter the number of minutes to

delay before redialling the ISP in the Delay Before Reconnect (minutes). The value can
range from 0 to 1440, and the default value is 0 which means there is no delay before
reconnecting to the ISP.
17. If you have call waiting on your telephone line, you should disable it or another call can

interrupt your connection to your ISP. Select Disable Call Waiting and then select
command from the list. If you do not see your command listed, select Other, and enter the
command in the field. If you are not sure which command to use, see the documentation
that came with your phone service or contact your phone service provider.
18. If the phone number for your ISP is busy, you can configure the number of times that the

SonicWALL security appliance modem attempts to connect in the Dial Retries per Phone
Number field. The default value is 0.
19. Enter the number of seconds between attempts to redial in the Delay Between Retries

(seconds) field. The default value is 5 seconds.
20. Select Disable VPN when Dialled if VPN Security Associations (SAs) are disabled when

the modem connects to the ISP. Terminating the dial-up connection re-enables the VPN
SAs. This is useful if you want to deploy your own point-to-point RAS network and want
packets to be sent in the clear to your intranets.

462

SonicOS 5.8.1 Administrator Guide

Modem

21. Click the Schedule tab.

22. If you want to specify scheduled times the modem can connect, select Limit Times for

Dialup Profile. Enter times for each day in 24-hour format that you want the modem to be
able to make a connection.
23. Click OK to add the dial-up profile to the SonicWALL security appliance. The Dialup Profile

appears in the Connection Profiles table.

Chat Scripts
Some legacy servers can require company-specific chat scripts for logging onto the dial-up
servers.
A chat script, like other types of scripts, automates the act of typing commands using a
keyboard. It consists of commands and responses, made up of groups of expect-response pairs
as well as additional control commands, used by the chat script interpreter on the TELE3 SP.
The TELE3 SP uses a default chat script that works with most ISPs, but your ISP may require
a chat script with specific commands to “chat” with their server. If an ISP requires a specific
chat script, it is typically provided to you with your dial-up access information. The default chat
script for the TELE3 SP has the following commands:
ABORT `NO DIALTONE'
ABORT `BUSY'
ABOR `NO CARRIER'
"ATQ0
"ATE0
"ATM1
"ATL0
"ATV1
OK ATDT\T
CONNECT \D \C

The first three commands direct the chat script interpreter to abort if any of the strings NO
CARRIER, NO DIALTONE, or BUSYare received from the modem.
The next five commands are AT commands that tell the chat interpreter to wait for nothing as
" defines an empty string, and configure the following on the modem: return command
responses, don't echo characters, report the connecting baud rate when connected, and return
verbose responses.

SonicOS 5.8.1 Administrator Guide

463

Modem

The next line has OK as the expected string, and the interpreters waits for OK to be returned
in response to the previous command, ATV1, before continuing the script. If OK is not returned
within the default time period of 50 seconds, the chat interpreter aborts the script and the
connection fails. If OK is received, the prefix and phone number of the selected dial-up account
is dialled. The \T command is replaced by chat script interpreter with the prefix and phone
number of the dial-up account.
In the last line of the script, CONNECT is the expected response from the remote modem. If
the modems successfully connect, CONNECT is returned from the TELE3 SP modem.The \D
adds a pause of one second to allow the server to start the PPP authentication. The \C
command ends the chat script end without sending a carriage return to the modem. The TELE3
SP then attempts to establish a PPP (Point-to-Point Protocol) connection over the serial link.
The PPP connection usually includes authentication of the user by using PAP (Password
Authentication Protocol) or CHAP (Challenge Handshake Authentication Protocol) from the
PPP suite. Once a PPP connection is established, it looks like any other network interface.

Custom Chat Scripts
Custom chat scripts can be used when the ISP dial-up server does not use PAP or CHAP as
an authentication protocol to control access. Instead, the ISP requires a user to log onto the
dial-up server by prompting for a user name and password before establishing the PPP
connection. For the most part, this type of server is part of the legacy systems rooted in the
dumb terminal login architecture. Because these types of servers can prompt for a user name
and password in a variety of ways or require subsequent commands to initiate the PPP
connection, a Chat Script field is provided for you to enter a custom script.
If a custom chat script is required by an ISP for establishing a connection, it is commonly found
on their web site or provided with their dial-up access information. Sometimes the scripts can
be found by using a search engine on the Internet and using the keywords, “chat script ppp
Linux ”.
A custom chat script can look like the following script:
ABORT `NO CARRIER'
ABORT `NO DIALTONE'
ABORT `BUSY'
" ATQ0
" ATE0
" ATM1
" ATW2
" ATV1
OK ATDT\T
CONNECT "
sername: \L
assword: \P

Tip!

The first character of username and password are ignored during PPP authentication.
The script looks a lot like the previous script with the exception of the commands at the end.
There is an empty string (") after CONNECT which sends a carriage return command to the
server. The chat interpreter then waits for sername: substring. When a response is returned,
the current PPP account user name, substituting the \L command control string, is sent. Then,
the chat interpreter waits for the substring assword:, and sends the password, substituting \P
with the PPP account password. If either the sername or assword substring are not received
within the timeout period, the chat interpreter aborts the dial-up process resulting in a dial-up
failure.

464

SonicOS 5.8.1 Administrator Guide

PART 6
Part 6:

SonicOS 5.8.1 Administrator Guide

Wireless

465

466

SonicOS 5.8.1 Administrator Guide

CHAPTER 34
Chapter 34:

Viewing WLAN Settings, Statistics, and
Station Status

Wireless Overview
Note

The wireless features described apply only to SonicWALL appliances equipped with internal
wireless hardware, such as the TZ series, the NSA 220W, and the NSA 250MW.
The SonicWALL Wireless security appliances support wireless protocols called IEEE 802.11b,
802.11g, and 802.11n commonly known as Wi-Fi, and send data via radio transmissions. The
SonicWALL wireless security appliance combines three networking components to offer a fully
secure wireless firewall: an Access Point, a secure wireless gateway, and a stateful firewall with
flexible NAT and VPN termination and initiation capabilities. With this combination, the wireless
security appliance offers the flexibility of wireless without compromising network security.
Typically, the wireless security appliance is the access point for your wireless LAN and serves
as the central access point for computers on your LAN. In addition, it shares a single broadband
connection with the computers on your network. Since the wireless security appliance also
provides firewall protection, intruders from the Internet cannot access the computers or files on
your network. This is especially important for an “always-on” connection such as a DSL or T1
line that is shared by computers on a network.
However, wireless LANs are vulnerable to “eavesdropping” by other wireless networks which
means you should establish a wireless security policy for your wireless LAN. On the wireless
security appliance, wireless clients connect to the Access Point layer of the firewall. Instead of
bridging the connection directly to the wired network, wireless traffic is first passed to the
Secure Wireless Gateway layer where the client is required to be authenticated via User Level
Authentication. Wireless access to Guest Services and MAC Filter Lists are managed by the
wireless security appliance. If all of the security criteria are met, then wireless network traffic
can then pass via one of the following Distribution Systems (DS):
•

LAN

•

WAN

•

Wireless Client on the WLAN

•

DMZ or other zone on Opt port

SonicOS 5.8.1 Administrator Guide

467

Wireless Overview

•

VPN tunnel

Considerations for Using Wireless Connections
•

Mobility - if the majority of your network is laptop computers, wireless is more portable than
wired connections.

•

Convenience - wireless networks do not require cabling of individual computers or
opening computer cases to install network cards.

•

Speed - if network speed is important to you, you may want to consider using Ethernet
connections rather than wireless connections.

•

Range and Coverage - if your network environment contains numerous physical barriers
or interference factors, wireless networking may not be suitable for your network.

•

Security - wireless networks have inherent security issues due to the unrestricted nature
of the wireless transmissions. However, the wireless security appliance is a firewall and has
NAT capabilities which provides security, and you can use WPA or WPA2 to secure data
transmissions.

Recommendations for Optimal Wireless Performance

468

•

Place the wireless security appliance near the center of your intended network. This can
also reduce the possibility of eavesdropping by neighboring wireless networks.

•

Minimize the number of walls or ceilings between the wireless security appliance and the
receiving points such as PCs or laptops.

SonicOS 5.8.1 Administrator Guide

Wireless Overview

•

Try to place the wireless security appliance in a direct line with other wireless components.
Best performance is achieved when wireless components are in direct line of sight with
each other.

•

Building construction can make a difference on wireless performance. Avoid placing the
wireless security appliance near walls, fireplaces, or other large solid objects. Placing the
wireless security appliance near metal objects such as computer cases, monitors, and
appliances can affect performance of the unit.

•

Metal framing, UV window film, concrete or masonry walls, and metallic paint can reduce
signal strength if the wireless security appliance is installed near these types of materials.

•

Installing the wireless security appliance in a high place can help avoid obstacles and
improve performance for upper stories of a building.

•

Neighboring wireless networks and devices can affect signal strength, speed, and range of
the wireless security appliance. Also, devices such as cordless phones, radios, microwave
ovens, and televisions may cause interference on the wireless security appliance.

Adjusting the Antennas
The antennas on the wireless security appliance can be adjusted for the best radio reception.
Begin with the antennas pointing straight up, and then adjust as necessary. Note that certain
areas, such as the area directly below the wireless security appliance, get relatively poor
reception. Pointing the antenna directly at another wireless device does not improve reception.
Do not place the antennas next to metal doors or walls as this can cause interference.

Wireless Node Count Enforcement
Users connecting to the WLAN or connecting through the SonicWALL GroupVPN are not
counted towards the node enforcement on the SonicWALL. Only users on the LAN and nonWireless zones on the Opt port are counted towards the node limit.
The Station Status table lists all the wireless nodes connected.

MAC Filter List
The SonicWALL wireless security appliance networking protocol provides native MAC address
filtering capabilities. When MAC address filtering is enabled, filtering occurs at the 802.11 layer,
wireless clients are prevented from authenticating and associating with the wireless access
point. Since data communications cannot occur without authentication and association, access
to the network cannot be granted until the client has given the network administrator the MAC
address of their wireless network card.

SonicOS 5.8.1 Administrator Guide

469

Wireless > Status

Wireless > Status
The Wireless > Status page provides status information for wireless network, including WLAN
Settings, WLAN Statistics, WLAN Activities and Station Status.

The Wireless > Status page has four tables:

470

•

“WLAN Settings” on page 471

•

“WLAN Statistics” on page 472

•

“WLAN Activities” on page 472

•

“Station Status” on page 473

SonicOS 5.8.1 Administrator Guide

Wireless > Status

WLAN Settings
The WLAN Settings table lists the configuration information for the built-in radio. All
configurable settings in the WLAN Settings table are hyperlinks to their respective pages for
configuration. Enabled features are displayed in green, and disabled features are displayed in
red. Click on a setting to go the page in the Management Interface where you can configure
that setting.

b

WLAN Settings

Value

WLAN

Enabled or Disabled

SSID

Wireless network identification information

MAC Address (BSSID)

Serial Number of the wireless security appliance

WLAN IP Address

IP address of the WLAN port

WLAN Subnet Mask

Subnet information

Regulatory Domain

FCC - North America for domestic appliances ETSI - Europe for
international appliances

Channel

Channel Number selected for transmitting wireless signal

Radio Tx Rate

Network speed in Mbps

Radio Tx Power

Current power level of the radio signal transmission

Authentication Type

Encryption settings for the radio, or Disabled--see the Wireless >
Security page

MAC Filter List

Enabled or Disabled

Guest Services

Enabled or Disabled

Intrusion Detection

Enabled or Disabled

Wireless Firmware

Firmware version on the radio card

Associated Stations

Number of clients associated with the wireless security appliance

Radio Mode

Current power level of the radio signal transmission

SonicOS 5.8.1 Administrator Guide

471

Wireless > Status

WLAN Statistics
The WLAN Statistics table lists all of the traffic sent and received through the WLAN. The
Wireless Statistics column lists the kinds of traffic recorded, the Rx column lists received
traffic, and the Tx column lists transmitted traffic.

Wireless Statistics

Rx/TX

Good Packets

Number of allowed packets received and transmitted.

Bad Packets

Number of packets that were dropped that were received and
transmitted.

Good Bytes

Total number of bytes in the good packets.

Management Packets

Number of management packets received and transmitted.

Control Packets

Number of control packets received and transmitted.

Data Packets

Number of data packets received and transmitted.

WLAN Activities
The WLAN Activities table describes the history of wireless clients connecting to the
SonicWALL wireless security appliance.

Wireless Activities Value
Associations

Number of wireless clients that have connected to the wireless security appliance.

Disassociations

Number of wireless clients that have disconnected to the wireless security
appliance.

Reassociations

Number of wireless clients that were previously connected that have reconnected.

Authentications

Number of wireless clients that have been authenticated.

Deauthentications

Number of authenticated clients that have disconnected.

Discards Packets

Number of discarded packets.

472

SonicOS 5.8.1 Administrator Guide

Wireless > Status

Station Status
The Station Status table displays information about wireless connections associated with the
wireless security appliance.
•

Station - the name of the connection used by the MAC address

•

MAC Address - the wireless network card MAC address

•

Authenticated - status of wireless authentication

•

Associated - status of wireless association

•

AID - Association ID, assigned by the security appliance

•

Signal - strength of the radio signal

•

Timeout - number of seconds left on the session

•

Configure - options for configuring the station:
–

-configure power management on the wireless network card of this station, if
enabled.

–

- block the station from the security appliance and add it to the Deny MAC Filter List.

–

- dissociate the station from the security appliance.

Discovered Access Points
The Discovered Access Points table appears when the SonicWALL appliance is in Wireless
Client Bridge mode.

To create a wireless bridge with another access point:

Note

1.

Before you begin, verify that your wireless security settings match that of the access point
to which you are bridging, and that you have switched your SonicWALL TZ wireless
appliance to Wireless Client Bridge mode in the Wireless > Settings page.

2.

In the Wireless > Status screen, locate the access point you wish to bridge to and click the
Connect button.

3.

The configuration is set and your SSID changes to mirror that of the wireless bridge host.

For security reasons, never create a bridge over an open wireless connection.

SonicOS 5.8.1 Administrator Guide

473

Wireless > Status

474

SonicOS 5.8.1 Administrator Guide

CHAPTER 35
Chapter 35:

Configuring Wireless Settings

Wireless > Settings
The Wireless > Settings page allows you to configure settings for the 802.11 wireless antenna.

SonicOS 5.8.1 Administrator Guide

475

Wireless > Settings

Wireless Radio Mode
The Radio Role allows you to configure the SonicWALL TZ wireless for one of two modes:

Note

Be aware that when switching between radio roles, the SonicWALL may require a restart.
Access Point - Configures the SonicWALL as an Internet/network gateway for wireless clients.

Wired LAN
10.10.20.x

Wireless LAN
10.10.50.x
Internal Corporate Networks

Wireless Client Bridge - The SonicWALL TZ wireless provides Internet/network access by
bridging wirelessly to another SonicWALL wireless device or SonicPoint access point, selected
on the Wireless > Status screen. This mode allows for the possibility of secure network
communications between physically seperate locations, without the need for long and costly
ethernet cabling runs.

Building 1
10.10.20.x

Building 2
10.10.30.x
Internal Corporate Networks

Note

476

For more information on Wireless Client Bridging, refer to the SonicWALL Secure Wireless
Network Integrated Solutions Guide, or the SonicWALL Wireless Bridging Technote,
available at 

SonicOS 5.8.1 Administrator Guide

Wireless > Settings

Wireless Settings
Enable WLAN Radio: Check this checkbox to turn the radio on, and enable wireless
networking. Click Apply in the top right corner of the management interface to have this setting
take effect.
Schedule: The schedule determines when the radio is on to send and receive data. The default
value is Always on. The Schedule list displays the schedule objects you create and manage
in the System > Schedule page. The default choices are:
•

Always on

•

Work Hours or M-T-W-TH-F 08:00-17:00 (these two options are the same schedules)

•

M-T-W-TH-F 00:00-08:00

•

After Hours or M-T-W-TH-F 17:00-24:00 (these two options are the same schedules)

•

Weekend Hours or SA-SU 00:00-24:00 (these two options are the same schedules)

SSID: The default value, sonicwall, for the SSID can be changed to any alphanumeric value
with a maximum of 32 characters.
Country Code: The country code determines which regulatory domain the radio operation falls
under.
Radio Mode: Select your preferred radio mode from the Radio Mode menu. The wireless
security appliance supports the following modes:
•

Tip

2.4GHz 802.11n Mixed - Supports 802.11b, 802.11g, and 802.11n clients simultaneously.
If your wireless network comprises multiple types of clients, select this mode.

For optimal throughput speed solely for 802.11n clients, SonicWALL recommends the
802.11n Only radio mode. Use the 802.11n/b/g Mixed radio mode for multiple wireless
client authentication compatibility.
•

802.11n Only - Allows only 802.11n clients access to your wireless network. 802.11a/b/g
clients are unable to connect under this restricted radio mode.

•

2.4GHz 802.11b/g Mixed - Supports 802.11b and 802.11g clients simultaneously. If your
wireless network comprises both types of clients, select this mode.

•

802.11g Only - If your wireless network consists only of 802.11g clients, you may select
this mode for increased 802.11g performance. You may also select this mode if you wish
to prevent 802.11b clients from associating.

•

802.11b Only - Select this mode if only 802.11b clients access your wireless network.

802.11n Wireless Settings
When the wireless radio is configured for a mode that supports 802.11n, the following options
are displayed:
Radio Band (802.11n only): Sets the band for the 802.11n radio:
•

Auto - Allows the appliance to automatically detect and set the optimal channel for wireless
operation based on signal strength and integrity. This is the default setting.

•

Standard - 20 MHz Channel - Specifies that the 802.11n radio will use only the standard
20 MHz channel. When this option is selected, the Standard Channel pulldown menu is
displayed.

SonicOS 5.8.1 Administrator Guide

477

Wireless > Settings

– Standard Channel - This pulldown menu only displays when the 20 MHz channel is

selected. By default, this is set to Auto, which allows the appliance to set the optimal
channel based on signal strength and integrity. Optionally, you can select a single
channel within the range of your regulatory domain. Selecting a specific a channel can
also help with avoiding interference with other wireless networks in the area.
•

Wide - 40 MHz Channel - Specifies that the 802.11n radio will use only the wide 40 MHz
channel. When this option is selected, the Primary Channel and Secondary Channel
pulldown menus are displayed:
– Primary Channel - By default this is set to Auto. Optionally, you can specify a specific

primary channel.
– Secondary Channel - The configuration of this pulldown menu is controlled by your

selection for the primary channel:
•

If the primary channel is set to Auto, the secondary channel is also set to Auto.

•

If the primary channel is set to a specific channel, the secondary channel is set to
to the optimum channel to avoid interference with the primary channel.

Enable Short Guard Interval: Specifies the short guard interval of 400ns (as opposed to the
standard guard interval of 800ns). The guard interval is a pause in transmission intended to
avoid data loss from interference or multipath delays.
Enable Aggregation: Enables 802.11n frame aggregation, which combines multiple frames to
reduce overhead and increase throughput.

Tip

The Enable Short Guard Interval and Enable aggregation options can slightly improve
throughput. They both function best in optimum network conditions where users have strong
signals with little interference. In networks that experience less than optimum conditions
(interference, weak signals, etc.), these options may introduce transmission errors that
eliminate any efficiency gains in throughput.

802.11b/g Wireless Settings
When the wireless radio is configured for 802.11b or 802.11g, the Channel pulldown menu is
displayed. An Auto setting allows the wireless security appliance to automatically detect and
set the optimal channel for wireless operation based upon signal strength and integrity. Auto is
the default channel setting, and it displays the selected channel of operation to the right.
Alternatively, an operating channel within the range of your regulatory domain can be explicitly
defined.

478

SonicOS 5.8.1 Administrator Guide

CHAPTER 36
Chapter 36:

Configuring Wireless Security

Wireless > Security
Note

When the SonicWALL wireless security appliance is configured in Access Point mode, this
page is called Security. When the appliance is configured in Wireless Bridge mode, this
page is called WEP Encryption.
Wired Equivalent Protocol (WEP) can be used to protect data as it is transmitted over the
wireless network, but it provides no protection past the SonicWALL. It is designed to provide a
minimal level of protection for transmitted data, and is not recommended for network
deployments requiring a high degree of security.
Wi-Fi Protected Access (WPA and WPA2) provides much greater security than WEP, but
requires a separate authentication protocol, such as RADIUS, be used to authenticate all users.
WPA uses a dynamic key that constantly changes, as opposed to the static key that WEP uses.
The SonicWALL security appliance provides a number of permutations of WEP and WPA
encryption.The following sections describe the available wireless security options:
•

“Authentication Overview” on page 479

•

“WPA/WPA2 Encryption Settings” on page 480

•

“WEP Encryption Settings” on page 482

Authentication Overview
Below is a list of available authentication types with descriptive features and uses for each:
WEP
•

Lower security

•

For use with older legacy devices, PDAs, wireless printers

WPA
•

Good security (uses TKIP)

•

For use with trusted corporate wireless clients

SonicOS 5.8.1 Administrator Guide

479

Wireless > Security

•

Transparent authentication with Windows log-in

•

No client software needed in most cases

WPA2
•

Best security (uses AES)

•

For use with trusted corporate wireless clients

•

Transparent authentication with Windows log-in

•

Client software install may be necessary in some cases

•

Supports 802.11i “Fast Roaming” feature

•

No backend authentication needed after first log-in (allows for faster roaming)

WPA2-AUTO
•

Tries to connect using WPA2 security.

•

If the client is not WPA2 capable, the connection will default to WPA.

WPA/WPA2 Encryption Settings
Both WPA and WPA2 support two protocols for storing and generating keys:
•

Pre-Shared Key (PSK): PSK allows WPA to generate keys from a pre-shared passphrase
that you configure. The keys are updated periodically based on time or number of packets.
Use PSK in smaller deployments where you do not have a RADIUS server.

•

Extensible Authentication Protocol (EAP): EAP allows WPA to synchronize keys with an
external RADIUS server. The keys are updated periodically based on time or number of
packets. Use EAP in larger, enterprise-like deployments where you have an existing
RADIUS framework.

WPA2 also supports EAP and PSK protocols, but adds an optional AUTO mode for each
protocol. WPA2 EAP AUTO and WPA2 PSK AUTO try to connect using WPA2 security, but will
default back to WPA if the client is not WPA2 capable.

Note

480

WPA support is only available in Access Point Mode. WPA support is not available in Bridge
Mode.

SonicOS 5.8.1 Administrator Guide

Wireless > Security

WPA2 and WPA PSK Settings
Encryption Mode: In the Authentication Type field, select either WPA-PSK, WPA2-PSK, or
WPA2-Auto-PSK.

WPA Settings
•

Cypher Type: select TKIP. Temporal Key Integrity Protocol (TKIP) is a protocol for
enforcing key integrity on a per-packet basis.

•

Group Key Update: Specifies when the SonicWALL security appliance updates the key.
Select By Timeout to generate a new group key after an interval specified in seconds.
Select By Packet to generate a new group key after a specific number of packets. Select
Disabled to use a static key.

•

Interval: If you selected By Timeout, enter the number of seconds before WPA
automatically generates a new group key.

Preshared Key Settings (PSK)
•

Passphrase: Enter the passphrase from which the key is generated.

Click Apply in the top right corner to apply your WPA settings.

SonicOS 5.8.1 Administrator Guide

481

Wireless > Security

WPA2 and WPA EAP Settings
Encryption Mode: In the Authentication Type field, select either WPA-EAP, WPA2-EAP, or
WPA2-AUTO-EAP.

WPA Settings
•

Cypher Type: Select TKIP. Temporal Key Integrity Protocol (TKIP) is a protocol for
enforcing key integrity on a per-packet basis.

•

Group Key Interval: Eenter the number of seconds before WPA automatically generates
a new group key.

Extensible Authentication Protocol Settings (EAP)
•

Radius Server 1 IP and Port: Enter the IP address and port number for your primary
RADIUS server.

•

Radius Server 1 Secret: Enter the password for access to Radius Server

•

Radius Server 2 IP and Port: Enter the IP address and port number for your secondary
RADIUS server, if you have one.

•

Radius Server 2 Secret: Enter the password for access to Radius Server

Click Apply in the top right corner to apply your WPA settings.

WEP Encryption Settings
The SonicWALL security appliance offers the following WEP encryption options:

482

•

WEP - Open system: In open-system authentication, the SonicWALL allows the wireless
client access without verifying its identity.

•

WEP -Shared key: Uses WEP and requires a shared key to be distributed to wireless
clients before authentication is allowed.

SonicOS 5.8.1 Administrator Guide

Wireless > Security

•

Both (Open System & Shared Key): The Default Key assignments are not important as
long as the identical keys are used in each field. If Shared Key is selected, then the key
assignment is important.

To configure wireless security on the SonicWALL, navigate to the Wireless > Security page
and perform the following tasks:
Step 1

Select the appropriate authentication type from the Authentication Type list.

Step 2

In the Default Key pulldown menu, select which key will be the default key.

Step 3

In the Key Entry menu, select if your keys will be Alphanumeric or Hexadecimnal.

WEP - 64-bit

WEP - 128-bit

Alphanumeric - 5 characters (0-9, A-Z)

Alphanumeric - 13 characters Alphanumeric - 16 characters

Hexadecimal - 10 characters (0-9, A-F) Hexadecimal - 26 characters

WEP - 152-bit

Hexadecimal - 32 characters

Step 4

You can enter up to four keys. For each key, select whether it will be 64-bit, 128-bit, or 152-bit.
The higher the bit number, the more secure the key is.

Step 5

Enter the keys.

Step 6

Click Apply.

SonicOS 5.8.1 Administrator Guide

483

Wireless > Security

484

SonicOS 5.8.1 Administrator Guide

CHAPTER 37
Chapter 37:

Configuring Advanced Wireless
Settings

Wireless > Advanced
To access Advanced configuration settings for the SonicWALL wireless security appliance, log
into the SonicWALL, click Wireless, and then Advanced. The Wireless > Advanced page is
only available when the SonicWALL is acting as an access point.

SonicOS 5.8.1 Administrator Guide

485

Wireless > Advanced

Beaconing & SSID Controls
1.

Select Hide SSID in Beacon. Suppresses broadcasting of the SSID name and disables
responses to probe requests. Checking this option helps prevent your wireless SSID from
being seen by unauthorized wireless clients.

2.

Type a value in milliseconds for the Beacon Interval. Decreasing the interval time makes
passive scanning more reliable and faster because Beacon frames announce the network
to the wireless connection more frequently.

Advanced Radio Settings
The following other advanced settings can be configured.

486

Step 1

Enable Short Slot Time: Select Enable Short Slot Time to increase performance if you only
expect 802.11g traffic. 802.11b is not compatible with short slot time.

Step 2

The Antenna Diversity setting determines which antenna the wireless security appliance uses
to send and receive data.

Step 3

Select Full Power from the Transmit Power menu to send the strongest signal on the WLAN.
For example, select Full Power if the signal is going from building-to-building. Half Power is
recommended for office-to-office within a building, and Quarter Power or Eighth Power are
recommended for shorter distance communications.

Step 4

Select Short or Long from the Preamble Length menu. Short is recommended for efficiency
and improved throughput on the wireless network.

Step 5

The Fragmentation Threshold (bytes) is 2346 by default. Increasing the value means that
frames are delivered with less overhead but a lost or damaged frame must be discarded and
retransmitted.

Step 6

The RTS Threshold (bytes) is 2346 by default. If network throughput is slow or a large number
of frame retransmissions is occurring, decrease the RTS threshold to enable RTS clearing.

Step 7

The default value for the DTIM Interval is 1. Increasing the DTIM Interval value allows you to
conserve power more effectively.

SonicOS 5.8.1 Administrator Guide

Wireless > Advanced

Step 8

The Association Timeout (seconds) is 300 seconds by default, and the allowed range is from
60 to 36000 seconds. If your network is very busy, you can increase the timeout by increasing
the number of seconds in the Association Timeout (seconds) field.

Step 9

Set the Maximum Client Associations to limit the number of stations that can connect
wirelessly at one time. The default is 128.

Step 10 Data Rate: Select the speed at which the data is transmitted and received. Best automatically

selects the best rate available in your area given interference and other factors. Or you can
manually select a data rate.
Step 11 Protection Mode: Protection can decrease collisions, particularly where you have two

overlapping SonicPoints. However, it can slow down performance. Auto is probably the best
setting, as it will engage only in the case of overlapping SonicPoints.
Step 12 Protection Rate: The protection rate determines the data rate when protection is on. The

slowest rate offers the greatest degree of protection but the slowest data transmission rate.
Choose 1 Mbps, 2 Mbps, 5 Mbps, or 11 Mbps.
Step 13 Protection Type: Select the type of handshake used to establish a wireless connection: CTS-

only or RTS-CTS. 802.11b traffic is only compatible with CTS.
Step 14 Click Apply in the top right corner of the page to apply your changes to the security appliance.

Click Restore Default to return the radio settings to the default settings.

Configurable Antenna Diversity
The dual antenna wireless SonicWALL security appliances employ two 5 dBi antennas running
in diversity mode. The default implementation of diversity mode means that one antenna acts
as a transmitting, and both antennas act as potential receiving antenna. As radio signals arrive
at both antennas on the secure wireless appliance, the strength and integrity of the signals are
evaluated, and the best received signal is used. The selection process between the two
antennas is constant during operation to always provide the best possible signal. To allow for
external (higher gain uni-directional) antennas to be used, antenna diversity can be disabled.
The SonicWALL NSA 220 and 250M wireless security appliances employ three antennas. The
Antenna Diversity is set to Best by default, this is the only setting available for these
appliances.
The Antenna Diversity setting determines which antenna the wireless security appliance uses
to send and receive data. You can select:
•

Best: This is the default setting. When Best is selected, the wireless security appliance
automatically selects the antenna with the strongest, clearest signal. In most cases, Best
is the optimal setting.

•

1: Select 1 to restrict the wireless security appliance to use antenna 1 only. Facing the rear
of the appliance, antenna 1 is on the left, closest to the console port. You can disconnect
antenna 2 when using only antenna 1.

•

2: Select 2 to restrict the wireless security appliance to use antenna 2 only. Facing the rear
of the appliance, antenna 2 is on the right, closest to the power supply. You can disconnect
antenna 1 when using only antenna 2.

SonicOS 5.8.1 Administrator Guide

487

Wireless > Advanced

488

SonicOS 5.8.1 Administrator Guide

CHAPTER 38
Chapter 38:

Configuring MAC Filter List

Wireless > MAC Filter List
Wireless networking provides native MAC filtering capabilities which prevents wireless clients
from authenticating and associating with the wireless security appliance. If you enforce MAC
filtering on the WLAN, wireless clients must provide you with the MAC address of their wireless
networking card.
To set up your MAC Filter List, log into the SonicWALL, and click Wireless, then MAC Filter
List.

Allow or Deny Specific Resources
The MAC Allow List contains groups of address objects for network resources that the security
appliance allows to connect via the WLAN, regardless of the selections in the deny list.
The MAC Deny List contains groups of address objects for network resources that the security
appliance denies to connect via the WLAN, regardless of the selections in the allow list.

SonicOS 5.8.1 Administrator Guide

489

Wireless > MAC Filter List

The items in the list are address object groups, defined groups of objects that represent specific
IP addresses or ranges of addresses that can be used throughout the management interface
to specify network resources. An address object group can contain other address object
groups.
The Allow List and Deny List are also address object groups.
You can create individual objects in the Wireless > Mac Filter List page:

490

Step 1

In the Allow List or Deny List box, select Create New MAC Address Object Group.

Step 2

In the Add Address Object Group field, enter a name for the new group

Step 3

In the left column, select the groups or individual address objects you want to allow or deny.
You can use Ctrl-click select more than one item.

Step 4

Click the > button to add the items to the group.

Step 5

Click OK to create the group and add it to the Allow List or Deny List.

SonicOS 5.8.1 Administrator Guide

CHAPTER 39
Chapter 39:

Configuring Wireless IDS

Wireless > IDS
Wireless Intrusion Detection Services (IDS) greatly increase the security capabilities of the
SonicWALL wireless security appliances by enabling them to recognize and even take
countermeasures against the most common types of illicit wireless activity. WIDS consists of
three types of services, namely, Sequence Number Analysis, Association Flood Detection, and
Rogue Access Point Detection. Wireless IDS logging and notification can be enabled under
Log > Categories by selecting the WLAN IDS checkbox under Log Categories and Alerts.

Access Point IDS
When the Radio Role of the wireless security appliance is set to Access Point mode, all three
types of WIDS services are available, but Rogue Access Point detection, by default, acts in a
passive mode (passively listening to other Access Point Beacon frames only on the selected
channel of operation). Selecting Scan Now momentarily changes the Radio Role to allow the
wireless security appliance to perform an active scan, and may cause a brief loss of

SonicOS 5.8.1 Administrator Guide

491

Wireless > IDS

connectivity for associated wireless clients. While in Access Point mode, the Scan Now
function should only be used if no clients are actively associated, or if the possibility of client
interruption is acceptable.

Intrusion Detection Settings
Rogue Access Points have emerged as one of the most serious and insidious threats to
wireless security. In general terms, an access point is considered rogue when it has not been
authorized for use on a network. The convenience, affordability and availability of non-secure
access points, and the ease with which they can be added to a network creates a easy
environment for introducing rogue access points. Specifically, the real threat emerges in a
number of different ways, including unintentional and unwitting connections to the rogue
device, transmission of sensitive data over non-secure channels, and unwanted access to LAN
resources. So while this doesn't represent a deficiency in the security of a specific wireless
device, it is a weakness to the overall security of wireless networks.
The security appliance can alleviate this weakness by recognizing rogue access points
potentially attempting to gain access to your network. It accomplishes this in two ways: active
scanning for access points on all 802.11a, 802.11g, and 802.11n channels, and passive
scanning (while in Access Point mode) for beaconing access points on a single channel of
operation.
Select the Enable Rogue Access Point Detection checkbox to specify the rogue access point
detection method. The Authorized Access Points menu allows you to specify All Authorized
Access Points, Create new MAC Address Object Group, or Select an Address Object
Group.
The Authorized Access Points menu allows you to specify which access points the
SonicWALL security appliance will considered authorized when it performs a scan. You can
select All Authorized Access Points to allow all SonicPoints, or you can select Create new
MAC Address Object Group to create an address object group containing a group of MAC
address to limit the list to only those SonicPoints whose MAC addresses are contained in the
address object group.
Select Create Address Object Group to add a new group of MAC address objects to the list.

492

SonicOS 5.8.1 Administrator Guide

Wireless > IDS

Discovered Access Points
The Discovered Access Points table displays information on every access point that can be
detected by all your SonicPoints or on a individual SonicPoint basis:
•

MAC Address (BSSID): The MAC address of the radio interface of the detected access
point.

•

SSID: The radio SSID of the access point.

•

Channel: The radio channel used by the access point.

•

Manufacturer: The manufacturer of the access point. SonicPoints will show a
manufacturer of either SonicWALL or Senao.

•

Signal Strength: The strength of the detected radio signal

•

Max Rate: The fastest allowable data rate for the access point radio, typically 54 Mbps.

•

Authorize: Click the icon
in the Authorize column to add the access point to the address
object group of authorized access points.

Scanning for Access Points
Active scanning occurs when the wireless security appliance starts up, and at any time Scan
Now is clicked at the bottom of the Discovered Access Points table. When the wireless
security appliance is operating in a Bridge Mode, the Scan Now feature does not cause any
interruption to the bridged connectivity. When the wireless security appliance is operating in
Access Point Mode, however, a temporary interruption of wireless clients occurs for no more
than a few seconds. This interruption manifests itself as follows:

Caution

•

Non-persistent, stateless protocols (such as HTTP) should not exhibit any ill-effects.

•

Persistent connections (protocols such as FTP) are impaired or severed.

The Scan Now feature causes a brief disruption in service. If this is a concern, wait and use
the Scan Now feature at a time when no clients are active, or the potential for disruption
becomes acceptable.

Authorizing Access Points on Your Network
Access Points detected by the wireless security appliance are regarded as rogues until they
are identified to the wireless security appliance as authorized for operation. To authorize an
access point, select it in the list of access points discovered by the wireless security appliance
scanning feature, and add it clicking the Authorize icon .

SonicOS 5.8.1 Administrator Guide

493

Wireless > IDS

494

SonicOS 5.8.1 Administrator Guide

CHAPTER 40
Chapter 40:

Configuring Virtual Access Points with
Internal Wireless Radio

Wireless > Virtual Access Point
This chapter describes the Virtual Access Point feature and includes the following sections:
•

“Wireless VAP Overview” section on page 495

•

“Wireless Virtual AP Configuration Task List” section on page 496

•

“VAP Sample Configuration” section on page 507

Wireless VAP Overview
This section provides an introduction to the Virtual Access Point feature for SonicWALL UTM
appliances equippped with internal wireless radios.
This section contains the following subsections:
•

“What Is a Virtual Access Point?” section on page 495

•

“Benefits of Using Virtual APs” section on page 496

What Is a Virtual Access Point?
A Virtual Access Point is a multiplexed instantiation of a single physical Access Point (AP) so
that it presents itself as multiple discrete Access Points. To wireless LAN clients, each Virtual
AP appears to be an independent physical AP, when in actuality there is only a single physical
AP. Before the evolution of the Virtual AP feature support, wireless networks were relegated to
a One-to-One relationship between physical Access Points and wireless network security
characteristics, such as authentication and encryption. In other words, an Access Point
providing WPA-PSK security could not simultaneously offer Open or WPA-EAP connectivity to
clients, and if the latter were required, they would had to have been provided by a separate,
distinctly configured Access Points. This forced WLAN network administrators to find a solution

SonicOS 5.8.1 Administrator Guide

495

Wireless > Virtual Access Point

to scale their existing wireless LAN infrastructure to provide differentiated levels of service.
With the Virtual APs (VAP) feature, multiple VAPs can exist within a single physical AP in
compliance with the IEEE 802.11 standard for the media access control (MAC) protocol layer
that includes a unique Basic Service Set Identifier (BSSID) and Service Set Identified (SSID).
This allows for segmenting wireless network services within a single radio frequency footprint
of a single physical access point device.
VAPs allow the network administrator to control wireless user access and security settings by
setting up multiple custom configurations on a single physical interface. Each of these custom
configurations acts as a separate (virtual) access point, and can be grouped and enforced on
a single internal wireless radio.
For more information on SonicOS Secure Wireless features, refer to the SonicWALL Secure
Wireless Integrated Solutions Guide.

Benefits of Using Virtual APs
This section includes a list of benefits in using the Virtual AP feature:
•

Radio Channel Conservation—Prevents building overlapped infrastructures by allowing
a single Physical Access Point to be used for multiple purposes to avoid channel collision
problem. Channel conservation. Multiple providers are becoming the norm within public
spaces such as airports. Within an airport, it might be necessary to support an FAA
network, one or more airline networks, and perhaps one or more Wireless ISPs. However,
in the US and Europe, 802.11b networks can only support three usable (non-overlapping)
channels, and in France and Japan only one channel is available. Once the channels are
utilized by existing APs, additional APs will interfere with each other and reduce
performance. By allowing a single network to be used for multiple purposes, Virtual APs
conserve channels.

•

Optimize Wireless LAN Infrastructure—Share the same Wireless LAN infrastructure
among multiple providers, rather than building an overlapping infrastructure, to lower down
the capital expenditure for installation and maintenance of your WLANs.

Wireless Virtual AP Configuration Task List
A Wireless VAP deployment requires several steps to configure. The following section provides
first a brief overview of the steps involved, and then a more in-depth examination of the parts
that make up a successful VAP deployment. This subsequent sections describe VAP
deployment requirements and provides an administrator configuration task list:

496

•

“Wireless VAP Overview” section on page 495

•

“Network Zones” section on page 498

•

“Wireless LAN Subnets” section on page 502

•

“DHCP Server Scope” section on page 503

•

“Deploying VAPs to the Wireless Radio” section on page 511

SonicOS 5.8.1 Administrator Guide

Wireless > Virtual Access Point

Wireless VAP Configuration Overview
The following are required areas of configuration for VAP deployment:
Step 1

Zone - The zone is the backbone of your VAP configuration. Each zone you create will have its
own security and access control settings and you can create and apply multiple zones to a
single physical interface by way of Wireless Subnets.

Step 2

Wireless Interface - The W0 interface (and its WLAN subnets) represent the physical
connections between your SonicWALL UTM appliance and the internal wireless radio.
Individual zone settings are applied to these interfaces and forwarded to the wireless radio.

Step 3

DHCP Server - The DHCP server assigns leased IP addresses to users within specified
ranges, known as “Scopes”. The default ranges for DHCP scopes are often excessive for the
needs of most wireless deployments, for instance, a scope of 200 addresses for an interface
that will only use 30. Because of this, DHCP ranges must be set carefully in order to ensure the
available lease scope is not exhausted.

Step 4

Virtual Access Point Profile - The VAP Profile feature allows for creation of wireless
configuration profiles which can be easily applied to new wireless Virtual Access Points as
needed.

Step 5

Virtual Access Point - The VAP Objects feature allows for setup of general VAP settings. SSID
and wireless subnet name are configured through VAP Settings.

Step 6

Virtual Access Point Group - The VAP Group feature allows for grouping of multiple VAP
objects to be simultaneously applied to a sinlge internal wireless radio.

Step 7

Assign VAP Group to Internal Wireless Radio- The VAP Group is applied to the internal
wireless radio and made available to users through multiple SSIDs.

Network Configuration
Zone

DHCP Scopes

Wireless Sub-Interface

VAP Configuration
VAP Authentication
VAP SSID

SonicOS 5.8.1 Administrator Guide

497

Wireless > Virtual Access Point

Network Zones
This section contains the following subsections:
•

“The Wireless Zone” section on page 498

•

“Custom Wireless Zone Settings” section on page 498

A network security zone is a logical method of grouping one or more interfaces with friendly,
user-configurable names, and applying security rules as traffic passes from one zone to
another zone. With the zone-based security, the administrator can group similar interfaces and
apply the same policies to them, instead of having to write the same policy for each interface.
Network zones are configured from the Network > Zones page.

For detailed information on configuring zones, see Chapter 18, Configuring Zones.

The Wireless Zone
The Wireless zone type, of which the “WLAN Zone” is the default instance, provides support to
SonicWALL wireless radio. When an interface or subinterface is assigned to a Wireless zone,
the interface can enforce security settings above the 802.11 layer, including WiFiSec
Enforcement, SSL VPN redirection, Guest Services, Lightweight Hotspot Messaging and all
licensed Deep Packet Inspection security services.

Custom Wireless Zone Settings
Although SonicWALL provides the pre-configured Wireless zone, administrators also have the
ability to create their own custom wireless zones. When using VAPs, several custom zones can
be applied to a single wireless radio. The following three sections describe settings for custom
wireless zones:

498

•

“General” section on page 499

•

“Wireless” section on page 500

•

“Guest Services” section on page 501

SonicOS 5.8.1 Administrator Guide

Wireless > Virtual Access Point

General

Feature

Description

Name

Create a name for your custom zone

Security Type

Select Wireless in order to enable and access wireless security
options.

Allow Interface Trust

Select this option to automatically create access rules to allow traffic
to flow between the interfaces of a zone. This will effectively allow
users on a wireless zone to communicate with each other. This option
is often disabled when setting up Guest Services.

SonicWALL Security
Services

Select the security services you wish to enforce on this zone. This
allows you to extend your SonicWALL UTM security services to your
wireless users.

SonicOS 5.8.1 Administrator Guide

499

Wireless > Virtual Access Point

Wireless

Feature

Description

Only allow traffic generated
by a SonicPoint

Restricts traffic on this zone to internally-generated traffic only.

SSL VPN Enforcement

Redirects all traffic entering the Wireless zone to a defined
SonicWALL SSL VPN appliance. This allows all wireless traffic
to be authenticated and encrypted by the SSL VPN, using, for
example, NetExtender to tunnel all traffic. Note: Wireless traffic
that is tunneled through an SSL VPN will appear to originate
from the SSL VPN rather than from the Wireless zone.
SSL VPN Server - Select the Address Object representing the
SSL VPN appliance to which you wish to redirect wireless
traffic.

500

SonicPoint Provisioning
Profile

Select a predefined SonicPoint Provisioning Profile to be
applied to all current and future SonicPoints on this zone.

SonicPointN Provisioning
Profile

Select a predefined SonicPointN Provisioning Profile to be
applied to all current and future SonicPoints on this zone.

SonicOS 5.8.1 Administrator Guide

Wireless > Virtual Access Point

Guest Services

The Enable Guest Services option allows the following guest services to be applied to a zone:

Feature

Description

Enable inter-guest
communication

Allows guests connecting to SonicPoints in this Wireless zone to
communicate directly and wirelessly with each other.

Bypass AV Check for
Guests

Allows guest traffic to bypass Anti-Virus protection

Enable Dynamic Address
Translation (DAT)

Dynamic Address Translation (DAT) allows the SonicPoint to
support any IP addressing scheme for Guest Services users.
If this option is disabled (unchecked), wireless guest users must
either have DHCP enabled, or an IP addressing scheme compatible
with the SonicPoint’s network settings.

Enable External Guest
Authentication

Requires guests connecting from the device or network you select
to authenticate before gaining access. This feature, based on
Lightweight Hotspot Messaging (LHM) is used for authenticating
Hotspot users and providing them parametrically bound network
access.

Custom Authentication
Page

Redirects users to a custom authentication page when they first
connect to a SonicPoint in the Wireless zone. Click Configure to set
up the custom authentication page. Enter either a URL to an
authentication page or a custom challenge statement in the text
field, and click OK.

Post Authentication Page

Directs users to the page you specify immediately after successful
authentication. Enter a URL for the post-authentication page in the
filed.

Bypass Guest
Authentication

Allows a SonicPoint running Guest Services to integrate into
environments already using some form of user-level authentication.
This feature automates the Guest Services authentication process,
allowing wireless users to reach Guest Services resources without
requiring authentication. This feature should only be used when
unrestricted Guest Services access is desired, or when another
device upstream of the SonicPoint is enforcing authentication.

Redirect SMTP traffic to

Redirects SMTP traffic incoming on this zone to an SMTP server
you specify. Select the address object to redirect traffic to.

Deny Networks

Blocks traffic from the networks you specify. Select the subnet,
address group, or IP address to block traffic from.

SonicOS 5.8.1 Administrator Guide

501

Wireless > Virtual Access Point

Feature

Description

Pass Networks

Automatically allows traffic through the Wireless zone from the
networks you select.

Max Guests

Specifies the maximum number of guest users allowed to connect
to the Wireless zone. The default is 10.

Wireless LAN Subnets
A Wireless LAN (WLAN) subnet allows you to split a single wireless radio interface (W0) into
many virtual network connections, each carrying its own set of configurations. The WLAN
subnet solution allows each VAP to have its own virtual separate subinterface, even though
there is only a single 802.11 radio.
WLAN subnets have several key capabilities and characteristics of a physical interface,
including zone assignability, security services, WAN assignability (static addressing only),
GroupVPN, DHCP server, IP Helper, routing, and full NAT policy and Access Rule controls.
Features excluded from WLAN subnets at this time are VPN policy binding, WAN dynamic
client support, and multicast support.
WLAN subnets are configured from the Network > Interfaces page.

Custom Wireless Subnet Settings
The table below lists configuration parameters and descriptions for wireless subnets:

502

Feature

Description

Zone

Select a pre-defined or custom zone. Only zones with security
type of “wireless” are available for selection.

Parent Interface

The default WLAN interface, normally W0.

Subnet Name

Choose a friendly name for this interface.

IP Configuration

Create an IP address and Subnet Mask in accordance with
your network configuration.

Sonic Point Limit

The number of radios supported in your deployment, the
default value is 1 SonicPoint.

Management

Select the protocols you wish to use when managing this
subnet.

SonicOS 5.8.1 Administrator Guide

Wireless > Virtual Access Point

Feature

Description

User Login

Select the protocols you will make available to clients who
access this subnet.

DHCP Server

Select the Create default DHCP Lease Scope option to enable
DHCP on this subnet, along with the default number of
available leases. Read the “DHCP Server Scope” section on
page 503 for more information on DHCP lease requirements.

DHCP Server Scope
The DHCP server assigns leased IP addresses to users within specified ranges, known as
“Scopes”. Take care in making these settings manually, as a scope of 200 addresses for
multiple interfaces that will only use 30 can lead to connection issues due to lease exhaustion.
The DHCP scope should be resized as each interface/subinterface is defined to ensure that
adequate DHCP space remains for all subsequently defined interfaces. Failure to do so may
cause the auto-creation of subsequent DHCP scopes to fail, requiring manual creation after
performing the requisite scope resizing. DHCP Server Scope is set from the Network > DHCP
Server page.

Virtual Access Point Profiles
A Virtual Access Point Profile allows the administrator to pre-configure and save access point
settings in a profile. VAP Profiles allows settings to be easily applied to new Virtual Access
Points. Virtual Access Point Profiles are configured from the Wireless > Virtual Access Point
page.
This feature is especially useful for quick setup in situations where multiple virtual access points
will share the same authenticaiton methods.

SonicOS 5.8.1 Administrator Guide

503

Wireless > Virtual Access Point

Virtual Access Point Profile Settings
The table below lists configuration parameters and descriptions for Virtual Access Point Profile
Settings:
Feature

Description

Name

Choose a friendly name for this VAP Profile. Choose something
descriptive and easy to remember as you will later apply this
profile to new VAPs.

Type

Set to Wireless-Internal-Radio by default. Retain this default
setting if using the internal radio for VAP access (currently the
only supported radio type)

Authentication Type

Below is a list available authentication types with descriptive
features and uses for each:
WPA
•

Good security (uses TKIP)

•

For use with trusted corporate wireless clients

•

Transparent authentication with Windows log-in

•

No client software needed in most cases

WPA2
•

Best security (uses AES)

•

For use with trusted corporate wireless clients

•

Transparent authentication with Windows log-in

•

Client software install may be necessary in some cases

•

Supports 802.11i “Fast Roaming” feature

•

No backend authentication needed after first log-in (allows
for faster roaming)

WPA2-AUTO
•

504

Tries to connect using WPA2 security, if the client is not
WPA2 capable, the connection will default to WPA.

Unicast Cipher

The unicast cipher will be automatically chosen based on the
authentication type.

Multicast Cipher

The multicast cipher will be automatically chosen based on the
authentication type.

Maximum Clients

Choose the maximum number of concurrent client connections
permissible for this virtual access point.

SonicOS 5.8.1 Administrator Guide

Wireless > Virtual Access Point

WPA-PSK / WPA2-PSK Encryption Settings
Pre-Shared Key (PSK) is available when using WPA or WPA2. This solution utilizes a shared
key.
Feature

Description

Pass Phrase

The shared passphrase users will enter when connecting with PSKbased authentication.

Group Key Interval

The time period for which a Group Key is valid. The default value is
86400 seconds. Setting to low of a value can cause connection issues.

WPA-EAP / WPA2-EAP Encryption Settings
Extensible Authentication Protocol (EAP) is available when using WPA or WPA2. This solution
utilizes an external 802.1x/EAP capable RADIUS server for key generation.
Feature

Description

RADIUS Server 1

The name/location of your RADIUS authentication server

RADIUS Server 1
Port

The port on which your RADIUS authentication server communicates
with clients and network devices.

RADIUS Server 1
Secret

The secret passcode for your RADIUS authentication server

RADIUS Server 2

The name/location of your backup RADIUS authentication server

RADIUS Server 2
Port

The port on which your backup RADIUS authentication server
communicates with clients and network devices.

RADIUS Server 2
Secret

The secret passcode for your backup RADIUS authentication server

Group Key Interval

The time period (in seconds) during which the WPA/WPA2 group key is
enforced to be updated.

Virtual Access Points
The VAP Settings feature allows for setup of general VAP settings. SSID and wireless subnet
name are configured through VAP Settings. Virtual Access Points are configured from the
Wireless > Virtual Access Point page.

SonicOS 5.8.1 Administrator Guide

505

Wireless > Virtual Access Point

General VAP Settings

Feature

Description

SSID

Create a friendly name for your VAP.

Subnet Name

Select a subnet name to associate this VAP with. Settings for this VAP
will be inherited from the subnet you select from this list.

Enable Virtual
Access Point

Enables this VAP.

Enable SSID
Suppress

Suppresses broadcasting of the SSID name and disables responses to
probe requests. Check this option if you do not wish for your SSID to be
seen by
unauthorized wireless clients.

Advanced VAP Settings
Advanced settings allows the administrator to configure authentication and encryption settings
for this connection. Choose a Profile Name to inherit these settings from a user created profile.
See “Virtual Access Point Profiles” section on page 503 for complete authentication and
encryption configuration information.

Virtual Access Point Groups
The Virtual Access Point Groups feature is available on SonicWALL NSA appliances. It allows
for grouping of multiple VAP objects to be simultaneously applied to your internal wireless
radio. Virtual Access Point Groups are configured from the Wireless > Virtual Access Point
page.

506

SonicOS 5.8.1 Administrator Guide

Wireless > Virtual Access Point

Enabling the Virtual Access Point Group
After your VAPs are configured and added to a VAP group, that group must be specified in the
Wireless > Settings page in order for the VAPs to be available through your internal wireless
radio. The default group is called Internal AP Group.

After this selection has been made and applied.

VAP Sample Configuration
This section provides configuration examples based on real-world wireless needs. This section
contains the following subsections:
•

“Configuring a VAP for School Faculty Access” section on page 507

Configuring a VAP for School Faculty Access
You can use a VAP for a set of users who are commonly in the office, on campius, and to whom
should be given full access to all network resources, providing that the connection is
authenticated and secure. These users would already belong to the network’s Directory
Service, Microsoft Active Directory, which provides an EAP interface through IAS – Internet
Authentication Services. This section contains the following subsection:
•

“Configuring a Zone” section on page 507

•

“Creating a New Wireless Subnet” section on page 509

•

“Creating the Wireless VAP” section on page 510

Configuring a Zone
In this section you will create and configure a new corporate wireless zone with SonicWALL
UTM security services and enhanced WiFiSec/WPA2 wireless security.
Step 1

Log into the management interface of your SonicWALL UTM appliance.

Step 2

In the left-hand menu, navigate to the Network > Zones page.

Step 3

Click the Add... button to add a new zone.

SonicOS 5.8.1 Administrator Guide

507

Wireless > Virtual Access Point

General Settings Tab
Step 1

In the General tab, enter a friendly name such as “WLAN_Faculty” in the Name field.

Step 2

Select Wireless from the Security Type drop-down menu.

Step 3

Select the Allow Interface Trust checkbox to allow communication between faculty users.

Step 4

Select checkboxes for all of the security services you would normally apply to faculty on the
wired LAN.

Wireless Settings Tab

508

Step 1

In the Wireless tab, check the Only allow traffic generated by a SonicPoint / SonicPointN
checkbox.

Step 2

Select a provisioning profile from the SonicPoint Provisioning Profile drop-down menu (if
applicable).

Step 3

Click the OK button to save these changes.

SonicOS 5.8.1 Administrator Guide

Wireless > Virtual Access Point

Your new zone now appears at the bottom of the Network > Zones page, although you may
notice it is not yet linked to a Member Interface. This is your next step.

Creating a New Wireless Subnet
In this section you will create and configure a new wireless subnet on your current WLAN. This
wireless subnet will be linked to the zone you created in the “Configuring a Zone” section on
page 507.
Step 1

In the Network > Interfaces page, click the Add WLAN Subnet button.

Step 2

In the Zone drop-down menu, select the zone you created in “Configuring a Zone, page 507”.
In this case, we have chosen WLAN_Faculty.

Step 3

Enter a Subnet Name for this interface. This name allows the internal wireless radio to identify
which traffic belongs to the “WLAN_Faculty” subnet. In this case, we choose Faculty as our
subnet name.

Step 4

Enter the desired IP Address for this subinterface.

Step 5

Optionally, you may add a comment about this subinterface in the Comment field.

Step 6

If you intend to use this interface, ensure that the Create default DHCP Lease Scope option
is checked. This option automatically creates a new DHCP lease scope for this subnet with 33
addresses. This setting can be adjusted later on the Network > DHCP page.

Step 7

Click the OK button to add this subinterface.
Your WLAN Subnet interface now appears in the Interface Settings list.

Creating a Wireless VAP Profile
In this section, you will create and configure a new Virtual Access Point Profile. You can create
VAP Profiles for each type of VAP, and use them to easily apply advanced settings to new
VAPs. This section is optional, but will facilitate greater ease of use when configuring multiple
VAPs.
Step 1

In the left-hand menu, navigate to the Wireless > Virtual Access Point page.

Step 2

Click the Add... button in the Virtual Access Point Profiles section.

Step 3

Enter a Profile Name such as “Corporate-WPA2” for this VAP Profile.

Step 4

Select WPA2-AUTO-EAP from the Authentication Type drop-down menu. This will employ an
automatic user authentication based on your current RADIUS server settings (Set below).

Step 5

In the Maximum Clients field, enter the maximum number of concurrent connections VAP will
support.

Step 6

In the WPA-EAP Encryption Settings section, enter your current RADIUS server information.
This information will be used to support authenticated login to the new subnet.

Step 7

Click the OK button to create this VAP Profile.

SonicOS 5.8.1 Administrator Guide

509

Wireless > Virtual Access Point

Creating the Wireless VAP
In this section, you will create and configure a new Virtual Access Point and associate it with
the wireless subnet you created in “Creating a New Wireless Subnet” section on page 509.
General Tab
Step 1

In the left-hand menu, navigate to the Wireless > Virtual Access Point page.

Step 2

Click the Add... button in the Virtual Access Points section.

Step 3

Enter a default name (SSID) for the VAP. In this case we chose Campus_Faculty. This is the
name users will see when choosing a wireless network to connect with.

Step 4

Select the Subnet Name you created in “Creating a New Wireless Subnet” section on page 509
from the drop-down list. In this case we chose Faculty, the name of our WLAN_Faculty subnet.

Step 5

Check the Enable Virtual Access Point checkbox to enable this access point upon creation.

Step 6

Check the Enable SSID Suppress checkbox to hide this SSID from users.

Step 7

Click the OK button to add this VAP.
Your new VAP now appears in the Virtual Access Points list.

Advanced Tab (Authentication Settings)
Step 1

Click the Advanced Tab to edit encryption settings. If you created a VAP Profile in the previous
section, select that profile from the Profile Name list. We created and choose a “CorporateWPA2” profile, which uses WPA2-AUTO-EAP as the authentication method. If you have not set
up a VAP Profile, continue with steps 2 through 4. Otherwise, continue to Create More / Deploy
Current VAPs, page 510.

Step 2

In the Advanced tab, select WPA2-AUTO-EAP from the Authentication Type drop-down
menu. This will employ an automatic user authentication based on your current RADIUS server
settings (Set below).

Step 3

In the Maximum Clients field, enter the maximum number of concurrent connections VAP will
support.

Step 4

In the WPA-EAP Encryption Settings section, enter your current RADIUS server information.
This information will be used to support authenticated login to the wireless subnet.
Create More / Deploy Current VAPs

Now that you have successfully set up a wireless subnet for faculty access, you can choose to
add more custom VAPs, or to deploy this configuration to your internal wireless radio in the
“Deploying VAPs to the Wireless Radio” section on page 511.

Tip

510

Remember that more VAPs can always be added at a later time. New VAPs can then be
deployed simultaneously by following the steps in the “Deploying VAPs to the Wireless
Radio” section on page 511.

SonicOS 5.8.1 Administrator Guide

Wireless > Virtual Access Point

Deploying VAPs to the Wireless Radio
In the following section you will group and deploy your new VAPs, associating them with the
internal wireless radio. Users will not be able to access your VAPs until you complete this
process:
•

Grouping Multiple VAPs, page 511

•

Associating a VAP Group with your Wireless Radio, page 511

Grouping Multiple VAPs
In this section, you will group multiple VAPs into a single group to be associated with your
SoncPoint(s).
Step 1

In the left-hand menu, navigate to the Wirelesst > Virtual Access Point page.

Step 2

Click the Add Group... button in the Virtual Access Point Group section.

Step 3

Enter a Virtual AP Group Name.

Step 4

Select the desired VAPs from the list and click the -> button to add them to the group.
Optionally, click the Add All button to add all VAPs to a single group.

Step 5

Press the OK button to save changes and create the group.

Step 6

To setup 802.11g WEP or 802.11a WEP/WPA encryption, or to enable MAC address filtering,
use the 802.11g and 802.11a tabs. If any of your VAPs use encryption, you must configure
these settings before your wireless VAPs will function.

Step 7

Click the OK button to save changes and create this Wireless Provisioning Profile.

Associating a VAP Group with your Wireless Radio
After your VAPs are configured and added to a VAP group, that group must be specified in the
Wireless > Settings page in order for the VAPs to be available through your internal wireless
radio.
Step 1

In the left-hand menu, navigate to the Wireless > Settings page.

Step 2

In the Wireless Virtual Access Point section, select the VAP group you created in Grouping
Multiple VAPs, page 511 from the Virtual Access Point Group drop-down list. In this case, we
choose the default Internal AP Group as our Virtual AP Group.

Step 3

Click the Accept button to continue and associate this VAP group with your internal wireless
radio.

Note

If you are setting up guest services for the first time, be sure to make necessary
configurations in the Users > Guest Services pages.

SonicOS 5.8.1 Administrator Guide

511

Wireless > Virtual Access Point

512

SonicOS 5.8.1 Administrator Guide

PART 7
Part 7:

SonicOS 5.8.1 Administrator Guide

SonicPoint

513

514

SONICOS 5.8.1 ADMINISTRATOR GUIDE

CHAPTER 41
Chapter 41:

Managing SonicPoints

SonicPoint > SonicPoints
SonicWALL SonicPoints are wireless access points specially engineered to work with
SonicWALL security appliances to provide wireless access throughout your enterprise. The
SonicPoint section of the Management Interface lets you manage the SonicPoints connected
to your system.

In addition to describing the settings available for managing SonicPoints in SonicOS Enhanced,
this chapter contains a best practices guide for deploying SonicPoints in your network.
See “SonicPoint Deployment Best Practices” on page 529.

SonicOS 5.8.1 Administrator Guide

515

SonicPoint > SonicPoints

Before Managing SonicPoints
Before you can manage SonicPoints in the Management Interface, you must first:
•

Verify that the SonicPoint image is downloaded to your SonicWALL security appliance. See
“Updating SonicPoint Firmware” on page 527.

•

Configure your SonicPoint Provisioning Profiles.

•

Configure a Wireless zone.

•

Assign profiles to wireless zones. This step is optional. If you do not assign a default profile
for a zone, SonicPoints in that zone will use the first profile in the list.

•

Assign an interface to the Wireless zone.

•

Attach the SonicPoints to the interfaces in the Wireless zone.

•

Test the SonicPoints.

SonicPoint Provisioning Profiles
SonicPoint Provisioning Profiles provide a scalable and highly automated method of
configuring and provisioning multiple SonicPoints across a Distributed Wireless Architecture.
SonicPoint Profile definitions include all of the settings that can be configured on a SonicPoint,
such as radio settings for the 2.4GHz and 5GHz radios, SSID’s, and channels of operation.
Once you have defined a SonicPoint profile, you can apply it to a Wireless zone. Each Wireless
zone can be configured with one SonicPoint profile. Any profile can apply to any number of
zones. Then, when a SonicPoint is connected to a zone, it is automatically provisioned with the
profile assigned to that zone.
SonicOS includes a default SonicPointN profile, named SonicPointN. You can modify this
profile or create a new one.

The default SonicPointN profile has the following settings:
802.11a Radio

802.11g Radio

802.11n Radio

Enable 802.11a
Radio

Yes - Always
on

Enable 802.11g
Radio

Yes - Always on

Enable 802.11n
Radio

Yes - Always on

SSID

sonicwall

SSID

sonicwall

SSID

sonicwall-D790
(where D790 is an
example; this is
determined by the
hardware address)

Radio Mode

54Mbps 802.11a

Radio Mode

2.4 GHz 54Mbps - Radio Mode
802.11g

2.4 GHz - 802.11n/
g/b Mixed

Channel

AutoChannel

Channel

AutoChannel

AutoChannel

516

SonicOS 5.8.1 Administrator Guide

Channel

SonicPoint > SonicPoints

ACL Enforcement Disabled

ACL Enforcement Disabled

ACL Enforcement Disabled

Authentication
Type

WEP - Both
Authentication
Open System Type
& Shared Key

WEP - Both
Open System &
Shared Key

Authentication
Type

WEP - Both
Open System &
Shared Key

Schedule IDS
Scan

Disabled

Schedule IDS
Scan

Disabled

Schedule IDS
Scan

Disabled

Data Rate

Best

Data Rate

Best

Data Rate

Best

Antenna Diversity Best

Antenna Diversity Best

Antenna Diversity Best

Configuring a SonicPoint Profile
The SonicPoint profile configuration process for 802.11n slightly different than for 802.11a or
802.11g. The following sections describe how to configure SonicPoint profiles:
•

“Configuring a SonicPointN Profile for 802.11n” on page 517

•

“Configuring a SonicPoint Profile for 802.11a or 802.11g” on page 522

Configuring a SonicPointN Profile for 802.11n
You can add any number of SonicPoint profiles. To configure a SonicPoint provisioning profile:
Step 1

To add a new profile click Add SonicPointN below the list of SonicPoint 802.11n provisioning
profiles. To edit an existing profile, select the profile and click the Configure icon in the same
line as the profile you are editing.

Step 2

In the Settings tab of the Add Profile window, specify:

– Enable SonicPoint: Check this to automatically enable each SonicPoint when it is

provisioned with this profile.
– Retain Settings: Check this to have the SonicPointNs provisioned by this profile retain

these settings until the appliance is rebooted.
– Name Prefix: Enter a prefix for the names of all SonicPointNs connected to this zone.

When each SonicPointN is provisioned it is given a name that consists of the name
prefix and a unique number, for example: “SonicPoint 126008.”
– Country Code: Select the country where you are operating the SonicPointNs. The

country code determines which regulatory domain the radio operation falls under.

SonicOS 5.8.1 Administrator Guide

517

SonicPoint > SonicPoints

– 802.11n Virtual AP Group: (optional; on SonicWALL NSA only) Select a Virtual Access

Point (VAP) group to assign these SonicPointNs to a VAP. This pulldown menu allows
you to create a new VAP group. For more information on VAPs, see “SonicPoint >
Virtual Access Point” on page 547.
Step 3

In the 802.11n tab, configure the radio settings for the 802.11n radio:

– Enable Radio: Check this to automatically enable the 802.11n radio bands on all

SonicPoints provisioned with this profile.
– Radio Mode: Select your preferred radio mode from the Radio Mode menu. The

wireless security appliance supports the following modes:

Tip

518

•

2.4GHz 802.11n Only - Allows only 802.11n clients access to your wireless
network. 802.11a/b/g clients are unable to connect under this restricted radio
mode.

•

2.4GHz 802.11n/g/b Mixed - Supports 802.11b, 802.11g, and 802.11n clients
simultaneously. If your wireless network comprises multiple types of clients, select
this mode.

For optimal throughput speed solely for 802.11n clients, SonicWALL recommends the
802.11n Only radio mode. Use the 802.11n/b/g Mixed radio mode for multiple wireless
client authentication compatibility.
•

2.4GHz 802.11g Only - If your wireless network consists only of 802.11g clients,
you may select this mode for increased 802.11g performance. You may also select
this mode if you wish to prevent 802.11b clients from associating.

•

5 GHz 802.11n Only - Allows only 802.11n clients access to your wireless network.
802.11a/b/g clients are unable to connect under this restricted radio mode.

•

5 GHz 802.11n/a Mixed - Supports 802.11n and 802.11a clients simultaneously. If
your wireless network comprises both types of clients, select this mode.

SonicOS 5.8.1 Administrator Guide

SonicPoint > SonicPoints

•

5 GHz 802.11a Only - Select this mode if only 802.11a clients access your wireless
network.

– SSID: Enter a recognizable string for the SSID of each SonicPoint using this profile.

This is the name that will appear in clients’ lists of available wireless connections.

Note

If all SonicPoints in your organization share the same SSID, it is easier for users to maintain
their wireless connection when roaming from one SonicPoint to another.
When the wireless radio is configured for a mode that supports 802.11n, the following options
are displayed:
Radio Band (802.11n only): Sets the band for the 802.11n radio:
•

Auto - Allows the appliance to automatically detect and set the optimal channel for wireless
operation based on signal strength and integrity. This is the default setting.

•

Standard - 20 MHz Channel - Specifies that the 802.11n radio will use only the standard
20 MHz channel. When this option is selected, the Standard Channel pulldown menu is
displayed.
– Standard Channel - This pulldown menu only displays when the 20 MHz channel is

selected. By default, this is set to Auto, which allows the appliance to set the optimal
channel based on signal strength and integrity. Optionally, you can select a single
channel within the range of your regulatory domain. Selecting a specific a channel can
also help with avoiding interference with other wireless networks in the area.
•

Wide - 40 MHz Channel - Specifies that the 802.11n radio will use only the wide 40 MHz
channel. When this option is selected, the Primary Channel and Secondary Channel
pulldown menus are displayed:
– Primary Channel - By default this is set to Auto. Optionally, you can specify a specific

primary channel.
– Secondary Channel - The configuration of this pulldown menu is controlled by your

selection for the primary channel:
•

If the primary channel is set to Auto, the secondary channel is also set to Auto.

•

If the primary channel is set to a specific channel, the secondary channel is set to
to the optimum channel to avoid interference with the primary channel.

Enable Short Guard Interval: Specifies the short guard interval of 400ns (as opposed to the
standard guard interval of 800ns). The guard interval is a pause in transmission intended to
avoid data loss from interference or multipath delays.
Enable Aggregation: Enables 802.11n frame aggregation, which combines multiple frames to
reduce overhead and increase throughput.

Tip

The Enable Short Guard Interval and Enable aggregation options can slightly improve
throughput. They both function best in optimum network conditions where users have strong
signals with little interference. In networks that experience less than optimum conditions
(interference, weak signals, etc.), these options may introduce transmission errors that
eliminate any efficiency gains in throughput.
ACL Enforcement: Select this to enforce Access Control by allowing or denying traffic from
specific devices. Select a MAC address group from the Allow List to automatically allow traffic
from all devices with MAC address in the group. Select a MAC address group from the Deny
List to automatically deny traffic from all devices with MAC address in the group. The deny list
is enforced before the Allow list.

SonicOS 5.8.1 Administrator Guide

519

SonicPoint > SonicPoints

Step 4

In the Wireless Security section of the 802.11n Radio tab, configure the following settings:
– Authentication Type: Select the method of authentication for your wireless network.

You can select WEP - Both (Open System & Shared Key), WEP - Open System,
WEP - Shared Key, WPA - PSK, WPA - EAP, WPA2-PSK, WPA2-EAP, WPA2-AUTOPSK, and WPA2-AUTO-EAP.
WEP Configuration
– WEP Key Mode: Select the size of the encryption key.
– Default Key: Select which key in the list below is the default key, which will be tried first

when trying to authenticate a user.
– Key Entry: Select whether the key is alphanumeric or hexadecimal.
– Key 1 - Key 4: Enter the encryptions keys for WEP encryption. Enter the most likely to

be used in the field you selected as the default key.
WPA or WPA2 Configuration:
– Cipher Type: The cipher that encrypts your wireless data. Choose either TKIP (older,

more compatable), AES (newer, more secure), or Both (backward compatable).
– Group Key Interval: The time period for which a Group Key is valid. The default value

is 86400 seconds. Setting to low of a value can cause connection issues.
– Passphrase (PSK only): This is the passphrase your network users must enter to gain

network access.
– RADIUS Server Settings (EAP Only): Configure settings for your RADIUS

authentication server.
Step 5

In the Advanced tab, configure the performance settings for the 802.11n radio. For most
802.11n advanced options, the default settings give optimum performance.

– Hide SSID in Beacon: Check this option to have the SSID broadcast as part of the

wireless beacon, rather than as a separate broadcast.

520

SonicOS 5.8.1 Administrator Guide

SonicPoint > SonicPoints

– Schedule IDS Scan: Select a time when there are fewer demands on the wireless

network to schedule an Intrusion Detection Service (IDS) scan to minimize the
inconvenience of dropped wireless connections.
– Data Rate: Select the speed at which the data is transmitted and received. Best

automatically selects the best rate available in your area given interference and other
factors. Or you can manually select a data rate.
– Transmit Power: Select the transmission power. Transmission power effects the range

of the SonicPoint. You can select: Full Power, Half (-3 dB), Quarter (-6 dB), Eighth
(-9 dB), or Minimum.
– Antenna Diversity: The Antenna Diversity setting determines which antenna the

SonicPoint uses to send and receive data. When Best is selected, the SonicPoint
automatically selects the antenna with the strongest, clearest signal.
– Beacon Interval (milliseconds): Enter the number of milliseconds between sending

out a wireless beacon.
– DTIM Interval: Enter the interval in milliseconds.
– Fragmentation Threshold (bytes): Enter the number of bytes of fragmented data you

want the network to allow.
– RTS Threshold (bytes): Enter the number of bytes.
– Maximum Client Associations: Enter the maximum number of clients you want the

SonicPoint to support on this radio at one time.
– Preamble Length: Select the length of the preamble--the initial wireless

communication send when associating with a wireless host. You can select Long or
Short.
– Protection Mode: Select the CTS or RTS protection. Select None, Always, or Auto.

None is the default.
– Protection Rate: Select the speed for the CTS or RTS protection, 1 Mbps, 2 Mbps, 5

Mbps, or 11 Mbps.
– Protection Type: Select the type of protection, CTS-only or RTS-CTS.
– Enable Short Slot Time: Allow clients to disassociate and reassociate more quickly.
– Allow Only 802.11g Clients to Connect: Use this if you are using Turbo G mode and

therefore are not allowing 802.11b clients to connect.
When a SonicPoint unit is first connected and powered up, it will have a factory default
configuration (IP address 192.168.1.20, username: admin, password: password). Upon
initializing, it will attempt to find a SonicOS device with which to peer. If it is unable to find a
peer SonicOS device, it will enter into a stand-alone mode of operation with a separate standalone configuration allowing it to operate as a standard Access Point.
If the SonicPoint does locate, or is located by a peer SonicOS device, via the SonicWALL
Discovery Protocol, an encrypted exchange between the two units will ensue wherein the
profile assigned to the relevant Wireless zone will be used to automatically configure
(provision) the newly added SonicPoint unit.
As part of the provisioning process, SonicOS will assign the discovered SonicPoint device a
unique name, and it will record its MAC address and the interface and zone on which it was
discovered. It can also automatically assign the SonicPoint an IP address, if so configured, so
that the SonicPoint can communicate with an authentication server for WPA-EAP support.
SonicOS will then use the profile associated with the relevant zone to configure the 2.4GHz and
5GHz radio settings.

SonicOS 5.8.1 Administrator Guide

521

SonicPoint > SonicPoints

Modifications to profiles will not affect units that have already been provisioned and are in an
operational state. Configuration changes to operational SonicPoint devices can occur in two
ways:
•

Via manual configuration changes – Appropriate when a single, or a small set of changes
are to be affected, particularly when that individual SonicPoint requires settings that are
different from the profile assigned to its zone.

Via un-provisioning – Deleting a SonicPoint unit effectively un-provisions the unit, or clears its
configuration and places it into a state where it will automatically engage the provisioning
process anew with its peer SonicOS device. This technique is useful when the profile for a zone
is updated or changed, and the change is set for propagation. It can be used to update firmware
on SonicPoints, or to simply and automatically update multiple SonicPoint units in a controlled
fashion, rather than changing all peered SonicPoints at once, which can cause service
disruptions.

Configuring a SonicPoint Profile for 802.11a or 802.11g
You can add any number of SonicPoint profiles. To configure a SonicPoint provisioning profile:
Step 1

To add a new profile click Add below the list of SonicPoint provisioning profiles. To edit an
existing profile, select the profile and click the edit icon
in the same line as the profile you
are editing.

Step 2

In the General tab of the Add Profile window, specify:

– Enable SonicPoint: Check this to automatically enable each SonicPoint when it is

provisioned with this profile.
– Retain Settings: Check this to have the SonicPoints provisioned by this profile retain

these settings until the appliance is rebooted.
– Enable RF Monitoring: Check this to enable RF monitoring on the SonicPoints.
– Name Prefix: Enter a prefix for the names of all SonicPoints connected to this zone.

When each SonicPoint is provisioned it is given a name that consists of the name prefix
and a unique number, for example: “SonicPoint 126008.”
– Country Code: Select the country where you are operating the SonicPoints. The

country code determines which regulatory domain the radio operation falls under.

522

SonicOS 5.8.1 Administrator Guide

SonicPoint > SonicPoints

– 802.11g Virtual AP Group and 802.11a Virtual AP Group: (optional; on SonicWALL

NSA only) Select a Virtual Access Point (VAP) group to assign these SonicPoints to a
VAP. This pulldown menu allows you to create a new VAP group. For more information
on VAPs, see “SonicPoint > Virtual Access Point” on page 547.
Step 3

In the 802.11g tab, Configure the radio settings for the 802.11g (2.4GHz band) radio:

– Enable 802.11g Radio: Check this to automatically enable the 802.11g radio bands on

all SonicPoints provisioned with this profile.
– SSID: Enter a recognizable string for the SSID of each SonicPoint using this profile.

This is the name that will appear in clients’ lists of available wireless connections.

Note

If all SonicPoints in your organization share the same SSID, it is easier for users to maintain
their wireless connection when roaming from one SonicPoint to another.
– Radio Mode: Select the speed of the wireless connection. You can choose 11Mbps -

802.11b, 54 Mbps - 802.11g, or 108 Mbps - Turbo G mode. If you choose Turbo mode,
all users in your company must use wireless access cards that support turbo mode.
– Channel: Select the channel the radio will operate on. The default is AutoChannel,

which automatically selects the channel with the least interference. Use AutoChannel
unless you have a specific reason to use or avoid specific channels.
– ACL Enforcement: Select this to enforce Access Control by allowing or denying traffic

from specific devices. Select a MAC address group from the Allow List to automatically
allow traffic from all devices with MAC address in the group. Select a MAC address
group from the Deny List to automatically deny traffic from all devices with MAC
address in the group. The deny list is enforced before the Allow list.
– Authentication Type: Select the method of authentication for your wireless network.

You can select WEP - Both (Open System & Shared Key), WEP - Open System,
WEP - Shared Key, WPA - PSK, WPA - EAP, WPA2-PSK, WPA2-EAP, WPA2-AUTOPSK, and WPA2-AUTO-EAP.

SonicOS 5.8.1 Administrator Guide

523

SonicPoint > SonicPoints

– WEP Key Mode: Select the size of the encryption key.
– Default Key: Select which key in the list below is the default key, which will be tried first

when trying to authenticate a user.
– Key Entry: Select whether the key is alphanumeric or hexadecimal.
– Key 1 - Key 4: Enter the encryptions keys for WEP encryption. Enter the most likely to

be used in the field you selected as the default key.
Step 4

In the 802.11g Advanced tab, configure the performance settings for the 802.11g radio. For
most 802.11g advanced options, the default settings give optimum performance.

– Hide SSID in Beacon: Check this option to have the SSID broadcast as part of the

wireless beacon, rather than as a separate broadcast.
– Schedule IDS Scan: Select a time when there are fewer demands on the wireless

network to schedule an Intrusion Detection Service (IDS) scan to minimize the
inconvenience of dropped wireless connections.
– Data Rate: Select the speed at which the data is transmitted and received. Best

automatically selects the best rate available in your area given interference and other
factors. Or you can manually select a data rate.
– Transmit Power: Select the transmission power. Transmission power effects the range

of the SonicPoint. You can select: Full Power, Half (-3 dB), Quarter (-6 dB), Eighth
(-9 dB), or Minimum.
– Antenna Diversity: The Antenna Diversity setting determines which antenna the

SonicPoint uses to send and receive data. You can select:
•

524

Best: This is the default setting. When Best is selected, the SonicPoint
automatically selects the antenna with the strongest, clearest signal. In most cases,
Best is the optimal setting.

SonicOS 5.8.1 Administrator Guide

SonicPoint > SonicPoints

The SonicPoint-N wireless security appliance employs three antennas. The
Antenna Diversity is set to Best by default, this is the only setting available for this
appliance.
•

1: Select 1 to restrict the SonicPoint to use antenna 1 only. Facing the rear of the
SonicPoint, antenna 1 is on the left, closest to the power supply.

•

2: Select 2 to restrict the SonicPoint to use antenna 2 only. Facing the rear of the
SonicPoint, antenna 2 is on the right, closest to the console port.

– Beacon Interval (milliseconds): Enter the number of milliseconds between sending

out a wireless beacon.
– DTIM Interval: Enter the interval in milliseconds.
– Fragmentation Threshold (bytes): Enter the number of bytes of fragmented data you

want the network to allow.
– RTS Threshold (bytes): Enter the number of bytes.
– Maximum Client Associations: Enter the maximum number of clients you want the

SonicPoint to support on this radio at one time.
– Preamble Length: Select the length of the preamble--the initial wireless

communication send when associating with a wireless host. You can select Long or
Short.
– Protection Mode: Select the CTS or RTS protection. Select None, Always, or Auto.

None is the default.
– Protection Rate: Select the speed for the CTS or RTS protection, 1 Mbps, 2 Mbps, 5

Mbps, or 11 Mbps.
– Protection Type: Select the type of protection, CTS-only or RTS-CTS.
– CCK OFDM Power Delta: Select the difference in radio transmit power you will allow

between the 802.11b and 802.11g modes: 0 dBm, 1 dBm, or 2 dBm.
– Enable Short Slot Time: Allow clients to disassociate and reassociate more quickly.
– Allow Only 802.11g Clients to Connect: Use this if you are using Turbo G mode and

therefore are not allowing 802.11b clients to connect.
Step 5

Configure the settings in the 802.11a Radio and 802.11a Advanced tabs. These settings affect
the operation of the 802.11a radio bands. The SonicPoint has two separate radios built in.
Therefore, it can send and receive on both the 802.11a and 802.11g bands at the same time.
The settings in the 802.11a Radio and 802.11a Advanced tabs are similar to the settings in
the 802.11g Radio and 802.11g Advanced tabs. Follow the instructions in step 3 and step 4
in this procedure to configure the 802.11a radio.
When a SonicPoint unit is first connected and powered up, it will have a factory default
configuration (IP address 192.168.1.20, username: admin, password: password). Upon
initializing, it will attempt to find a SonicOS device with which to peer. If it is unable to find a
peer SonicOS device, it will enter into a stand-alone mode of operation with a separate standalone configuration allowing it to operate as a standard Access Point.

SonicOS 5.8.1 Administrator Guide

525

SonicPoint > SonicPoints

If the SonicPoint does locate, or is located by a peer SonicOS device, via the SonicWALL
Discovery Protocol, an encrypted exchange between the two units will ensue wherein the
profile assigned to the relevant Wireless zone will be used to automatically configure
(provision) the newly added SonicPoint unit.

As part of the provisioning process, SonicOS will assign the discovered SonicPoint device a
unique name, and it will record its MAC address and the interface and zone on which it was
discovered. It can also automatically assign the SonicPoint an IP address, if so configured, so
that the SonicPoint can communicate with an authentication server for WPA-EAP support.
SonicOS will then use the profile associated with the relevant zone to configure the 2.4GHz and
5GHz radio settings.

Modifications to profiles will not affect units that have already been provisioned and are in an
operational state. Configuration changes to operational SonicPoint devices can occur in two
ways:
•

Via manual configuration changes – Appropriate when a single, or a small set of changes
are to be affected, particularly when that individual SonicPoint requires settings that are
different from the profile assigned to its zone.

•

Via un-provisioning – Deleting a SonicPoint unit effectively un-provisions the unit, or clears
its configuration and places it into a state where it will automatically engage the provisioning
process anew with its peer SonicOS device. This technique is useful when the profile for a
zone is updated or changed, and the change is set for propagation. It can be used to update
firmware on SonicPoints, or to simply and automatically update multiple SonicPoint units in
a controlled fashion, rather than changing all peered SonicPoints at once, which can cause
service disruptions.

Updating SonicPoint Settings
You can change the settings of any individual SonicPoint list on the Sonicpoint > SonicPoints
page.

526

SonicOS 5.8.1 Administrator Guide

SonicPoint > SonicPoints

Edit SonicPoint Settings
To edit the settings of an individual SonicPoint:
Step 1

Under SonicPoint Settings, click the Edit icon
to edit.

in the same line as the SonicPoint you want

Step 2

In Edit SonicPoint screen, make the changes you want. See “Configuring a SonicPoint Profile”
on page 517 for instructions on configuring these settings.

Step 3

Click OK to apply these settings.

Synchronize SonicPoints
Click Synchronize SonicPoints at the top of the SonicPoint > SonicPoints page to update
the settings for each SonicPoint reported on the page. When you click Synchronize
SonicPoints, SonicOS polls all connected SonicPoints and displays updated settings on the
page.

Enable and Disable Individual SonicPoints
You can enable or disable individual SonicPoints on the SonicPoint > SonicPoints page:
Step 1

Check the box under Enable to enable the SonicPoint, uncheck the box to disable it.

Step 2

Click Accept at the top of the SonicPoint > SonicPoints page to apply this setting to the
SonicPoint.

Updating SonicPoint Firmware
Not all SonicOS Enhanced firmware contains an image of the SonicPoint firmware. To check,
scroll to the bottom of the SonicPoint > SonicPoints page and look for the Download link.
If your SonicWALL appliance has Internet connectivity, it will automatically download the
correct version of the SonicPoint image from the SonicWALL server when you connect a
SonicPoint device.
If your SonicWALL appliance does not have Internet access, or has access only through a
proxy server, you must perform the following steps:
Step 1

Download the SonicPoint image from http://www.mysonicwall.com to a local system with
Internet access.
You can download the SonicPoint image from one of the following locations:
– On the same page where you can download the SonicOS Enhanced firmware
– On the Download Center page, by selecting SonicPoint in the Type drop-down menu

Step 2

Load the SonicPoint image onto a local Web server that is reachable by your SonicWALL
appliance.

SonicOS 5.8.1 Administrator Guide

527

SonicPoint > SonicPoints

You can change the file name of the SonicPoint image, but you should keep the extension
in tact (ex: .bin.sig).
Step 3

In the SonicOS user interface on your SonicWALL appliance, in the navigation pane, click
System and then click Administration.

Step 4

In the System > Administration screen, under Download URL, click the Manually specify
SonicPoint image URL checkbox to enable it.

Step 5

In the text box, type the URL for the SonicPoint image file on your local Web server.

Step 6

Click Accept.

Automatic Provisioning (SDP & SSPP)
The SonicWALL Discovery Protocol (SDP) is a layer 2 protocol employed by SonicPoints and
devices running SonicOS Enhanced. SDP is the foundation for the automatic provisioning of
SonicPoint units via the following messages:
•

Advertisement – SonicPoint devices without a peer will periodically and on startup
announce or advertise themselves via a broadcast. The advertisement will include
information that will be used by the receiving SonicOS device to ascertain the state of the
SonicPoint. The SonicOS device will then report the state of all peered SonicPoints, and
will take configuration actions as needed.

•

Discovery – SonicOS devices will periodically send discovery request broadcasts to elicit
responses from L2 connected SonicPoint units.

•

Configure Directive – A unicast message from a SonicOS device to a specific SonicPoint
unit to establish encryption keys for provisioning, and to set the parameters for and to
engage configuration mode.

•

Configure Acknowledgement – A unicast message from a SonicPoint to its peered
SonicOS device acknowledging a Configure Directive.

•

Keepalive – A unicast message from a SonicPoint to its peered SonicOS device used to
validate the state of the SonicPoint.

If via the SDP exchange the SonicOS device ascertains that the SonicPoint requires
provisioning or a configuration update (e.g. on calculating a checksum mismatch, or when a
firmware update is available), the Configure directive will engage a 3DES encrypted, reliable
TCP based SonicWALL Simple Provisioning Protocol (SSPP) channel. The SonicOS device will
then send the update to the SonicPoint via this channel, and the SonicPoint will restart with the
updated configuration. State information will be provided by the SonicPoint, and will be
viewable on the SonicOS device throughout the entire discovery and provisioning process.

SonicPoint and SonicPointN States
SonicPoint and SonicPointN devices can function in and report the following states (in all states
listed below, SonicPoint refers to both SonicPoint and SonicPointN devices):

528

•

Initializing – The state when a SonicPoint starts up and advertises itself via SDP prior to
it entering into an operational or stand-alone mode.

•

Operational – Once the SonicPoint has peered with a SonicOS device and has its
configuration validated, it will enter into a operational state, and will be ready for clients.

•

Provisioning – If the SonicPoint configuration requires an update, the SonicOS device will
engage an SSPP channel to update the SonicPoint. During this brief process it will enter
the provisioning state.

SonicOS 5.8.1 Administrator Guide

SonicPoint Deployment Best Practices

•

Safemode – Safemode can be engaged by depressing the reset button, or from the
SonicOS peer device. Placing a SonicPoint into Safemode returns its configuration to
defaults, disables the radios, and disables SDP. The SonicPoint must then be rebooted to
enter either a stand-alone, or some other functional state.

•

Non-Responsive – If a SonicOS device loses communications with a previously peered
SonicPoint, it will report its state as non-responsive. It will remain in this state until either
communications are restored, or the SonicPoint is deleted from the SonicOS device’s table.

•

Updating Firmware – If the SonicOS device detects that it has a firmware update available
for a SonicPoint, it will use SSPP to update the SonicPoint’s firmware.

•

Downloading Firmware – The SonicWALL appliance is downloading new SonicPoint
firmware from the configured URL, which can be customized by the administrator. The
default URL is http://software.sonicwall.com.

•

Downloading Failed – The SonicWALL appliance cannot download the SonicPoint
firmware from the configured URL.

•

Writing Firmware – While the SonicPoint is writing new firmware to its flash, the progress
is displayed as a percentage in the SonicOS management interface in the SonicPoint status
field.

•

Over-Limit – By default, up to 2 SonicPoint devices can be attached to the Wireless zone
interface. If more than 2 units are detected, the over-limit devices will report an over-limit
state, and will not enter an operational mode. The number can be reduced from 2 as
needed.

•

Rebooting – After a firmware or configuration update, the SonicPoint will announce that it
is about to reboot, and will then do so.

•

Firmware failed – If a firmware update fails, the SonicPoint will report the failure, and will
then reboot.

•

Provision failed – In the unlikely event that a provision attempt from a SonicOS device
fails, the SonicPoint will report the failure. So as not to enter into an endless loop, it can
then be manually rebooted, manually reconfigured, or deleted and re-provisioned.

•

Stand-alone Mode (not reported) – If a SonicPoint device cannot find or be found by a
SonicOS device to peer with, it will enter a stand-alone mode of operation. This will engage
the SonicPoint’s internal GUI (which is otherwise disabled) and will allow it to be configured
as a conventional Access Point. If at any time it is placed on the same layer 2 segment as
a SonicOS device that is sending Discovery packets, it will leave stand-alone mode, and
will enter into a managed mode. The stand-alone configuration will be retained.

SonicPoint Deployment Best Practices
This section provides SonicWALL recommendations and best practices regarding the design,
installation, deployment, and configuration issues for SonicWALL’s SonicPoint wireless access
points. The information covered allows site administrators to properly deploy SonicPoints in
environments of any size. This section also covers related external issues that are required for
successful operation and deployment.
SonicWALL cannot provide any direct technical support for any of the third-party Ethernet
switches referenced in this section. The material is also subject to change without SonicWALL’s
knowledge when the switch manufacturer releases new models or firmware that may invalidate
the information contained here. The only exception to this rule is Hewlett-Packard, as
SonicWALL is currently a member of HP’s ProCurve Alliance program, and works closely with
HP to ensure compatibility with the ProCurve switch product line.
Further information on this can be found at:
SonicOS 5.8.1 Administrator Guide

529

SonicPoint Deployment Best Practices

http://h20195.www2.hp.com/v2/GetPDF.aspx/4AA1-9147ENUC.pdf
Best practices information is provided in the following sections:
•

“Prerequisites” on page 530

•

“Layer 2 and Layer 3 Considerations for SonicPoints” on page 531

•

“Tested Switches” on page 531

•

“Wiring Considerations” on page 531

•

“Channels” on page 532

•

“PoE” on page 533

•

“Spanning-Tree” on page 534

•

“VTP and GVRP” on page 534

•

“Port-Aggregation” on page 534

•

“Broadcast Throttling/Broadcast Storm” on page 534

•

“VAP Issues” on page 535

•

“Troubleshooting” on page 535

•

“Resetting the SonicPoint” on page 536

•

“Switch Programming Tips” on page 536

Prerequisites
The following are required for a successful SonicPoint deployment:
•

SonicOS Enhanced requires public Internet access in order for the UTM appliance to
download and update the SonicPoint firmware images. If the device does not have public
Internet access, you will need to obtain and download the SonicPoint firmware manually.

•

One or more SonicWALL SonicPoint or SonicPoint-G wireless access points.

•

If you are using a PoE switch to power the SonicPoint, it must be an 802.3af-compliant
Ethernet switches. Vendor-specific switch programming notes can be found towards the
end of this section for HP, Cisco, Dell, and D-Link. If not, you will need to use the power
adapter that ships with the SonicPoint, or SonicWALL’s PoE Injector. See:
http://www.sonicwall.com/downloads/SonicWALL_PoE_Injector_Users_Guide.pdf

530

•

It is strongly recommended you obtain a support contract for SonicWALL as well as the PoE
switch; this will allow you to update to new versions if issues are found on the switch side
or on the SonicWALL side, or when new features are released.

•

Be sure do conduct a full site survey before installation (see section below).

•

Check wiring and cable infrastructure to verify that end-to-end runs between SonicPoints
and the Ethernet switches are CAT5, CAT5e, or CAT6.

•

Check building codes for install points and work with building’s facilities staff, as some
desired install points may violate regulations.

SonicOS 5.8.1 Administrator Guide

SonicPoint Deployment Best Practices

Layer 2 and Layer 3 Considerations for SonicPoints
SonicWALL uses two proprietary protocols (SDP and SSPP) and both *cannot* be routed
across any layer 3 device. Any SonicPoint that will be deployed must have an Ethernet
connection back to the provisioning SonicWALL UTM appliance, in the same broadcast domain/
network.
The SonicWALL UTM appliance must have an interface or sub-interface in same VLAN/
broadcast domain as SonicPoint.
SonicPoints must be able to reach the DHCP scope on the SonicWALL; make sure other DHCP
servers are not present on the VLAN/broadcast domain.
Sharing SSIDs across SonicPoints attached to multiple interfaces may cause connectivity
issues as a wireless client roams to a different SonicPoint subnet.

Tested Switches
•

Most Cisco switches work well; however SonicWALL does not recommend deploying
SonicPoints using the “Cisco Express” switch line.

•

SonicWALL does not recommend deploying SonicPoints using Netgear PoE switches.

•

If you are using D-Link PoE switches, you will need to shut off all their proprietary broadcast
control and storm control mechanisms, as they will interfere with the provisioning and
acquisition mechanisms in the SonicPoint (see section regarding this).

•

Dell – make sure to configure STP for fast start on SonicPoint ports.

•

Extreme – make sure to configure STP for fast start on SonicPoint ports.

•

Foundry – make sure to configure STP for fast start on SonicPoint ports.

•

HP ProCurve – make sure to configure STP for fast start on SonicPoint ports.

Wiring Considerations
•

Make sure wiring is CAT5, CAT5e, or CAT6 end to end.

•

Due to signaling limitations in 802.3af, Ethernet cable runs cannot go over 100 meters
between PoE switch and SonicPoint.

•

You will need to account for PoE power loss as the cable run becomes longer; this can be
up to 16%. For longer cable runs, the port will require more power to be supplied.

Site Survey and Planning
•

Conduct a full site-walk of all areas SonicPoints will be deployed in with a wireless spectrum
scanner; note any existing APs and the channels they are broadcasting on. SonicWALL
currently recommends using Fluke or AirMagnet products to conduct full site surveys. You
may also wish to try out NetStumbler/MiniStumbler, which while free does a decent job of
surveying, providing it works with your wireless card.

•

Blueprints of floor plans are helpful; here you can mark the position of Access Points and
the range of the wireless cell. Make multiple copies of these as during the site-survey
results may cause the original design not to be the best and a new start will be needed. As
well you see where walls, halls and elevators are located, that can influence the signal.
Also, areas in which users are located – and where not - can be seen. During the sitesurvey keep an eye open for electrical equipment that may cause interference

SonicOS 5.8.1 Administrator Guide

531

SonicPoint Deployment Best Practices

(microwaves, CAT Scan equipment, etc…) In area’s were a lot of electrical equipment is
placed, also take a look at the cabling being used. In areas with a lot of electrical equipment
UTP should not be used, FTP or STP is required.
•

Survey three dimensionally, wireless signals cross over to different floors.

•

Determine where you can locate APs based on power and cabling. Remember that you
shouldn't place APs close to metal or concrete walls and you should put them as close to
the ceiling as possible.

•

Use the wireless scanning tool to check signal strengths and noise. Signal to noise ratio
should at least be 10dB (minimum requirements for 11 Mbps), however 20dB is preferred.
Both factors influence the quality of the service.

•

Relocate the APs and re-test, depending of the results of your survey.

•

Save settings, logs and note the location of the AP for future reference.

•

If you find that certain areas, or all areas are saturated with existing overlapping 802.11b/
g channels, you may wish to deploy SonicPoints using the 802.11a radio. This provides a
much larger array of channels to broadcast on, although the range of 802.11a is limited,
and the SonicPoint does not allow for the addition of external antennas (only the
SonicPoint-G model allows this).

•

When planning, make sure you note the distance of cable runs from where the SonicPoint
will be mounted; this must be 100 meters or less. If you are not using PoE switches, you
will also need to account for the power adapter or PoE injector for the SonicPoint or
SonicPoint- G. Make sure you are not creating an electrical or fire hazard.

•

Be wary of broadcasting your wireless signal into areas that you do not control; check for
areas where people might be able to leach signal and tune the SonicPoints accordingly.

•

For light use, you can plan for 15-20 users for each SonicPoint. For business use, you
should plan for 5-10 users for each SonicPoint.

•

Plan accordingly for roaming users – this will require tuning the power on each SonicPoint
so that the signal overlap is minimal. Multiple SonicPoints broadcasting the same SSID in
areas with significant overlap can cause ongoing client connectivity issues.

•

Use the scheduling feature in SonicOS Enhanced to shut SonicPoints when not in use – it’s
recommended that you do not operate your SonicPoints during non-business-hours (off
nights and weekends).

Channels
The default setting of SonicPoints is auto-channel. When this is set, at boot-up the SP will do
a scan and check if there are other wireless devices are transmitting. Then it will try to find an
unused channel and use this for transmission. Especially in larger deployments, this can cause
trouble. Here it is recommended to assign fixed channels to each SonicPoint. A diagram of the
SPs and their MAC-Addresses helps to avoid overlaps, best is to mark the location of the SPs
and MAC Addresses on a floor-plan.
Wireless Card Tuning

If you are experiencing connectivity issues with laptops, check to see if the laptop has an Intel
embedded wireless adapter. The following Intel chipsets are publicly known and acknowledged
by Intel to have disconnect issues with third-party wireless access points such as the
SonicWALL SonicPoint and SonicPoint-G:

532

•

Intel PRO/Wireless 2100 Network Connection

•

Intel PRO/Wireless 2100A Network Connection

SonicOS 5.8.1 Administrator Guide

SonicPoint Deployment Best Practices

•

Intel PRO/Wireless 2200BG Network Connection

•

Intel PRO/Wireless 2915ABG Network Connection

•

Intel PRO/Wireless 3945ABG Network Connection

These wireless cards are provided to OEM laptop manufacturers and are often rebranded
under the manufacturers name – for example, both Dell and IBM use the above wireless cards
but the drivers are branded under their own name.
To identify the adapter, go to Intel’s support site and do a search for Intel Network Connection
ID Tool. Install and run this tool on any laptop experiencing frequent wireless disconnect
issues. The tool will identify which Intel adapter is installed inside the laptop.
Once you have identified the Intel wireless adapter, go to Intel’s support site and download the
newest software package for that adapter – it is recommended that you download and install
the full Intel PRO/Set package and allow it to manage the wireless card, instead of Windows or
any OEM provided wireless network card management program previously used. SonicWALL
recommends that you use version 10.5.2.0 or newer of the full Intel PRO/Set Wireless software
driver/manager.
Be sure to use the Intel wireless management utility and to disable Microsoft’s Wireless Zero
Config management service – the Intel utility should control the card, not the OS.
In the ‘Advanced’ section, disable the power management by unchecking the box next to ‘Use
default value’, then move the slidebar under it to ‘Highest’. This instructs the wireless card to
operate at full strength and not go into sleep mode. When you are done, click on the ‘OK’ button
to save and activate the change. Reboot the laptop.
In the ‘Advanced’ section, adjust the roaming aggressiveness by unchecking the box next to
‘Use default value’, then move the slidebar under it to ‘Lowest’. This instructs the wireless card
to stay stuck to the AP it’s associated as long as possible, and only roam if the signal is
significantly degraded. This is extremely helpful in environments with large numbers of access
points broadcasting the same SSID. When you are done, click on the ‘OK’ button to save and
activate the change. Reboot the laptop.
If you continue to have issues, you may also try adjusting the Preamble Mode on the wireless
card. By default the Intel wireless cards above are set to ‘auto’. All SonicWALL wireless
products by default are set to use a ‘Long’ preamble, although this can be adjusted in the
Management GUI. To adjust the Intel wireless card’s preamble setting, go to the ‘Advanced’
section and uncheck the box next to ‘Use default value’, then select ‘Long Tx Preamble’ from
the drop-down below it. When you are done, click on the ‘OK’ button to save and activate the
change. Reboot the laptop.

PoE
•

A SonicPoint at full power draws 6-10 Watts.

•

SonicPoints are set to Class 0 PD (meaning that it can be 0.44W minimum up to 12.95W
maximum). A mismatch in Class will cause confusion in the handshake and reboot the
SonicPoint.

•

Full 802.3af compliance is required on any switch that will be supplying PoE to a SonicPoint
or SonicPoint-G. Do not operate SonicPoints on non-compliant switches as SonicWALL
does not support it.

•

Turn off pre-802.3af-spec detection as it may cause connectivity issues.

•

Long cable runs cause loss of power; 100 meter runs between SonicPoint and PoE switch
may incur up to 16% power/signal degradation; because of this the PoE switch will need to
supply more power to the port to keep the SonicPoint operational.

SonicOS 5.8.1 Administrator Guide

533

SonicPoint Deployment Best Practices

•

Because of this, make sure each port can get 10 Watts guaranteed if possible, and set the
PoE priority to critical or high.

•

One thing to be particularly careful to plan for is that not all PoE switches can provide the
full 15.4 watts of power to each of its PoE ports – it might have 24 but it can’t actually have
all ports with PoE devices attached without the addition of an external redundant power
supply. You will need to work closely with the manufacturer of the PoE switch to ensure that
enough power is supplied to the switch to power all of your PoE devices.

Spanning-Tree
•

When an Ethernet port becomes electrically active, most switches by default will activate
the spanning-tree protocol on the port to determine if there are loops in the network
topology. During this detection period of 50-60 seconds the port does not pass any traffic
– this feature is well-known to cause problems with SonicPoints. If you do not need
spanning-tree, disable it globally on the switch, or disable it on each port connected to a
SonicPoint device.

•

If this is not possible, check with the switch manufacturer to determine if they allow for “fast
spanning-tree detection”, which is a method that runs spanning-tree in a shortened time so
as to not cause connectivity issues. Please refer to the switch-specific sections at the end
of this technote for programming samples on how to do this.

VTP and GVRP
Turn these trunking protocols off on ports connected directly to SonicPoints, as they have been
known to cause issues with SonicPoints – especially the high-end Cisco Catalyst series
switches.

Port-Aggregation
•

Many switches have port aggregation turned on by default – this causes a lot of issues and

•

should be deactivated on ports connected directly to SonicPoints.

•

PAGP/Fast EtherChannel/EtherChannel – turn this off on the ports going to SonicPoints.

•

LACP – turn this off on the ports going to SonicPoints.

Broadcast Throttling/Broadcast Storm
This feature is an issue on some switches, especially D-Link. Please disable on per port basis
if possible, if not disable globally.
Speed and Duplex

534

•

At present, auto-negotiation of speed and duplex is the only option for SonicPoints.

•

Lock speed and duplex on switch and reboot SonicPoint -- this may help with connectivity
issues.

•

Check port for errors, as this is the best way to determine if there is a duplex issue (port will
also experience degraded throughput).

SonicOS 5.8.1 Administrator Guide

SonicPoint Deployment Best Practices

Troubleshooting Older SonicPoints

If you have an older SonicPoint and it’s consistently port flapping, or doesn’t power up at all, or
is stuck reboot cycling, or reports in the GUI as stuck in provisioning, check to see if you are
running a current version of firmware, and that the SonicWALL UTM appliance has public
internet access. You may need to RMA for a newer SonicPoint.

VAP Issues
•

You will need to manually adjust the broadcast/beacon timing when using multiple SSIDs,
if using versions of SonicOS Enhanced older than 4.0.1.0 (set beacon to 800).

•

Only VLAN-supported SonicWALL platforms can offer VAP features for existing releases.
Each SSID should be associated with the unique VLAN ID to segment traffic in different
broadcast domains. SDP/SSPP protocol packets must be untagged before reaching
SonicWALL WLAN interface or SonicPoint.

•

The switch between SonicWALL and SonicPoint must be configured properly to allow both
untagged SDP/SSPP traffic and tagged traffic with VLAN ID for each VAP SSID.

•

If at all possible assign each VAP to its own VLAN/Security Zone -- this will provide
maximum security and although not explicitly required for PCI compliance, puts you solidly
in the "green" zone.

•

If you use VLAN’s, do not use the parent interface and do not use the default VLAN.

Troubleshooting
•

When creating a Wireless zone and interface, make sure to configure the interface for the
number of SonicPoints you wish to support -- new interfaces are set to ‘No SonicPoints’ by
default. If you do not do this, the UTM appliance will not create the necessary DHCP scope
and will not acquire any SonicPoints added to the interface.

•

If you added SonicPoints and only a certain number were detected and acquired, check
interface settings as noted above, as it might be set for too few SonicPoints.

•

If throughput seems sluggish, check to see how many SonicPoints you have on an interface
– in large deployments it’s advisable to spread them across more than one. Try to limit the
interfaces to a 4-to-1 oversubscription ratio. For example, if you have a 100Mbps, you can
safely attach up to 20 SonicPoints to it and expect reasonable performance.

•

Given throughput on SonicPoints only 20-22 Mbps at best – this is a limitation of the
802.11a and 802.11g and not the SonicPoint.

•

If you are still experiencing throughput issues, please upgrade to SonicOS 4.0.1.0 or
newer, as it contains several fixes that will help.

•

Make sure your security zone (the default WLAN, or your own custom wireless zone) has
the right settings – they might be blocking traffic for various reasons.

•

If the SonicPoints are not acquiring, check DHCP scopes; they might be off, or missing
entirely.

•

It is NOT advisable to use the same SSID for the 802.11bg and the 802.11a radios, as
clients with tri-band cards may experience disconnect issues – name them separately.

•

Stuck in provisioning mode? Unplug, clear from config, reboot and plug back in.

•

All versions of SonicOS Enhanced after version 3.5 no longer contain the SonicPoint
firmware image, and in order for a SonicPoint to be discovered and provisioned, the UTM
appliance must be connected to the Internet.

SonicOS 5.8.1 Administrator Guide

535

SonicPoint Deployment Best Practices

•

Note that SonicPoints have a ‘Standalone Mode’ which they will transition to if they can’t
find a SonicWALL UTM appliance. If you have more than one SonicPoint, you may have
issues as all of the SonicPoints will revert to the same default IP address of 192.168.1.20/
24.

•

When troubleshooting wireless issues, logging, Syslog, and SNMP are your friends –
SonicWALL’s Global Management System (GMS) package can centralize all of these for
all of your SonicWALL devices, regardless of location. A free alternative is Kiwi’s Syslog
Daemon, which can accept Syslog streams and SNMP traps from all SonicWALL UTM
appliances. The most current version can be found here:
http://www.kiwisyslog.com/

•

Check the network cabling. Is shielded or unshielded TP cable being used?

Resetting the SonicPoint
The SonicPoint has a reset switch inside a small hole in the back of the unit, next to the console
port. You can reset the SonicPoint at any time by pressing the reset switch with a straightened
paperclip, a tooth pick, or other small, straight object.
The reset button resets the configuration of the mode the SonicPoint is operating in to the
factory defaults. It does not reset the configuration for the other mode. Depending on the mode
the SonicPoint is operating in, and the amount of time you press the reset button, the
SonicPoint behaves in one of the following ways:
•

Press the reset button for at least three seconds, and less than eight seconds with the
SonicPoint operating in Managed Mode to reset the Managed Mode configuration to factory
defaults and reboot the SonicPoint.

•

Press the reset button for more than eight seconds with the SonicPoint operating in
Managed Mode to reset the Managed Mode configuration to factory defaults and reboot the
SonicPoint in SafeMode.

•

Press the reset button for at least three seconds, and less than eight seconds with the
SonicPoint operating in Stand-Alone Mode to reset the Stand-Alone Mode configuration to
factory defaults and reboot the SonicPoint.

•

Press the reset button for more than eight seconds with the SonicPoint operating in
Stand-Alone Mode to reset the Stand-Alone Mode configuration to factory defaults and
reboot the SonicPoint in SafeMode.

Switch Programming Tips
Sample HP ProCurve switch commands (per-interface)

536

•

name ‘link to SonicPoint X’

•

no lacp

•

no cdp

•

power critical

•

no power-pre-std-detect (note: global command)

•

speed-duplex 100-half (note: only if you are seeing FCS errors)

•

spanning-tree xx admin-edge-port (note: replace xx with port number)

•

mdix-mode mdix

SonicOS 5.8.1 Administrator Guide

SonicPoint Deployment Best Practices

Sample Cisco Catalyst switch configuration

Any Cisco POE Switch: On the connecting interface/port, issue the command ‘Power inline
static 10000’.
2900/3500-series:
1.

On the connecting interface/port, issue the command ‘spanning-tree portfast’, which will
greatly reduce the time STP is performed on the interface/port.

2.

If you are using a 2950 or 3550 switch, issue the command ‘switchport mode access’ to
disable trunking on the interface/port.

3.

On the connecting interface, issue the commands ‘speed 100’ (or ‘speed 10’) and ‘duplex
full’ (or ‘duplex half’) to lock the speed and duplex of the port.

2948/2980/4000/4500/5000/5500/6500-series running CatOS:

Note

1.

On the connecting interface/port, issue the command ‘set spantree portfast __/__ enable’
(fill in first blank with module number, and second blank with port), which will greatly reduce
the time STP is performed on the interface/port.

2.

On the connecting interface/port, issue the command ‘set port channel __/__ off’ (fill in first
blank with module number, and second blank with port range), which will disable
EtherChannel (PAgP) on the interface/port.

3.

On the connecting interface/port, issue the command ‘set port trunk __/__’ (fill in first blank
with module number, and second blank with port), which will disable trunking on the
interface/port.

4.

On the connecting interface/port, issue the command ‘set port speed __/__ 100’ (fill in first
blank with module number, and second blank with port), which will lock the speed to
100Mbps on the interface/port (you can also lock it to 10Mbps if you wish).

5.

On the connecting interface/port, issue the command ‘set port duplex __/__ full’ (fill in first
blank with module number, and second blank with port), which will lock the duplex to full on
the interface/port (you can also lock it to half duplex if you wish).

Cisco switches running CatOS 5.2 and newer have a special macro command called ‘set
port host __/__‘ that sets the interface/port for portfast, disables trunking, and disables
EtherChannel. You will still have to manually set the speed/duplex for the port(s), however.
1900-Series

1900-series switch have portfast enabled by default on the 10mbps ports and disabled on the
100 Mbps ports. If you are using the 100mbps ports to connect to a SonicWALL device, issue
the command ‘spantree start-forwarding’, which will greatly reduce the time STP is performed
on the interface/port.
Sample Dell switch configuration (per interface)
•

spanning-tree portfast

•

no back-pressure

•

no channel-group

•

duplex half (note: only if you are seeing FCS errors)

•

speed 100

•

no flowcontrol

•

no gvrp enable

SonicOS 5.8.1 Administrator Guide

537

SonicPoint Deployment Best Practices

•

no lldp enable

•

mdix on

•

mdix auto

•

no port storm-control broadcast enable

Sample D-Link switch configuration

The D-Link PoE switches do not have a CLI, so you will need to use their web GUI. Note that
D-Link recommends upgrading to Firmware Version 1.20.09 if you are using multicast in your
environment.
Disable spanning-tree, broadcast storm control, LLDP and the Safeguard Engine on the switch
before adding SonicPoints to the switch, as all may impact their successful provisioning,
configuration, and functionality.

538

SonicOS 5.8.1 Administrator Guide

CHAPTER 42
Chapter 42:

Viewing Station Status

SonicPoint > Station Status
The SonicPoint > Station Status page reports on the statistics of each SonicPoint.
.

The table lists entries for each wireless client connected to each SonicPoint. The sections of
the table are divided by SonicPoint. Under each SonicPoint, is the list of all clients currently
connected to it.
Click the Refresh button in the top left corner to refresh the list.
By default, the page displays the first 50 entries found. Click the First Page , Previous Page
, Next Page , and Last Page icons to navigate if you need to view more than 50 entries.

SonicOS 5.8.1 Administrator Guide

539

SonicPoint > Station Status

Click on the Statistics icon to see a detailed report for an individual station. Each SonicPoint
device reports for both radios, and for each station, the following information to its SonicOS
peer:

•

MAC Address – The client’s (Station’s) hardware address.

•

Station State – The state of the station. States can include:
– None – No state information yet exists for the station.
– Authenticated – The station has successfully authenticated.
– Associated – The station is associated.
– Joined – The station has joined the ESSID.
– Connected – The station is connected (joined, authenticated or associated).
– Up – An Access Point state, indicating that the Access Point is up and running.
– Down – An Access Point state, indicating that the Access Point is not running.

540

•

Associations – Total number of Associations since power up.

•

Dis-Associations – Total number of Dis-Associations.

•

Re-Associations – Total number of Re-Associations.

•

Authentications – Number of Authentications.

•

De-Authentications – Number of De-Authentications.

•

Good Frames Received – Total number of good frames received.

•

Good Frames Transmitted – Total number of good frames transmitted.

•

Error in Receive Frames – Total number of error frames received.

•

Error in Transmit Frames – Total number of error frames transmitted.

•

Discarded Frames – Total number of frames discarded. Discarded frames are generally a
sign of network congestion.

•

Total Bytes received – Total number of bytes received.

•

Total Bytes Transmitted – Total number of bytes transmitted.

SonicOS 5.8.1 Administrator Guide

SonicPoint > Station Status

•

Management Frames Received – Total number of Management frames received.
Management Frames include:
– Association request
– Association response
– Re-association request
– Re-association response
– Probe request
– Probe response
– Beacon frame
– ATIM message
– Disassociation
– Authentication
– De-authentication

•

Management Frames Transmitted – Total number of Management frames transmitted.

•

Control Frames Received – Total number of Control frames received. Control frames
include:
– RTS – Request to Send
– CTS – Clear to Send
– ACK – Positive Acknowledgement

•

Control Frames Transmitted – Total number of Control frames transmitted.

•

Data Frames Received – Total number of Data frames received.

•

Data Frames Transmitted – Total number of Data frames transmitted.

SonicOS 5.8.1 Administrator Guide

541

SonicPoint > Station Status

542

SonicOS 5.8.1 Administrator Guide

CHAPTER 43
Chapter 43:

Using and Configuring IDS

SonicPoint > IDS
You can have many wireless access points within reach of the signal of the SonicPoints on your
network. The SonicPoint > IDS page reports on all access points the SonicWALL security
appliance can find by scanning the 802.11a and 802.11g radio bands.

Wireless Intrusion Detection Services
Intrusion Detection Services (IDS) greatly increase the security capabilities of the SonicWALL
security appliance with SonicOS Enhanced by enabling it to recognize and even take
countermeasures against the most common types of illicit wireless activity. IDS logging and
notification can be enabled under Log > Categories by selecting the IDS checkbox under Log
Categories and Alerts.

SonicOS 5.8.1 Administrator Guide

543

SonicPoint > IDS

Intrusion Detection Settings
Rogue Access Points have emerged as one of the most serious and insidious threats to
wireless security. In general terms, an access point is considered rogue when it has not been
authorized for use on a network. The convenience, affordability and availability of non-secure
access points, and the ease with which they can be added to a network creates a easy
environment for introducing rogue access points. Specifically, the real threat emerges in a
number of different ways, including unintentional and unwitting connections to the rogue
device, transmission of sensitive data over non-secure channels, and unwanted access to LAN
resources. So while this doesn't represent a deficiency in the security of a specific wireless
device, it is a weakness to the overall security of wireless networks.
The security appliance can alleviate this weakness by recognizing rogue access points
potentially attempting to gain access to your network. It accomplishes this in two ways: active
scanning for access points on all 802.11a, 802.11g, and 802.11n (SonicPointN only) channels,
and passive scanning (while in Access Point mode) for beaconing access points on a single
channel of operation.
Check Enable Rogue Access Point Detection to enable the security appliance to search for
rogue access points.
The Authorized Access Points list determines which access points the security appliance will
considered authorized when it performs a scan. You can select All Authorized Access Points
to allow all SonicPoints, or you can select an address object group containing a group of MAC
address to limit the list to only those SonicPoints whose MAC addresses are contained in the
address object group.
Select Create Address Object Group to add a new group of MAC address objects to the list.

Note

See Chapter 20, Configuring Address Objects for instructions on creating address
objects and address object groups.

Scanning for Access Points
Active scanning occurs when the security appliance starts up, and at any time Scan All is
clicked on the SonicPoint > IDS page. When the security appliance performs a scan, a
temporary interruption of wireless clients occurs for no more than a few seconds. This
interruption manifests itself as follows:

Caution

•

Non-persistent, stateless protocols (such as HTTP) should not exhibit any ill-effects.

•

Persistent connections (protocols such as FTP) are impaired or severed.

If service disruption is a concern, it is recommended that the Scan Now feature not be used
while the SonicWALL security appliance is in Access Point mode until such a time that no
clients are active, or the potential for disruption becomes acceptable.
You can also scan on a SonicPoint by SonicPoint basis by choosing from the following options
in the Perform SonicWALL Scan menu on the header for the individual SonicPoint:

544

•

Scan Both Radios

•

Scan 802.11a Radio (5GHz)

•

Scan 802.11g Radio (2.4GHZ)

•

Scan 802.11n Radio (5GHz)

•

Scan 802.11n Radio (2.4GHZ)

SonicOS 5.8.1 Administrator Guide

SonicPoint > IDS

Discovered Access Points
The Discovered Access points displays information on every access point that can be detected
by the SonicPoint radio:
•

SonicPoint: The SonicPoint that detected the access point.

•

MAC Address (BSSID): The MAC address of the radio interface of the detected access
point.

•

SSID: The radio SSID of the access point.

•

Type: The range of radio bands used by the access point, 2.4 GHz or 5 GHz.

•

Channel: The radio channel used by the access point.

•

Manufacturer: The manufacturer of the access point. SonicPoints will show a
manufacturer of either SonicWALL or Senao.

•

Signal Strength: The strength of the detected radio signal

•

Max Rate: The fastest allowable data rate for the access point radio, typically 54 Mbps.

•

Authorize: Click the Authorize icon to add the access point to the address object group of
authorized access points.

View Style
If you have more than one SonicPoint, you can select an individual device from the SonicPoint
list to limit the Discovered Access Points table to display only scan results from that
SonicPoint. Select All SonicPoints to display scan results from all SonicPoints.

Authorizing Access Points on Your Network
Access Points detected by the security appliance are regarded as rogues until they are
identified to the security appliance as authorized for operation. To authorize an access point, it
can be manually added to the Authorized Access Points list by clicking edit icon in the
Authorize column and specifying its MAC address (BSSID) along with an optional comment.
Alternatively, if an access point is discovered by the security appliance scanning feature, it can
be added to the list by clicking the Authorize icon.

SonicOS 5.8.1 Administrator Guide

545

SonicPoint > IDS

546

SonicOS 5.8.1 Administrator Guide

CHAPTER 44
Chapter 44:

Configuring Virtual Access Points

SonicPoint > Virtual Access Point
This chapter describes the Virtual Access Point feature and includes the following sections:
•

“SonicPoint VAP Overview” section on page 547

•

“Prerequisites” section on page 550

•

“Deployment Restrictions” section on page 551

•

“SonicPoint Virtual AP Configuration Task List” section on page 551

•

“Thinking Critically About VAPs” section on page 562

•

“VAP Sample Configurations” section on page 565

SonicPoint VAP Overview
This section provides an introduction to the Virtual Access Point feature.

Note

Virtual Access Points are supported when using SonicPoint wireless access points along
with SonicWALL NSA appliances. For Virtual Access Point configuration using a TZ
appliance, see the “Wireless > Virtual Access Point” section on page 495.
This section contains the following subsections:
•

“What Is a Virtual Access Point?” section on page 548

•

“What Is an SSID?” section on page 549

•

“Wireless Roaming with ESSID” section on page 549

•

“What Is a BSSID?” section on page 549

•

“Benefits of Using Virtual APs” section on page 550

•

“Benefits of Using Virtual APs with VLANs” section on page 550

SonicOS 5.8.1 Administrator Guide

547

SonicPoint > Virtual Access Point

What Is a Virtual Access Point?
A Virtual Access Point is a multiplexed instantiation of a single physical Access Point (AP) so
that it presents itself as multiple discrete Access Points. To wireless LAN clients, each Virtual
AP appears to be an independent physical AP, when in actuality there is only a single physical
AP. Before the evolution of the Virtual AP feature support, wireless networks were relegated to
a One-to-One relationship between physical Access Points and wireless network security
characteristics, such as authentication and encryption. In other words, an Access Point
providing WPA-PSK security could not simultaneously offer Open or WPA-EAP connectivity to
clients, and if the latter were required, they would had to have been provided by a separate,
distinctly configured Access Points. This forced WLAN network administrators to find a solution
to scale their existing wireless LAN infrastructure to provide differentiated levels of service.
With the Virtual APs (VAP) feature, multiple VAPs can exist within a single physical AP in
compliance with the IEEE 802.11 standard for the media access control (MAC) protocol layer
that includes a unique Basic Service Set Identifier (BSSID) and Service Set Identified (SSID).
This allows for segmenting wireless network services within a single radio frequency footprint
of a single physical access point device.
VAPs allow the network administrator to control wireless user access and security settings by
setting up multiple custom configurations on a single physical interface. Each of these custom
configurations acts as a separate (virtual) access point, and can be grouped and enforced on
single or multiple physical SonicPoint access points simultaneously.

Internet

RADIUS
Server

WGS
No Encryption
No LAN Access

VLAN 50 - SSID: VAP-Corporate
VLAN 100 - SSID: VAP-Legacy
VLAN 150 - SSID: VAP-Guest_Secure

WiFiSec Enforced
LAN Access

MAC Filtering
LAN Access

For more information on SonicOS Secure Wireless features, refer to the SonicWALL Secure
Wireless Integrated Solutions Guide.
548

SonicOS 5.8.1 Administrator Guide

SonicPoint > Virtual Access Point

What Is an SSID?
A Service Set IDentifier (SSID) is the name assigned to a wireless network. Wireless clients
must use this same, case-sensitive SSID to communicate to the SonicPoint. The SSID consists
of a text string up to 32 bytes long. Multiple SonicPoints on a network can use the same SSIDs.
You can configure up to 8 unique SSIDs on SonicPoints and assign different configuration
settings to each SSID.
SonicPoints broadcast a beacon (announcements of availability of a wireless network) for every
SSID configured. By default, the SSID is included within the beacon so that wireless clients can
see the wireless networks. The option to suppress the SSID within the beacon is provided on
a per-SSID (e.g. per-VAP or per-AP) basis to help conceal the presence of a wireless network,
while still allowing clients to connect by manually specifying the SSID.
The following settings can be assigned to each VAP:
•

Authentication method

•

VLAN

•

Maximum number of client associations using the SSID

•

SSID Suppression

Wireless Roaming with ESSID
An ESSID (Extended Service Set IDentifier) is a collection of Access Points (or Virtual Access
Points) sharing the same SSID. A typical wireless network comprises more than one AP for the
purpose of covering geographic areas larger than can be serviced by a single AP. As clients
move through the wireless network, the strength of their wireless connection decreases as they
move away from one Access Point (AP1) and increases as they move toward another (AP2).
Providing AP1 and AP2 are on the same ESSID (for example, ‘sonicwall’) and that the (V)APs
share the same SSID and security configurations, the client will be able to roam from one to the
other. This roaming process is controlled by the wireless client hardware and driver, so roaming
behavior can differ from one client to the next, but it is generally dependent upon the signal
strength of each AP within an ESSID.

What Is a BSSID?
A BSSID (Basic Service Set IDentifier) is the wireless equivalent of a MAC (Media Access
Control) address, or a unique hardware address of an AP or VAP for the purposes of
identification. Continuing the example of the roaming wireless client from the ESSID section
above, as the client on the ‘sonicwall’ ESSID moves away from AP1 and toward AP2, the
strength of the signal from the former will decrease while the latter increases. The client’s
wireless card and driver constantly monitors these levels, differentiating between the (V)APs
by their BSSID. When the card/driver’s criteria for roaming are met, the client will detach from
the BSSID of AP1 and attach to the BSSID or AP2, all the while remaining connected the
‘sonicwall’ ESSID.

SonicOS 5.8.1 Administrator Guide

549

SonicPoint > Virtual Access Point

Benefits of Using Virtual APs
This section includes a list of benefits in using the Virtual AP feature:
•

Radio Channel Conservation—Prevents building overlapped infrastructures by allowing
a single Physical Access Point to be used for multiple purposes to avoid channel collision
problem. Channel conservation. Multiple providers are becoming the norm within public
spaces such as airports. Within an airport, it might be necessary to support an FAA network,
one or more airline networks, and perhaps one or more Wireless ISPs. However, in the US
and Europe, 802.11b networks can only support three usable (non-overlapping) channels,
and in France and Japan only one channel is available. Once the channels are utilized by
existing APs, additional APs will interfere with each other and reduce performance. By
allowing a single network to be used for multiple purposes, Virtual APs conserve channels.

•

Optimize SonicPoint LAN Infrastructure—Share the same SonicPoint LAN infrastructure
among multiple providers, rather than building an overlapping infrastructure, to lower down
the capital expenditure for installation and maintenance of your WLANs.

Benefits of Using Virtual APs with VLANs
Although the implementation of VAPs does not require the use of VLANs, VLAN use does
provide practical traffic differentiation benefits. When not using VLANs, the traffic from each
VAP is handled by a common interface on the SonicWALL security appliance. This means that
all traffic from each VAP will belong to the same zone and same subnet (Footnote: a future
version of SonicOS Enhanced will allow for traffic from different VAPs to exist on different
subnets within the same zone, providing a measure of traffic differentiation even without VLAN
tagging). By tagging the traffic from each VAP with a unique VLAN ID, and by creating the
corresponding subinterfaces on the SonicWALL security appliance, it is possible to have each
VAP occupy a unique subnet, and to assign each subinterface to its own zone.
This affords the following benefits:
•

Each VAP can have its own security services settings (e.g. GAV, IPS, CFS, etc.).

•

Traffic from each VAP can be easily controlled using Access Rules configured from the
zone level.

•

Separate Guest Services or Lightweight Hotspot Messaging (LHM) configurations can be
applied to each, facilitating the presentation of multiple guest service providers with a
common set of SonicPoint hardware.

•

Bandwidth management and other Access Rule-based controls can easily be applied.

Prerequisites

550

•

Each SonicWALL SonicPoint must be explicitly enabled for Virtual Access Point support by
selecting the SonicPoint > SonicPoints > General Settings Tab: “Enable SonicPoint”
checkbox in the SonicOS management interface and enabling either Radio A or G.

•

SonicPoints must be linked to a WLAN zone on your SonicWALL UTM appliance in order
for provisioning of APs to take place.

•

When using VAPs with VLANs, you must ensure that the physical SonicPoint discovery and
provisioning packets remain untagged (unless being terminated natively into a VLAN
subinterface on the SonicWALL). You must also ensure that VAP packets that are VLAN
tagged by the SonicPoint are delivered unaltered (neither un-encapsulated nor doubleencapsulated) by any intermediate equipment, such as a VLAN capable switch, on the
network.

SonicOS 5.8.1 Administrator Guide

SonicPoint > Virtual Access Point

Deployment Restrictions
When configuring your VAP setup, be aware of the following deployment restrictions:
•

Maximum SonicPoint restrictions apply and differ based on your SonicWALL security
appliance. Review these restrictions in the “Custom VLAN Settings” section on page 557.

SonicPoint Virtual AP Configuration Task List
A SonicPoint VAP deployment requires several steps to configure. The following section
provides first a brief overview of the steps involved, and then a more in-depth examination of
the parts that make up a successful VAP deployment. This subsequent sections describe VAP
deployment requirements and provides an administrator configuration task list:
•

“SonicPoint VAP Configuration Overview” section on page 551

•

“Network Zones” section on page 552

•

“VLAN Subinterfaces” section on page 557

•

“DHCP Server Scope” section on page 558

•

“Sonic Point Provisioning Profiles” section on page 562

•

“Thinking Critically About VAPs” section on page 562

•

“Deploying VAPs to a SonicPoint” section on page 577

SonicPoint VAP Configuration Overview
The following are required areas of configuration for VAP deployment:
Step 1

Zone - The zone is the backbone of your VAP configuration. Each zone you create will have its
own security and access control settings and you can create and apply multiple zones to a
single physical interface by way of VLAN subinterfaces.

Step 2

Interface (or VLAN Subinterface) - The Interface (X2, X3, etc...) represents the physical
connection between your SonicWALL UTM appliance and your SonicPoint(s). Your individual
zone settings are applied to these interfaces and then forwarded to your SonicPoints.

Step 3

DHCP Server - The DHCP server assigns leased IP addresses to users within specified
ranges, known as “Scopes”. The default ranges for DHCP scopes are often excessive for the
needs of most SonicPoint deployments, for instance, a scope of 200 addresses for an interface
that will only use 30. Because of this, DHCP ranges must be set carefully in order to ensure the
available lease scope is not exhausted.

Step 4

VAP Profile - The VAP Profile feature allows for creation of SonicPoint configuration profiles
which can be easily applied to new SonicPoint Virtual Access Points as needed.

Step 5

VAP Objects - The VAP Objects feature allows for setup of general VAP settings. SSID and
VLAN ID are configured through VAP Settings.

Step 6

VAP Groups - The VAP Group feature allows for grouping of multiple VAP objects to be
simultaneously applied to your SonicPoint(s).

Step 7

Assign VAP Group to SonicPoint Provisioning Profile Radio- The Provisioning Profile
allows a VAP Group to be applied to new SonicPoints as they are provisioned.

Step 8

Assign WEP Key (for WEP encryption only) - The Assign WEP Key allows for a WEP
Encryption Key to be applied to new SonicPoints as they are provisioned. WEP keys are
configured per-SonicPoint, meaning that any WEP-enabled VAPs assigned to a SonicPoint

SonicOS 5.8.1 Administrator Guide

551

SonicPoint > Virtual Access Point

must use the same set of WEP keys. Up to 4 keys can be defined per-SonicPoint, and WEPenabled VAPs can use these 4 keys independently. WEP keys are configured on individual
SonicPoints or on SonicPoint Profiles from the SonicPoint > SonicPoints page.
Network Configuration
Zone

DHCP Scopes

VLANs

VAP Configuration
VAP Profiles

VAP Objects

Network Zones
This section contains the following subsections:

552

•

“The Wireless Zone” section on page 553

•

“Custom Wireless Zone Settings” section on page 553

SonicOS 5.8.1 Administrator Guide

SonicPoint > Virtual Access Point

A network security zone is a logical method of grouping one or more interfaces with friendly,
user-configurable names, and applying security rules as traffic passes from one zone to
another zone. With the zone-based security, the administrator can group similar interfaces and
apply the same policies to them, instead of having to write the same policy for each interface.
Network zones are configured from the Network > Zones page.

For detailed information on configuring zones, see Chapter 18, Configuring Zones.

The Wireless Zone
The Wireless zone type, of which the “WLAN Zone” is the default instance, provides support to
SonicWALL SonicPoints. When an interface or subinterface is assigned to a Wireless zone, the
interface can discover and provision Layer 2 connected SonicPoints, and can also enforce
security settings above the 802.11 layer, including WiFiSec Enforcement, SSL VPN redirection,
Guest Services, Lightweight Hotspot Messaging and all licensed Deep Packet Inspection
security services.

Note

SonicPoints can only be managed using untagged, non-VLAN packets. When setting
up your WLAN, ensure that packets sent to the SonicPoints are non VLAN tagged.

Custom Wireless Zone Settings
Although SonicWALL provides the pre-configured Wireless zone, administrators also have the
ability to create their own custom wireless zones. When using VAPs, several custom zones can
be applied to a single, or multiple SonicPoint access points. The following three sections
describe settings for custom wireless zones:
•

“General” section on page 554

•

“Wireless” section on page 555

•

“Guest Services” section on page 556

SonicOS 5.8.1 Administrator Guide

553

SonicPoint > Virtual Access Point

General

554

Feature

Description

Name

Create a name for your custom zone

Security Type

Select Wireless in order to enable and access wireless security
options.

Allow Interface Trust

Select this option to automatically create access rules to allow traffic
to flow between the interfaces of a zone. This will effectively allow
users on a wireless zone to communicate with each other. This option
is often disabled when setting up Guest Services.

SonicWALL Security
Services

Select the security services you wish to enforce on this zone. This
allows you to extend your SonicWALL UTM security services to your
SonicPoints.

SonicOS 5.8.1 Administrator Guide

SonicPoint > Virtual Access Point

Wireless

Feature

Description

Only allow traffic generated
by a SonicPoint

Restricts traffic on this zone to SonicPoint-generated traffic only.

SSL VPN Enforcement

Redirects all traffic entering the Wireless zone to a defined
SonicWALL SSL VPN appliance. This allows all wireless traffic to
be authenticated and encrypted by the SSL VPN, using, for
example, NetExtender to tunnel all traffic. Note: Wireless traffic
that is tunneled through an SSL VPN will appear to originate from
the SSL VPN rather than from the Wireless zone.
SSL VPN Server - Select the Address Object representing the
SSL VPN appliance to which you wish to redirect wireless traffic.

WiFiSec Enforcement

Requires all traffic be either IPsec or WPA. With this option
checked, all non-guest connections must be IPsec enforced.
WiFiSec Exception Service - Select the service(s) you wish to be
exempt from WiFiSec Enforcement.

Require WiFiSec for Site-to- For use with WiFiSec enforcement, requires WiFiSec security on
site VPN Tunnel Traversal
all site-to-site VPN connections through this zone.
Trust WPA/WPA2 traffic as
WiFiSec

Allows WPA or WPA2 to be used as an alternative to WiFiSec.

SonicPoint Provisioning
Profile

Select a predefined SonicPoint Provisioning Profile to be applied
to all current and future SonicPoints on this zone.

SonicOS 5.8.1 Administrator Guide

555

SonicPoint > Virtual Access Point

Guest Services

The Enable Guest Services option allows the following guest services to be applied to a zone:

Feature

Description

Enable inter-guest
communication

Allows guests connecting to SonicPoints in this Wireless zone to
communicate directly and wirelessly with each other.

Bypass AV Check for
Guests

Allows guest traffic to bypass Anti-Virus protection

Enable Dynamic Address
Translation (DAT)

Dynamic Address Translation (DAT) allows the SonicPoint to
support any IP addressing scheme for Guest Services users.
If this option is disabled (unchecked), wireless guest users must
either have DHCP enabled, or an IP addressing scheme compatible
with the SonicPoint’s network settings.

556

Enable External Guest
Authentication

Requires guests connecting from the device or network you select
to authenticate before gaining access. This feature, based on
Lightweight Hotspot Messaging (LHM) is used for authenticating
Hotspot users and providing them parametrically bound network
access.

Custom Authentication
Page

Redirects users to a custom authentication page when they first
connect to a SonicPoint in the Wireless zone. Click Configure to set
up the custom authentication page. Enter either a URL to an
authentication page or a custom challenge statement in the text
field, and click OK.

Post Authentication Page

Directs users to the page you specify immediately after successful
authentication. Enter a URL for the post-authentication page in the
filed.

Bypass Guest
Authentication

Allows a SonicPoint running Guest Services to integrate into
environments already using some form of user-level authentication.
This feature automates the Guest Services authentication process,
allowing wireless users to reach Guest Services resources without
requiring authentication. This feature should only be used when
unrestricted Guest Services access is desired, or when another
device upstream of the SonicPoint is enforcing authentication.

Redirect SMTP traffic to

Redirects SMTP traffic incoming on this zone to an SMTP server
you specify. Select the address object to redirect traffic to.

Deny Networks

Blocks traffic from the networks you specify. Select the subnet,
address group, or IP address to block traffic from.

SonicOS 5.8.1 Administrator Guide

SonicPoint > Virtual Access Point

Feature

Description

Pass Networks

Automatically allows traffic through the Wireless zone from the
networks you select.

Max Guests

Specifies the maximum number of guest users allowed to connect
to the Wireless zone. The default is 10.

VLAN Subinterfaces
A Virtual Local Area Network (VLAN) allows you to split your physical network connections (X2,
X3, etc...) into many virtual network connection, each carrying its own set of configurations. The
VLAN solution allows each VAP to have its own separate subinterface on an actual physical
interface.
VLAN subinterfaces have most of the capabilities and characteristics of a physical interface,
including zone assignability, security services, WAN assignability (static addressing only),
GroupVPN, DHCP server, IP Helper, routing, and full NAT policy and Access Rule controls.
Features excluded from VLAN subinterfaces at this time are VPN policy binding, WAN dynamic
client support, and multicast support.
VLAN subinterfaces are configured from the Network > Interfaces page.

Custom VLAN Settings
The table below lists configuration parameters and descriptions for VLAN subinterfaces:
Feature

Description

Zone

Select a zone to inherit zone settings from a predefined or
custom user-defined zone.

VLAN Tag

Specify the VLAN ID for this subinterface.

Parent Interface

Select a physical parent interface (X2, X3, etc...) for the VLAN.

IP Configuration

Create an IP address and Subnet Mask in accordance with
your network configuration.

Sonic Point Limit

Select the maximum number of SonicPoints to be used on this
interface. Below are the maximum number of SonicPoints per
interface based on your SonicWALL UTM hardware:

Management Protocols

Select the protocols you wish to use when managing this
interface.

Login Protocols

Select the protocols you will make available to clients who
access this subinterface.

SonicOS 5.8.1 Administrator Guide

557

SonicPoint > Virtual Access Point

DHCP Server Scope
The DHCP server assigns leased IP addresses to users within specified ranges, known as
“Scopes”. The default ranges for DHCP scopes are often excessive for the needs of most
SonicPoint deployments, for instance, a scope of 200 addresses for an interface that will only
use 30. Because of this, DHCP ranges must be set carefully in order to ensure the available
lease scope is not exhausted.
The DHCP scope should be resized as each interface/subinterface is defined to ensure that
adequate DHCP space remains for all subsequently defined interfaces. Failure to do so may
cause the auto-creation of subsequent DHCP scopes to fail, requiring manual creation after
performing the requisite scope resizing. DHCP Server Scope is set from the Network > DHCP
Server page.

The table below shows maximum allowed DHCP leases for SonicWALL security appliances.
Platform

Maximum DHCP Leases

NSA 3500

1,024 leases

NSA 4500, E5500, E6500, E7500

4,096 leases

Virtual Access Points Profiles
A Virtual Access Point Profile allows the administrator to pre-configure and save access point
settings in a profile. VAP Profiles allows settings to be easily applied to new Virtual Access
Points. Virtual Access Point Profiles are configured from the SonicPoint > Virtual Access
Point page.

558

SonicOS 5.8.1 Administrator Guide

SonicPoint > Virtual Access Point

Virtual Access Point Profile Settings
The table below lists configuration parameters and descriptions for Virtual Access Point Profile
Settings:
Feature

Description

Name

Choose a friendly name for this VAP Profile. Choose
something descriptive and easy to remember as you will later
apply this profile to new VAPs.

Type

Set to SonicPoint by default. Retain this default setting if using
SonicPoints as VAPs (currently the only supported radio type)

Authentication Type

Below is a list available authentication types with descriptive
features and uses for each:
WEP
•

Lower security

•

For use with older legacy devices, PDAs, wireless printers

WPA
•

Good security (uses TKIP)

•

For use with trusted corporate wireless clients

•

Transparent authentication with Windows log-in

•

No client software needed in most cases

WPA2
•

Best security (uses AES)

•

For use with trusted corporate wireless clients

•

Transparent authentication with Windows log-in

•

Client software install may be necessary in some cases

•

Supports 802.11i “Fast Roaming” feature

•

No backend authentication needed after first log-in (allows
for faster roaming)

WPA2-AUTO
•

Tries to connect using WPA2 security, if the client is not
WPA2 capable, the connection will default to WPA.

Unicast Cipher

The unicast cipher will be automatically chosen based on the
authentication type.

Multicast Cipher

The multicast cipher will be automatically chosen based on the
authentication type.

Maximum Clients

Choose the maximum number of concurrent client connections
permissible for this virtual access point.

SonicOS 5.8.1 Administrator Guide

559

SonicPoint > Virtual Access Point

WPA-PSK / WPA2-PSK Encryption Settings
Pre-Shared Key (PSK) is available when using WPA or WPA2. This solution utilizes a shared
key.
Feature

Description

Pass Phrase

The shared passphrase users will enter when connecting with PSKbased authentication.

Group Key Interval

The time period for which a Group Key is valid. The default value is
86400 seconds. Setting to low of a value can cause connection issues.

WPA-EAP / WPA2-EAP Encryption Settings
Extensible Authentication Protocol (EAP) is available when using WPA or WPA2. This solution
utilizes an external 802.1x/EAP capable RADIUS server for key generation.
Feature

Description

RADIUS Server 1

The name/location of your RADIUS authentication server

RADIUS Server 1
Port

The port on which your RADIUS authentication server communicates
with clients and network devices.

RADIUS Server 1
Secret

The secret passcode for your RADIUS authentication server

RADIUS Server 2

The name/location of your backup RADIUS authentication server

RADIUS Server 2
Port

The port on which your backup RADIUS authentication server
communicates with clients and network devices.

RADIUS Server 2
Secret

The secret passcode for your backup RADIUS authentication server

Group Key Interval

The time period (in seconds) during which the WPA/WPA2 group key is
enforced to be updated.

Shared / Both (WEP) Encryption Settings
WEP is provided for use with legacy devices that do not support the newer WPA/WPA2
encryption methods. This solution utilizes a shared key.

560

Feature

Description

Encryption Key

Select the key to use for WEP connections to this VAP. WEP encryption
keys are configured in the SonicPoint > SonicPoints page under
SonicPoint Provisioning Profiles.

SonicOS 5.8.1 Administrator Guide

SonicPoint > Virtual Access Point

Virtual Access Points
The VAP Settings feature allows for setup of general VAP settings. SSID and VLAN ID are
configured through VAP Settings. Virtual Access Points are configured from the SonicPoint >
Virtual Access Point page.

General VAP Settings

Feature

Description

SSID

Create a friendly name for your VAP.

VLAN ID

When using platforms that support VLAN, you may optionally select a
VLAN ID to associate this VAP with. Settings for this VAP will be
inherited from the VLAN you select.

Enable Virtual
Access Point

Enables this VAP.

Enable SSID
Suppress

Suppresses broadcasting of the SSID name and disables responses to
probe requests. Check this option if you do not wish for your SSID to be
seen by
unauthorized wireless clients.

Advanced VAP Settings
Advanced settings allows the administrator to configure authentication and encryption settings
for this connection. Choose a Profile Name to inherit these settings from a user created profile.
See “Virtual Access Points Profiles” section on page 558 for complete authentication and
encryption configuration information.

SonicOS 5.8.1 Administrator Guide

561

SonicPoint > Virtual Access Point

Virtual Access Point Groups
The Virtual Access Point Groups feature is available on SonicWALL NSA appliances. It allows
for grouping of multiple VAP objects to be simultaneously applied to your SonicPoint(s). Virtual
Access Point Groups are configured from the SonicPoint > Virtual Access Point page.

Sonic Point Provisioning Profiles
SonicPoint Provisioning Profiles provide a scalable and highly automated method of
configuring and provisioning multiple SonicPoints across a Distributed Wireless Architecture.
SonicPoint Profile definitions include all of the settings that can be configured on a SonicPoint,
such as radio settings for the 2.4GHz and 5GHz radios, SSID’s, and channels of operation. For
more information, see “SonicPoint Provisioning Profiles” on page 516.

Thinking Critically About VAPs
This section provides content to help determine what your VAP requirements are and how to
apply these requirements to a useful VAP configuration. This section contains the following
subsections:
•

“Determining Your VAP Needs” section on page 562

•

“A Sample Network” section on page 563

•

“Determining Security Configurations” section on page 563

•

“VAP Configuration Worksheet” section on page 563

Determining Your VAP Needs
When deciding how to configure your VAPs, begin by considering your communication needs,
particularly:

562

•

How many different classes of wireless users do I need to support?

•

How do I want to secure these different classes of wireless users?

•

Do my wireless client have the required hardware and drivers to support the chosen
security settings?

•

What network resources do my wireless users need to communicate with?

•

Do any of these wireless users need to communicate with other wireless users?

•

What security services do I wish to apply to each of these classes or wireless users?

SonicOS 5.8.1 Administrator Guide

SonicPoint > Virtual Access Point

A Sample Network
The following is a sample VAP network configuration, describing four separate VAPs:
•

VAP #1, Corporate Wireless Users – A set of users who are commonly in the office, and
to whom should be given full access to all network resources, providing that the connection
is authenticated and secure. These users already belong to the network’s Directory
Service, Microsoft Active Directory, which provides an EAP interface through IAS – Internet
Authentication Services.

•

VAP#2, Legacy Wireless Devices – A collection of older wireless devices, such as
printers, PDAs and handheld devices, that are only capable of WEP encryption.

•

VAP#3, Visiting Partners – Business partners, clients, and affiliated who frequently visit
the office, and who need access to a limited set of trusted network resources, as well as
the Internet. These users are not located in the company’s Directory Services.

•

VAP# 4, Guest Users – Visiting clients to whom you wish to provide access only to
untrusted (e.g. Internet) network resources. Some guest users will be provided a simple,
temporary username and password for access.

•

VAP#5, Frequent Guest Users – Same as Guest Users, however, these users will have
more permanent guest accounts through a back-end database.

Determining Security Configurations
Understanding these requirements, you can then define the zones (and interfaces) and VAPs
that will provide wireless services to these users:
•

Corp Wireless – Highly trusted wireless zone. Employs WPA2-AUTO-EAP security.
WiFiSec (WPA) Enforced.

•

WEP & PSK – Moderate trust wireless zone. Comprises two virtual APs and subinterfaces,
one for legacy WEP devices (e.g. wireless printers, older handheld devices) and one for
visiting clients who will use WPA-PSK security.

•

Guest Services – Using the internal Guest Services user database.

•

LHM – Lightweight Hotspot Messaging enabled zone, configured to use external LHM
authentication-back-end server.

VAP Configuration Worksheet
The worksheet below provides some common VAP setup questions and solutions along with a
space for you to record your own configurations.
Questions

Examples

Solutions

How many different types of
users will I need to support?

Corporate wireless, guest access, visiting Plan out the number of different
partners, wireless devices are all common VAPs needed. Configure a zone
user types, each requiring their own VAP and VLAN for each VAP needed
Your Configurations:

SonicOS 5.8.1 Administrator Guide

563

SonicPoint > Virtual Access Point

Questions

Examples

Solutions

How many users will each VAP
need to support?

A corporate campus has 100 employees,
all of whom have wireless capabilities

The DHCP scope for the visitor
zone is set to provide at least 100
addresses

A corporate campus often has a few
dozen wireless capable visitors

The DHCP scope for the visitor
zone is set to provide at least 25
addresses

Your Configurations:

How do I want to secure different A corporate user who has access to
wireless users?
corporate LAN resources.
A guest user who is restricted to only
Internet access

Configure WPA2-EAP
Enable Guest Services but
configure no security settings

A legacy wireless printer on the corporate Configure WEP and enable MAC
LAN
address filtering
Your Configurations:

What network resources do my
users need to communicate
with?

A corporate user who needs access to the Enable Interface Trust on your
corporate LAN and all internal LAN
corporate zone.
resources, including other WLAN users.
A wireless guest who needs to access
Disable Interface Trust on your
InternetInternet and should not be allowed guest zone.
to communicate with other WLAN users.
Your Configurations:

What security services to I wish
to apply to my users?

Corporate users who you want protected
by the full SonicWALL security suite.

Enable all SonicWALL security
services.

Guest users who you do not give a hoot
about since they are not even on your
LAN.

Disable all SonicWALL security
services.

Your Configurations:

564

SonicOS 5.8.1 Administrator Guide

SonicPoint > Virtual Access Point

VAP Sample Configurations
This section provides configuration examples based on real-world wireless needs. This section
contains the following subsections:
•

“Configuring a VAP for Guest Access” section on page 565

•

“Configuring a VAP for Corporate LAN Access” section on page 572

•

“Deploying VAPs to a SonicPoint” section on page 577

Configuring a VAP for Guest Access
You can use a Guest Access VAP for visiting clients to whom you wish to provide access only
to untrusted (e.g. Internet) network resources. Guest users will be provided a simple, temporary
username and password for access. More advanced configurations also offer more permanent
guest accounts, verified through a back-end database.
This section contains the following subsection:
•

“Configuring a Zone” section on page 565

•

“Creating a Wireless LAN (WLAN) Interface” section on page 568

•

“Creating a VLAN Subinterface on the WLAN” section on page 569

•

“Configuring DHCP IP Ranges” section on page 569

•

“Creating the SonicPoint VAP” section on page 571

Configuring a Zone
In this section you will create and configure a new wireless zone with guest login capabilities.
Step 1

Log into the management interface of your SonicWALL UTM appliance.

Step 2

In the left-hand menu, navigate to the Network > Zones page.

Step 3

Click the Add... button to add a new zone.

SonicOS 5.8.1 Administrator Guide

565

SonicPoint > Virtual Access Point

General Settings Tab
Step 1

In the General tab, enter a friendly name such as “VAP-Guest” in the Name field.

Step 2

Select Wireless from the Security Type drop-down menu.

Step 3

De-select the Allow Interface Trust checkbox to disallow communication between wireless
guests.

Wireless Settings Tab

566

Step 1

In the Wireless tab, check the Only allow traffic generated by a SonicPoint checkbox.

Step 2

Uncheck all other options in this tab.

Step 3

Select a provisioning profile from the SonicPoint Provisioning Profile drop-down menu (if
applicable).

SonicOS 5.8.1 Administrator Guide

SonicPoint > Virtual Access Point

Guest Services Tab
Step 1

Note

In the Guest Services tab, check the Enable Guest Services checkbox.

In the following example, steps 2 through 7 are optional, they only represent a typical guest
VAP configuration using guest services. Steps 2 and 7, however, are recommended.

Step 2

Check the Enable Dynamic Address Translation (DAT) checkbox to allow guest users full
communication with addresses outside the local network.

Step 3

Check the Custom Authentication Page checkbox and click the Configure button to
configure a custom header and footer for your guest login page.

Step 4

Click the OK button to save these changes.

Step 5

Check the Post Authentication Page checkbox and enter a URL to redirect wireless guests to
after login.

Step 6

Check the Pass Networks checkbox to configure a website (such as your corporate site) that
you wish to allow access to without logging in to guest services.

Step 7

Enter the maximum number of guests this VAP will support in the Max Guests field.

Step 8

Click the OK button to save these changes.

SonicOS 5.8.1 Administrator Guide

567

SonicPoint > Virtual Access Point

Your new zone now appears at the bottom of the Network > Zones page, although you may
notice it is not yet linked to a Member Interface. This is your next step.

Creating a Wireless LAN (WLAN) Interface
In this section you will configure one of your ports to act as a WLAN. If you already have a
WLAN configured, skip to the “Creating a Wireless LAN (WLAN) Interface” section on
page 568.
Step 1

In the Network > Interfaces page, click the Configure
icon corresponding to the interface
you wish to use as a WLAN. The Interface Settings screen displays.

Step 2

Select WLAN from the Zone drop-down list.

Step 3

Enter the desired IP Address for this interface.

Step 4

In the SonicPoint Limit drop-down menu, select a limit for the number of SonicPoints. This
defines the total number of SonicPoints your WLAN interface will support.

Note

Step 5

The maximum number of SonicPoints depends on your platform. Refer to the “Custom VLAN
Settings” section on page 557 to view the maximum number of SonicPoints for your
platform.
Click the OK button to save changes to this interface.
Your WLAN interface now appears in the Interface Settings list.

568

SonicOS 5.8.1 Administrator Guide

SonicPoint > Virtual Access Point

Creating a VLAN Subinterface on the WLAN
In this section you will create and configure a new VLAN subinterface on your current WLAN.
This VLAN will be linked to the zone you created in the “Configuring a Zone” section on
page 565.
Step 1

In the Network > Interfaces page, click the Add Interface

button.

Step 2

In the Zone drop-down menu, select the zone you created in “Configuring a Zone, page 565”.
In this case, we have chosen VAP-Guest.

Step 3

Enter a VLAN Tag for this interface. This number allows the SonicPoint(s) to identify which
traffic belongs to the “VAP-Guest” VLAN. You should choose a number based on an organized
scheme. In this case, we choose 200 as our tag for the VAP-Guest VLAN.

Step 4

In the Parent Interface drop-down menu, select the interface that your SonicPoint(s) are
physically connected to. In this case, we are using X2, which is our WLAN interface.

Step 5

Enter the desired IP Address for this subinterface.

Step 6

Select a limit for the number of SonicPoints from the SonicPoint Limit drop-down menu. This
defines the total number of SonicPoints your VLAN will support.

Step 7

Optionally, you may add a comment about this subinterface in the Comment field.

Step 8

Click the OK button to add this subinterface.
Your VLAN subinterface now appears in the Interface Settings list.

Configuring DHCP IP Ranges
Because the number of available DHCP leases vary based on your platform, the DHCP scope
should be resized as each interface/subinterface is defined to ensure that adequate DHCP
space remains for all subsequently defined interfaces. To view the maximum number of DHCP
leases for your SonicWALL security appliance, refer to the “DHCP Server Scope” section on
page 558.
Step 1

In the left-hand menu, navigate to the Network > DHCP Server page.

Step 2

Locate the interface you just created, in our case this is the X2:V200 (virtual interface 200 on
the physical X2 interface) interface. Click the Configure
icon corresponding to the desired
interface.

SonicOS 5.8.1 Administrator Guide

569

SonicPoint > Virtual Access Point

Note

If the interface you created does not appear on the Network > DHCP Server page, it is
possible that you have already exceeded the number of allowed DHCP leases for your
SonicWALL. For more information on DHCP lease exhaustion, refer to the “DHCP Server
Scope” section on page 558.

Step 3

Edit the Range Start and Range End fields to meet your deployment needs

Step 4

Click the OK button to save these changes.
Your new DHCP lease scope now appears in the DHCP Server Lease Scopes list.

Creating a SonicPoint VAP Profile
In this section, you will create and configure a new Virtual Access Point Profile. You can create
VAP Profiles for each type of VAP, and use them to easily apply advanced settings to new
VAPs. This section is optional, but will facilitate greater ease of use when configuring multiple
VAPs.

570

Step 1

In the left-hand menu, navigate to the SonicPoint > Virtual Access Point page.

Step 2

Click the Add... button in the Virtual Access Point Profiles section.

Step 3

Enter a Profile Name such as “Guest” for this VAP Profile.

Step 4

Choose an Authentication Type. For unsecured guest access, we choose “Open”.

Step 5

Click the OK button to create this VAP Profile.

SonicOS 5.8.1 Administrator Guide

SonicPoint > Virtual Access Point

Creating the SonicPoint VAP
In this section, you will create and configure a new Virtual Access Point and associate it with
the VLAN you created in “Creating a VLAN Subinterface on the WLAN” section on page 569.
Step 1

In the left-hand menu, navigate to the SonicPoint > Virtual Access Point page.

Step 2

Click the Add... button in the Virtual Access Points section.

Step 3

Enter a default name (SSID) for the VAP. In this case we chose VAP-Guest, the same name
as the zone to which it will be associated.

Step 4

Select the VLAN ID you created in “VLAN Subinterfaces” section on page 557 from the dropdown list. In this case we chose 200, the VLAN ID of our VAP-Guest VLAN.

Step 5

Check the Enable Virtual Access Point checkbox to enable this access point upon creation.

Step 6

Click the Advanced Tab to edit encryption settings. If you created a VAP Profile in the previous
section, select that profile from the Profile Name list. We created and choose a “Guest” profile,
which uses open as the authentication method.

Step 7

Click the OK button to add this VAP. Your new VAP now appears in the Virtual Access Points
list.

Now that you have successfully set up your Guest configuration, you can choose to add more
custom VAPs, or to deploy this configuration to your SonicPoint(s) in the “Deploying VAPs to a
SonicPoint” section on page 577.

Tip

Remember that more VAPs can always be added at a later time. New VAPs can then be
deployed simultaneously to all of your SonicPoints by following the steps in the “Deploying
VAPs to a SonicPoint” section on page 577.

SonicOS 5.8.1 Administrator Guide

571

SonicPoint > Virtual Access Point

Configuring a VAP for Corporate LAN Access
You can use a Corporate LAN VAP for a set of users who are commonly in the office, and to
whom should be given full access to all network resources, providing that the connection is
authenticated and secure. These users would already belong to the network’s Directory
Service, Microsoft Active Directory, which provides an EAP interface through IAS – Internet
Authentication Services. This section contains the following subsection:
•

“Configuring a Zone” section on page 572

•

“Creating a VLAN Subinterface on the WLAN” section on page 574

•

“Configuring DHCP IP Ranges” section on page 574

•

“Creating the SonicPoint VAP” section on page 576

Configuring a Zone
In this section you will create and configure a new corporate wireless zone with SonicWALL
UTM security services and enhanced WiFiSec/WPA2 wireless security.
Step 1

Log into the management interface of your SonicWALL UTM appliance.

Step 2

In the left-hand menu, navigate to the Network > Zones page.

Step 3

Click the Add... button to add a new zone.
General Settings Tab

572

Step 1

In the General tab, enter a friendly name such as “VAP-Corporate” in the Name field.

Step 2

Select Wireless from the Security Type drop-down menu.

Step 3

Select the Allow Interface Trust checkbox to allow communication between corporate
wireless users.

Step 4

Select checkboxes for all of the security services you would normally apply to wired corporate
LAN users.

SonicOS 5.8.1 Administrator Guide

SonicPoint > Virtual Access Point

Wireless Settings Tab
Step 1

In the Wireless tab, check the Only allow traffic generated by a SonicPoint checkbox.

Step 2

Select the checkbox for WiFiSec Enforcement to enable WiFiSec security on this connection.

Step 3

Select Trust WPA/WPA2 traffic as WiFiSec to enable WPA/WPA2 users access to this
connection.

Step 4

Select a provisioning profile from the SonicPoint Provisioning Profile drop-down menu (if
applicable).

Step 5

Click the OK button to save these changes.
Your new zone now appears at the bottom of the Network > Zones page, although you may
notice it is not yet linked to a Member Interface. This is your next step.

SonicOS 5.8.1 Administrator Guide

573

SonicPoint > Virtual Access Point

Creating a VLAN Subinterface on the WLAN
In this section you will create and configure a new VLAN subinterface on your current WLAN.
This VLAN will be linked to the zone you created in the “Configuring a Zone” section on
page 572.
Step 1

In the Network > Interfaces page, click the Add Interface button.

Step 2

In the Zone drop-down menu, select the zone you created in “Configuring a Zone, page 572”.
In this case, we have chosen VAP-Corporate.

Step 3

Enter a VLAN Tag for this interface. This number allows the SonicPoint(s) to identify which
traffic belongs to the “VAP-Corporate” VLAN. You should choose a number based on an
organized scheme. In this case, we choose 50 as our tag for the VAP-Corporate VLAN.

Step 4

In the Parent Interface drop-down menu, select the interface that your SonicPoint(s) are
physically connected to. In this case, we are using X2, which is our WLAN interface.

Step 5

Enter the desired IP Address for this subinterface.

Step 6

In the SonicPoint Limit drop-down menu, select a limit for the number of SonicPoints. This
defines the total number of SonicPoints your WLAN interface will support.

Step 7

Optionally, you may add a comment about this subinterface in the Comment field.

Step 8

Click the OK button to add this subinterface.
Your VLAN subinterface now appears in the Interface Settings list.

Configuring DHCP IP Ranges
Because the number of available DHCP leases vary based on your platform, the DHCP scope
should be resized as each interface/subinterface is defined to ensure that adequate DHCP
space remains for all subsequently defined interfaces. To view the maximum number of DHCP
leases for your SonicWALL security appliance, refer to the “DHCP Server Scope” section on
page 558.

574

Step 1

In the left-hand menu, navigate to the Network > DHCP Server page.

Step 2

Locate the interface you just created, in our case this is the X2:V50 (virtual interface 50 on the
physical X2 interface) interface. Click the Configure
icon corresponding to the desired
interface.

SonicOS 5.8.1 Administrator Guide

SonicPoint > Virtual Access Point

Note

If the interface you created does not appear on the Network > DHCP Server page, it is
possible that you have already exceeded the number of allowed DHCP leases for your
SonicWALL. For more information on DHCP lease exhaustion, refer to the “DHCP Server
Scope” section on page 558.

Step 3

Edit the Range Start and Range End fields to meet your deployment needs

Step 4

Click the OK button to save these changes. Your new DHCP lease scope now appears in the
DHCP Server Lease Scopes list.

Creating a SonicPoint VAP Profile
In this section, you will create and configure a new Virtual Access Point Profile. You can create
VAP Profiles for each type of VAP, and use them to easily apply advanced settings to new
VAPs. This section is optional, but will facilitate greater ease of use when configuring multiple
VAPs.
Step 1

In the left-hand menu, navigate to the SonicPoint > Virtual Access Point page.

Step 2

Click the Add... button in the Virtual Access Point Profiles section.

Step 3

Enter a Profile Name such as “Corporate-WPA2” for this VAP Profile.

Step 4

Select WPA2-AUTO-EAP from the Authentication Type drop-down menu. This will employ an
automatic user authentication based on your current RADIUS server settings (Set below).

Step 5

In the Maximum Clients field, enter the maximum number of concurrent connections VAP will
support.

Step 6

In the WPA-EAP Encryption Settings section, enter your current RADIUS server information.
This information will be used to support authenticated login to the VLAN.

Step 7

Click the OK button to create this VAP Profile.

SonicOS 5.8.1 Administrator Guide

575

SonicPoint > Virtual Access Point

Creating the SonicPoint VAP
In this section, you will create and configure a new Virtual Access Point and associate it with
the VLAN you created in “Creating a VLAN Subinterface on the WLAN” section on page 574.
General Tab
Step 1

In the left-hand menu, navigate to the SonicPoint > Virtual Access Point page.

Step 2

Click the Add... button in the Virtual Access Points section.

Step 3

Enter a default name (SSID) for the VAP. In this case we chose VAP-Guest, the same name as
the zone to which it will be associated.

Step 4

Select the VLAN ID you created in “Creating a VLAN Subinterface on the WLAN” section on
page 574 from the drop-down list. In this case we chose 50, the VLAN ID of our VAP-Corporate
VLAN.

Step 5

Check the Enable Virtual Access Point checkbox to enable this access point upon creation.

Step 6

Check the Enable SSID Suppress checkbox to hide this SSID from users

Step 7

Click the OK button to add this VAP.
Your new VAP now appears in the Virtual Access Points list.

Advanced Tab (Authentication Settings)
Step 1

Click the Advanced Tab to edit encryption settings. If you created a VAP Profile in the previous
section, select that profile from the Profile Name list. We created and choose a “CorporateWPA2” profile, which uses WPA2-AUTO-EAP as the authentication method. If you have not set
up a VAP Profile, continue with steps 2 through 4. Otherwise, continue to Create More / Deploy
Current VAPs, page 576.

Step 2

In the Advanced tab, select WPA2-AUTO-EAP from the Authentication Type drop-down
menu. This will employ an automatic user authentication based on your current RADIUS server
settings (Set below).

Step 3

In the Maximum Clients field, enter the maximum number of concurrent connections VAP will
support.

Step 4

In the WPA-EAP Encryption Settings section, enter your current RADIUS server information.
This information will be used to support authenticated login to the VLAN.
Create More / Deploy Current VAPs

Now that you have successfully set up a VLAN for Corporate LAN access, you can choose to
add more custom VAPs, or to deploy this configuration to your SonicPoint(s) in the “Deploying
VAPs to a SonicPoint” section on page 577.

576

SonicOS 5.8.1 Administrator Guide

SonicPoint > Virtual Access Point

Tip

Remember that more VAPs can always be added at a later time. New VAPs can then be
deployed simultaneously to all of your SonicPoints by following the steps in the “Deploying
VAPs to a SonicPoint” section on page 577.

Deploying VAPs to a SonicPoint
In the following section you will group and deploy your new VAPs, associating them with one
or more SonicPoint Radios. Users will not be able to access your VAPs until you complete this
process:
•

Grouping Multiple VAPs, page 577

•

Creating a SonicPoint Provisioning Profile, page 578

Grouping Multiple VAPs
In this section, you will group multiple VAPs into a single group to be associated with your
SoncPoint(s).
Step 1

In the left-hand menu, navigate to the SonicPoint > Virtual Access Point page.

Step 2

Click the Add Group... button in the Virtual Access Point Group section.

Step 3

Enter a Virtual AP Group Name.

Step 4

Select the desired VAPs from the list and click the -> button to add them to the group.
Optionally, click the Add All button to add all VAPs to a single group.

Step 5

Press the OK button to save changes and create the group.

SonicOS 5.8.1 Administrator Guide

577

SonicPoint > Virtual Access Point

Creating a SonicPoint Provisioning Profile
In this section, you will associate the group you created in the “Grouping Multiple VAPs” section
on page 577 with a SonicPoint by creating a provisioning profile. This profile will allow you to
provision settings from a group of VAPs to all of your SonicPoints.
Step 1

In the left-hand menu, navigate to the SonicPoint > SonicPoints page.

Step 2

Click the Add button in the SonicPoint Provisioning Profiles section.

Step 3

Click the Enable SonicPoint checkbox to enable this profile.

Step 4

In the Name Prefix field, enter a name for this profile.

Step 5

Select a Country Code from the drop-down list.

Step 6

From the 802.11 Radio Virtual AP Group pull-down list, select the group you created in the
“Grouping Multiple VAPs” section on page 577.

Step 7

To setup 802.11g WEP or 802.11a WEP/WPA encryption, or to enable MAC address filtering,
use the 802.11g and 802.11a tabs. If any of your VAPs use encryption, you must configure
these settings before your SonicPoint VAPs will function.

Step 8

Click the OK button to save changes and create this SonicPoint Provisioning Profile.

Step 9

Click the Synchronize SonicPoints button at the top of the screen to apply your provisioning
profile to available SonicPoints.
Your SonicPoint may take a moment to reboot before changes take place. After this process is
complete, all of your VAP profiles will be available to wireless users through this SonicPoint.

578

SonicOS 5.8.1 Administrator Guide

SonicPoint > Virtual Access Point

Associating a VAP Group with your SonicPoint
If you did not create a SonicPoint Provisioning Profile, you can provision your SonicPoint(s)
manually. You may want to use this method if you have only one SonicPoint to provision. This
section is not necessary if you have created and provisioned your SonicPoints using a
SonicPoint Profile.
Step 1

In the left-hand menu, navigate to the SonicPoint > SonicPoints page.

Step 2

Click the Configure button next to the SonicPoint you wish to associate your Virtual APs with.

Step 3

In the Virtual Access Point Settings section, select the VAP group you created in Grouping
Multiple VAPs, page 577 from the 802.11g (or 802.11a) Radio Virtual AP Group drop-down
list. In this case, we choose VAP as our Virtual AP Group.

Step 4

Click the OK button to associate this VAP Group with your SonicPoint.

Step 5

Click the Synchronize SonicPoints button at the top of the screen to apply your provisioning
profile to available SonicPoints.
Your SonicPoint may take a moment to reboot before changes take place. After this process is
complete, all of your VAP profiles will be available to wireless users through this SonicPoint.

Note

If you are setting up guest services for the first time, be sure to make necessary
configurations in the Users > Guest Services pages. For more information on configuring
guest services, refer to the SonicOS Enhanced Administrator’s Guide.

SonicOS 5.8.1 Administrator Guide

579

SonicPoint > Virtual Access Point

580

SonicOS 5.8.1 Administrator Guide

CHAPTER 45
Chapter 45:

Configuring RF Management

SonicPoint > RF Management
This chapter describes how to plan, design, implement, and maintain the RF Management
feature in SonicWALL SonicOS Enhanced. This chapter contains the following sections:
•

“RF Management Overview” section on page 582
– “Why RF Management?” section on page 582
– “Benefits” section on page 582

•

“Enabling RF Management on SonicPoint(s)” section on page 583

•

“Using The RF Management Interface” section on page 584
– “Selecting RF Signature Types” section on page 585
– “Viewing Discovered RF Threat Stations” section on page 585
– “Adding a Threat Station to the Watch List” section on page 586

•

“Types of RF Threat Detection” section on page 586

•

“Practical RF Management Field Applications” section on page 587
– “Before Reading this Section” section on page 588
– “Using Sensor ID to Determine RF Threat Location” section on page 588
– “Using RSSI to Determine RF Threat Proximity” section on page 589

SonicOS 5.8.1 Administrator Guide

581

SonicPoint > RF Management

RF Management Overview
The following section provides a brief overview of the RF Management feature found on
SonicWALL security appliances running SonicOS Enhanced 5.0 or higher. This section
contains the following subsections:
•

“Why RF Management?” section on page 582

•

“Benefits” section on page 582

Why RF Management?
Radio Frequency (RF) technology used in today’s 802.11-based wireless networking devices
poses an attractive target for intruders. If left un-managed, RF devices can leave your wireless
(and wired) network open to a variety of outside threats, from Denial of Service (DoS) to
network security breaches.
In order to help secure your SonicPoint Wireless Access Point (AP) stations, SonicWALL takes
a closer look at these threats. By using direct RF management, SonicWALL helps detect threats
without interrupting the current operation of your wireless or wired network.

Benefits
SonicWALL RF Management provides real-time threat monitoring and management of
SonicPoint radio frequency traffic. In addition to its real-time threat management capabilities,
SonicWALL RF Management provides network administrators a system for centralized
collection of RF threats and traffic statistics; offering a way to easily manage RF capabilities
directly from the SonicWALL security appliance gateway
SonicWALL RF Management is:

582

•

Real-Time - View logged information as it happens

•

Transparent - No need to halt legitimate network traffic when managing threats

•

Comprehensive - Provides detection of many types of RF threats. For complete
descriptions of the above types of RF Threat Detection, see the “Types of RF Threat
Detection” section on page 586.

SonicOS 5.8.1 Administrator Guide

SonicPoint > RF Management

Enabling RF Management on SonicPoint(s)
In order for RF Management to be enforced, you must enable the RF Management option on
all available SonicPoint de