Page 1
Security
Security
Network Security Firewall
User Manual
DFL-210/ 800/1600/ 2500
DFL-260/ 860
Ver. 1.05
Network Security Solution http://www.dlink.com
Page 2
User Manual
DFL-210/260/800/860/1600/2500
NetDefendOS version 2.12
No. 289, Sinhu 3rd Rd, Neihu District, Taipei City 114, Taiwan R.O.C.
D-Link Corporation
http://www.DLink.com
Published 2007-05-29
Copyright © 2007
Page 3
User Manual
DFL-210/260/800/860/1600/2500
NetDefendOS version 2.12
Published 2007-05-29
Copyright © 2007
Copyright Notice
This publication, including all photographs, illustrations and software, is protected under international copyright laws, with all rights reserved. Neither this manual, nor any of the material contained
herein, may be reproduced without written consent of the author.
Disclaimer
The information in this document is subject to change without notice. The manufacturer makes no
representations or warranties with respect to the contents hereof and specifically disclaim any implied warranties of merchantability or fitness for any particular purpose. The manufacturer reserves
the right to revise this publication and to make changes from time to time in the content hereof
without obligation of the manufacturer to notify any person of such revision or changes.
Limitations of Liability
UNDER NO CIRCUMSTANCES SHALL D-LINK OR ITS SUPPLIERS BE LIABLE FOR DAMAGES OF ANY CHARACTER (E.G. DAMAGES FOR LOSS OF PROFIT, SOFTWARE RESTORATION, WORK STOPPAGE, LOSS OF SAVED DATA OR ANY OTHER COMMERCIAL
DAMAGES OR LOSSES) RESULTING FROM THE APPLICATION OR IMPROPER USE OF
THE D-LINK PRODUCT OR FAILURE OF THE PRODUCT, EVEN IF D-LINK IS INFORMED
OF THE POSSIBILITY OF SUCH DAMAGES. FURTHERMORE, D-LINK WILL NOT BE LIABLE FOR THIRD-PARTY CLAIMS AGAINST CUSTOMER FOR LOSSES OR DAMAGES.
D-LINK WILL IN NO EVENT BE LIABLE FOR ANY DAMAGES IN EXCESS OF THE
AMOUNT D-LINK RECEIVED FROM THE END-USER FOR THE PRODUCT.
Page 4
Table of Contents
Preface .............................................................................................................. xii
1. Product Overview .............................................................................................. 1
1.1. About D-Link NetDefendOS ..................................................................... 1
1.2. NetDefendOS Architecture ....................................................................... 3
1.2.1. State-based Architecture ................................................................ 3
1.2.2. NetDefendOS Building Blocks ........................................................ 3
1.2.3. Basic Packet Flow ......................................................................... 3
1.3. NetDefendOS Packet Flow ........................................................................ 6
2. Operations and Maintenance ...............................................................................10
2.1. Configuring NetDefendOS .......................................................................10
2.1.1. Overview ...................................................................................10
2.1.2. Default User Accounts ..................................................................10
2.1.3. Command Line Interface (CLI) ......................................................11
2.1.4. Web Interface .............................................................................13
2.1.5. Working with Configurations .........................................................15
2.2. Events and Logging ................................................................................21
2.2.1. Overview ...................................................................................21
2.2.2. Event Messages ...........................................................................21
2.2.3. Event Message Distribution ...........................................................21
2.3. RADIUS Accounting ..............................................................................24
2.3.1. Overview ...................................................................................24
2.3.2. RADIUS Accounting messages ......................................................24
2.3.3. Interim Accounting Messages ........................................................26
2.3.4. Activating RADIUS Accounting .....................................................26
2.3.5. RADIUS Accounting Security ........................................................26
2.3.6. RADIUS Accounting and High Availability ......................................26
2.3.7. Handling Unresponsive Servers ......................................................27
2.3.8. Accounting and System Shutdowns .................................................27
2.3.9. Limitations with NAT'ed Networks .................................................27
2.4. Maintenance ..........................................................................................28
2.4.1. Reset to Factory Defaults ..............................................................28
2.4.2. Configuration Backup and Restore ..................................................28
2.4.3. Auto-Update Mechanism ...............................................................29
3. Fundamentals ...................................................................................................31
3.1. The Address Book ..................................................................................31
3.1.1. Overview ...................................................................................31
3.1.2. IP Addresses ...............................................................................31
3.1.3. Ethernet Addresses .......................................................................33
3.1.4. Address Groups ...........................................................................34
3.1.5. Auto-Generated Address Objects ....................................................34
3.2. Services ................................................................................................35
3.2.1. Overview ...................................................................................35
3.2.2. TCP and UDP Based Services ........................................................36
3.2.3. ICMP Services ............................................................................37
3.2.4. Custom IP Protocol Services ..........................................................38
3.3. Interfaces ..............................................................................................40
3.3.1. Overview ...................................................................................40
3.3.2. Ethernet .....................................................................................41
3.3.3. Virtual LAN ...............................................................................43
3.3.4. PPPoE .......................................................................................43
3.3.5. Interface Groups ..........................................................................45
3.4. ARP ....................................................................................................47
3.4.1. Overview ...................................................................................47
3.4.2. ARP in NetDefendOS ...................................................................47
3.4.3. ARP Cache .................................................................................47
3.4.4. Static and Published ARP Entries ....................................................48
3.4.5. Advanced ARP Settings ................................................................50
iv
Page 5
User Manual
3.5. The IP Rule-Set .....................................................................................52
3.5.1. Overview ...................................................................................52
3.5.2. Rule Evaluation ...........................................................................52
3.5.3. IP Rule components .....................................................................53
3.5.4. Editing IP Rule-set Entries .............................................................54
3.6. Schedules .............................................................................................55
3.7. X.509 Certificates ..................................................................................57
3.7.1. Overview ...................................................................................57
3.7.2. The Certification Authority ............................................................57
3.7.3. Validity Time ..............................................................................57
3.7.4. Certificate Revocation Lists ...........................................................57
3.7.5. Trusting Certificates .....................................................................58
3.7.6. Identification Lists .......................................................................58
3.7.7. X.509 Certificates in NetDefendOS .................................................58
3.8. Setting Date and Time .............................................................................59
3.8.1. General Date and Time Settings ......................................................59
3.8.2. Time Servers ..............................................................................60
3.9. DNS Lookup .........................................................................................64
4. Routing ...........................................................................................................66
4.1. Overview ..............................................................................................66
4.2. Static Routing ........................................................................................67
4.2.1. Static Routing in NetDefendOS ......................................................68
4.2.2. Route Failover ............................................................................71
4.2.3. Proxy ARP .................................................................................75
4.3. Policy-based Routing ..............................................................................76
4.3.1. Overview ...................................................................................76
4.3.2. Policy-based Routing Tables ..........................................................76
4.3.3. Policy-based Routing Rules ...........................................................76
4.3.4. Policy-based Routing Table Selection ..............................................77
4.3.5. The Ordering parameter ................................................................77
4.4. Dynamic Routing ...................................................................................80
4.4.1. Dynamic Routing overview ...........................................................80
4.4.2. OSPF ........................................................................................81
4.4.3. Dynamic Routing Policy ...............................................................84
4.5. Transparent Mode ..................................................................................88
4.5.1. Overview of Transparent Mode ......................................................88
4.5.2. Comparison with Routing mode .....................................................88
4.5.3. Transparent Mode implementation ..................................................88
4.5.4. Enabling Transparent Mode ...........................................................89
4.5.5. Transparent Mode example scenarios ..............................................89
5. DHCP Services ................................................................................................96
5.1. Overview ..............................................................................................96
5.2. DHCP Servers .......................................................................................97
5.3. Static DHCP Assignment .........................................................................99
5.4. DHCP Relaying ................................................................................... 100
6. Security Mechanisms ....................................................................................... 102
6.1. Access Rules ....................................................................................... 102
6.1.1. Introduction ..............................................................................102
6.1.2. IP spoofing ............................................................................... 102
6.1.3. Access Rule Settings .................................................................. 103
6.2. Application Layer Gateways ................................................................... 105
6.2.1. Overview .................................................................................105
6.2.2. Hyper Text Transfer Protocol ....................................................... 105
6.2.3. File Transfer Protocol ................................................................. 105
6.2.4. Simple Mail Transfer Protocol ......................................................110
6.2.5. H.323 ...................................................................................... 111
6.3. Intrusion Detection and Prevention .......................................................... 125
6.3.1. Overview .................................................................................125
6.3.2. IDP Availability in D-Link Models ............................................... 125
6.3.3. IDP Rules ................................................................................. 126
6.3.4. Insertion/Evasion Attack Prevention .............................................. 127
6.3.5. IDP Pattern Matching ................................................................. 128
6.3.6. IDP Signature Groups ................................................................. 129
v
Page 6
User Manual
6.3.7. IDP Actions ..............................................................................131
6.3.8. SMTP Log Receiver for IDP Events .............................................. 131
6.4. Anti-Virus .......................................................................................... 135
6.4.1. Overview .................................................................................135
6.4.2. Implementation ......................................................................... 135
6.4.3. Activation ................................................................................ 136
6.4.4. The Signature Database .............................................................. 136
6.4.5. Subscribing to the D-Link Anti-Virus Service ................................. 136
6.4.6. Anti-Virus Options ..................................................................... 137
6.5. Web Content Filtering ........................................................................... 140
6.5.1. Overview .................................................................................140
6.5.2. Active Content Handling ............................................................. 140
6.5.3. Static Content Filtering ...............................................................141
6.5.4. Dynamic Content Filtering .......................................................... 143
6.6. Denial-Of-Service (DoS) Attacks ............................................................155
6.6.1. Overview .................................................................................155
6.6.2. DoS Attack Mechanisms ............................................................. 155
6.6.3. Ping of Death and Jolt Attacks ..................................................... 155
6.6.4. Fragmentation overlap attacks: Teardrop, Bonk, Boink and Nestea ...... 156
6.6.5. The Land and LaTierra attacks ..................................................... 156
6.6.6. The WinNuke attack ................................................................... 156
6.6.7. Amplification attacks: Smurf, Papasmurf, Fraggle ........................... 157
6.6.8. TCP SYN Flood Attacks ............................................................. 158
6.6.9. The Jolt2 Attack ........................................................................158
6.6.10. Distributed DoS Attacks ............................................................ 158
6.7. Blacklisting Hosts and Networks ............................................................. 159
7. Address Translation ........................................................................................ 161
7.1. Dynamic Address Translation (NAT) .......................................................161
7.1.1. Which Protocols can NAT handle? ................................................ 162
7.2. Static Address Translation (SAT) ............................................................ 164
7.2.1. Translation of a Single IP Address (1:1) ......................................... 164
7.2.2. Translation of Multiple IP Addresses (M:N) .................................... 167
7.2.3. All-to-One Mappings (N:1) ......................................................... 169
7.2.4. Port Translation ......................................................................... 170
7.2.5. Which Protocols can SAT handle? ................................................170
7.2.6. Which SAT Rule is executed if several are matching? .......................171
7.2.7. SAT and FwdFast Rules ..............................................................171
8. User Authentication ........................................................................................ 174
8.1. Overview ............................................................................................ 174
8.1.1. Authentication Methods .............................................................. 174
8.1.2. Choosing Passwords ................................................................... 174
8.1.3. User Types ............................................................................... 175
8.2. Authentication Components ................................................................... 176
8.2.1. The Local User Database (UserDB) ...............................................176
8.2.2. External Authentication Servers .................................................... 176
8.2.3. Authentication Agents ................................................................ 176
8.2.4. Authentication Rules ..................................................................177
8.3. Authentication Process .......................................................................... 178
9. Virtual Private Networks ..................................................................................181
9.1. VPN overview ..................................................................................... 181
9.1.1. The need for VPNs .....................................................................181
9.1.2. The basics of VPN Encryption ..................................................... 181
9.1.3. Planning a VPN ......................................................................... 181
9.2. IPsec .................................................................................................. 183
9.2.1. IPsec Basics .............................................................................. 183
9.2.2. Proposal Lists ........................................................................... 192
9.2.3. Pre-shared Keys ........................................................................ 193
9.2.4. Identification Lists .....................................................................193
9.3. IPsec Tunnels ...................................................................................... 196
9.3.1. Overview of IPsec tunnels ...........................................................196
9.3.2. LAN to LAN tunnels with a Pre-shared Key ................................... 196
9.3.3. Roaming Clients ........................................................................ 196
9.3.4. Fetching CRLs from an alternate LDAP server ................................ 200
vi
Page 7
User Manual
9.4. PPTP/L2TP ......................................................................................... 202
9.4.1. PPTP .......................................................................................202
9.4.2. L2TP .......................................................................................203
10. Traffic Management ......................................................................................209
10.1. Traffic Shaping ..................................................................................209
10.1.1. Introduction ............................................................................ 209
10.1.2. Traffic Shaping Basics ..............................................................209
10.1.3. Traffic Shaping in NetDefendOS ................................................. 210
10.1.4. Pipes Basics ............................................................................ 211
10.1.5. Priorities and Guarantees ........................................................... 214
10.1.6. Grouping Users of a Pipe ........................................................... 219
10.2. Threshold Rules ................................................................................. 221
10.2.1. Overview ................................................................................ 221
10.2.2. Connection Rate/Total Connection Limiting .................................. 221
10.2.3. Grouping ................................................................................ 221
10.2.4. Rule Actions ...........................................................................221
10.2.5. Multiple Triggered Actions ........................................................ 222
10.2.6. Exempted Connections .............................................................. 222
10.2.7. Threshold Rules and ZoneDefense .............................................. 222
10.2.8. Threshold Rule Blacklisting ....................................................... 222
10.3. Server Load Balancing ........................................................................ 223
10.3.1. Overview ................................................................................ 223
10.3.2. Identifying the Servers ..............................................................224
10.3.3. The Load Distribution Mode ......................................................224
10.3.4. The Distribution Algorithm ........................................................ 224
10.3.5. Server Health Monitoring .......................................................... 226
10.3.6. SLB_SAT Rules ...................................................................... 226
11. High Availability .......................................................................................... 229
11.1. Overview .......................................................................................... 229
11.2. How rapid failover is accomplished ........................................................ 231
11.2.1. Shared IP addresses and Failover ................................................ 231
11.2.2. Cluster heartbeats .....................................................................231
11.2.3. The synchronization interface ..................................................... 232
11.3. High Availability Issues ....................................................................... 233
11.3.1. High Availability Configuration .................................................. 233
12. ZoneDefense ................................................................................................ 235
12.1. Overview .......................................................................................... 235
12.2. ZoneDefense Switches ......................................................................... 236
12.3. ZoneDefense Operation ....................................................................... 237
12.3.1. SNMP .................................................................................... 237
12.3.2. Threshold Rules ....................................................................... 237
12.3.3. Manual Blocking and Exclude Lists ............................................. 238
12.3.4. Limitations ............................................................................. 239
13. Advanced Settings ......................................................................................... 241
13.1. IP Level Settings ................................................................................ 241
13.2. TCP Level Settings ............................................................................. 245
13.3. ICMP Level Settings ........................................................................... 249
13.4. ARP Settings .....................................................................................250
13.5. Stateful Inspection Settings ................................................................... 252
13.6. Connection Timeouts ..........................................................................254
13.7. Size Limits by Protocol ........................................................................ 255
13.8. Fragmentation Settings ........................................................................ 257
13.9. Local Fragment Reassembly Settings ..................................................... 261
13.10. DHCP Settings ................................................................................. 262
13.11. DHCPRelay Settings ......................................................................... 263
13.12. DHCPServer Settings ........................................................................ 264
13.13. IPsec Settings ................................................................................... 265
13.14. Transparent Mode Settings ................................................................. 267
13.15. Logging Settings ...............................................................................269
13.16. High Availability Settings .................................................................. 270
13.17. Time Synchronization Settings ............................................................ 271
13.18. DNS Client Settings .......................................................................... 273
13.19. HTTP Poster Settings ........................................................................ 274
vii
Page 8
User Manual
13.20. PPP Settings .................................................................................... 275
13.21. IDP ................................................................................................ 276
13.22. Hardware Monitor Settings ................................................................. 277
13.23. Packet Re-assembly Settings ............................................................... 278
13.24. Miscellaneous Settings ....................................................................... 279
A. Subscribing to Security Updates ........................................................................ 281
B. IDP Signature Groups .....................................................................................283
C. Anti-Virus MIME filetypes .............................................................................. 287
D. The OSI Framework ....................................................................................... 291
E. D-Link worldwide offices ................................................................................ 292
Alphabetical Index ............................................................................................. 294
viii
Page 9
List of Figures
1.1. Packet Flow Schematic Part I ............................................................................ 6
1.2. Packet Flow Schematic Part II ........................................................................... 7
1.3. Packet Flow Schematic Part III .......................................................................... 8
4.1. A Route Failover Scenario for ISP Access ...........................................................71
4.2. Virtual Links Example 1 ..................................................................................83
4.3. Virtual Links Example 2 ..................................................................................84
4.4. Transparent mode scenario 1 ............................................................................89
4.5. Transparent mode scenario 2 ............................................................................91
6.1. IDP Database Updating ................................................................................. 126
6.2. Dynamic Content Filtering Flow .....................................................................143
9.1. The AH protocol .......................................................................................... 190
9.2. The ESP protocol ......................................................................................... 190
10.1. Packet flow through pipes ............................................................................ 211
10.2. The Eight Pipe Precedences. .........................................................................214
10.3. A Pipe defined with minimum precedence and maximum precedence. .................. 215
10.4. A pipe with traffic in one precedence, grouped per IP address. ............................ 219
10.5. A Server Load Balancing configuration ..........................................................223
10.6. Connections from Three Clients .................................................................... 225
10.7. Stickiness and Round-Robin ......................................................................... 225
10.8. Stickiness and Connection Rate .....................................................................226
11.1. High Availability Setup Example ................................................................... 230
D.1. The 7 layers of the OSI model ........................................................................ 291
ix
Page 10
List of Examples
1. Example notation ............................................................................................. xii
2.1. Enabling SSH Remote Access ..........................................................................12
2.2. Enabling remote management via HTTPS. ..........................................................14
2.3. Listing Configuration Objects ...........................................................................16
2.4. Displaying a Configuration Object .....................................................................16
2.5. Editing a Configuration Object .........................................................................17
2.6. Adding a Configuration Object .........................................................................17
2.7. Deleting a Configuration Object ........................................................................18
2.8. Undeleting a Configuration Object ....................................................................18
2.9. Listing Modified Configuration Objects ..............................................................19
2.10. Activating and Committing a Configuration .......................................................20
2.11. Enable Logging to a Syslog Host .....................................................................22
2.12. Reset to Factory Defaults with the standard user interface .....................................28
2.13. Configuration Backup and Restore ...................................................................28
3.1. Adding an IP Host ..........................................................................................32
3.2. Adding an IP Network .....................................................................................32
3.3. Adding an IP Range ........................................................................................32
3.4. Deleting an Address Object ..............................................................................33
3.5. Adding an Ethernet Address .............................................................................33
3.6. Listing the Available Services ...........................................................................35
3.7. Viewing a Specific Service ..............................................................................35
3.8. Adding a TCP/UDP Service .............................................................................37
3.9. Adding a IP Protocol Service ............................................................................39
3.10. Enabling DHCP ...........................................................................................42
3.11. Defining a virtual LAN ..................................................................................43
3.12. Configuring a PPPoE client on the wan interface with traffic routed over PPPoE. .....45
3.13. Creating an Interface Group ............................................................................45
3.14. Displaying the ARP Cache .............................................................................48
3.15. Flushing the ARP Cache ................................................................................48
3.16. Defining a Static ARP Entry ...........................................................................49
3.17. Setting up a Time-Scheduled Policy .................................................................55
3.18. Uploading an X.509 Certificate .......................................................................58
3.19. Setting the Current Date and Time ...................................................................59
3.20. Setting the Time Zone ...................................................................................60
3.21. Enabling DST ..............................................................................................60
3.22. Enabling Time Synchronization using SNTP ......................................................61
3.23. Manually Triggering a Time Synchronization ....................................................62
3.24. Modifying the Maximum Adjustment Value ......................................................62
3.25. Forcing Time Synchronization ........................................................................62
3.26. Enabling the D-Link NTP Server .....................................................................63
3.27. Configuring DNS Servers ...............................................................................64
4.1. Displaying the Routing Table ...........................................................................69
4.2. Displaying the Core Routes ..............................................................................70
4.3. Creating a Policy-Based Routing table ................................................................78
4.4. Creating the Route ..........................................................................................78
4.5. Policy Based Routing Configuration ..................................................................78
4.6. Importing Routes from an OSPF AS into the Main Routing Table ...........................85
4.7. Exporting the Default Route into an OSPF AS .....................................................86
4.8. Setting up Transparent Mode - Scenario 1 ...........................................................90
4.9. Setting up Transparent Mode - Scenario 2 ...........................................................91
5.1. Setting up a DHCP server ................................................................................97
5.2. Checking the status of a DHCP server ................................................................98
5.3. Setting up Static DHCP ...................................................................................99
5.4. Setting up a DHCP relayer ............................................................................. 100
6.1. Setting up an Access Rule .............................................................................. 104
6.2. Protecting an FTP Server with ALG ................................................................. 106
6.3. Protecting FTP Clients .................................................................................. 109
6.4. Protecting Phones Behind D-Link Firewalls ...................................................... 113
x
Page 11
User Manual
6.5. H.323 with private IP addresses ...................................................................... 114
6.6. Two Phones Behind Different D-Link Firewalls ................................................. 115
6.7. Using Private IP Addresses ............................................................................ 116
6.8. H.323 with Gatekeeper ..................................................................................118
6.9. H.323 with Gatekeeper and two D-Link Firewalls .............................................. 119
6.10. Using the H.323 ALG in a Corporate Environment ........................................... 120
6.11. Configuring remote offices for H.323 ............................................................. 123
6.12. Allowing the H.323 Gateway to register with the Gatekeeper .............................. 123
6.13. Configuring an SMTP Log Receiver .............................................................. 131
6.14. Setting up IDP for a Mail Server .................................................................... 132
6.15. Enabling Anti-Virus Scanning ....................................................................... 138
6.16. Stripping ActiveX and Java applets ................................................................ 141
6.17. Setting up a white and blacklist ..................................................................... 142
6.18. Enable Dynamic Content Filtering ................................................................. 144
6.19. Enabling Audit Mode .................................................................................. 145
6.20. Reclassifying a blocked site .......................................................................... 147
7.1. Adding a NAT Policy ................................................................................... 162
7.2. Enabling Traffic to a Protected Web Server in a DMZ ......................................... 164
7.3. Enabling Traffic to a Web Server on an Internal Network .................................... 166
7.4. Translating Traffic to Multiple Protected Web Servers ........................................ 168
8.1. Creating an authentication user group ............................................................... 178
9.1. Using a Proposal List .................................................................................... 192
9.2. Using a Pre-Shared key .................................................................................193
9.3. Using an Identity List .................................................................................... 194
9.4. Setting up a PSK based VPN tunnel for roaming clients .......................................197
9.5. Setting up a Self-signed Certificate based VPN tunnel for roaming clients ...............198
9.6. Setting up a CA Server issued Certificate based VPN tunnel for roaming clients ....... 199
9.7. Setting up an LDAP server ............................................................................. 200
9.8. Setting up a PPTP server ................................................................................ 202
9.9. Setting up an L2TP server .............................................................................. 203
9.10. Setting up an L2TP Tunnel ........................................................................... 204
10.1. Applying a Simple Bandwidth Limit .............................................................. 211
10.2. Applying a Two-Way Bandwidth Limit .......................................................... 213
12.1. A simple ZoneDefense scenario .................................................................... 238
xi
Page 12
Preface
Intended audience
The target audience for this reference guide is Administrators who are responsible for configuring
and managing D-Link Firewalls which are running the NetDefendOS operating system. This guide
assumes that the reader has some basic knowledge of networks and network security.
Text structure and conventions
The text is broken down into chapters and subsections. Numbered subsections are shown in the table
of contents at the beginning. An index is included at the end of the document to aid with alphabetical lookup of subjects.
Where a "See section" link (such as: see ) is provided in the main text this can be clicked to take the
reader directly to that reference.
Text that may appear in the user interface of the product is designated by being in Bold Case.
Where is term is being introduced for the first time or being stressed it may appear in a italics.
Where console interaction is shown in the main text outside of an example this will appear in a box
with a gray background:
gw-world:/>
Where a web address reference is shown in the text this will open the specified URL in a browser in
a new window when clicked (some systems may not allow this). For example: http://www.dlink.com.
Examples
Examples in the text are denoted by the header Example and appear with a gray background as
shown below. They contain a CLI example and/or a Web Interface example as appropriate. (The accompanying "CLI Reference Guide" documents all CLI commands).
Example 1. Example notation
Information about what the example is trying to achieve is found here, sometimes with an explanatory image.
CLI
The Command Line Interface example would appear here. It would start with the command prompt followed by
the command:
gw-world:/> somecommand someparameter=somevalue
Web Interface
The Web Interface actions for the example are shown here. They are typically a numbered list showing what
items in the tree-view list at the left of the interface or in the menu bar or in a context menu need to be opened followed by information about the data items that need to be entered:
1. Go to Item X > Item Y > Item Z
2. Now enter:
• DataItem1: datavalue1
• DataItem2: datavalue2
xii
Page 13
Notes to the main text Preface
Notes to the main text
Special sections of text which the reader should pay special attention to are indicated by icons on the
the left hand side of the page followed by a short paragraph in italicized text. Such sections have the
following types and purposes:
Note
This indicates some piece of information that is an addition to the preceding text. It
may concern something that is being emphasised or something that is not obvious or
explicitly stated in the preceding text.
Tip
This indicates a piece of non-critical information that is useful to know in certain situations but is not essential reading.
Caution
This indicates where the reader should be careful with their actions as an undesirable
situation may result if care is not exercised.
Important
This is an essential point that the reader should read and understand.
Warning
This is essential reading for the user as they should be aware that a serious situation
may result if certain actions are taken or not taken.
xiii
Page 14
Chapter 1. Product Overview
This chapter outlines the key features of NetDefendOS.
• About D-Link NetDefendOS, page 1
• NetDefendOS Architecture, page 3
• NetDefendOS Packet Flow, page 6
1.1. About D-Link NetDefendOS
D-Link NetDefendOS is the firmware, the software engine that drives and controls all D-Link Firewall products.
Designed as a network security operating system, NetDefendOS features high throughput performance with high reliability plus super-granular control. In contrast to products built on standard operating systems such as Unix or Microsoft Windows, NetDefendOS offers seamless integration of all
subsystems, in-depth administrative control of all functionality as well as a minimal attack surface
which helps negate the risk of being a target for security attacks.
From the administrator's perspective the conceptual approach of NetDefendOS is to visualize operations through a set of logical building blocks or objects, which allow the configuration of the
product in an almost limitless number of different ways. This granular control allows the administrator to meet the requirements of the most demanding network security scenario.
NetDefendOS is an extensive and feature-rich network operating system. The list below presents the
most essential features:
IP Routing
Address Translation
Firewalling
NetDefendOS provides a variety of options for IP routing including static routing, dynamic routing, multicast routing and
advanced virtual routing capabilities. In addition, NetDefendOS supports features such as Virtual LANs, Route Monitoring, Proxy ARP and Transparency. For more information,
please see Chapter 4, Routing.
For functionality as well as security reasons, NetDefendOS
supports policy-based address translation. Dynamic Address
Translation (NAT) as well as Static Address Translation
(SAT) is supported, and resolves most types of address translation needs. This feature is covered in Chapter 7, Address
Translation.
At the heart of the product, NetDefendOS features stateful inspection-based firewalling for common protocols such as
TCP, UDP and ICMP. As an administrator, you have the possibility to define detailed firewalling policies based on source
and destination network and interface, protocol, ports, user
credentials, time-of-day and much more. Section 3.5, “The IP
Rule-Set”, describes how to use the firewalling aspects of
NetDefendOS.
Intrusion Detection and Prevention
To mitigate application-layer attacks towards vulnerabilities
in services and applications, NetDefendOS provides a powerful Intrusion Detection and Prevention (IDP) engine. The IDP
engine is policy-based and is able to perform highperformance scanning and detection of attacks and can perform blocking and optional black-listing of attacking hosts.
1
Page 15
1.1. About D-Link NetDefendOS Chapter 1. Product Overview
For more information about the IDP capabilities of NetDefendOS, please see Section 6.3, “Intrusion Detection and Prevention”.
Anti-Virus
Web Content Filtering
Virtual Private Networking
Traffic Management
NetDefendOS features integrated gateway anti-virus functionality. Traffic passing through the gateway can be subjected to
in-depth scanning for viruses, and attacking hosts can be
blocked and black-listed at your choice. Section 6.4,
“Anti-Virus”, provides more information about how to use
the integrated anti-virus feature.
NetDefendOS provides various mechanisms for filtering web
content that is deemed inappropriate according to your web
usage policy. Web content can be blocked based on category,
malicious objects can be removed and web sites can be
whitelisted or blacklisted in multiple policies. For more information, please see Section 6.5, “Web Content Filtering”.
A device running NetDefendOS is highly suitable for participating in a Virtual Private Network (VPN). NetDefendOS
supports IPsec, L2TP and PPTP based VPNs concurrently,
can act as either server or client for all of the VPN types, and
can provide individual security policies for each VPN tunnel.
Virtual Private Networking is covered in detail by Chapter 9,
Virtual Private Networks.
With the support of Traffic Shaping, Threshold Rules and
Server Load Balancing features, NetDefendOS is optimal for
traffic management. The Traffic Shaping feature enables finegranular limiting and balancing of bandwidth; Threshold
Rules allows for implementing various types of thresholds
where to alarm or limit network traffic, and Server Load Balancing enables a device running NetDefendOS to distribute
network load to multiple hosts. Chapter 10, Traffic Manage-
ment, provides more detailed information on the various
traffic management capabilities.
Operations and Maintenance
ZoneDefense
Reading through this documentation carefully will ensure that you get the most out of your NetDefendOS product. In addition to this document, the reader should also be aware of the companion
volumes:
• The NetDefendOS CLI Guide which details all NetDefendOS console commands.
• The NetDefendOS Log Reference Guide which details all NetDefendOS log event messages.
These documents together form the essential documentation for NetDefendOS operation.
To facilitate management of a NetDefendOS device, administrative control is enabled through a Web-based User Interface
or via the Command Line Interface. In addition, NetDefendOS provides very detailed event and logging capabilities and
support for monitoring using standards such as SNMP. For
more information, please see Chapter 2, Operations and
Maintenance.
NetDefendOS can be used to control D-Link switches using
the ZoneDefense feature.
Note
High Availability, Anti-Virus, Web Content Filtering and ZoneDefense are not available with some models as specified in the chapters relating to those features.
2
Page 16
1.2. NetDefendOS Architecture Chapter 1. Product Overview
1.2. NetDefendOS Architecture
1.2.1. State-based Architecture
The NetDefendOS architecture is centered around the concept of state-based connections. Traditional IP routers or switches commonly inspect all packets and then perform forwarding decisions based
on information found in the packet headers. With this approach, packets are forwarded without any
sense of context which basically eliminates any possibility to detect and analyze complex protocols
and enforce corresponding security policies.
A NetDefendOS device, on the contrary, will inspect and forward traffic on a per-connection basis.
In other words, NetDefendOS is able to detect when a new connection is being established, and then
keeps a small piece of information, a "state", for the entire life-length of that connection. By doing
this, NetDefendOS is able to understand the context of the network traffic, which enables the device
to perform in-depth traffic scanning, apply bandwidth management and much more. In addition, this
approach provides high throughput performance with the added advantage of a design that is highly
scalable.
1.2.2. NetDefendOS Building Blocks
The basic building blocks in NetDefendOS are interfaces, logical objects and various types of rules
(or rule-sets).
Interfaces are the doorways for network traffic passing through, to or from the system. Without interfaces, a NetDefendOS system has no means for receiving or sending traffic. Several types of interfaces are supported; Physical Interfaces, Physical Sub-Interfaces and Tunnel Interfaces. Physical
interfaces corresponds to actual physical Ethernet ports; physical sub-interfaces include VLAN and
PPPoE interfaces while tunnel interfaces are used for receiving and sending traffic in VPN tunnels.
The NetDefendOS interface design is symmetric, meaning that the interfaces of the device are not
fixed as being on the "insecure outside" or "secure inside" of a network topology. The notion of
what is inside and outside is totally for the administrator to define.
Logical objects can be seen as pre-defined building blocks for use by the rule-sets. The address
book, for instance, contains named objects representing host and network addresses. Another example of logical objects are services , representing specific protocol and port combinations. Also
important objects are the Application Layer Gateway (ALG) objects, used for defining additional
parameters on specific protocols such as HTTP, FTP, SMTP and H.323.
Finally, the various rule-sets are used for actually implementing the policies in the system. The most
fundamental rule-set is the IP Rules, which is used to define the layer 3 IP filtering policy as well as
carrying out address translation and server load balancing. The Traffic Shaping Rules define the
policy for bandwidth management, the IPS Rules controls the behavior of the intrusion prevention
engine and so forth.
1.2.3. Basic Packet Flow
This section outlines the basic flow for packets received and forwarded by a NetDefendOS device.
Please note that this description is simplified to ease the understanding and might not be fully applicable in all scenarios. The basic principle, however, is still valid in all applications.
1. An Ethernet frame is received on one of the Ethernet interfaces in the system. Basic Ethernet
frame validation is performed and the packet is dropped if the frame is invalid.
2. The packet is associated with a Source Interface. The source interface is determined as follows:
• If the Ethernet frame contains a VLAN ID (Virtual LAN identifier), the system checks for a
configured VLAN interface with a corresponding VLAN ID. If one is found, that VLAN
interface becomes the source interface for the packet. If no matching interface is found, the
packet is dropped and the event is logged.
3
Page 17
1.2.3. Basic Packet Flow Chapter 1. Product Overview
• If the Ethernet frame contains a PPP payload, the system checks for a matching PPPoE interface. If one is found, that interface becomes the source interface for the packet. If no
matching interface is found, the packet is dropped and the event is logged.
• If none the above is true, the receiving Ethernet interface becomes the source interface for
the packet.
3. The IP datagram within the packet is passed on to the NetDefendOS Consistency Checker. The
consistency checker performs a number of sanity checks on the packet, including validation of
checksums, protocol flags, packet length and so forth. If the consistency checks fail, the packet
gets dropped and the event is logged.
4. NetDefendOS now tries to lookup an existing connection by matching parameters from the incoming packet. A number of parameters are used in the match attempt, including the source interface, source and destination IP addresses, IP protocol and so forth.
If a match cannot be found, a connection establishment process starts which includes steps 5 to
10 below. If a match is found, the forwarding process continues at step 11 below.
5. The source interface is examined to find out if the interface is a member of a specific routing
table. Also, the Virtual Routing Rules are evaluated to determine the correct routing table for
the connection.
6. The Access rules are evaluated to find out if the source IP address of the new connection is allowed on the received interface. If no access rule matches then a reverse route lookup will be
done. In other words, by default, an interface will only accept source IP addresses that belong
to networks routed over that interface. If the access rules or the reverse route lookup determine
that the source IP is invalid, then the packet is dropped and the event is logged.
7. A route lookup is being made using the appropriate routing table. The destination interface for
the connection has now been determined.
8. The IP rules are now searched for a rule that matches the packet. Basically, the following parameters are part of the matching process: Source and destination interfaces, source and destination network, IP protocol (TCP, UDP, ICMP etc), TCP/UDP ports or ICMP types and schedule
(time-of-day).
If a match cannot be found, the packet is dropped.
If a rule is found that matches the new connection, the Action parameter of the rule decides
what NetDefendOS should do with the connection. If the action is Drop, the packet is dropped
and the event is logged according to the log settings for the rule.
If the action is Allow, the packet is allowed through the system. A corresponding state will be
added to the connection table for matching subsequent packets belonging to the same connection. In addition, the Service object which matched the IP protocol and ports might have contained a reference to an Application Layer Gateway (ALG) object. This information is recorded
in the state so that NetDefendOS will know that application layer processing will have to be
performed on the connection.
Finally, the opening of the new connection will be logged according to the log settings of the
rule.
Note
There are actually a number of additional actions available such as address
translation and server load balancing. The basic concept of dropping and allowing traffic is still the same.
9. The Intrusion Detection and Prevention (IDP) Rules are now evaluated in a similar way to the
IP rules. If a match is found, the IDP data is recorded with the state. By doing this, NetDefendOS will know that IDP scanning is supposed to be conducted on all packets belonging to this
4
Page 18
1.2.3. Basic Packet Flow Chapter 1. Product Overview
connection.
10. The Traffic Shaping and the Threshold Limit Rule-sets are now searched. If a match is found,
the corresponding information is recorded with the state. This will enable proper traffic management on the connection.
11. From the information in the state, NetDefendOS now knows what to do with the incoming
packet:
• If ALG information is present or if IDP scanning is to be performed, the payload of the
packet is taken care of by the TCP Pseudo-Reassembly subsystem, which in turn makes use
of the different Application Layer Gateways, layer 7 scanning engines and so forth, to further analyze or transform the traffic.
• If the contents of the packet is encapsulated (i.e. being IPsec, L2TP/PPTP or some other
type of tunneled traffic), the interface lists are checked for a matching interface. If one is
found, the packet is decapsulated and the payload (the plaintext) is sent into NetDefendOS
again, now with source interface being the matched tunnel interface. In other words, the
process continues at step 3 above.
• If traffic management information is present, the packet might get queued or otherwise be
subjected to actions related to traffic management.
12. Eventually, the packet will be forwarded out on the destination interface according to the state.
If the destination interface is a tunnel interface or a physical sub-interface, additional processing such as encryption, and encapsulation and so forth might occur.
The following section provides a set of diagrams which illustrate the flow of packets through NetDefendOS.
5
Page 19
1.3. NetDefendOS Packet Flow Chapter 1. Product Overview
1.3. NetDefendOS Packet Flow
The diagrams in this section provide a summary of the flow of packets through the NetDefendOS
state-engine. There are three diagrams, each flowing into the next.
Figure 1.1. Packet Flow Schematic Part I
The packet flow is continued on the following page.
6
Page 20
1.3. NetDefendOS Packet Flow Chapter 1. Product Overview
Figure 1.2. Packet Flow Schematic Part II
The packet flow is continued on the following page.
7
Page 21
1.3. NetDefendOS Packet Flow Chapter 1. Product Overview
Figure 1.3. Packet Flow Schematic Part III
8
Page 22
1.3. NetDefendOS Packet Flow Chapter 1. Product Overview
9
Page 23
Chapter 2. Operations and Maintenance
This chapter describes the operations and maintenance related aspects of NetDefendOS.
• Configuring NetDefendOS, page 10
• Events and Logging, page 21
• RADIUS Accounting, page 24
• Maintenance, page 28
2.1. Configuring NetDefendOS
2.1.1. Overview
NetDefendOS is designed to give both high performance and high reliability. Not only does it
provide an extensive feature set, it also enables the administrator to be in full control of almost every
detail of the system. This means the product can be deployed in the most challenging environments.
A good understanding on how NetDefendOS configuration is performed is crucial for proper usage
of the system. For this reason, this section provides an in-depth presentation of the configuration
subsystem as well as a description of how to work with the various management interfaces.
NetDefendOS provides the following management interfaces:
Web User Interface
Command Line Interface (CLI)
The Web User Interface provides a user-friendly and intuitive
graphical management interface, accessible from a standard
web browser.
The Command Line Interface, accessible locally via serial
console port or remotely using the Secure Shell (SSH) protocol, provides the most fine-granular control over all parameters in NetDefendOS.
Note
Microsoft Internet Explorer and Firefox are the recommended web-browsers for the
web interface. Other browsers may not provide full support.
Access to a management interface is regulated by a remote management policy, where you can restrict management access based on source network, source interface, credentials and so forth. The
remote management policy provides a detailed and comprehensive control of all management capabilities. For instance, access to the web interface can be permitted to administrative users on a certain network, while at the same time allowing CLI access for a remote administrator connecting
through a specific IPsec tunnel.
By default, Web User Interface access is enabled for users on the network connected via the LAN
interface of the firewall (on products where more than one LAN interface is available, LAN1 is the
default).
2.1.2. Default User Accounts
NetDefendOS offers several possibilities for storing user information, either using local user databases or external databases.
10
Page 24
2.1.3. Command Line Interface (CLI) Chapter 2. Operations and Maintenance
By default, NetDefendOS has a local user database, AdminUsers, with one user account pre-defined:
• Username admin with password admin.
The admin account has full administrative rights.
Important
For security reasons, it is highly recommended that you change the default password
of the default account as soon as possible.
Extra user accounts can be created. These accounts can belong to the "Administrators" user group,
in which case they have complete read/write access. Or a user can belong to the "Auditors" user
group, in which case they have "read-only" access. For more detailed information about user authentication, please see Chapter 8, User Authentication.
2.1.3. Command Line Interface (CLI)
NetDefendOS provides a Command Line Interface (CLI) for administrators that prefer or require a
command-line approach, or who need more granular control of system configuration. The CLI is
available either locally through the serial console port, or remotely using the Secure Shell ("SSH")
protocol.
The CLI provides a comprehensive set of commands that allow the display and modification of configuration data as well as allowing runtime data to be displayed and allowing system maintenance
tasks to be performed.
For a complete reference to all CLI commands, please see the D-Link CLI Reference Guide.
2.1.3.1. CLI Access Methods
Serial Console Port
The serial console port is a RS-232 port that enables access to the CLI through a serial connection to
a PC or terminal. To locate the serial console port on your D-Link system, please see the D-Link
quickstart guide .
To use the console port, you need the following equipment:
• A terminal or a (portable) computer with a serial port and the ability to emulate a terminal (i.e.
using the Hyper Terminal software included in most Microsoft Windows installations). The serial console port uses the following default settings: 9600 baud, No parity, 8 bits and 1 stop bit.
• A RS-232 cable with appropriate connectors. An appliance package includes a RS-232 null-
modem cable.
To connect a terminal to the console port, follow these steps:
1. Set the terminal protocol as described previously.
2. Connect one of the connectors of the RS-232 cable directly to the console port on your system
hardware.
3. Connect the other end of the cable to the terminal or the serial connector of the computer running the communications software.
4. Press the enter key on the terminal. The NetDefendOS login prompt should appear on the terminal screen.
11
Page 25
2.1.4. Web Interface Chapter 2. Operations and Maintenance
SSH (Secure Shell)
The SSH (Secure Shell) protocol can be used to access the CLI over the network from a remote
host. SSH is a protocol primarily used for secure communication over insecure networks, providing
strong authentication and data integrity.
NetDefendOS supports version 1, 1.5 and 2 of the SSH protocol.
SSH access is regulated by the remote management policy in NetDefendOS, and is disabled by de-
fault.
Example 2.1. Enabling SSH Remote Access
This example shows how to enable remote SSH access from the lannet network through the lan interface by
adding a rule to the remote management policy.
CLI
gw-world:/> add RemoteManagement RemoteMgmtSSH ssh Network=lannet Interface=lan
Web Interface
1. Go to System > Remote Management > Add > Secure Shell Management
2. Enter a Name for the SSH remote management policy, e.g. ssh.
3. Select the following from the dropdown lists:
• User Database: AdminUsers
• Interface: lan
• Network: lannet
4. Click OK.
LocalUserDatabase=AdminUsers
2.1.3.2. Common CLI Operations
Logging on to the CLI
When access to the CLI has been established using one of the methods described in the earlier sections, you need to logon to the system before being able to execute any CLI command. This authentication step is needed to ensure that only trusted users can access the system, as well as providing
user information for the audit mechanism.
The CLI uses the common user authentication mechanisms provided. In other words, local user
databases as well as external user databases can be used to lookup user credentials for CLI access.
For more information about user authentcation, please see section Chapter 8, User Authentication.
When accessing the CLI, the system will respond with the login prompt. Enter your username and
press Enter, followed by your password and Enter. After a successful logon you will see the command prompt. If a welcome message has been set then it will be displayed directly after the logon:
gw-world:/>
For security reasons, it can be better to disable or anonymize the CLI welcome message.
Logging off from the CLI
After finishing working with the CLI, you should logout to avoid other people getting unauthorized
access to the system. Log off by using the exit or the logout command.
12
Page 26
2.1.4. Web Interface Chapter 2. Operations and Maintenance
2.1.4. Web Interface
NetDefendOS provides a highly versatile web user interface for management of the system using a
standard web browser. This allows you to perform remote management from virtually anywhere in
the world without having to install any third-party clients.
2.1.4.1. Logging on to the Web Interface
To access the web interface, launch a standard web browser and point the browser at the IP address
of the firewall. The factory default address for all D-Link Firewalls is 192.168.1.1.
You MUST use https:// as the protocol of the URL in the browser eg: https://192.168.1.1 (https
will protect the username and password with encryption when they are sent to NetDefendOS). A
user authentication dialog like the one below will then be presented.
Enter your username and password and click the Login button. If the user credentials are correct,
you will be transferred to the main web interface page. This page, with its essential parts highlighted, is shown below.
For information about the default user name and password, please see Section 2.1.2, “Default User
Accounts”.
13
Page 27
2.1.4. Web Interface Chapter 2. Operations and Maintenance
Note
Access to the web interface is regulated by the remote management policy. By default,
the system will only allow web access from the internal network.
2.1.4.2. Interface Layout
The main web interface page is divided into three major sections:
Menu bar
The menu bar located at the top of the web interface contains a number of buttons and drop-down menus that are used to perform configuration tasks as well as
for navigation to various tools and status pages.
• Home - Navigates to the first page of the web interface.
• Configuration
• Save and Activate - Saves and activates the configuration.
• Discard Changes - Discards any changes made to the configuration dur-
ing the current session.
• View Changes - List the changes made to the configuration since it was
last saved.
• Tools - Contains a number of tools that are useful for maintaining the system.
• Status - Provides various status pages that can be used for system dia-
gnostics.
• Maintenance
• Update Center - Manually update or schedule updates of the intrusion
detection and antivirus signatures.
• License - View license details or enter activation code.
• Backup - Make a backup of the configuration to your local computer or
restore a previously downloaded backup.
• Reset - Restart the firewall or reset to factory default.
• Upgrade - Upgrade the firewall's firmware.
Navigator
Main Window
The navigator located on the left-hand side of the web interface contains a tree
representation of the system configuration. The tree is divided into a number of
sections corresponding to the major building blocks of the configuration. The tree
can be expanded to expose additional sections.
The main window contains configuration or status details corresponding to the
section selected in the navigator or the menu bar.
2.1.4.3. Controlling Access to the Web Interface
By default, the web interface is accessible only from the internal network. If you need to enable access from other parts of the network, you can do so by modifying the remote management policy.
Example 2.2. Enabling remote management via HTTPS.
14
Page 28
2.1.5. Working with Configurations Chapter 2. Operations and Maintenance
CLI
gw-world:/> add RemoteManagement RemoteMgmtHTTP https
Web Interface
1. Go to System > Remote Management > Add > HTTP/HTTPS Management
2. Enter a Name for the HTTP/HTTPS remote management policy, e.g. https.
3. Check the HTTPS checkbox.
4. Select the following from the dropdown lists:
• User Database: AdminUsers
• Interface: any
• Network: all-nets
5. Click OK.
Network=all-nets Interface=any LocalUserDatabase=AdminUsers HTTPS=Yes
Caution
The above example is provided for informational purposes only. It is never recommended to expose any management interface to any user on the Internet.
2.1.4.4. Logging out from the Web Interface
When you have finished working in the web interface, you should always logout to prevent other
users with access to your workstation to get unauthorized access to the system. Logout by clicking
on the Logout button at the right of the menu bar.
2.1.5. Working with Configurations
Configuration Objects
The system configuration is built up by Configuration Objects, where each object represents a configurable item of any kind. Examples of configuration objects are routing table entries, address book
entries, service definitions, IP rules and so forth. Each configuration object has a number of properties that constitute the values of the object.
A configuration object has a well-defined type. The type defines the properties that are available for
the configuration object, as well as the constraints for those properties. For instance, the IP4Address
type is used for all configuration objects representing a named IPv4 address.
In the web user interface the configuration objects are organized into a tree-like structure based on
the type of the object.
In the CLI similar configuration object types are grouped together in a category. These categories
are different from the structure used in the web user interface to allow quick access to the configuration objects in the CLI. The IP4Address, IP4Group and EthernetAddress types are, for instance,
grouped in a category named Address, as they all represent different addresses. Consequently, Ethernet and VLAN objects are all grouped in a category named Interface, as they are all interface objects. The categories have actually no impact on the system configuration; they are merely provided
as means to simplify administration.
Listing Configuration Objects
To find out what configuration objects exist, you can retrieve a listing of the objects.
15
Page 29
2.1.5. Working with Configurations Chapter 2. Operations and Maintenance
Example 2.3. Listing Configuration Objects
This example shows how to list all service objects.
CLI
gw-world:/> show Service
A list of all services will be displayed, grouped by their respective type.
Web Interface
1. Go to Objects > Services
2. A web page listing all services will be presented.
A list contains the following basic elements:
• Add Button - Displays a dropdown menu when clicked. The menu will list all types of configuration items that
can be added to the list.
• Header - The header row displays the titles of the columns in the list. The tiny arrow images next to each title
can be used for sorting the list according to that column.
• Rows - Each row in the list corresponds to one configuration item. Most commonly, each row starts with the
name of the object (if the item has a name), followed by values for the columns in the list.
A single row in the list can be selected by clicking on the row on a spot where there is no hyperlink. The background color of the row will turn dark blue. Right-clicking the row will bring up a menu where you can choose to
edit or delete the object as well as modify the order of the objects.
Displaying a Configuration Object
The most simple operation on a configuration object is just to show its contents, in other words the
values of the object properties.
Example 2.4. Displaying a Configuration Object
This example shows how to display the contents of a configuration object representing the telnet service.
CLI
gw-world:/> show Service ServiceTCPUDP telnet
----------------- ------DestinationPorts: 23
PassICMPReturn: No
The Property column lists the names of all properties in the ServiceTCPUDP class and the Value column lists the
corresponding property values.
Web Interface
1. Go to Objects > Services
2. Click on the telnet hyperlink in the list.
3. A web page displaying the telnet service will be presented.
Property Value
Name: telnet
SourcePorts: 0-65535
MaxSessions: 1000
Type: TCP
SYNRelay: No
ALG: (none)
Comments: Telnet
16
Page 30
2.1.5. Working with Configurations Chapter 2. Operations and Maintenance
Note
When accessing object via the CLI you can omit the category name and just use the
type name. The CLI command in the above example, for instance, could be simplified
to:
gw-world:/> show ServiceTCPUDP telnet
Editing a Configuration Object
When you need to modify the behavior of NetDefendOS, you will most likely need to modify one or
several configuration objects.
Important
Changes to a configuration object will not be applied to a running system until you activate and commit the changes.
Example 2.5. Editing a Configuration Object
This example shows how to edit the Comments property of the telnet service.
CLI
gw-world:/> set Service ServiceTCPUDP telnet Comments="Modified Comment"
Show the object again to verify the new property value:
gw-world:/> show Service ServiceTCPUDP telnet
----------------- ------DestinationPorts: 23
PassICMPReturn: No
Web Interface
1. Go to Objects > Services
2. Click on the telnet hyperlink in the list
3. In the Comments textbox, enter your new comment
4. Click OK
Verify that the new comment has been updated in the list.
Property Value
Name: telnet
SourcePorts: 0-65535
MaxSessions: 1000
Type: TCP
SYNRelay: No
ALG: (none)
Comments: Modified Comment
Adding a Configuration Object
Example 2.6. Adding a Configuration Object
This example shows how to add a new IP4Address object, here using the IP address 192.168.10.10, to the Ad-
17
Page 31
2.1.5. Working with Configurations Chapter 2. Operations and Maintenance
dress Book.
CLI
gw-world:/> add Address IP4Address myhost Address=192.168.10.10
Show the new object:
gw-world:/> show Address IP4Address myhost
--------------------- -------------
UserAuthGroups: (none)
NoDefinedCredentials: No
Web Interface
1. Go to Objects > Address Book
2. Click on the Add button
3. In the dropdown menu displayed, select IP4 Address
4. In the Name text box, enter myhost
5. Enter 192.168.10.10 in the IP Address textbox
6. Click OK
7. Verify that the new IP4 address object has been added to the list
Property Value
Name: myhost
Address: 192.168.10.10
Comments: (none)
Deleting a Configuration Object
Example 2.7. Deleting a Configuration Object
This example shows how to delete the newly added IP4Address object.
CLI
gw-world:/> delete Address IP4Address myhost
Web Interface
1. Go to Objects > Address Book
2. Right-click on the row containing the myhost object.
3. In the dropdown menu displayed, select Delete.
The row will be rendered with a strike-through line indicating that the object is marked for deletion.
Undeleting a Configuration Object
A deleted object can always be restored until the configuration has been activated and committed.
Example 2.8. Undeleting a Configuration Object
This example shows how to restore the deleted IP4Address object shown in the previous example.
18
Page 32
2.1.5. Working with Configurations Chapter 2. Operations and Maintenance
CLI
gw-world:/> undelete Address IP4Address myhost
Web Interface
1. Go to Objects > Address Book
2. Right-click on the row containing the myhost object.
3. In the dropdown menu displayed, select Undo Delete.
Listing Modified Objects
After modifying several configuration objects, you might want to see a list of the objects that were
changed, added and removed since the last commit.
Example 2.9. Listing Modified Configuration Objects
This example shows how to list configuration objects that have been modified.
CLI
gw-world:/> show -changes
Type Object
------------- ------
- IP4Address myhost
* ServiceTCPUDP telnet
A "+" character in front of the row indicates that the object has been added. A "*" character indicates that the object has been modified. A "-" character indicates that the object has been marked for deletion.
Web Interface
1. Go to Configuration > View Changes in the menu bar.
A list of changes is displayed.
Activating and Committing a Configuration
When changes to a configuration have been made, the configuration has to be activated for those
changes to have an impact on the running system. During the activation process, the new proposed
configuration is validated and NetDefendOS will attempt to initialize affected subsystems with the
new configuration data.
Committing IPsec Changes
The adminstrator should be aware that if any changes that effect the configurations of
live IPsec tunnels are committed, then those live tunnels connections WILL BE TERMINATED and must be re-established.
If the new configuration is validated, NetDefendOS will wait for a short period (30 seconds by default) during which a connection to the administrator must be re-established. If the configuratin was
activated via the CLI, a commit command must be issued within that period. If the connection could
not be re-established or if the commit command was not issued, the system will revert to using the
previous configuration. This is a powerful fail-safe mechanism as it will, amongst others things, prevent you from locking yourself out of the firewall when using a remote system.
19
Page 33
2.1.5. Working with Configurations Chapter 2. Operations and Maintenance
Example 2.10. Activating and Committing a Configuration
This example shows how to activate and commit a new configuration.
CLI
gw-world:/> activate
The system will validate and start using the new configuration. When the command prompt is shown again:
gw-world:/> commit
The new configuration is now committed.
Web Interface
1. Go to Configuration > Save and Activate in the menu bar
2. Click OK to confirm
The web browser will automatically try to connect back to the web interface after 10 seconds. If the connection
succeeds, this is interpreted by NetDefendOS that remote management is still working. The new configuration is
then automatically committed.
Note
All changes to a configuration can be ignored simply by not committing a changed
configuration.
20
Page 34
2.2. Events and Logging Chapter 2. Operations and Maintenance
2.2. Events and Logging
2.2.1. Overview
The ability to log and analyze system activities is one of the most vital and fundamental features of
a NetDefendOS system. Logging enables you not only to monitor system status and health, but also
to audit the usage of your network as well as to assist you with debugging functionality.
NetDefendOS defines a number of event messages, which are generated as a result of corresponding
system events. Examples of such events are establishment and teardown of connections, receiving
malformed packets, dropping traffic according to filtering policies and so forth.
Whenever an event message is generated, it can be filtered and distributed to Event Receivers such
as a Syslog receiver. . Multiple event receivers can be defined, with each event receiver having its
own customizable event filter.
The sophisticated design of the event and logging mechanisms of NetDefendOS ensures that enabling logging is simple and straightforward, while it still allows a granular control of all the activities in the system for the more advanced deployments.
2.2.2. Event Messages
NetDefendOS defines several hundred events for which event messages can be generated. The
events range from high-level, customizable, user events down to low-level and mandatory system
events.
The conn_open event, for instance, is a typical high-level event that generates an event message
whenever a new connection is established, given that the matching security policy rule has defined
that event messages should be generated for that connection.
An example of a low-level event would be the startup_normal event, which generates a mandatory
event message as soon as the system starts up.
All event messages have a common design, with attributes like category, severity, recommended actions and so forth. These attributes enable you to easily filter the event messages, either within NetDefendOS prior to sending them to an event receiver, or as part of the analysis taking place after
logging and storing the messages on an external log server.
Note
A list of all event messages can be found in the Log Reference Guide. That guide also
describes the design of event messages, and explains the various attributes available.
2.2.3. Event Message Distribution
To distribute and log the event messages generated, it is necessary to define one or more event receivers that specify what events to capture, and where to send them.
NetDefendOS can distribute event messages using the following standards and protocols:
Memlog
Syslog
A D-Link Firewall has a built in logging mechanism known as the Memory Log. This retains all event log messages in memory and allows direct viewing of log messages
through the web interface.
The de-facto standard for logging events from network devices. If you have other network devices logging to syslog hosts, you should consider using syslog from NetDefendOS as well to simplify your overall log administration.
21
Page 35
2.2.3. Event Message Distribution Chapter 2. Operations and Maintenance
2.2.3.1. Logging to Syslog Hosts
Syslog is a standardized protocol for sending log data to loghosts, although there is no standardized
format of these log messages. The format used by NetDefendOS is well suited for automated processing, filtering and searching.
Although the exact format of each log entry depends on how your syslog recipient works, most are
very much alike. The way in which logs are read is also dependent on how your syslog recipient
works. Syslog daemons on UNIX servers usually log to text files, line by line.
Most syslog recipients preface each log entry with a timestamp and the IP address of the machine
that sent the log data:
Feb 5 2000 09:45:23 gateway.ourcompany.com
This is followed by the text the sender has chosen to send.
Feb 5 2000 09:45:23 gateway.ourcompany.com EFW: DROP:
Subsequent text is dependent on the event that has occurred.
In order to facilitate automated processing of all messages, NetDefendOS writes all log data to a
single line of text. All data following the initial text is presented in the format name=value. This enables automatic filters to easily find the values they are looking for without assuming that a specific
piece of data is in a specific location in the log entry.
Note
The "Prio=" field in SysLog messages contains the same as the "Severity" field for DLink Logger messages, however the ordering of the numbering is reversed.
Example 2.11. Enable Logging to a Syslog Host
To enable logging of all events with a severity greater than or equal to Notice to a syslog server with IP address
195.11.22.55, follow the steps outlined below:
CLI
gw-world:/> add LogReceiverSyslog my_syslog IPAddress=195.11.22.55
Web Interface
1. Go to System > Log and Event Receivers > Add > Syslog Receiver
2. Specify a suitable name for the event receiver, for instance my_syslog.
3. Enter 195.11.22.55 in the IP Address textbox.
4. Select an appropriate facility in the Facility dropdown list. The facility name is commonly used as a filter
parameter in most syslog daemons.
5. Click OK.
The system will now be logging all events with a severity greater than or equal to Notice to the syslog server at
195.11.22.55.
Note
The syslog server may have to be configured to receive log messages from NetDefendOS. Please see the documentation for your specific Syslog server software in order to
correctly configure it.
22
Page 36
2.2.3. Event Message Distribution Chapter 2. Operations and Maintenance
23
Page 37
2.3. RADIUS Accounting Chapter 2. Operations and Maintenance
2.3. RADIUS Accounting
2.3.1. Overview
Within a network environment containing large numbers of users, it is advantageous to have one or
a cluster of central servers that maintain user account information and are responsible for authentication and authorization tasks. The central database residing on the dedicated server(s) contains all
user credentials as well as details of connections, significantly reducing administration complexity.
The Remote Authentication Dial-in User Service (RADIUS) is an Authentication, Authorization and
Accounting (AAA) protocol widely used to implement this approach and is used by NetDefendOS
to implement user accounting.
The RADIUS protocol is based on a client/server architecture. The D-Link Firewall acts as the client
of the RADIUS server, creating and sending requests to a dedicated server(s). In RADIUS terminology the firewall acts as the Network Access Server (NAS). For user authentication, the RADIUS
server receives the requests, verifies the user's information by consulting its database, and returns
either an "ACCEPT" or "REJECT" decision to the requested client. In RFC2866, RADIUS was extended to handle the delivery of accounting information and this is the standard followed by NetDefendOS for user accounting. The benefits of having centralized servers are thus extended to user
connection accounting. (For details of the usage of RADIUS for NetDefendOS authentication see
Section 8.2, “Authentication Components”).
2.3.2. RADIUS Accounting messages
Statistics, such as number of bytes sent and received, and number of packets sent and received are
updated and stored throughout RADIUS sessions. All statistics are updated for an authenticated user
whenever a connection related to an authenticated user is closed.
When a new client session is started by a user establishing a new connection through the D-Link
Firewall, NetDefendOS sends an AccountingRequest START message to a nominated RADIUS
server, to record the start of the new session. User account information is also delivered to the RADIUS server. The server will send back an AccountingResponse message to NetDefendOS, acknowledging that the message has been received. The diagram below illustrates the message interaction.
When a user is no longer authenticated, for example, after the user logs out or the session time expires, an AccountingRequest STOP message is sent by NetDefendOS containing the relevant session statistics. The information included in these statistics is user configurable. The contents of the
START and STOP messages are described in detail below:
START Message Parameters
Parameters included in START messages sent by NetDefendOS are:
• Type - Marks this AccountingRequest as signaling the beginning of the service (START).
• ID - A unique identifier to enable matching of an AccountingRequest with Acct-Status-Type set
to STOP.
• User Name - The user name of the authenticated user.
• NAS IP Address - The IP address of the D-Link Firewall.
• NAS Port - The port of the NAS on which the user was authenticated (this is a physical port and
not a TCP or UDP port).
• User IP Address - The IP address of the authenticated user. This is sent only if specified on the
authentication server.
• How Authenticated - How the user was authenticated. This is set to either RADIUS if the user
24
Page 38
2.3.2. RADIUS Accounting messages Chapter 2. Operations and Maintenance
was authenticated via RADIUS, or LOCAL if the user was authenticated via a local user database.
• Delay Time - The time delay (in seconds) since the AccountingRequest packet was sent and the
authentication acknowledgement was received. This can be subtracted from the time of arrival
on the server to find the approximate time of the event generating this AccountingRequest. Note
that this does not reflect network delays. The first attempt will have this parameter set to 0.
• Timestamp - The number of seconds since 1970-01-01. Used to set a timestamp when this
packet was sent from NetDefendOS.
STOP Message Parameters
Parameters included in STOP messages sent by NetDefendOS are:
• Type - Marks this accounting request as signalling the end of a session (STOP).
• ID - An identifier matching a previously sent AccountingRequest packet, with Acct-Status-Type
set to START.
• User Name - The user name of the authenticated user.
• NAS IP Address - The IP address of the D-Link Firewall.
• NAS Port - The port on the NAS on which the user was authenticated. (this is a physical port
and not a TCP or UDP port).
• User IP Address - The IP address of the authenticated user. This is sent only if specified on the
authentication server
• Input Bytes - The number of bytes received by the user. (*)
• Output Bytes - The number of bytes sent by the user. (*)
• Input Packets - The number of packets received by the user. (*)
• Output Packets - The number of packets sent by the user. (*)
• Session Time - The number of seconds this session lasted. (*)
• Termination Cause - The reason why the session was terminated.
• How Authenticated - How the user was authenticated. This is set to either RADIUS if the user
was authenticated via RADIUS, or LOCAL if the user was authenticated via a local user database.
• Delay Time - See the above comment about this parameter.
• Timestamp - The number of seconds since 1970-01-01. Used to set a timestamp when this
packet was sent from the D-Link Firewall. In addition to this, two more attributes are possibly
sent:
• Input Gigawords - Indicates how many times the Input Bytes counter has wrapped. This is only
sent if Input Bytes has wrapped, and if the Input Bytes attribute is sent.
• Output Gigawords - Indicates how many times the Output Bytes counter has wrapped. This is
only sent if Ouput Bytes has wrapped, and if the Output Bytes attribute is sent.
25
Page 39
2.3.3. Interim Accounting Messages Chapter 2. Operations and Maintenance
Note
The (*) symbol in the above list indicates that the sending of the parameter is user
configurable.
2.3.3. Interim Accounting Messages
In addition to START and STOP messages NetDefendOS can optionally periodically send Interim
Accounting Messages to update the accounting server with the current status of an authenticated
user. An Interim Accounting Message can be seen as a snapshot of the network resources that an authenticated user has used up until a given point. With this feature, the RADIUS server can track how
many bytes and packets an authenticated user has sent and received up until the point when the last
message was sent.
An Interim Accounting Message contains the current values of the statistics for an authenticated
user. It contains more or less the same parameters as found in an AccountingRequest Stop message,
except that the Acct-Terminate-Cause is not included (as the user has not disconnected yet).
The frequency of Interim Accounting Messages can be specified either on the authentication server,
or in NetDefendOS. Switching on the setting in NetDefendOS will override the setting on the accounting server.
2.3.4. Activating RADIUS Accounting
In order to activate RADIUS accounting a number of steps must be followed:
• The RADIUS accounting server must be specified.
• A user authentication object must have a rule associated with it where a RADIUS server is spe-
cified.
Some important points should be noted about activation:
• RADIUS Accounting will not function where a connection is subject to a FwdFast rule in the IP
rule-set.
• The same RADIUS server does not need to handle both authentication and accounting; one serv-
er can be responsible for authentication while another is responsible for accounting tasks.
• Multiple RADIUS servers can be configured in NetDefendOS to deal with the event when the
primary server is unreachable.
2.3.5. RADIUS Accounting Security
Communication between NetDefendOS and any RADIUS accounting server is protected by the use
of a shared secret. This secret is never sent over the network but instead a 16 byte long Authenticat-
or code is calculated using a one way MD5 hash function and this is used to authenticate accounting
messages.
The shared secret is case sensitive, can contain up to 100 characters, and must be typed exactly the
same for NetDefendOS and for the RADIUS server.
Messages are sent using the UDP protocol and the default port number used is 1813 although this is
user configurable.
2.3.6. RADIUS Accounting and High Availability
26
Page 40
2.3.7. Handling Unresponsive Servers Chapter 2. Operations and Maintenance
In an HA cluster, accounting information is synched between the active and passive D-Link Firewalls. This means that accounting information is automatically updated on both cluster members
whenever a connection is closed. Two special accounting events are also used by the active unit to
keep the passive unit synchronized:
• An AccountingStart event is sent to the inactive member in an HA setup whenever a response
has been received from the accounting server. This specifies that accounting information should
be stored for a specific authenticated user.
• A lack of accounting information synching could occur if an active unit has an authenticated
user for whom the associated connection times out before it is synched to the inactive unit. To
get around this problem, a special AccountingUpdate event is sent to the passive unit on a
timeout and this contains the most recent accounting information for connections.
2.3.7. Handling Unresponsive Servers
A question arises in the case of a client that sends an AccountingRequest START packet which the
RADIUS server never replies to. CorePlus will re-send the request after the user-specified number
of seconds. This will however mean that a user will still have authenticated access while CorePlus is
trying to contact to the accounting server.
Only after CorePlus has made three attempts to reach the server will it conclude that the accounting
server is unreachable. The administrator can use the CorePlus advanced setting AllowAuthIfNoAc-
countingResponse to determine how this situation is handled. If this setting is enabled then an
already authenticated user's session will be unaffected. If it is not enabled, any effected user will
automatically be logged out even if they have already been authenticated.
2.3.8. Accounting and System Shutdowns
In the case that the client for some reason fails to send a RADIUS AccountingRequest STOP packet
(due to, for example, the accounting server will never be able to update its user statistics, but will
most likely believe that the session is still active and this situation should be avoided.
In the case that the D-Link Firewall administrator issues a shutdown command while authenticated
users are still online, the AccountingRequest STOP packet will potentially never be sent. To avoid
this, NetDefendOS has the advanced setting LogOutAccUsersAtShutdown. This setting allows the
administrator to explicitly specify that NetDefendOS must first send a STOP message for any authenticated users to any configured RADIUS servers before commencing with the shutdown.
2.3.9. Limitations with NAT'ed Networks
The User Authentication module in NetDefendOS is based on the user's IP address. Problems can
therefore occur with users who have the same IP address.
This can happen, for instance, when several users are behind the same network and which uses NAT
to allow network access. This means that as soon as one user is authenticated, all users from the
same network are also authenticated. NetDefendOS RADIUS Accounting will therefore gather statistics for all the users on the network together as though they were one user instead of individuals.
27
Page 41
2.4. Maintenance Chapter 2. Operations and Maintenance
2.4. Maintenance
2.4.1. Reset to Factory Defaults
It is possible to apply the original defaults that existed when the D-Link Firewall was purchased.
These defaults can be applied only to the current configuration or to the entire hardware unit. The
latter option essentially restores the unit to the state it was in when it left the factory.
Example 2.12. Reset to Factory Defaults with the standard user interface
Web Interface
1. Go to Maintenance > Reset
2. Select Reset the configuration to Factory Defaults then confirm and wait for the restore to complete, OR
3. Select Reset the entire unit to Factory Defaults then confirm and wait for the restore to complete.
Reset alternative via the Serial Console
Connect the serial cable and connect with a console using a terminal emulator software product. If
Microsoft Windows is being used, "HyperTerminal" can be used. Reset the firewall. Press a key
when the "Press any key to abort and load boot menu" message appears at the console. When the
boot menu appears, select the desired option then confirm and wait for the process to complete.
Reset alternative for the DFL-210/260/800/860 only
To reset the DFL-210/260/800/860 you must hold down the reset button at the rear panel for 10-15
seconds while powering on the unit. After that, release the reset button and the DFL-210/800 will
continue to load and startup in default mode, i.e. with 192.168.1.1 on the LAN interface.
Reset alternatives for the DFL-1600 and DFL-2500 only
Press any key on the keypad when the "Press keypad to Enter Setup" message appears on the display. Select "Reset firewall", confirm by selecting "Yes" and wait for the process to complete.
Warning
DO NOT ABORT THE RESET TO FACTORY DEFAULTS PROCESS. If aborted the
firewall can cease to function properly.
2.4.2. Configuration Backup and Restore
The configuration of D-Link Firewalls can be backed up or restored on demand. This could, for instance, be used to recall the "last known good" configuration when experimenting with different
configuration setups.
Example 2.13. Configuration Backup and Restore
Web Interface
To create a backup of the currently running configuration:
28
Page 42
2.4.3. Auto-Update Mechanism Chapter 2. Operations and Maintenance
1. Go to Tools > Backup
2. Download configuration, select a name and begin backup.
To restore a configuration backup:
1. Go to Tools > Backup
2. In Restore unit's configuration browse and locate the desired backup.
3. Click Upload configuration and then choose to activate that configuration.
Note
Backups include only static information in the firewall configuration. Dynamic information such as the DHCP server lease database will not be backed up.
2.4.3. Auto-Update Mechanism
A number of the NetDefendOS security features rely on external servers for automatic updates and
content filtering. The Intrusion Prevention and Detection system and Anti-Virus modules require access to updated signature databases in order to provide protection against the latest threats.
To facilitate the Auto-Update feature D-Link maintains a global infrastructure of servers providing
update services for D-Link Firewalls. To ensure availability and low response times, NetDefendOS
employs a mechanism for automatically selecting the most appropriate server to supply updates.
For more details on these features see the following sections:
• Section 6.3, “Intrusion Detection and Prevention”
• Section 6.4, “Anti-Virus”
• Section 6.5, “Web Content Filtering”
• Appendix A, Subscribing to Security Updates
29
Page 43
2.4.3. Auto-Update Mechanism Chapter 2. Operations and Maintenance
30
Page 44
Chapter 3. Fundamentals
This chapter describes the fundamental logical objects upon which NetDefendOS is built. These logical objects include such things as addresses, services and schedules. In addition, this chapter explains how the various supported interfaces work, it outlines how policies are constructed and how
basic system settings are configured.
• The Address Book, page 31
• Services, page 35
• Interfaces, page 40
• ARP, page 47
• The IP Rule-Set, page 52
• Schedules, page 55
• X.509 Certificates, page 57
• Setting Date and Time, page 59
• DNS Lookup, page 64
3.1. The Address Book
3.1.1. Overview
The Address Book contains named objects representing various types of addresses, including IP addresses, networks and Ethernet MAC addresses.
Using Address Book objects has three distinct benefits; it increases readability, reduces the danger
of entering incorrect network addresses, and makes it easier to change addresses. By using objects
instead of numerical addresses, you only need to make changes in a single location, rather than in
each configuration section where the address appears.
3.1.2. IP Addresses
IP Address objects are used to define symbolic names for various types of IP addresses. Depending
on how the address is specified, an IP Address object can represent either a host (a single IP address), a network, a range of IP addresses or even a DNS name.
In addition, IP Address objects can be used for specifying user credentials later used by the various
user authentication subsystems. For more information on this, see Chapter 8, User Authentication.
The following list presents the various types of addresses an IP Address object can hold, along with
what format that is used to represent that specific type:
Host
A single host is represented simply by its IP address.
For example: 192.168.0.14
IP Network
An IP Network is represented using CIDR (Classless Inter Domain Routing) form.
CIDR uses a forward slash and a digit (0-32) to denote the size of the network
(netmask). /24 corresponds to a class C net with 256 addresses (netmask
255.255.255.0), /27 corresponds to a 32 address net (netmask 255.255.255.224)
and so forth. The numbers 0-32 correspond to the number of binary ones in the
netmask.
31
Page 45
3.1.2. IP Addresses Chapter 3. Fundamentals
For example: 192.168.0.0/24
IP Range
A range of IP addresses is represented on the form a.b.c.d - e.f.g.h. Please note that
ranges are not limited to netmask boundaries; they may include any span of IP addresses.
For example: 192.168.0.10-192.168.0.15 represents six hosts in consecutive order.
Example 3.1. Adding an IP Host
This example adds the IP host wwwsrv1 with IP address 192.168.10.16 to the Address Book:
CLI
gw-world:/> add Address IP4Address wwwsrv1 Address=192.168.10.16
Web Interface
1. Go to Objects > Address Book > Add > IP address
2. Specify a suitable name for the IP host, for instance wwwwsrv1.
3. Enter 192.168.10.16 in the IP Address textbox.
4. Click OK.
Example 3.2. Adding an IP Network
This example adds an IP network named wwwsrvnet with address 192.168.10.0/24 to the Address Book:
CLI
gw-world:/> add Address IP4Address wwwsrvnet Address=192.168.10.0/24
Web Interface
1. Go to Objects > Address Book > Add > IP address
2. Specify a suitable name for the IP network, for instance wwwsrvnet.
3. Enter 192.168.10.0/24 in the IP Address textbox.
4. Click OK.
Example 3.3. Adding an IP Range
This example adds a range of IP addresses from 192.168.10.16 to 192.168.10.21 and names the range
wwwservers:
CLI
gw-world:/> add Address IP4Address wwwservers Address=192.168.10.16-192.168.10.21
Web Interface
32
Page 46
3.1.3. Ethernet Addresses Chapter 3. Fundamentals
1. Go to Objects > Address Book > Add > IP address
2. Specify a suitable name for the IP Range, for instance wwwservers.
3. Enter 192.168.10.16-192.168.10.21 in the IP Address textbox.
4. Click OK.
Example 3.4. Deleting an Address Object
To delete an object named wwwsrv1 in the Address Book, do the following:
CLI
gw-world:/> delete Address IP4Address wwwsrv1
Web Interface
1. Go to Objects > Address Book
2. Select and right-click the address object wwwsrv1 in the grid.
3. Choose Delete in the menu.
4. Click OK.
3.1.3. Ethernet Addresses
Ethernet Address objects are used to define symbolic names for Ethernet addresses (also known as
MAC addresses). This is useful, for instance, when populating the ARP table with static ARP
entries, or for other parts of the configuration where symbolic names are preferred over numerical
Ethernet addresses.
When specifying an Ethernet address the format aa-bb-cc-dd-ee-ff should be used. Ethernet addresses are also displayed using this format.
Example 3.5. Adding an Ethernet Address
The following example adds an Ethernet Address object named wwwsrv1_mac with a numerical MAC address of
08-a3-67-bc-2e-f2:
CLI
gw-world:/> add Address EthernetAddress wwwsrv1_mac Address=08-a3-67-bc-2e-f2
Web Interface
1. Go to Objects > Address Book > Add > Ethernet Address
2. Specify a suitable name for the Ethernet Address object, e.g. wwwsrv1_mac.
3. Enter 08-a3-67-bc-2e-f2 in the MAC Address textbox.
4. Click OK.
33
Page 47
3.1.5. Auto-Generated Address Objects
3.1.4. Address Groups
Address objects can be grouped in order to simplify configuration. Consider a number of public
servers that should be accessible from the Internet. The servers have IP addresses that are not in a
sequence, and can therefore not be referenced to as a single IP range. Consequently, individual IP
Address objects have to be created for each server.
Instead of having to cope with the burden of creating and maintaining separate filtering policies allowing traffic to each server, an Address Group named, for instance, Webservers, can be created
with the web server hosts as group members. Now, a single policy can be used with this group,
thereby greatly reducing the administrative workload.
Address Group objects are not restricted to contain members of the same subtype. In other words, IP
host objects can be teamed up with IP ranges, IP networks with DNS names and so forth. All addresses of all group members are combined, effectively resulting in a union of the addresses. As an
example, a group containing two IP ranges, one with addresses 192.168.0.10 - 192.168.0.15 and the
other with addresses 192.168.0.14 - 192.168.0.19, will result in a single IP range with addresses
192.168.0.10 - 192.168.0.19.
Keep in mind however that for obvious reasons, IP address objects can not be combined with Ethernet addresses.
3.1.5. Auto-Generated Address Objects
Chapter 3. Fundamentals
To simplify the configuration, several address objects are automatically generated when the system
is run for the first time. These objects are being used by other parts of the configuration already
from start.
The following address objects are auto-generated:
Interface Addresses
Default Gateway
all-nets
For each Ethernet interface in the system, two IP Address objects are
pre-defined; one object for the IP address of the actual interface, and
one object representing the local network for that interface.
Interface IP address objects are named interfacename_ip and network
objects are named interfacenamenet. As an example, an interface
named lan will have an associated interface IP object named lan_ip
and a network object named lannet.
An IP Address object named wan_gw is auto-generated and represents the default gateway of the system. The wan_gw object is used
primarily by the routing table, but is also used by the DHCP client
subsystem to store gateway address information aquired from an DHCP server. If a default gateway address has been provided during the
setup phase, the wan_gw object will contain that address. Otherwise,
the object will be left empty (i.e. the IP address being 0.0.0.0).
The all-nets IP address object is initialized to the address 0.0.0.0/0,
thus representing all possible IP addresses. This object is used extensively throughout the configuration.
34
Page 48
3.2. Services Chapter 3. Fundamentals
3.2. Services
3.2.1. Overview
A Service object is a reference to a specific IP protocol with associated parameters. A Service definition is usually based on one of the major transport protocols such as TCP or UDP, with the associated port number(s). The HTTP service, for instance, is defined as using the TCP protocol with associated port 80.
Service objects are in no way restricted to TCP or UDP; they can be used to define ICMP messages,
as well as any user-definable IP protocol.
Services are simple objects in that they cannot carry out any action in the system on their own. Instead, Service objects are used frequently by the various system policies. For instance, a rule in the
IP Rule-set can use a Service object as a filter to decide whether or not to allow certain traffic
through the firewall. For more information on how service objects are being used in policies, please
see Section 3.5, “The IP Rule-Set”.
A great number of Service objects comes pre-defined with the NetDefendOS. These include common services such as HTTP, FTP, Telnet and SSH. These pre-defined services can be used and also
modified just like user-defined Services. However it is advisable not to make any changes to predefined services, but instead create new ones with the desired parameters.
Example 3.6. Listing the Available Services
To produce a listing of the available services in the system:
CLI
gw-world:/> show Service
The output will look similar to the following listing:
ServiceGroup
Name Comments
------------ -------------------------------------------------all_services All ICMP, TCP and UDP services
all_tcpudp All TCP and UDP services
ipsec-suite The IPsec+IKE suite
l2tp-ipsec L2TP using IPsec for encryption and authentication
l2tp-raw L2TP control and transport, unencrypted
pptp-suite PPTP control and transport
ServiceICMP
...
Web Interface
1. Go to Objects > Services
Example 3.7. Viewing a Specific Service
To view a specific service in the system:
CLI
gw-world:/> show Service ServiceTCPUDP echo
The output will look similar to the following listing:
----------------- ----------------
Property Value
35
Page 49
3.2.2. TCP and UDP Based Services Chapter 3. Fundamentals
DestinationPorts: 7
SourcePorts: 0-65535
PassICMPReturn: No
MaxSessions: 1000
Web Interface
1. Go to Objects > Services
2. Select the specific service object in the grid control.
3. A grid listing all services will be presented.
Name: echo
Type: TCPUDP (TCP/UDP)
ALG: (none)
Comments: Echo service
3.2.2. TCP and UDP Based Services
Most applications are using TCP and/or UDP as transport protocol for transferring application data
over IP networks.
TCP (Transmission Control Protocol) is a connection-oriented protocol that, among other things, includes mechanisms for reliable transmission of data. TCP is used by many common applications,
such as HTTP, FTP and SMTP, where error-free transfers are mandatory.
For other types of applications where, for instance, performance is of great importance, such as
streaming audio and video services, UDP (User Datagram Protocol) is the preferred protocol. UDP
is connection-less, provides very few error recovery services, and give thereby much lower overhead traffic than when using TCP. For this reason, UDP is used for non-streaming services as well,
and it is common in those cases that the applications themselves provide the error recovery mechanisms.
To define a TCP or UDP service in the D-Link Firewall, a TCP/UDP Service object is used. This
type of object contains, apart from a unique name describing the service, also information on what
protocol (TCP, UDP or both) and what source and destination ports are applicable for the service.
Port numbers can be specified in several ways:
Single Port
For many services, a single destination port is sufficient. HTTP, for instance, uses destination port 80 in most cases,
SMTP uses port 25 and so forth. For this type of services, the
single port number is simply specified in the TCP/UDP Service object.
Port Ranges
Some services use a range of destination ports. As an example, the NetBIOS protocol used by Microsoft Windows
uses destination ports 137 to 139. To define a range of ports
in a TCP/UDP Service object, the format mmm-nnn is used.
A port range is inclusive, meaning that a range specified as
137-139 covers ports 137, 138 and 139.
Multiple Ports and Port Ranges
Multiple ranges or individual ports may also be entered, separated by commas. This provides the possibility to cover a
wide range of ports using only a single TCP/UDP Service object. For instance, all Microsoft Windows networking can be
covered using a port definition specified as 135-139,445. HTTP and Secure HTTP (HTTPS) can be covered by stating destination ports 80,443.
36
Page 50
3.2.3. ICMP Services Chapter 3. Fundamentals
Tip
The above methods of specifying port numbers are not used just for destination ports.
Source port definitions can follow the same conventions, although it is most usual that
the source ports are left as their default values, namely 0-65535, which matches all
possible source ports.
Example 3.8. Adding a TCP/UDP Service
This example shows how to add a TCP/UDP Service, using destination port 3306, which is used by MySQL:
CLI
gw-world:/> add Service ServiceTCPUDP MySQL DestinationPorts=3306 Type=TCP
Web Interface
1. Go to Objects > Services > Add > TCP/UDP service
2. Specify a suitable name for the service, for instance MySQL.
3. Now enter:
• Type: TCP
• Source: 0-65535
• Destination: 3306
4. Click OK.
Apart from protocol and port information, TCP/UDP Service objects also contain several other parameters that are being described in more detail in other sections of this users guide:
SYN Flood Protection
Passing ICMP Errors
Application Layer Gateway
3.2.3. ICMP Services
Internet Control Message Protocol (ICMP), is a protocol integrated with IP for error reporting and
transmitting control information. The PING service, for example, uses ICMP to test an Internet connectivity.
ICMP messages is delivered in IP packets, and includes a Message Type that specifies the type, that
is, the format of the ICMP message, and a Code that is used to further qualify the message. For example, the message type Destination Unreachable, uses the Code parameter to specify the exact
reason for the error.
A TCP based service can be configured to enable protection
against SYN Flood attacks. For more details on how this feature works see Section 6.6.8, “TCP SYN Flood Attacks”.
If an attempt to open a TCP connection is made by a user application behind the D-Link Firewall and the remote server is
not in operation, an ICMP error message is returned as the response. These ICMP errors can either be ignored or allowed
to pass through, back to the requesting application.
A TCP/UDP Service can be linked to an Application Layer
Gateway to enable deeper inspection of certain protocols. For
more information, please see Section 6.2, “Application Layer
Gateways”.
37
Page 51
3.2.4. Custom IP Protocol Services Chapter 3. Fundamentals
The ICMP message types that can be configured in NetDefendOS are listed as follows:
• Echo Request: sent by PING to a destination in order to check connectivity.
• Destination Unreachable: the source is told that a problem has occurred when delivering a pack-
et. There are codes from 0 to 5 for this type:
• Code 0: Net Unreachable
• Code 1: Host Unreachable
• Code 2: Protocol Unreachable
• Code 3: Port Unreachable
• Code 4: Cannot Fragment
• Code 5: Source Route Failed
• Redirect: the source is told that there is a better route for a particular packet. Codes assigned are
as follows:
• Code 0: Redirect datagrams for the network
• Code 1: Redirect datagrams for the host
• Code 2: Redirect datagrams for the Type of Service and the network
• Code 3: Redirect datagrams for the Type of Service and the host
• Parameter Problem: identifies an incorrect parameter on the datagram.
• Echo Reply: the reply from the destination which is sent as a result of the Echo Request.
• Source Quenching: the source is sending data too fast for the receiver, the buffer has filled up.
• Time Exceeded: the packet has been discarded as it has taken too long to be delivered.
3.2.4. Custom IP Protocol Services
Services that run over IP and perform application/transport layer functions can be uniquely identified by IP protocol numbers. IP can carry data for a number of different protocols. These protocols
are each identified by a unique IP protocol number specified in a field of the IP header, for example,
ICMP, IGMP, and EGP have protocol numbers 1, 2, and 8 respectively.
NetDefendOS supports these types of IP protocols by the concept of Custom IP Protocol Services.
Basically, a Custom IP Protocol service is a service definition giving a name to an IP protocol number. Some of the common IP protocols, such as IGMP, are already pre-defined in the system configuration.
Similar to the TCP/UDP port ranges described previously, a range of IP protocol numbers can be
used to specify multiple applications for one service.
Note
The currently assigned IP protocol numbers and references are published by the Internet Assigned Numbers Authority (IANA) and can be found at http://www.iana.org/assignments/protocol-numbers
38
Page 52
3.2.4. Custom IP Protocol Services Chapter 3. Fundamentals
Example 3.9. Adding a IP Protocol Service
This example shows how to add an IP Protocol Service, with the Virtual Router Redundancy Protocol.
CLI
gw-world:/> add Service ServiceIPProto VRRP IPProto=112
Web Interface
1. Go to Objects > Services > Add > IP protocol service
2. Specify a suitable name for the service, for instance VRRP.
3. Enter 112 in the IP Protocol control.
4. Preferably, enter Virtual Router Redundancy Protocol in the Comments control.
5. Click OK.
39
Page 53
3.3. Interfaces Chapter 3. Fundamentals
3.3. Interfaces
3.3.1. Overview
An Interface is one of the most important logical building blocks in NetDefendOS. All network
traffic that passes through or gets terminated in the system is done so through one or several interfaces.
An interface can be seen as a doorway for network traffic to or from the system. Thus, when traffic
enters the system through an interface, that interface would be referred to as the receiving interface
(or sometimes ingress or incoming interface). Consequently, when traffic is leaving the system, the
interface used to send the traffic is referred to as the sending interface (or sometimes egress interface).
NetDefendOS supports a number of interface types, which can be divided into the following four
major groups:
Physical Interfaces
Physical Sub-Interfaces
Tunnel Interfaces
Each physical interface represents a physical port in a NetDefendOS-based product. Thus, all network traffic that originates
from or is terminated in the system will eventually pass
through any of the physical interfaces.
NetDefendOS currently supports Ethernet as the only physical
interface type. For more information about Ethernet interfaces,
please see Section 3.3.2, “Ethernet”.
Some interfaces require a binding to an underlying physical interface in order to transfer data. This group of interfaces is
called Physical Sub-Interfaces.
NetDefendOS has support for two types of physical subinterfaces:
• Virtual LAN (VLAN) interfaces as specified by IEEE
802.1Q. When routing IP packets over a Virtual LAN interface, they will be encapsulated in VLAN-tagged Ethernet
frames. For more information about Virtual LAN interfaces, please see Section 3.3.3, “Virtual LAN”.
• PPPoE (PPP-over-Ethernet) interfaces for connections to
PPPoE servers. For more information about PPPoE, please
see Section 3.3.4, “PPPoE”.
Tunnel interfaces are used when network traffic is being
tunneled between the system and another tunnel end-point in
the network, before it gets routed to its final destination.
To accomplish tunneling, additional headers are added to the
traffic that is to be tunneled. Furthermore, various transformations can be applied to the network traffic depending on the
type of tunnel interface. When routing traffic over an IPsec interface, for instance, the payload is usually encrypted to
achieve confidentiality.
NetDefendOS supports the following tunnel interface types:
• IPsec interfaces are used as end-points for IPsec VPN tunnels. For more information about IPsec VPN, please see
Section 9.2.1, “IPsec Basics”.
• PPTP/L2TP interfaces are used as end-points for PPTP or
40
Page 54
3.3.2. Ethernet Chapter 3. Fundamentals
L2TP tunnels. For more information about PPTP/L2TP,
please see Section 9.4, “PPTP/L2TP”.
Even though the various types of interfaces are very different in the way they are implemented and
how they work, NetDefendOS treats all interfaces as logical IP interfaces. This means that all types
of interfaces can be used almost interchangeably in the various subystems and policies. The result of
this is a very high flexibility in how traffic can be controlled and routed in the system.
Each interface in NetDefendOS is given a unique name to be able to select it into other subsystems.
Some of the interface types provide relevant default names that are possible to modify should that be
needed, while other interface types require a user-provided name.
The any and core interfaces
In addition, NetDefendOS provides two special logical interfaces named core and any:
• any represents all possible interfaces including the core interface
• core indicates that it is NetDefendOS itself that will deal with the traffic. Examples of the use of
core would be when the D-Link Firewall acts as a PPTP or L2TP server or is to respond to
ICMP "Ping" requests. By specifying the Destination Interface of a route as core, NetDefendOS will then know that it is itself that is the ultimate destination of the traffic.
3.3.2. Ethernet
The IEEE 802.3 Ethernet standard allows various devices to be attached at arbitrary points or 'ports'
to a physical transport mechanism such as a coaxial cable. Using the CSMA/CD protocol, each Ethernet connected device 'listens' to the network and sends data to another connected device when no
other is sending. If 2 devices broadcast simultaneously, algorithms allow them to re-send at different
times. Devices broadcast data as frames and the other devices 'listen' to determine if they are the intended destination for any of these frames.
A frame is a sequence of bits which specify the originating device plus the destination device, the
data payload along with error checking bits. A pause between the broadcasting of individual frames
allows devices time to process each frame before the next arrives and this pause becomes progressively smaller as the transmission rates get faster from normal to Fast and then Gigabit Ethernet.
Each Ethernet interface in a D-Link Firewall corresponds to a physical Ethernet port in the system.
The number of ports, their link speed and the way the ports are realized, is dependent on the hardware model.
Note
Some systems use an integrated layer 2 switch for providing additional physical Ethernet ports. Such additional ports are seen as a single interface by NetDefendOS.
3.3.2.1. Ethernet Interface Basics
Ethernet Interface Names
The names of the Ethernet interfaces are pre-defined by the system, and are mapped to the names of
the physical ports; a system with a wan port will have an Ethernet inteface named wan and so forth.
The names of the Ethernet interfaces can be changed to better reflect their usage. For instance, if an
interface named dmz is connected to a wireless LAN, it might be convenient to change the interface
name to radio. For maintenance and troubleshooting, it is recommended to tag the corresponding
physical port with the new name.
41
Page 55
IP Addresses Chapter 3. Fundamentals
Note
The startup process will enumerate all available Ethernet interfaces. Each interface
will be given a name of the form lanN, wanN and dmz, where N represents the number
of the interface if your D-Link Firewall has more than one of these interfaces. In most
of the examples in this guide lan is used for LAN traffic and wan is used for WAN
traffic. If your D-Link Firewall does not have these interfaces, please substitute the
references with the name of your chosen interface.
IP Addresses
Each Ethernet interface is required to have an Interface IP Address, which can be either a static address or an address provided by DHCP. The interface IP address is used as the primary address for
communicating with the system through the specific Ethernet interface.
The standard is to use IP4 Address objects to define the addresses of Ethernet interfaces. Those objects are normally auto-generated by the system. For more information, please see Section 3.1.5,
“Auto-Generated Address Objects”.
Tip
Multiple IP addresses can be specified for an Ethernet interface by using the ARP
Publish feature. (See section Section 3.4, “ARP”).
In addition to the interface IP address, a Network address is also specified for the Ethernet interface.
The Network address provides information to NetDefendOS about what IP addresses are directly
reachable through the interface, i.e. residing on the same LAN segment as the interface itself. In the
routing table associated with the interface, NetDefendOS will automatically create a direct route to
the specified network over the actual interface.
Default Gateway
Optionally, a Default Gateway address can be specified for an Ethernet interface. This setting tells
NetDefendOS how to reach hosts for which no routes exist. In other words, if a Default Gateway address has been specified, NetDefendOS will automatically create a default route (destination network 0.0.0.0/0) over the actual interface using the specified gateway. For natural reasons, only one
Ethernet interface at a time can be assigned a default gateway.
3.3.2.2. Using DHCP on Ethernet Interfaces
NetDefendOS includes a DHCP client for dynamic assignment of address information. The information that can be set using DHCP includes the IP address of the interface, the local network that the
interface is attached to, and the default gateway.
All addresses received from the DHCP server are assigned to corresponding IP4Address objects. In
this way, dynamically assigned addresses can be used throughout the configuration in the same way
as static addresses. By default, the objects in use are the same ones as defined in Section 3.1.5,
“Auto-Generated Address Objects”.
Example 3.10. Enabling DHCP
CLI
gw-world:/> set Interface Ethernet wan DHCPEnabled=Yes
Web Interface
1. Go to Interfaces > Ethernet
2. In the grid, click on the ethernet object of interest.
42
Page 56
3.3.3. Virtual LAN Chapter 3. Fundamentals
3. Check the Enable DHCP client control.
4. Click OK.
3.3.3. Virtual LAN
NetDefendOS is fully compliant with the IEEE 802.1Q specification for Virtual LANs. On a protocol level, Virtual LANs work by adding a Virtual LAN identifier (VLAN ID) to the Ethernet
frame header. The VLAN ID is a number from 0 to 4095 and is used to identify a specific Virtual
LAN. In this way, Ethernet frames can belong to different Virtual LANs, but still share the same
physical media.
The Virtual LAN support in NetDefendOS works by defining one or more Virtual LAN interfaces.
Each Virtual LAN interface is interpreted as a logical interface by the system.
Ethernet frames received by the system are examined for a VLAN ID. If a VLAN ID is found, and a
matching Virtual LAN interface has been defined, the system will consider that interface to be the
receiving interface for the frame before further processing takes place.
Virtual LANs are useful in several different scenarios, for instance, when filtering is needed
between different Virtual LANs in an organization, or when the number of interfaces needs to be expanded. For more information about the latter, please see the section Using Virtual LANs to expand
firewall interfaces below.
Note
The number of Virtual LAN interfaces that can be defined in the system is determined
by the particular product license you have.
Example 3.11. Defining a virtual LAN
This example defines a virtual LAN using a VLAN ID of 10. Note that this Virtual LAN interface will use the IP address of the corresponding Ethernet interface, as no IP address is specified.
CLI
gw-world:/> add Interface VLAN VLAN10 Ethernet=lan Network=all-nets VLANID=10
Web Interface
1. Go to Interfaces > VLAN > Add > VLAN
2. Specify a suitable name for the VLAN, for instance VLAN10.
3. Now enter:
• Interface: lan
• VLAN ID: 10
• Network: all-nets
4. Click OK.
3.3.4. PPPoE
Point-to-Point Protocol over Ethernet (PPPoE) is a tunneling protocol used for connecting multiple
users on an Ethernet network to the Internet through a common serial interface, such as a single
43
Page 57
3.3.4. PPPoE Chapter 3. Fundamentals
DSL line, wireless device or cable modem. All the users on the Ethernet share a common connection, while access control can be done on a per-user basis.
Internet server providers (ISPs) often require customers to connect through PPPoE to their broadband service. Using PPPoE the provider can:
• Implement security and access-control using username/password authentication
• Trace IP addresses to a specific user
• Allocate IP address automatically for PC users (similar to DHCP). IP address provisioning can
be per user group
3.3.4.1. Overview of PPP
Point-to-Point Protocol (PPP), is a protocol for communication between two computers using a serial interface, such as the case of a personal computer connected through a switched telephone line to
an ISP. In terms of the OSI model, PPP provides a layer 2 encapsulation mechanism to allow packets of any protocol to travel through IP networks. PPP uses Link Control Protocol (LCP) for link establishment, configuration and testing. Once the LCP is initialized, one or several Network Control
Protocols (NCPs) can be used to transport traffic for a particular protocol suite, so that multiple protocols can interoperate on the same link, for example, both IP and IPX traffic can share a PPP link.
Authentication is an option with PPP. Authentication protocols supported are Password Authentication Protocol (PAP), Challenge Handshake Authentication Protocol (CHAP), Microsoft CHAP
(version 1 and 2). If authentication is used, at least one of the peers has to authenticate itself before
the network layer protocol parameters can be negotiated using NCP. During the LCP and NCP negotiation, optional parameters such as encryption, can be negotiated.
3.3.4.2. PPPoE Client Configuration
The PPPoE interface
Since the PPPoE protocol runs PPP over Ethernet, the firewall needs to use one of the normal Ethernet interfaces to run PPPoE over. Each PPPoE Tunnel is interpreted as a logical interface by the
NetDefendOS, with the same routing and configuration capabilities as regular interfaces, with the IP
rule-set being applied to all traffic. Network traffic arriving at the firewall through the PPPoE tunnel
will have the PPPoE tunnel interface as its source interface. For outbound traffic, the PPPoE tunnel
interface will be the destination interface. As with any interface, one or more routes are defined so
NetDefendOS knows what IP addresses it should accept traffic from and which to send traffic to
through the PPPoE tunnel. The PPPoE client can be configured to use a service name to distinguish
between different servers on the same Ethernet network.
IP address information
PPPoE uses automatic IP address allocation which is similar to DHCP. When NetDefendOS receives this IP address information from the ISP, it stores it in a network object and uses it as the IP
address of the interface.
User authentication
If user authentication is required by the ISP, the username and password can be setup in NetDefendOS for automatic sending to the PPPoE server.
Dial-on-demand
44
Page 58
3.3.5. Interface Groups Chapter 3. Fundamentals
If dial-on-demand is enabled, the PPPoE connection will only be up when there is traffic on the
PPPoE interface. It is possible to configure how the firewall should sense activity on the interface,
either on outgoing traffic, incoming traffic or both. Also configurable is the time to wait with no
activity before the tunnel is disconnected.
Example 3.12. Configuring a PPPoE client on the wan interface with traffic routed over
PPPoE.
CLI
gw-world:/> add Interface PPPoETunnel PPPoEClient EthernetInterface=wan
Web Interface
1. Go to Interfaces > PPPoE > Add > PPoE Tunnel
2. Then enter:
• Name: PPPoEClient
• Physical Interface: wan
• Remote Network: all-nets (as we will route all traffic into the tunnel)
• Service Name: Service name provided by the service provider
• Username: Username provided by the service provider
• Password: Password provided by the service provider
• Confirm Password: Retype the password
• Authentication You can specify exactly which authentication protocol to use. The default settings will be
• Enable dial-on-demand Disable
• Advanced If "Add route for remote network" is enabled, a new route is added for the interface.
3. Click OK.
Network=all-nets Username=exampleuser Password=examplepw
used if not specified.
Note
To provide a point-to-point connection over Ethernet, each PPP session must learn the
Ethernet address of the remote peer, as well as establish a unique session identifier.
PPPoE includes a discovery protocol that provides this.
3.3.5. Interface Groups
Multiple NetDefendOS interfaces can be grouped together to form an Interface Group. Such a logical group can then be subject to common policies and be referred to using a group name in the IP
rule-set and User Authentication Rules.
A group can consist of regular Ethernet interfaces, VLAN interfaces, or VPN Tunnels and the members of a group need not be of the same type. A group might consist, for instance, of two Ethernet
interfaces and four VLAN interfaces.
Example 3.13. Creating an Interface Group
CLI
gw-world:/> add Interface InterfaceGroup examplegroup Members=exampleif1,exampleif2
45
Page 59
3.3.5. Interface Groups Chapter 3. Fundamentals
Web Interface
1. Go to Interfaces > Interface Groups > Add > InterfaceGroup
2. Enter the following information to define the group:
• Name: The name of the group to be used later
• Security/Transport Equivalent: If enabled, the interface group can be used as a destination interface in
rules where connections might need to be moved between the interfaces. Examples of such usage are
Route Fail-Over and OSPF
• Interfaces: Select the interfaces to be in the group
3. Click OK.
46
Page 60
3.4. ARP Chapter 3. Fundamentals
3.4. ARP
3.4.1. Overview
Address Resolution Protocol (ARP) is a protocol, which maps a network layer protocol address to a
data link layer hardware address and it is used to resolve an IP address into its corresponding Ethernet address. It works at the OSI Data Link Layer (Layer 2 - see Appendix D, The OSI Framework)
and is encapsulated by Ethernet headers for transmission.
A host in an Ethernet network can communicate with another host, only if it knows the Ethernet address (MAC address) of that host. A higher level protocols like IP uses IP addresses which are fundamentally different from a lower level hardware addressing scheme like the MAC address. ARP is
used to get the Ethernet address of a host from its IP address. When a host needs to resolve an IP address to its Ethernet address, it broadcasts an ARP request packet. The ARP request packet contains
the source MAC address and the source IP address and the destination IP address. Each host in the
local network receives this packet. The host with the specified destination IP address, sends an ARP
reply packet to the originating host with its MAC address.
3.4.2. ARP in NetDefendOS
NetDefendOS provides not only standard support for ARP, but also adds a number of security
checks on top of the protocol implementation. As an example, NetDefendOS will by default not accept ARP replies for which the system has not sent out a corresponding ARP query for. Without this
type of protection, the system would be vulnerable to "connection hijacking".
NetDefendOS supports both dynamic ARP as well as static ARP, and the latter is available in two
modes; Publish and XPublish.
Dynamic ARP is the main mode of operation for ARP, where NetDefendOS sends out ARP requests
whenever it needs to resolve an IP address to an Ethernet address. The ARP replies are stored in the
ARP cache of the system.
Static ARP is used for manually lock an IP address to a specific Ethernet address. This is explained
in more detail in the sections below.
3.4.3. ARP Cache
The ARP Cache is the temporary table in NetDefendOS for storing the mapping between IP and
Ethernet addresses. The ARP cache is empty at system startup and will be populated with entries as
needed.
The contents of a typical (minimal) ARP Cache looks similar to the following table:
Type IP Address Ethernet Address Expire
Dynamic 192.168.0.10 08:00:10:0f:bc:a5 45
Dynamic 193.13.66.77 0a:46:42:4f:ac:65 136
Publish 10.5.16.3 4a:32:12:6c:89:a4 -
The first item in this ARP Cache is a dynamic ARP entry which tells us that IP address 192.168.0.10
is mapped to an Ethernet address of 08:00:10:0f:bc:a5. The second item dynamically maps the IP
address 193.13.66.77 to Ethernet address 0a:46:42:4f:ac:65. Finally, the third item is a static ARP
entry binding the IP address 10.5.16.3 to Ethernet address 4a:32:12:6c:89:a4.
The third column in the table, Expire, is used to indicate for how much longer the ARP entry will be
valid. The first item, for instance, has an expiry value of 45, which means that this entry will be
rendered invalid and removed from the ARP Cache in 45 seconds. If traffic is going to be sent to the
192.168.0.10 IP address after the expiration, NetDefendOS will issue a new ARP request.
The default expiration time for dynamic ARP entries is 900 seconds (15 minutes). This can be
changed by modifying the Advanced Setting ARPExpire. The setting ARPExpireUnknown spe-
47
Page 61
3.4.4. Static and Published ARP Entries
cifies how long NetDefendOS is to remember addresses that cannot be reached. This is done to ensure that NetDefendOS does not continously request such addresses. The default value for this setting is 3 seconds.
Displaying the ARP Cache
Example 3.14. Displaying the ARP Cache
The contents of the ARP Cache can be displayed from within the CLI.
CLI
gw-world:/> arp -show
ARP cache of iface lan
Dynamic 10.4.0.1 = 1000:0000:4009 Expire=196
Dynamic 10.4.0.165 = 0002:a529:1f65 Expire=506
Flushing the ARP Cache
If a host in your network has recently been replaced with a new hardware but keeping the same IP
address, it is most likely to have a new Ethernet address. If NetDefendOS has an ARP entry for that
host, the Ethernet address of that entry will be invalid, causing data sent to the host to never reach its
destination.
Chapter 3. Fundamentals
Naturally, after the ARP expiration time, NetDefendOS will learn the new Ethernet address of the
requested host, but sometimes it might be necessary to manually force a re-query. This is easiest
achieved by flushing the ARP cache, an operation which will basically delete all dynamic ARP
entries from the cache, thereby forcing NetDefendOS to issue new ARP queries.
Example 3.15. Flushing the ARP Cache
This example shows how to flush the ARP Cache from within the CLI.
CLI
gw-world:/> arp -flush
ARP cache of all interfaces flushed.
Size of the ARP Cache
By default, the ARP Cache is able to hold 4096 ARP entries at the same time. This is feasible for
most deployments, but in rare occasions, such as when there are several very large LANs directly
connected to the firewall, it might be necessary to adjust this value. This can be done by by modifying the Adavnced Setting ARPCacheSize.
So-called "hash tables" are used to rapidly look up entries in the ARP Cache. For maximum efficiency, a hash should be twice as large as the table it is indexing, so if the largest directly-connected
LAN contains 500 IP addresses, the size of the ARP entry hash should be at least 1000 entries. The
administrator can modify the Advanced Setting ARPHashSize to reflect specific network requirements. The default value of this setting is 512.
The ARPHashSizeVLAN setting is similar to the ARPHashSize setting, but affects the hash size
for VLAN interfaces only. The default value is 64.
3.4.4. Static and Published ARP Entries
NetDefendOS supports defining static ARP entries (static binding of IP addresses to Ethernet ad-
48
Page 62
3.4.4. Static and Published ARP
Entries
dresses) as well as publishing IP addresses with a specific Ethernet address.
Static ARP Entries
Static ARP items may help in situations where a device is reporting incorrect Ethernet address in response to ARP requests. Some workstation bridges, such as radio modems, can have such problems.
It may also be used to lock an IP address to a specific Ethernet address for increasing security or to
avoid denial-of-service if there are rogue users in a network. Note however, that such protection
only applies to packets being sent to that IP address, it does not apply to packets being sent from
that IP address.
Example 3.16. Defining a Static ARP Entry
This example will create a static mapping between IP address 192.168.10.15 and Ethernet address
4b:86:f6:c5:a2:14 on the lan interface:
CLI
Chapter 3. Fundamentals
gw-world:/> add ARP Interface=lan IP=192.168.10.15 Mode=Static
Web Interface
1. Go to Interfaces > ARP > Add > ARP
2. Select the following from the dropdown lists:
• Mode: Static
• Interface: lan
3. Enter the following:
• IP Address: 192.168.10.15
• MAC: 4b-86-f6-c5-a2-14
4. Click OK.
MACAddress=4b-86-f6-c5-a2-14
Published ARP Entries
NetDefendOS supports publishing ARP entries, meaning that you can define IP addresses (and optionally Ethernet addresses) for an interface. NetDefendOS will then provide ARP replies for ARP
requests related to those IP addresses.
This can serve two purposes:
• To give the impression that an interface in NetDefendOS has more than one IP address.
• To aid nearby network equipment responding to ARP in an incorrect manner. This use is
however less common.
The first purpose is useful if there are several separate IP spans on a single LAN. The hosts on each
IP span may then use a gateway in their own span when these gateway addresses are published on
the corresponding NetDefendOS interface.
Another use is publishing multiple addresses on an external interface, enabling NetDefendOS to
statically address translate communications to these addresses and send it onwards to internal servers with private IP addresses.
There are two publishing modes; Publish and XPublish. The difference between the two is that
49
Page 63
3.4.5. Advanced ARP Settings Chapter 3. Fundamentals
XPublish "lies" about the sender Ethernet address in the Ethernet header; this is set to be the same as
the published Ethernet address rather than the actual Ethernet address of the Ethernet interface. If a
published Ethernet address is the same as the Ethernet address of the interface, it will make no difference if you select Publish or XPublish, the result will be the same.
Tip
In the configuration of ARP entires, addresses may only be published one at a time.
However, you can use the ProxyARP feature to handle publishing of entire networks
(see Section 4.2.3, “Proxy ARP”).
3.4.5. Advanced ARP Settings
This section presents some of the advanced settings related to ARP. In most cases, these settings
need not to be changed, but in some deployments, modifications might be needed. Most can be
found in the WebUI by going to ARP > Advanced Settings.
Multicast and Broadcast
ARP requests and ARP replies containing multicast or broadcast addresses are usually never correct,
with the exception of certain load balancing and redundancy devices, which make use of hardware
layer multicast addresses.
The default behavior of NetDefendOS is to drop and log such ARP requests and ARP replies. This
can however be changed by modifying the Advanced Settings ARPMulticast and ARPBroadcast.
Unsolicited ARP Replies
It is fully possible for a host on the LAN to send an ARP reply to the firewall, even though a corresponding ARP request has not been issued. According to the ARP specification, the recipient should
accept these types of ARP replies. However, because this can facilitate hijacking of local connections, NetDefendOS will normally drop and log such replies.
The behavior can be changed by modifying the Advanced Setting UnsolicitedARPReplies.
ARP Requests
The ARP specification states that a host should update its ARP Cache with data from ARP requests
received from other hosts. However, as this procedure can facilitate hijacking of local connections,
NetDefendOS will normally not allow this.
To make the behavior compliant with the RFC 826 specification, the administrator can modify the
Adavnced Setting ARPRequests. Even if ARPRequests is set to "Drop", meaning that the packet is
discarded without being stored, the system will, provided that other rules approve the request, reply
to it.
Changes to the ARP Cache
NetDefendOS provides a few settings controlling how to manage changes to the ARP cache.
Possibly, a received ARP reply or ARP request would alter an existing item in the ARP cache. Al-
lowing this to take place may allow hijacking of local connections. However, not allowing this may
cause problems if, for example, a network adapter is replaced, as NetDefendOS will not accept the
new address until the previous ARP cache entry has timed out.
The Advanced Setting ARPChanges can be adjusted to change the behavior. The default behaviour
is that NetDefendOS will allow changes to take place, but all such changes will be logged.
Another, similar, situation is where information in ARP replies or ARP requests would collide with
static entries in the ARP cache. Naturally, this is never allowed to happen. However, changing the
Adavnced Setting StaticARPChanges allow the administrator to specify whether or not such situations are to be logged.
50
Page 64
3.4.5. Advanced ARP Settings Chapter 3. Fundamentals
Sender IP 0.0.0.0
NetDefendOS can be configured on what to do with ARP queries that have a sender IP of 0.0.0.0.
Such sender IPs are never valid in responses, but network units that have not yet learned of their IP
address sometimes ask ARP questions with an "unspecified" sender IP. Normally, these ARP replies
are dropped and logged, but the behavior can be changed by modifying the Advanced Setting
ARPQueryNoSenderIP.
Matching Ethernet Addresses
By default, NetDefendOS will require that the sender address at Ethernet level should comply with
the Ethernet address reported in the ARP data. If this is not the case, the reply will be dropped and
logged. Change the behavior by modifying the Advanced Setting ARPMatchEnetSender.
51
Page 65
3.5. The IP Rule-Set Chapter 3. Fundamentals
3.5. The IP Rule-Set
3.5.1. Overview
Security policies designed by the administrator regulate the way in which network applications are
protected against abuse and inappropriate use. NetDefendOS provides an array of mechanisms and
logical constructs to help with the building of such policies for attack prevention, privacy protection,
identification, and access control.
The IP Rule-set is at the heart of creating NetDefendOS security policies. The IP Rule-set determines the essential filtering functions of NetDefendOS, regulating what is allowed or not allowed to
pass through the D-Link Firewall, and how address translation, bandwidth management and traffic
shaping are applied to the traffic flow.
Once logical constructs such as Application Layer Gateways are created, they won't have any effect
on traffic flow until they are used somewhere in the IP Rule-set. Understanding how to define the IP
Rule-set is crucial to understanding how to create overall security policies. A good understanding is
also important since ambiguous or faulty IP rules can lead to breaches in security.
There are two essential stances which describe the underlying philosophy of the IP Rule-set and
NetDefendOS security policies in general:
• Everything is denied unless specifically permitted
• Everything is permitted unless specifically denied
In order to provide the highest possible security, Drop is the default policy of the IP Rule-set
(everything is denied). The default of dropping packets can be achieved without an explicit IP rule
that does this. For logging purposes however, it is recommended that the IP Rule-set has a DropAll
rule with logging enabled placed as the last rule in the rule-set.
3.5.2. Rule Evaluation
When a new TCP/IP connection is being established through the D-Link Firewall, the list of IP rules
are evaluated from top to bottom until a rule that matches the parameters of that new connection is
found. Those parameters include, amongst others, the source IP address and the destination IP address plus the source interface and the destination interface. The rule's Action is then carried out by
NetDefendOS.
If the action is Allow then the establishment of the new connection will be permitted. Furthermore,
an entry or "state" representing that new connection is added to the NetDefendOS's internal "state
table" which allows monitoring of opened and active connections passing through the firewall. If,
instead, the action were Drop, the new connection will be refused.
The First Matching Principle
If several rules match the connections parameters, the first matching rule in the scan from top to bottom of the list, is the rule that decides what will happen with the connection (the exception to this
being SAT rules).
After initial rule evaluation of the opening connection, subsequent packets belonging to a connection will not need to be evaluated individually against the rule-set. Instead, a highly efficient algorithm searches the state table for each packet to determine if it belongs to an established connection. This approach is known as "stateful inspection" and is applied not only to stateful protocols
such as TCP connections, but also, by means of "pseudo-connections", to stateless protocols such
UDP and ICMP as well. This approach means that evaluation against the IP rule-set is only done in
the initial opening phase of a connection. The size of the IP rule-set consequently has negligible effect on overall performance.
52
Page 66
3.5.4. Editing IP Rule-set Entries Chapter 3. Fundamentals
3.5.3. IP Rule components
A rule consists of two logical parts: the connection parameters and the action to take if there is a
match with those parameters.
Rule parameters are pre-defined and reusable network objects such as Addresses and Services,
which can be used in any rule to specify the criteria for a match.
IP Rule Parameters
The following parameters are set for a single rule. There has to be a match with all parameters in a
rule for that rule to be triggered.
Service
Source Interface
Source Network
Destination Interface
Destination Network
The protocol type to which the packet belongs. Services are
defined as logical objects before configuring the rules.
An Interface or Interface Group where the packet is received on
the firewall.
The network that contains the source IP address of the packet.
An Interface or an Interface Group from which the packet
would leave the firewall.
The network to which the destination IP address of the packet be-
longs.
IP Rule Actions
When an IP rule is triggered by a match with its parameters any one of the following can occur:
Allow
NAT
The packet is allowed to pass. As the rule is applied to only the opening of a connection, an entry in the "state table" is made to record that a connection is open. The remaining packets related to this connection will pass through the firewall's "stateful inspection engine".
This functions like an Allow rule, but with dynamic address translation (NAT) enabled.
See Section 7.1, “Dynamic Address Translation (NAT)”.
FwdFast
SAT
Drop
Reject
Let the packet pass through the firewall without setting up a state for it. This means
that the stateful inspection process is bypassed and is therefore less secure than Allow
or NAT rules. Packet processing is also slower than Allow rules as every packet is
checked against the entire rule-set.
Tells NetDefendOS to perform static address translation. A SAT rule also requires a
matching Allow, NAT or FwdFast rule further down the rule-set. See Section 7.2,
“Static Address Translation (SAT)” for more information on this topic.
Tells NetDefendOS to immediately discard the packet.
Acts like Drop, but will return a "TCP RST" or "ICMP Unreachable message", inform-
ing the sending computer that the packet was disallowed.
Note
Packets not matching a rule in the rule-set and not having an already opened matching connection in the "state table" will be dropped.
53
Page 67
3.5.4. Editing IP Rule-set Entries Chapter 3. Fundamentals
3.5.4. Editing IP Rule-set Entries
After adding various rules to the rule-set editing any line can be achieved in the Web-UI by right
clicking on that line.
A context menu will appear with the following options:
Edit
Delete
Disable/Enable
Move options
This allows the contents of the rule to be changed.
This will remove the rule permanently from the rule-set.
This allows the rule to be disabled but left in the rule set. While disabled the
rule-set line will not effect traffic flow and will appear grayed out in the user
interface. It can be re-enabled at any time.
The last section of the context menu allows the rule to be moved to a different position in the rule-set and therefore have a different precedence
54
Page 68
3.6. Schedules Chapter 3. Fundamentals
3.6. Schedules
In some scenarios, it might be useful to control not only what functionality is enabled, but also when
that functionality is being used.
For instance, the IT policy of an enterprise might stipulate that web traffic from a certain department
is only allowed access outside that department during normal office hours. Another example might
be that authentication using a specific VPN connection is only permitted on weekdays before noon.
NetDefendOS addresses this requirement by providing Schedule objects, or simply schedules, that
can be selected and used with various types of security policies to accomplish time-based control.
This functionality is in no way limited to IP Rules, but is valid for most types of policies, including
Traffic Shaping rules, Intrusion Detection and prevention (IDP) rules and Virtual Routing rules. A
Schedule object is, in other words, a very powerful component that can allow detailed regulation of
when functions in NetDefendOS are enabled or disabled.
A Schedule object gives the possibility to enter multiple time ranges for each day of the week. Furthermore, a start and a stop date can be specified that will impose additional constraints on the
schedule. For instance, a schedule can be defined as Mondays and Tuesdays, 08:30 - 10:40 and
11:30 - 14:00, Fridays 14:30 - 17:00.
Important
As schedules depend on an accurate date and time, it is very important that the system
date and time are set correctly. Preferably, time synchronization has also been enabled to ensure that scheduled policies will be enabled and disabled at the right time.
For more information, please see Section 3.8, “Setting Date and Time”.
Example 3.17. Setting up a Time-Scheduled Policy
This example creates a schedule object for office hours on weekdays, and attaches the object to an IP Rule that
allows HTTP traffic.
CLI
gw-world:/> add ScheduleProfile OfficeHours Mon=8-17 Tue=8-17 Wed=8-17 Thu=8-17
gw-world:/> add IPRule Action=NAT Service=http SourceInterface=lan
Web Interface
1. Go to Objects > Schedules > Add > Schedule
2. Enter the following:
• Name: OfficeHours
3. Select 08-17, Monday to Friday in the grid.
4. Click OK.
1. Go to Rules > IP Rules > Add > IPRule
2. Enter the following:
• Name: AllowHTTP
3. Select the following from the dropdown lists:
Fri=8-17
SourceNetwork=lannet DestinationInterface=any
DestinationNetwork=all-nets Schedule=OfficeHours
name=AllowHTTP
55
Page 69
3.6. Schedules Chapter 3. Fundamentals
• Action: NAT
• Service: http
• Schedule: OfficeHours
• SourceInterface: lan
• SourceNetwork lannet
• DestinationInterface: any
• DestinationNetwork: all-nets
4. Click OK.
56
Page 70
3.7. X.509 Certificates Chapter 3. Fundamentals
3.7. X.509 Certificates
NetDefendOS supports digital certificates that comply with the ITU-T X.509 standard. This involves the use of an X.509 certificate hierarchy with public-key cryptography to accomplish key
distribution and entity authentication.
3.7.1. Overview
An X.509 certificate is a digital proof of identity. It links an identity to a public key in order to establish whether a public key truly belongs to the supposed owner. By doing this, it prevents data
transfer interception by a malicious third-party who might post a phony key with the name and user
ID of an intended recipient.
A certificate consists of the following:
• A public key: The "identity" of the user, such as name, user ID.
• Digital signatures: A statement that tells the information enclosed in the certificate has been
vouched for by a Certificate Authority (CA).
By binding the above information together, a certificate is a public key with identification attached,
coupled with a stamp of approval by a trusted party.
3.7.2. The Certification Authority
A certification authority ("CA") is a trusted entity that issues certificates to other entities. The CA
digitally signs all certificates it issues. A valid CA signature in a certificate verifies the identity of
the certificate holder, and guarantees that the certificate has not been tampered with by any third
party.
A certification authority is responsible for making sure that the information in every certificate it issues is correct. It also has to make sure that the identity of the certificate matches the identity of the
certificate holder.
A CA can also issue certificates to other CAs. This leads to a tree-like certificate hierarchy. The
highest CA is called the root CA. In this hierarchy, each CA is signed by the CA directly above it,
except for the root CA, which is typically signed by itself.
A certification path refers to the path of certificates from one certificate to another. When verifying
the validity of a user certificate, the entire path from the user certificate up to the trusted root certificate has to be examined before establishing the validity of the user certificate.
The CA certificate is just like any other certificates, except that it allows the corresponding private
key to sign other certificates. Should the private key of the CA be compromised, the whole CA, including every certificate it has signed, is also compromised.
3.7.3. Validity Time
A certificate is not valid forever. Each certificate contains the dates between which the certificate is
valid. When this validity period expires, the certificate can no longer be used, and a new certificate
has to be issued.
3.7.4. Certificate Revocation Lists
A Certificate Revocation List (CRL) contains a list of all certificates that have been cancelled before
their expiration date. This can happen for several reasons. One reason could be that the keys of the
certificate have been compromised in some way, or perhaps that the owner of the certificate has lost
the rights to authenticate using that certificate. This could happen, for instance, if an employee has
57
Page 71
3.7.5. Trusting Certificates Chapter 3. Fundamentals
left the company from whom the certificate was issued.
A CRL is regularly published on a server that all certificate users can access, using either the LDAP
or HTTP protocols.
Certificates often contain a CRL Distribution Point (CDP) field, which specifies the location from
where the CRL can be downloaded. In some cases certificates do not contain this field. In those
cases the location of the CRL has to be configured manually.
The CA updates its CRL at a given interval. The length of this interval depends on how the CA is
configured. Typically, this is somewhere between an hour to several days.
3.7.5. Trusting Certificates
When using certificates, the firewall trusts anyone whose certificate is signed by a given CA. Before
a certificate is accepted, the following steps are taken to verify the validity of the certificate:
• Construct a certification path up to the trusted root CA.
• Verify the signatures of all certificates in the certification path.
• Fetch the CRL for each certificate to verify that none of the certificates have been revoked.
3.7.6. Identification Lists
In addition to verifying the signatures of certificates, NetDefendOS also employs identification lists.
An identification list is a list naming all the remote identities that are allowed access through a specific VPN tunnel, provided the certificate validation procedure described above succeeded.
3.7.7. X.509 Certificates in NetDefendOS
X.509 certificates can be uploaded to the D-Link Firewall for use in IKE/IPsec authentication,
Webauth etc. There are two types of certificates that can be uploaded, self signed certificates and remote certificates belonging to a remote peer or CA server.
Example 3.18. Uploading an X.509 Certificate
The certificate may either be self-signed or belonging to a remote peer or CA server.
Web Interface
1. Go to Objects > Authentication Objects > Add > Certificate
2. Specify a suitable name for the certificate.
3. Now select one of the following:
• Upload self-signed X.509 Certificate
• Upload a remote certificate
4. Click OK and follow the instructions.
58
Page 72
3.8. Setting Date and Time Chapter 3. Fundamentals
3.8. Setting Date and Time
Correctly setting the date and time is important for NetDefendOS to operate properly. Time scheduled policies, auto-update of IDP signatures, and other product features require that the system clock
is accurately set. In addition, log messages are tagged with time-stamps in order to indicate when a
specific event occured. Not only does this assume a working clock, but also that the clock is correctly synchronized with other devices in the network.
To maintain current date and time, NetDefendOS makes use of a built-in real-time hardware clock.
This clock is also equipped with a battery backup to guard against a temporary loss of power. In addition, NetDefendOS supports Time Synchronization Protocols in order to automatically adjust the
clock, based on queries sent to special external servers.
3.8.1. General Date and Time Settings
3.8.1.1. Current Date and Time
The administrator can set the date and time manually and this is recommended when a new NetDefendOS installation is started for the first time.
Example 3.19. Setting the Current Date and Time
To adjust the current date and time, follow the steps outlined below:
CLI
gw-world:/> time -set YYYY-mm-DD HH:MM:SS
Where YYYY-mm-DD HH:MM:SS is the new date and time. Note that the date order is year, then month and then
day. For example, to set the date and time to 9:25 in the morning on April 27th, 2007 the command would be:
gw-world:/> time -set 2007-04-27 09:25:00
Web Interface
1. Go to System > Date and Time
2. Click Set Date and Time.
3. Set year, month, day and time via the dropdown controls.
4. Click OK.
Note
A new date and time will be applied by NetDefendOS as soon as it is set.
3.8.1.2. Time Zones
The world is divided up into a number of time zones with Greenwich Mean Time (GMT) in London
at zero longitude being taken as the base time zone. All other time zones going east and west from
zero longitude are taken as being GMT plus or minus a given integer number of hours. All locations
counted as being inside a given time zone will then have the same local time and this will be one of
the integer offsets from GMT.
The NetDefendOS time zone setting reflects the time zone where the D-Link Firewall is physically
located.
59
Page 73
3.8.2. Time Servers Chapter 3. Fundamentals
Example 3.20. Setting the Time Zone
To modify the NetDefendOS time zone to be GMT plus 1 hour, follow the steps outlined below:
CLI
gw-world:/> set DateTime Timezone=GMTplus1
Web Interface
1. Go to System > Date and Time
2. Select (GMT+01:00) in the Timezone drop-down list.
3. Click OK.
3.8.1.3. Daylight Saving Time
Many regions follow Daylight Saving Time (DST) (or "Summer-time" as it is called in some countries) and this means clocks are advanced for the summer period. Unfortunately, the principles regulating DST vary from country to country, and in some cases there can be variations within the same
country. For this reason, NetDefendOS does not automatically know when to adjust for DST. Instead, this information has to be manually provided if daylight saving time is to be used.
There are two parameters governing daylight saving time; the DST period and the DST offset. The
DST period specifies on what dates daylight saving time starts and ends. The DST offset indicates
the number of minutes to advance the clock during the daylight saving time period.
Example 3.21. Enabling DST
To enable DST, follow the steps outlined below:
CLI
gw-world:/> set DateTime DSTEnabled=Yes
Web Interface
1. Goto System/Date and Time
2. Check the Enable daylight saving time checkbox control.
3. Click OK.
3.8.2. Time Servers
The hardware clock which NetDefendOS uses can sometimes become fast or slow after a period of
operation. This is normal behavior in most network and computer equipment and is solved by utilizing Time Servers.
NetDefendOS is able to adjust the clock automatically based on information received from one or
more Time Servers which provide a highly accurate time, usually using atomic clocks. Using Time
Servers is highly recommended as it ensures NetDefendOS will have its date and time aligned with
other network devices.
60
Page 74
3.8.2. Time Servers Chapter 3. Fundamentals
3.8.2.1. Time Synchronization Protocols
Time Synchronization Protocols are standardised methods for retrieving time information from external Time Servers. NetDefendOS supports the following time synchronization protocols:
• SNTP - Defined by RFC 2030, The Simple Network Time Protocol (SNTP) is a lightweight implementation of NTP (RFC 1305). This is used by NetDefendOS to query NTP servers.
• UDP/TIME - The Time Protocol (UDP/TIME) is an older method of providing time synchronization service over the Internet. The protocol provides a site-independent, machine-readable date
and time. The server sends back the time in seconds since midnight on January first, 1900.
Most public Time Servers run the NTP protocol and are accesible using SNTP.
3.8.2.2. Configuring Time Servers
Up to three Time Servers can be configured to query for time information. By using more than a
single server, situations where an unreachable server causes the time synchronization process to fail
can be prevented. NetDefendOS always queries all configured Time Servers and then computes an
average time based on all responses. Internet search engines can be used to list publicly available
Time Servers.
Important
Make sure an external DNS server is configured so that Time Server URLs can be resolved (see Section 3.9, “DNS Lookup”). This is not needed if using server IP addresses.
Example 3.22. Enabling Time Synchronization using SNTP
In this example, time synchronization is set up to use the SNTP protocol to communicate with the NTP servers at
the Swedish National Laboratory for Time and Frequency. The NTP server URLs are ntp1.sp.se and ntp2.sp.se.
CLI
gw-world:/> set DateTime TimeSynchronization=custom TimeSyncServer1=dns:ntp1.sp.se
Web Interface
1. Go to System > Date and Time
2. Check the Enable time synchronization.
3. Now enter:
• Time Server Type: SNTP
• Primary Time Server: ntp1.sp.se
• Seconadry Time Server: ntp2.sp.se
4. Click OK.
TimeSyncServer2=dns:ntp2.sp.se TimeSyncInterval=86400
Note
If the TimeSyncInterval parameter is not specified when using the CLI to set the synchronization interval, the default of 86400 seconds (= 1 day) is used.
61
Page 75
3.8.2. Time Servers Chapter 3. Fundamentals
Example 3.23. Manually Triggering a Time Synchronization
Time synchronization can be triggered from the CLI. The output below shows a typical response.
CLI
gw-world:/> time -sync
Attempting to synchronize system time...
Server time: 2007-02-27 12:21:52 (UTC+00:00)
Local time: 2007-02-27 12:24:30 (UTC+00:00) (diff: 158)
Local time successfully changed to server time.
3.8.2.3. Maximum Time Adjustment
To avoid situations where a faulty Time Server causes the clock to be updated with a extremely inaccurate time, a Maximum Adjustment value (in seconds) can be set. If the difference between the
current NetDefendOS time and the time received from a Time Server is greater than this Maximum
Adjustment value, then the Time Server response will be discarded. For example, assume that the
maximum adjustment value is set to 60 seconds and the current NetDefendOS time is 16:42:35. If a
Time Server responds with a time of 16:43:38 then the difference is 63 seconds. This is greater than
the Maximum Adjustment value so no update occurs for this response.
Example 3.24. Modifying the Maximum Adjustment Value
CLI
gw-world:/> set DateTime TimeSyncMaxAdjust=40000
Web Interface
1. Go to System > Date and Time
2. For the setting Maximum time drift that a server is allowed to adjust, enter the maximum time drift in
seconds that a server is allowed to adjust for
3. Click OK
Sometimes it might be necessary to override the maximum adjustment, for instance, if time synchronization has just been enabled and the inital time difference is greater than the maximum adjust
value. It is then possible to manually force a synchronization and disregard the maximum adjustment parameter.
Example 3.25. Forcing Time Synchronization
This example demonstrates how to force time synchronization, without respecting the maximum adjustment setting.
CLI
gw-world:/> time -sync -force
62
Page 76
3.8.2. Time Servers Chapter 3. Fundamentals
3.8.2.4. Synchronization Intervals
The interval between each synchronization attempt can be adjusted if needed. By default, this value
is 86,400 seconds (1 day), meaning that the time synchronization process is executed once in a 24
hour period.
3.8.2.5. D-Link Time Servers
Using D-Link's own Time Servers is an option in NetDefendOS and this is the recommended way of
synchronizing the firewall clock. These servers communicate with NetDefendOS using the SNTP
protocol.
When the D-Link Server option is chosen, a pre-defined set of recommended default values for the
synchronization are used.
Example 3.26. Enabling the D-Link NTP Server
To enable the use of the D-Link NTP server:
CLI
gw-world:/> set DateTime TimeSynchronization=D-Link
Web Interface
1. Go to System > Date and Time
2. Select the D-Link TimeSync Server radio button
3. Click OK.
As mentioned above, it is important to have an external DNS server configured so that the D-Link
Time Server URLs can be resolved during the access process.
63
Page 77
3.9. DNS Lookup Chapter 3. Fundamentals
3.9. DNS Lookup
A DNS server resolves a textual URL address into a numeric IP address. This allows the actual
physical IP address to change while the URL can stay the same.
URLs can be used in various areas of a NetDefendOS configuration where IP addresses are unknown, or where it makes more sense to make use of DNS resolution instead of using static IP addresses.
To accomplish DNS resolution, NetDefendOS has a built-in DNS client that can be configured to
make use of up to three DNS servers.
Example 3.27. Configuring DNS Servers
In this example, the DNS client is configured to use one primary and one secondary DNS server, having IP addresses 10.0.0.1 and 10.0.0.2 respectively.
CLI
gw-world:/> set DNS DNSServer1=10.0.0.1 DNSServer2=10.0.0.2
Web Interface
1. Goto System > DNS
2. Enter the following:
• Primary DNS: 10.0.0.1
• Secondary DNS: 10.0.0.2
3. Click OK.
64
Page 78
3.9. DNS Lookup Chapter 3. Fundamentals
65
Page 79
Chapter 4. Routing
This chapter describes how to configure IP routing in NetDefendOS.
• Overview, page 66
• Static Routing, page 67
• Policy-based Routing, page 76
• Dynamic Routing, page 80
• Transparent Mode, page 88
4.1. Overview
IP routing capabilities belong to the most fundamental functionalities of NetDefendOS: any IP packet flowing through the system will be subjected to at least one routing decision at some point in
time, and proper setup of routing is crucial for a NetDefendOS system to function as expected.
Apart from basic Static Routing, NetDefendOS also supports Virtual Routing and Dynamic Routing.
In addition, routes can be actively monitored to achieve route and link redundancy with fail-over
capabilities.
66
Page 80
4.2. Static Routing Chapter 4. Routing
4.2. Static Routing
The most basic form of routing is known as Static Routing. The term static refers to the fact that
entries in the routing table are manually added and are therefore permanent (or static) by nature.
Due to this manual approach, static routing is most appropriate to use in smaller network deployments where addresses are fairly fixed and where the amount of connected networks are limited to a
few. For larger networks however (or whenever the network topology is complex), the work of
manually maintaining static routing tables will be time-consuming and problematic. As a consequence, dynamic routing should be used in those cases.
For more information about the dynamic routing capabilities of NetDefendOS, please see Section 4.4, “Dynamic Routing”. Note however, that even if you choose to implement dynamic routing
for your network, you will still need to understand the principles of static routing and how it is implemented in NetDefendOS.
The Principles of Routing
IP routing is essentially the mechanism in TCP/IP networks used for delivering IP packets from
their source to their ultimate destination through a number of intermediary nodes, most often referred to as routers or firewalls. In each router, a routing table is consulted to find out where to send
the packet next. A routing table usually consists of several routes, where each route in principle contains a destination network, an interface to forward the packet on and optionally the IP address of
the next gateway in the path to the destination.
The images below illustrates a typical D-Link Firewall deployment and how the associated routing
table would look like.
Route # Interface Destination Gateway
1 lan 192.168.0.0/24
2 dmz 10.4.0.0/16
3 wan 195.66.77.0/24
4 wan 0.0.0.0/0 195.66.77.4
Basically, this routing table provides the following information:
• Route #1: All packets going to hosts on the 192.168.0.0/24 network should be sent out on the lan
interface. As no gateway is specified for the route entry, the host is assumed to be located on the
network segment directly reachable from the lan interface.
• Route #2: All packets going to hosts on the 10.4.0.0/16 network are to be sent out on the dmz interface. Also for this route, no gateway is specified.
• Route #3: All packets going to hosts on the 195.66.77.0/24 network will be sent out on the wan
interface. No gateway is required to reach the hosts.
• Route #4: All packets going to any host (the 0.0.0.0/0 network will match all hosts) will be sent
out on the wan interface and to the gateway with IP address 195.66.77.4. That gateway will then
consult its routing table to find out where to send the packets next. A route with destination
0.0.0.0/0 is often referred to as the Default Route as it will match all packets for which no specific route has been configured.
When a routing table is evaluated, the ordering of the routes is important. In general, a routing table
is evaluated with the most specific routes first. In other words, if two routes have destination networks that overlap, the more narrow network will be evaluated prior to the wider one. In the above
example, a packet with a destination IP address of 192.168.0.4 will theoretically match both the first
route and the last one. However, the first route entry is a more specific match, so the evaluation will
end there and the packet will be routed according to that entry.
67
Page 81
4.2.1. Static Routing in NetDefendOS Chapter 4. Routing
4.2.1. Static Routing in NetDefendOS
This section describes how routing is implemented in NetDefendOS, and how to configure static
routing.
NetDefendOS supports multiple routing tables. A default table called main is pre-defined and is always present in NetDefendOS. However, additional and completely separate routing tables can be
defined by the administrator to provide alternate routing.
These user-defined extra routing toubles can be used to implement Policy Based Routing which
means the administrator can set up rules in the IP rule-set which decide which of the routing tables
will handle certain types of traffic. (see Section 4.3, “Policy-based Routing”).
Route Lookup Mechanism
The NetDefendOS route lookup mechanism has some slight differences to how some other router
products work. In many routers, where the IP packets are forwarded without context (in other words,
the forwarding is stateless), the routing table is scanned for each and every IP packet received by the
router. In NetDefendOS, packets are forwarded with state-awareness, so the route lookup process is
tightly integrated into NetDefendOS's stateful inspection mechanism.
When an IP packet is received on any of the interfaces, the connection table is consulted to see if
there is an already open connection for which the received packet belongs. If an existing connection
is found, the connection table entry includes information on where to route the packet so there is no
need for lookups in the routing table. This is far more efficient than traditional routing table lookups, and is one reason for the high forwarding performance of NetDefendOS.
If an established connection cannot be found, then the routing table is consulted. It is important to
understand that the route lookup is performed before the various rules sections get evaluated. As a
result, the destination interface is known at the time NetDefendOS decides if the connection should
be allowed or dropped. This design allows for a more fine-grained control in security policies.
Route Notation
NetDefendOS uses a slightly different way of describing routes compared to most other systems but
this way is easier to understand, making errors less likely.
Many other products do not use the specific interface in the routing table, but specify the IP address
of the interface instead. The routing table below is from a Microsoft Windows XP workstation:
====================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x10003 ...00 13 d4 51 8d dd ...... Intel(R) PRO/1000 CT Network
0x20004 ...00 53 45 00 00 00 ...... WAN (PPP/SLIP) Interface
====================================================================
====================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
10.4.2.143 255.255.255.255 127.0.0.1 127.0.0.1 50
10.255.255.255 255.255.255.255 10.4.2.143 10.4.2.143 50
85.11.194.33 255.255.255.255 192.168.0.1 192.168.0.10 20
192.168.0.0 255.255.255.0 192.168.0.10 192.168.0.10 20
192.168.0.10 255.255.255.255 127.0.0.1 127.0.0.1 20
192.168.0.255 255.255.255.255 192.168.0.10 192.168.0.10 20
255.255.255.255 255.255.255.255 10.4.2.143 10.4.2.143 1
255.255.255.255 255.255.255.255 192.168.0.10 192.168.0.10 1
Default Gateway: 192.168.0.1
====================================================================
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.10 20
10.0.0.0 255.0.0.0 10.4.2.143 10.4.2.143 1
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
224.0.0.0 240.0.0.0 10.4.2.143 10.4.2.143 50
224.0.0.0 240.0.0.0 192.168.0.10 192.168.0.10 20
68
Page 82
4.2.1. Static Routing in NetDefendOS Chapter 4. Routing
Persistent Routes:
None
The corresponding routing table in NetDefendOS is similar to this:
Flags Network Iface Gateway Local IP Metric
----- ------------------ -------- -------------- --------- ------
192.168.0.0/24 lan 20
10.0.0.0/8 wan 1
0.0.0.0/0 wan 192.168.0.1 20
The NetDefendOS way of describing the routes is easier to read and understand. Another advantage
with this form of notation is that you can specify a gateway for a particular route without having a
route that covers the gateways's IP address or despite the fact that the route covers the gateway's IP
address is normally routed via another interface.
It is also worth mentioning that NetDefendOS allows you to specify routes for destinations that are
not aligned with traditional subnet masks. In other words, it is perfectly legal to specify one route
for the destination address range 192.168.0.5-192.168.0.17 and another route for addresses
192.168.0.18-192.168.0.254. This is a feature that makes NetDefendOS highly suitable for routing
in highly complex network topologies.
Displaying the Routing Table
It is important to distinguish between the routing table that is active in the system, and the routing
table that you configure. The routing table that you configure contains only the routes that you have
added manually (in other words, the static routes). The content of the active routing table, however,
will vary depending on several factors. For instance, if dynamic routing has been enabled, the routing table will be populated with routes learned by communicating with other routers in the network.
Also, features such as route fail-over will cause the active routing table to look different from time
to time.
Example 4.1. Displaying the Routing Table
This example illustrates how to display the contents of the configured routing table as well as the active routing table.
CLI
To see the configured routing table:
gw-world:/> cc RoutingTable main
gw-world:/main> show
Route
# Interface Network Gateway Local IP
- --------- -------- ------------- -------1 wan all-nets 213.124.165.1 (none)
2 lan lannet (none) (none)
3 wan wannet (none) (none)
To see the active routing table enter:
gw-world:/> routes
Flags Network Iface Gateway Local IP Metric
----- ------------------ -------------- --------------- --------------- ------
192.168.0.0/24 lan 0
69
Page 83
4.2.1. Static Routing in NetDefendOS Chapter 4. Routing
213.124.165.0/24 wan 0
0.0.0.0/0 wan 213.124.165.1 0
Web Interface
To see the configured routing table:
1. Go to Routing > Routing Tables
2. Select and right-click the main routing table in the grid.
3. Choose Edit in the menu.
The main window will list the configured routes.
To see the active routing table, select the Routes item in the Status dropdown menu in the menu bar. The main
window will list the active routing table.
Core Routes
NetDefendOS automatically populates the active routing table with Core Routes. These routes are
present for the system to understand where to route traffic that is destined for the system itself.
There is one route added for each interface in the system. In other words, two interfaces named lan
and wan, and with IP addresses 192.168.0.10 and 193.55.66.77, respectively, will result in the following routes:
Route # Interface Destination Gateway
1 core 192.168.0.10
2 core 193.55.66.77
Basically, when the system receives an IP packet whose destination address is one of the interface
IPs, the packet will be routed to the core interface, i.e. intercepted by the system itself.
There is also a core route added for all multicast addresses:
Route # Interface Destination Gateway
1 core 224.0.0.0/4
To include the core routes when you display the active routing table, you have to specify an option
to the routing command.
Example 4.2. Displaying the Core Routes
This example illustrates how to display the core routes in the active routing table.
CLI
gw-world:/> routes -all
Flags Network Iface Gateway Local IP Metric
----- ------------------ -------------- --------------- --------------- ------
127.0.0.1 core (Shared IP) 0
192.168.0.1 core (Iface IP) 0
213.124.165.181 core (Iface IP) 0
127.0.3.1 core (Iface IP) 0
127.0.4.1 core (Iface IP) 0
192.168.0.0/24 lan 0
213.124.165.0/24 wan 0
224.0.0.0/4 core (Iface IP) 0
0.0.0.0/0 wan 213.124.165.1 0
70
Page 84
4.2.2. Route Failover Chapter 4. Routing
Web Interface
To see the core routes from the web interface, select the Routes item in the Status dropdown menu in the menu
bar. Check the Show all routes checkbox and click the Apply button. The main window will list the active routing
table including the core routes.
Tip
For detailed information about the output of the CLI routes command. Please see the
CLI Reference Guide.
4.2.2. Route Failover
Overview
D-Link Firewalls are often deployed in mission-critical locations where availability and connectivity
is crucial. A corporation relying heavily on access to the Internet, for instance, could have their operations severely disrupted if an Internet connection fails.
As a consequence, it is quite common to have backup Internet connectivity using a secondary Internet Service Provider (ISP). The connections to the two service providers often use different access
methods to avoid a single point of failure.
To facilitate a scenario such as multiple ISPs, NetDefendOS provides a Route Failover capability so
that should one route fail, traffic can automatically failover to another, alternate route. NetDefendOS
implements Route Failover through the use of Route Monitoring in which NetDefendOS monitors
the availability of routes and switches traffic to an alternate route should the primary, preferred one
fail.
Figure 4.1. A Route Failover Scenario for ISP Access
Setting Up Route Failover
Route Monitoring should be enabled on a per-route basis. To enable the Route Failover feature in a
scenario with a preferred and a backup route, the preferred route will have Route Monitoring enabled, however the backup route does not require it to be enabled since it will usually have no route
to failover to. For a route with Route Monitoring enabled, one of two Route Monitoring methods
must be chosen:
71
Page 85
4.2.2. Route Failover Chapter 4. Routing
Interface Link Status
NetDefendOS will monitor the link status of the interface specified in the route. As long as the interface is up, the route is diagnosed as healthy. This method is appropriate for monitoring that
the interface is physically attached and that the cabling is working
as expected. As any changes to the link status are instantly noticed, this method provides the fastest response to failure.
Gateway Monitoring
If a specific gateway has been specified as the next hop for a
route, accessibility to that gateway can be monitored by sending
periodic ARP requests. As long as the gateway responds to these
requests, the route is considered to be functioning correctly.
Host Monitoring
The first two options check the accessibility of components local
to the D-Link Firewall. An alternative is to monitor the accessibility of one or more nominated remote hosts. These hosts might
have known high availability and polling them can indicate if
traffic from the local D-Link Firewall is reaching them. Host monitoring also provides a way to measure the network delays in
reaching remote hosts and to initiate failover to an alternate route
if delays exceed administrator-specified thresholds.
Setting the Route Metric
When specifying routes, the administrator should manually set a route's Metric. The Metric is a positive integer that indicates how preferred the route is as a means to reach its destination. When two
routes offer a means to reach the same destination, NetDefendOS will select the one with the lowest
Metric value for sending data (if two routes have the same Metric, the route found first in the routing table will be chosen).
A primary, preferred route should have a lower Metric (eg."10"), and a secondary, failover route
should have a higher Metric value (eg."20").
Multiple Failover Routes
It is possible to specify more than one failover route. For instance, the primary route could have two
other routes as failover routes instead of just one. In this case the Metric should be different for each
of the three routes: "10" for the primary route, "20" for the first failover route and "30" for the
second failover route. The first two routes would have Route Monitoring enabled in the routing table but the last one (with the highest Metric) would not since it has no route to failover to.
Failover Processing
Whenever monitoring determines that a route is not available, NetDefendOS will mark the route as
disabled and instigate Route Failover for existing and new connections. For already established connections, a route lookup will be performed to find the next best matching route and the connections
will then switch to using the new route. For new connections, route lookup will ignore disabled
routes and the next best matching route will be used instead.
The table below defines two default routes, both having 0.0.0.0/0 as the destination, but using two
different gateways. The first, primary route has the lowest Metric and also has Route Monitoring enabled. Route Monitoring for the second, alternate route isn't meaningful since it has no failover
route.
Route # Interface Destination Gateway Metric Monitoring
1 wan 0.0.0.0/0 195.66.77.1 10 On
2 wan 0.0.0.0/0 193.54.68.1 20 Off
When a new connection is about to be established to a host on the Internet, a route lookup will result
72
Page 86
4.2.2. Route Failover Chapter 4. Routing
in the route that has the lowest Metric being chosen. If the primary WAN router should then fail,
this will be detected by NetDefendOS, and the first route will be disabled. As a consequence, a new
route lookup will be performed and the second route will be selected with the first one being marked
as disabled.
Re-enabling Routes
Even if a route has been disabled, NetDefendOS will continue to check the status of that route.
Should the route become available again, it will be re-enabled and existing connections will automatically be transferred back to it.
Route Interface Grouping
When using route monitoring, it is important to check if a failover to another route will cause the
routing interface to be changed. If this could happen, it is necessary to take some precautionary steps
to ensure that policies and existing connections will be maintained.
To illustrate the problem, consider the following configuration:
First, there is one IP rule that will NAT all HTTP traffic destined for the Internet through the wan
interface:
# Action Src Iface Src Net Dest Iface Dest Net Parameters
1 NAT lan lannet wan all-nets http
The routing table consequently contains the following default route:
Route # Interface Destination Gateway Metric Monitoring
1 wan 0.0.0.0/0 195.66.77.1 10 Off
Now a secondary route is added over a backup DSL connection and Route Monitoring is enabled for
this. The updated routing table will look like this:
Route # Interface Destination Gateway Metric Monitoring
1 wan 0.0.0.0/0 195.66.77.1 10 On
2 dsl 0.0.0.0/0 193.54.68.1 20 Off
Notice that Route Monitoring is enabled for the first route but not the backup, failover route.
As long as the preferred wan route is healthy, everything will work as expected. Route Monitoring
will also be functioning, so the secondary route will be enabled should the wan route fail.
There are, however, some problems with this setup: if a route failover occurs, the default route will
then use the dsl interface. When a new HTTP connection is then established from the intnet network, a route lookup will be made resulting in a destination interface of dsl. The IP rules will then
be evaluated, but the original NAT rule assumes the destination interface to be wan so the new connection will be dropped by the rule-set.
In addition, any existing connections matching the NAT rule will also be dropped as a result of the
change in the destination interface. Clearly, this is undesirable.
To overcome this issue, potential destination interfaces should be grouped together into an Interface
Group and the Security/Transport Equivalent flag should be enabled for the Group. The Interface
Group is then used as the Destination Interface when setting policies. For more information on
groups, see Section 3.3.5, “Interface Groups”.
Gratuitous ARP Generation
By default NetDefendOS generates a gratuitous ARP request when a route failover occurs. The reason for this is to notify surrounding systems that there has been a route change. This behaviour can
73
Page 87
4.2.2. Route Failover Chapter 4. Routing
be controlled by the advanced setting RFO_GratuitousARPOnFail.
Host Monitoring
Overview
To provide a more flexible and configurable way to monitor the integrity of routes, NetDefendOS
provides the additonal capability to perform Host Monitoring as a means to monitor a route. This
feature means that one or more external host systems can be routinely polled to check that a particular route is available.
The advantages of Host Monitoring are twofold:
• In a complex network topology it is more reliable to check accessibility to external hosts. Just
monitoring a link to a local switch may not indicate a problem in another part of the internal network.
• Host monitoring can be used to help in setting the acceptable Quality of Service level of internet
response times. Internet access may be functioning but it may be desirable to instigate route failover if response latency times become unacceptable using the existing route.
Enabling Host Monitoring
As part of Route Properties Host Monitoring can be enabled and a single route can have multiple
hosts associated with it for monitoring. Multiple hosts can provide a higher certainty that any network problem resides in the local network rather than because one remote host itself is down.
In association with Host Monitoring there are two numerical parameters for a route:
Grace Period
Minimum Number of Hosts
Available
This is the period of time after startup or after reconfiguration
of the D-Link Firewall which NetDefendOS will wait before
starting Route Monitoring. This waiting period allows time
for all network links to initialize once the firewall comes online.
This is the minimum number of hosts that must be considered
to be accessible before the route is deemed to have failed. The
criteria for host accessibility are described below
Specifying Hosts
For each host specified for host monitoring there are a number of property parameters that should be
set:
A host can be polled using a different protocol which can be one of:
• Method - The method by which the host is to be polled. This can be one of:
• ICMP - ICMP "Ping" polling. An IP address must be specified for this.
• HTTP - A normal HTTP server request using a URL. A URL must be specified for this as
well as a text string which is the beginning (or complete) text of a valid response. If no text
is specified, any response from the server will be valid.
• Interval - The interval in milliseconds between polling attempts.
74
Page 88
4.2.3. Proxy ARP Chapter 4. Routing
• Sample - The number of polling attempts used as a sample size for calculating the Percentage
Loss and the Average Latency.
• Max Number of Failed Attempts - The maximum permissable number of polling attempts that
fail. If this number is exceeded then the host is considered unreachable.
• Max Average Latency - The maximum number of milliseconds allowable for a response to be
received by the host. If this threshold is exceeded then the host is considered unreachable. Average Latency is calculated by averaging the response times from the host. If a polling attempt receives no response then it is not included in the averaging calculation.
The Reachability Required option
An important option that can be enabled for a host is the Reachability Required option. When this
is selected, the host must be determined as accessible in order for that route to be considered to be
functioning. Even if other hosts are accessible, this option says that the accessibility of a host with
this option set is mandatory.
Where multiple hosts are specified for host monitoring, more than one of them could have Reach-
ability Required enabled. If NetDefendOS determines that any host with this option enabled is not
reachable, Route Failover is initiated.
4.2.3. Proxy ARP
As explained previously in Section 3.4, “ARP”, the ARP protocol facilitates a mapping between an
IP address and the MAC address of a node on an Ethernet network. However situations may exist
where a network running Ethernet is separated into two parts with a routing device such as an installed D-Link Firewall, in between. In such a case, NetDefendOS itself can respond to ARP requests directed to the network on the other side of the D-Link Firewall using the feature known as
Proxy ARP.
For example, host A on one subnet might send an ARP request to find out the MAC address of the
IP address of host B on another separate network. The proxy ARP feature means that NetDefendOS
responds to this ARP request instead of host B. The NetDefendOS sends its own MAC address instead in reply, essentially pretending to be the target host. After receiving the reply, Host A then
sends data directly to NetDefendOS which, acting as a proxy, forwards the data on to host B. In the
process the device has the opportunity to examine and filter the data.
The splitting of an Ethernet network into two distinct parts is a common application of D-Link Firewall's Proxy ARP feature, where access between the parts needs to be controlled. In such a scenario
NetDefendOS can monitor and regulate all traffic passing between the two parts.
Note
It is only possible to have Proxy ARP functioning for Ethernet and VLAN interfaces.
75
Page 89
4.3. Policy-based Routing Chapter 4. Routing
4.3. Policy-based Routing
4.3.1. Overview
Policy-based Routing is an extension to the standard approach to routing described previously. It offers administrators significant flexibility in implementing routing decision policies by be able to
define Policy-based Routing Rules.
Normal routing forwards packets according to destination IP address information derived from static
routes or from a dynamic routing protocol. For example, using OSPF, the route chosen for packets
will be the least-cost (shortest) path derived from an SPF calculation. Policy-based Routing means
that the routes chosen for traffic can be based on various parameters, such as the source address or
service type.
NetDefendOS implements routing by not only looking at packets one by one, but by implementing
it on a state or connection basis so that routing policy provides control on both the forward and return routing directions.
Policy-based Routing can also be applied on an application basis by allowing:
Source based routing
Service-based routing
Creating provider-independent
metropolitan area networks
Policy-based Routing implementation in NetDefendOS consists of two elements:
• One or more user-defined alternate Policy-based routing tables in addition to the standard de-
fault main routing table.
• Policy-based routing rules, which determines which routing table to use depending on the
traffic.
When more than one ISP is used to provide Internet services,
Policy-based Routing can route traffic originating from different sets of users through different routes. For example, traffic
from one address range might be routed through one ISP,
whilst traffic from another address range might be through a
second ISP.
Policy-based Routing can route a given protocols such as HTTP, through transparent proxies such as Web caches.
All users share a common active backbone, but each can use
different ISPs, subscribing to different providers.
4.3.2. Policy-based Routing Tables
NetDefendOS, as standard, has one default routing table called main. In addition to the main table,
it is possible to define one or more, additional alternate routing tables (this section will sometimes
refer to Policy-based Routing Tables as alternate routing tables).
Alternate routing tables contain the same information for describing routes as main, except that
there is an extra parameter ordering defined for each of them. This parameter decides how route
lookup is done with the alternate table in conjunction with the main table. This is described further
in Section 4.3.5, “The Ordering parameter” below.
4.3.3. Policy-based Routing Rules
A rule in the Policy-based Routing rule-set can decide which routing table is selected. A Policy-
76
Page 90
4.3.4. Policy-based Routing Table Selection
based Routing rule can be triggered by the type of Service (eg. HTTP) in combination with the
Source/Destination Interface and Source/Destination Network.
When looking up Policy-based Rules, it is the first matching rule found that is triggered.
4.3.4. Policy-based Routing Table Selection
When a new connection is established the following is the way the decision is made as to which
routing table is chosen:
1. Access Rules are checked first.
2. The source interface is looked up in the main routing table to find the packet's destination ad-
dress.
3. A search is made for a Policy-based Routing rule that matches the source and destination inter-
face. If a matching rule is found then this determines the routing table to use.
4. Once the correct routing table has been located, a final check is made to make sure that the
source IP address is routed on the receiving interface. This is done by making a reverse lookup
in the routing table using the source IP address. If this check fails then a Default access rule
error message is generated.
Chapter 4. Routing
5. The connection is then subject to the normal IP Rule-set. If a SAT rule is encountered, address
translation will be performed. The decision of which routing table to use is made before carrying out address translation but the actual route lookup is performed on the altered address.
6. The packet is finally forwarded and the new connection opened by NetDefendOS.
4.3.5. The Ordering parameter
Once the routing table for a new connection is chosen and that table is an alternate routing table, the
Ordering parameter associated with the table is used to decide how the alternate table is combined
with the main table to lookup the appropriate route. The three available options are:
1. Default - The default behaviour is to first look up the connection's route in the main table. If
no matching route is found, or the default route 0.0.0.0/0 is found, a lookup for a matching
route in the alternate table is done. If no match is found in the alternate table then the default
route in the main table will be used.
2. First - This behaviour is to first look up the connection's route in the alternate table. If no
matching route is found there then the main table is searched.
3. Only - This option ignores the existence of any other table except the alternate table. One ap-
plication of this is to give the administrator a way to dedicate a single routing table to one set of
interfaces.
The first two options can be regarded as combining the alternate table with the main table and assigning one route if there is a match in both tables.
Important - Ensuring all-nets appears in the main table.
A common mistake with Policy-based routing is the absence of a route in the default
main routing table with a destination interface of all-nets. The absence of an all-nets
route will prevent Policy-based Routing Rules from functioning.
77
Page 91
4.3.5. The Ordering parameter Chapter 4. Routing
Example 4.3. Creating a Policy-Based Routing table
In this example we create a Policy-based Routing table named "TestPBRTable".
Web Interface
1. Go to Routing > Routing Tables > Add > RoutingTable
2. Now enter:
• Name: TestPBRTable
• For Ordering select one of:
• First - the named routing table is consulted first of all. If this lookup fails, the lookup will continue in the
main routing table.
• Default - the main routing table will be consulted first. If the only match is the default route (0.0.0.0/0),
the named routing table will be consulted. If the lookup in the named routing table fails, the lookup as a
whole is considered to have failed.
• Only - the named routing table is the only one consulted. If this lookup fails, the lookup will not continue in the main routing table.
3. If Remove Interface IP Routes is enabled, the default interface routes are removed, i.e. routes to the core
interface (which are routes to NetDefendOS itself).
4. Click OK.
Example 4.4. Creating the Route
After defining the routing table "TestPBRTable", we add routes into the table.
Web Interface
1. Go to Routing > Routing Tables > TestPBRTable > Add > Route
2. Now enter:
• Interface: The interface to be routed
• Network: The network to route
• Gateway: The gateway to send routed packets to
• Local IP Address: The IP address specified here will be automatically published on the corresponding in-
terface. This address will also be used as the sender address in ARP queries. If no address is specified,
the firewall's interface IP address will be used.
• Metric: Specifies the metric for this route. (Mostly used in route fail-over scenarios)
3. Click OK
Example 4.5. Policy Based Routing Configuration
This example illustrates a multiple ISP scenario which is a common use of Policy-based Routing. The following is
assumed:
• Each ISP will give you an IP network from its network range. We will assume a 2-ISP scenario, with the net-
work 1.2.3.0/24 belonging to "ISP A" and "2.3.4.0/24" belonging to "ISP B". The ISP gateways are 1.2.3.1 and
2.3.4.1, respectively.
• All addresses in this scenario are public addresses for the sake of simplicity.
78
Page 92
4.3.5. The Ordering parameter Chapter 4. Routing
• This is a "drop-in" design, where there are no explicit routing subnets between the ISP gateways and the D-
Link Firewall.
In a provider-independent metropolitan area network, clients will likely have a single IP address, belonging to one
of the ISPs. In a single-organization scenario, publicly accessible servers will be configured with two separate IP
addresses: one from each ISP. However, this difference does not matter for the policy routing setup itself.
Note that, for a single organization, Internet connectivity through multiple ISPs is normally best done with the BGP
protocol, where you do not need to worry about different IP spans or policy routing. Unfortunately, this is not always possible, and this is where Policy Based Routing becomes a necessity.
We will set up the main routing table to use ISP A, and add a named routing table, "r2" that uses the default gateway of ISP B.
Interface Network Gateway ProxyARP
lan1 1.2.3.0/24 wan1
lan1 2.3.4.0/24 wan1
wan1 1.2.3.1/32 wan1
wan2 2.3.4.1/32 lan1
wan1 0.0.0.0/0 1.2.3.1
Contents of the named Policy-based Routing table r2:
Interface Network Gateway
wan2 0.0.0.0/0 2.3.4.1
The table r2 has its Ordering parameter set to Default, which means that it will only be consulted if the main routing table lookup matches the default route (0.0.0.0/0).
Contents of the Policy-based Routing Policy:
Source Interface
lan1 1.2.3.0/24 wan2 0.0.0.0/0 ALL r2 r2
wan2 0.0.0.0/0 lan1 2.3.4.0/24 ALL r2 r2
To configure this example scenario:
Web Interface
1. Add the routes found in the list of routes in the main routing table, as shown earlier.
2. Create a routing table called "r2" and make sure the ordering is set to "Default".
3. Add the route found in the list of routes in the routing table "r2", as shown earlier.
4. Add two VR policies according to the list of policies shown earlier.
• Routing > Routing Rules > Add > RoutingRule
• Enter the information found in the list of policies displayed earlier.
• Repeat the above to add the second rule.
Source
Range
Destination
Interface
Destination
Range
Service Forward VR
table
Return VR table
Note
Rules in the above example are added for both inbound and outbound connections.
79
Page 93
4.4. Dynamic Routing Chapter 4. Routing
4.4. Dynamic Routing
4.4.1. Dynamic Routing overview
Dynamic routing is different to static routing in that the D-Link Firewall will adapt to changes of
network topology or traffic load automatically. NetDefendOS first learns of all the directly connected networks and gets further route information from other routers. Detected routes are sorted and
the most suitable routes for destinations are added into the routing table and this information is distributed to other routers. Dynamic Routing responds to routing updates on the fly but has the disadvantage that it is more susceptible to certain problems such as routing loops. In the Internet, two
types of dynamic routing algorithm are used: the Distance Vector(DV) algorithm and the Link
State(LS) algorithm. How a router decides the optimal or "best" route and shares updated information with other routers depends on the type of algorithm used.
4.4.1.1. Distance Vector algorithms
The Distance vector (DV) algorithm is a decentralized routing algorithm that computes the "best"
path in a distributed way. Each router computes the costs of its own attached links, and shares the
route information only with its neighbor routers. The router will gradually learns the least-cost path
by iterative computation and information exchange with its neighbors.
The Routing Information Protocol (RIP) is a well-known DV algorithm and involves sending regular update messages and reflecting routing changes in the routing table. Path determination is based
on the "length" of the path which is the number of intermediate routers {also known as "hops"}.
After updating its own routing table, the router immediately begins transmitting its entire routing table to neighboring routers to inform them of changes.
4.4.1.2. Link State algorithms
Different from the DV algorithms, Link State (LS) algorithms enable routers to keep routing tables
that reflect the topology of the entire network. Each router broadcasts its attached links and link
costs to all other routers in the network. When a router receives these broadcasts it runs the LS algorithm and calculates its own set of least-cost paths. Any change of the link state will be sent
everywhere in the network, so that all routers keep the same routing table information.
Open Shortest Path First (OSPF) is a widely used LS algorithm. An OSPF enabled router first identifies the routers and subnets that are directly connected to it and then broadcasts the information to
all the other routers. Each router uses the information it receives to build a table of what the whole
network looks like. With a complete routing table, each router can identify the subnetworks and
routers that lead to any destination. Routers using OSPF only broadcast updates that inform of
changes and not the entire routing table.
OSPF depends on various metrics for path determination, including hops, bandwidth, load and
delay. OSPF can provide a great deal of control over the routing process since its parameters can
finely tuned.
4.4.1.3. Comparing dynamic routing algorithms
Due to the fact that the global link state information is maintained everywhere in a network, Link
State algorithms have a high degree of configuration control and scalability. Changes result in
broadcasts of just the updated information to others routers which results in faster convergence and
less possibility of routing loops. OSPF can also operate within a hierarchy, whereas RIP has no
knowledge of sub-network addressing. NetDefendOS uses OSPF as its dynamic routing algorithm
because of the advantages it offers.
4.4.1.4. Routing metrics
Routing metrics are the criteria a routing algorithm uses to compute the "best" route to a destination.
A routing protocol relies on one or several metrics to evaluate links across a network and to determine the optimal path. The principal metrics used include:
80
Page 94
4.4.2. OSPF Chapter 4. Routing
Path length
Item Bandwidth
Load
Delay
The sum of the costs associated with each link. A commonly used value for
this metric is called "hop count" which is the number of routing devices a
packet must pass through when it travels from source to destination.
The traffic capacity of a path, rated by "Mbps".
The usage of a router. The usage can be evaluated by CPU utilization and
throughput.
The time it takes to move a packet from the source to the destination. The
time depends on various factors, including bandwidth, load, and the length
of the path.
4.4.2. OSPF
4.4.2.1. OSPF Protocol Overview
Open Shortest Path First (OSPF) is a routing protocol developed for IP networks by the Internet Engineering Task Force (IETF). The NetDefendOS OSPF implementation is based upon RFC 2328,
with compatibility to RFC 1583.
The way OSPF works is that it routes IP packets based only on the destination IP address found in
the IP packet header. IP packets are routed "as is", that is they are not encapsulated in any further
protocol headers as they transit the Autonomous System (AS). OSPF is a dynamic routing protocol,
it quickly detects topological changes in the AS (such as router interface failures) and calculates
new loop-free routes after a period of time.
OSPF is a link-state routing protocol that calls for the sending of link-state advertisements (LSAs) to
all other routers within the same area. In a link-state routing protocol, each router maintains a database describing the Autonomous System's topology. This database is referred to as the link-state
database. Each router in the same AS has an identical database. From the information in the linkstate database, each router constructs a tree of shortest paths with itself as root. This shortest-path
tree gives the route to each destination in the Autonomous System.
OSPF allows sets of networks to be grouped together, this is called an area. The topology of an area
is hidden from the rest of the AS. This information hiding reduces the amount of routing traffic exchanged. Also, routing within the area is determined only by the area's own topology, lending the
area protection from bad routing data. An area is a generalization of an IP subnetted network.
All OSPF protocol exchanges can be authenticated. This means that only routers with the correct authentication can join the Autonomous System. Different authentication schemes can be used, like
none, passphrase or MD5 digest. It is possible to configure separate authentication methods for each
Autonomous System.
4.4.2.2. OSPF Area Overview
The Autonomous System is divided into smaller parts called OSPF Areas. This chapter describes
what an area is, and associated terms.
Areas
An area consists of networks and hosts within an AS that have been grouped
together. Routers that are only within an area are called internal routers, all
interfaces on internal routers are directly connected to networks within the
area. The topology of an area is hidden from the rest of the AS.
ABRs
ASBRs
Routers that have interfaces in more than one area are called Area Border
Routers (ABRs), these maintain a separate topological database for each area
to which they have an interface.
Routers that exchange routing information with routers in other Autonomous
Systems are called Autonomous System Boundary Router (ASBRs). They
81
Page 95
4.4.2. OSPF Chapter 4. Routing
advertise externally learned routes throughout the Autonomous System.
Backbone Areas
Stub Areas
Transit Areas
All OSPF networks need to have at least the backbone area, that is the area
with ID 0. This is the area that all other areas should be connected to, and the
backbone make sure to distribute routing information between the connected
areas. When an area is not directly connected to the backbone it needs a virtual link to it.
Stub areas are areas through which or into which AS external advertisements
are not flooded. When an area is configured as a stub area, the router will
automatically advertises a default route so that routers in the stub area can
reach destinations outside the area.
Transit areas are used to pass traffic from a area that is not directly connect
to the backbone area.
4.4.2.3. Designated Router
Each OSPF broadcast network has a designated router and a backup designated router. The routers
uses OSPF hello protocol to elect the DR and BDR for the network based on the priorities advertised by all the routers. If there already are a DR on the network, the router will accept that one, regardless of its own router priority.
4.4.2.4. Neighbors
Routers that are in the same area become neighbors in that area. Neighbors are elected via the Hello
protocol. Hello packets are sent periodically out of each interface using IP multicast. Routers become neighbors as soon as they see themselves listed in the neighbor's Hello packet. This way, a
two way communication is guaranteed.
The following Neighbor States are defined:
Down
Init
2-Way
ExStart
Exchange
Loading
Full
This is the initial stat of the neighbor relationship.
When a HELLO packet is received from a neighbor, but does NOT include the Router
ID of the firewall in it, the neighbor will be placed in Init state. As soon as the neighbor in question receives a HELLO packet it will know the sending routers Router ID
and will send a HELLO packet with that included. The state of the neighbors will
change to 2-way state.
In this state the communication between the router and the neighbor is bi-directional.
On Point-to-Point and Point-to-Multipoint interfaces, the state will be changed to
Full. On Broadcast interfaces, only the DR/BDR will advance to Fullstate with their
neighbors, all the remaining neighbors will remain in the 2-Way state.
Preparing to build adjacency.
Routers are exchanging Data Descriptors.
Routers are exchanging LSAs.
This is the normal state of an adjacency between a router and the DR/BDR.
4.4.2.5. Aggregates
OSPF Aggregation is used to combine groups of routes with common addresses into a single entry
in the routing table. This is commonly used to minimize the routing table.
4.4.2.6. Virtual Links
82
Page 96
4.4.2. OSPF Chapter 4. Routing
Virtual links are used for:
• Linking an area that does not have a direct connection to the backbone.
• Linking the backbone in case of a partitioned backbone.
Area without direct connection to the backbone
The backbone always need to be the center of all other areas. In some rare case where it is impossible to have an area physically connected to the backbone, a virtual link is used. This virtual
link will provide that area with a logical path to the backbone area. This virtual link is established
between two ABRs that are on one common area, with one of the ABRs connected to the backbone
area. In the example below two routers are connected to the same area (Area 1) but just one of them,
fw1, is connected physically to the backbone area.
Figure 4.2. Virtual Links Example 1
In the above example, the Virtual Link is configured between fw1 and fw2 on Area 1, as it is used as
the transit area. In this configuration only the Router ID has to be configured. The diagram shows
that fw2 needs to have a Virtual Link to fw1 with Router ID 192.168.1.1 and vice versa. These Virtual Links need to be configured in Area 1.
Partitioned Backbone
OSPF allows for linking a partitioned backbone using a virtual link. The virtual link should be configured between two separate ABRs that touch the backbone are from each side and having a common area in between.
83
Page 97
4.4.3. Dynamic Routing Policy Chapter 4. Routing
Figure 4.3. Virtual Links Example 2
The Virtual Link is configured between fw1 and fw2 on Area 1, as it is used as the transit area. In
the configuration only the Router ID have to be configured, as in the example above show fw2 need
to have a Virtual Link to fw1 with the Router ID 192.168.1.1 and vice versa. These VLinks need to
be configured in Area 1.
4.4.2.7. OSPF High Availability Support
There are some limitations in HA support for OSPF that should be noted:
Both the active and the inactive part of an HA cluster will run separate OSPF processes, although
the inactive part will make sure that it is not the preferred choice for routing. The HA master and
slave will not form adjacency with each other and are not allowed to become DR/BDR on broadcast
networks. This is done by forcing the router priority to 0.
For OSPF HA support to work correctly, the firewall needs to have a broadcast interface with at
least ONE neighbor for ALL areas that the firewall is attached to. In essence, the inactive part of the
cluster needs a neighbor to get the link state database from.
It should also be noted that is not possible to put two HA firewalls on the same broadcast network
without any other neighbors (they won't form adjacency with each other because of the router priority 0). However it, based on scenario, may be possible to setup a point to point link between them
instead. Special care must also be taken when setting up a virtual link to an HA firewall. The endpoint setting up a link to the HA firewall must setup 3 separate links: one to the shared, one the master and one to the slave router id of the firewall.
4.4.3. Dynamic Routing Policy
4.4.3.1. Overview
84
Page 98
4.4.3. Dynamic Routing Policy Chapter 4. Routing
In a dynamic routing environment, it is important for routers to be able to regulate to what extent
they will participate in the routing exchange. It is not feasible to accept or trust all received routing
information, and it might be crucial to avoid that parts of the routing database gets published to other routers.
For this reason, NetDefendOS provides a Dynamic Routing Policy, which is used to regulate the
flow of dynamic routing information.
A Dynamic Routing Policy rule filters either statically configured or OSPF learned routes according
to parameters like the origin of the routes, destination, metric and so forth. The matched routes can
be controlled by actions to be either exported to OSPF processes or to be added to one or more routing tables.
The most common usages of Dynamic Routing Policy are:
• Importing OSPF routes from an OSPF process into a routing table.
• Exporting routes from a routing table to an OSPF process.
• Exporting routes from one OSPF process to another.
Note
By default, NetDefendOS will not import or export any routes. In other words, for dynamic routing to be meaningful, it is mandatory to define at least one Dynamic Routing Policy rule.
4.4.3.2. Importing Routes from an OSPF AS into the Main Routing Table
In this example, the routes received using OSPF will be added into the main routing table.
Example 4.6. Importing Routes from an OSPF AS into the Main Routing Table
First of all a Dynamic Routing Policy filter needs to be created. The filter needs to have a name, in this example
ImportOSPFRoutes is used, as it explains what the filter does.
The filter must also specify from what OSPF AS the routes should be imported. In this example, a pre-configured
OSPF AS named as0 is used.
Depending on how your routing topology looks like you might want to just import certain routes using the Destina-
tion Interface/Destination Network filters, but in this scenario all routes that are within the all-nets network (i.e.
0.0.0.0/0) are allowed.
CLI
gw-world:/> add DynamicRoutingRule OSPFProcess=as0 Name=ImportOSPFRoutes
DestinationNetworkExactly=all-nets
Web Interface
1. Go to Routing > Dynamic Routing Rules > Add > Dynamic routing policy rule
2. Specify a suitable name for the filter, in this case ImportOSPFRoutes.
3. In the Select OSPF Process, make as0 selected.
4. Choose all-nets in the ...Exactly Matches dropdown control.
5. Click OK.
The next step is to create a Dynamic Routing Action that will do the actual importing of the routes into a routing ta-
85
Page 99
4.4.3. Dynamic Routing Policy Chapter 4. Routing
ble. Specify the destination routing table that the routes should be added to, in this case main.
CLI
gw-world:/> cc DynamicRoutingRule ImportOSPFRoutes
gw-world:/ImportOSPFRoutes> add DynamicRoutingRuleAddRoute
Web Interface
1. Go to Routing > Dynamic Routing Rules
2. Click on the recently created ImportOSPFRoutes
3. Go to OSPF Routing Action > Add > DynamicRountingRuleAddRoute
4. In the Destination control, add Main Routing Table to the Selected list.
5. Click OK.
Destination=MainRoutingTable
4.4.3.3. Exporting the Default Route into an OSPF AS
In this example, the default route from the main routing table will be exported into an OSPF AS
named as0.
Example 4.7. Exporting the Default Route into an OSPF AS
Add a dynamic routing policy filter that matches the main routing table and the default route:
CLI
gw-world:/> add DynamicRoutingRule OSPFProcess=as0 name=ExportDefRoute
Web Interface
1. Go to Routing > Dynamic Routing Rules > Add > Dynamic routing policy rule
2. Specify a suitable name for the filter, for instance ExportDefRoute.
3. In the From Routing Table, make Main Routing Table selected.
4. Choose wan in the Destination Interface control.
5. Choose all-nets in the ...Exactly Matches dropdown control.
6. Click OK.
Then, create an OSPF Action that will export the filtered route to the specified OSPF AS:
CLI
gw-world:/> cc DynamicRoutingRule ExportDefRoute
gw-world:/ExportDefRoute/> add DynamicRoutingRuleExportOSPF ExportToProcess=as0
Web Interface
RoutingTable=MainRoutingTable DestinationInterface=wan
DestinationNetworkExactly=all-nets
1. Go to Routing > Dynamic Routing Rules
86
Page 100
4.4.3. Dynamic Routing Policy Chapter 4. Routing
2. Click on the recently created ExportDefRoute.
3. Go to OSPF Action > Add > DynamicRoutingRuleExportOSPF.
4. In the Export to process control, choose as0.
5. Click OK.
87
Loading...