Page 1
Security
Security
Network Security Firewall
User Manual
DFL-210/ 800/1600/ 2500
DFL-260/ 860
Ver. 1.07
Network Security Solution http://www.dlink.com
Page 2
User Manual
DFL-210/260/800/860/1600/2500
NetDefendOS version 2.20
D-Link NetDefend Security
http://security.dlink.com.tw
Published 2008-08-05
Copyright © 2008
Page 3
User Manual
DFL-210/260/800/860/1600/2500
NetDefendOS version 2.20
Published 2008-08-05
Copyright © 2008
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 ...............................................................................................................12
1. Product Overview .............................................................................................14
1.1. About D-Link NetDefendOS ....................................................................14
1.2. NetDefendOS Architecture ......................................................................16
1.2.1. State-based Architecture ...............................................................16
1.2.2. NetDefendOS Building Blocks .......................................................16
1.2.3. Basic Packet Flow ........................................................................17
1.3. NetDefendOS State Engine Packet Flow .....................................................19
2. Management and Maintenance ............................................................................23
2.1. Managing NetDefendOS ..........................................................................23
2.1.1. Overview ...................................................................................23
2.1.2. Default Administrator Accounts .....................................................23
2.1.3. The CLI .....................................................................................24
2.1.4. The WebUI .................................................................................26
2.1.5. Working with Configurations .........................................................29
2.2. Events and Logging ................................................................................35
2.2.1. Overview ...................................................................................35
2.2.2. Event Messages ...........................................................................35
2.2.3. Event Message Distribution ...........................................................35
2.3. RADIUS Accounting ..............................................................................39
2.3.1. Overview ...................................................................................39
2.3.2. RADIUS Accounting Messages ......................................................39
2.3.3. Interim Accounting Messages ........................................................41
2.3.4. Activating RADIUS Accounting .....................................................41
2.3.5. RADIUS Accounting Security ........................................................41
2.3.6. RADIUS Accounting and High Availability ......................................41
2.3.7. Handling Unresponsive Servers ......................................................42
2.3.8. Accounting and System Shutdowns .................................................42
2.3.9. Limitations with NAT ...................................................................42
2.4. Monitoring ............................................................................................43
2.4.1. SNMP Monitoring .......................................................................43
2.5. Maintenance ..........................................................................................45
2.5.1. Auto-Update Mechanism ...............................................................45
2.5.2. Configuration Backup and Restore ..................................................45
2.5.3. Resetting to Factory Defaults .........................................................45
3. Fundamentals ...................................................................................................48
3.1. The Address Book ..................................................................................48
3.1.1. Overview ...................................................................................48
3.1.2. IP Addresses ...............................................................................48
3.1.3. Ethernet Addresses .......................................................................50
3.1.4. Address Groups ...........................................................................51
3.1.5. Auto-Generated Address Objects ....................................................51
3.2. Services ................................................................................................52
3.2.1. Overview ...................................................................................52
3.2.2. TCP and UDP Based Services ........................................................53
3.2.3. ICMP Services ............................................................................55
3.2.4. Custom IP Protocol Services ..........................................................55
3.3. Interfaces ..............................................................................................57
3.3.1. Overview ...................................................................................57
3.3.2. Ethernet .....................................................................................58
3.3.3. VLAN .......................................................................................60
3.3.4. PPPoE .......................................................................................61
3.3.5. GRE Tunnels ..............................................................................63
3.3.6. Interface Groups ..........................................................................66
3.4. ARP ....................................................................................................68
3.4.1. Overview ...................................................................................68
3.4.2. ARP in NetDefendOS ...................................................................68
4
Page 5
User Manual
3.4.3. ARP Cache .................................................................................68
3.4.4. Static and Published ARP Entries ....................................................69
3.4.5. Advanced ARP Settings ................................................................71
3.5. The IP Rule Set ......................................................................................73
3.5.1. Security Policies ..........................................................................73
3.5.2. IP Rule Evaluation .......................................................................74
3.5.3. IP Rule Actions ...........................................................................75
3.5.4. Editing IP rule set Entries ..............................................................76
3.6. Schedules .............................................................................................77
3.7. X.509 Certificates ..................................................................................79
3.7.1. Overview ...................................................................................79
3.7.2. X.509 Certificates in NetDefendOS .................................................80
3.8. Setting Date and Time .............................................................................82
3.8.1. General Date and Time Settings ......................................................82
3.8.2. Time Servers ..............................................................................83
3.9. DNS Lookup .........................................................................................87
4. Routing ...........................................................................................................89
4.1. Overview ..............................................................................................89
4.2. Static Routing ........................................................................................90
4.2.1. Basic Principles of Routing ............................................................90
4.2.2. Static Routing .............................................................................91
4.2.3. Route Failover ............................................................................94
4.2.4. Proxy ARP .................................................................................96
4.3. Policy-based Routing ..............................................................................98
4.3.1. Overview ...................................................................................98
4.3.2. Policy-based Routing Tables ..........................................................98
4.3.3. Policy-based Routing Rules ...........................................................98
4.3.4. Policy-based Routing Table Selection ..............................................99
4.3.5. The Ordering parameter ................................................................99
4.4. Dynamic Routing ................................................................................. 103
4.4.1. Dynamic Routing overview ......................................................... 103
4.4.2. OSPF ...................................................................................... 104
4.4.3. Dynamic Routing Policy ............................................................. 107
4.5. Multicast Routing ................................................................................. 110
4.5.1. Overview ................................................................................. 110
4.5.2. Multicast Forwarding using the SAT Multiplex Rule ........................ 110
4.5.3. IGMP Configuration ..................................................................114
4.6. Transparent Mode ................................................................................ 119
4.6.1. Overview of Transparent Mode .................................................... 119
4.6.2. Comparison with Routing mode ................................................... 119
4.6.3. Transparent Mode Implementation ................................................ 119
4.6.4. Enabling Transparent Mode ......................................................... 120
4.6.5. High Availability with Transparent Mode ....................................... 120
4.6.6. Transparent Mode Scenarios ........................................................ 120
5. DHCP Services .............................................................................................. 127
5.1. Overview ............................................................................................127
5.2. DHCP Servers ..................................................................................... 128
5.3. Static DHCP Assignment .......................................................................130
5.4. DHCP Relaying ................................................................................... 131
5.5. IP Pools .............................................................................................. 132
6. Security Mechanisms ....................................................................................... 135
6.1. Access Rules ....................................................................................... 135
6.1.1. Introduction .............................................................................. 135
6.1.2. IP spoofing ............................................................................... 135
6.1.3. Access Rule Settings .................................................................. 136
6.2. Application Layer Gateways ................................................................... 138
6.2.1. Overview ................................................................................. 138
6.2.2. HTTP ......................................................................................139
6.2.3. FTP ......................................................................................... 140
6.2.4. TFTP ....................................................................................... 145
6.2.5. SMTP ...................................................................................... 146
6.2.6. POP3 ....................................................................................... 151
6.2.7. SIP .......................................................................................... 152
5
Page 6
User Manual
6.2.8. H.323 ...................................................................................... 155
6.3. Web Content Filtering ........................................................................... 169
6.3.1. Overview ................................................................................. 169
6.3.2. Active Content Handling .............................................................169
6.3.3. Static Content Filtering ............................................................... 170
6.3.4. Dynamic Web Content Filtering ................................................... 172
6.4. Anti-Virus Scanning .............................................................................183
6.4.1. Overview ................................................................................. 183
6.4.2. Implementation .........................................................................183
6.4.3. Activating Anti-Virus Scanning ....................................................184
6.4.4. The Signature Database ..............................................................184
6.4.5. Subscribing to the D-Link Anti-Virus Service ................................. 184
6.4.6. Anti-Virus Options .....................................................................184
6.5. Intrusion Detection and Prevention .......................................................... 188
6.5.1. Overview ................................................................................. 188
6.5.2. IDP Availability in D-Link Models ............................................... 188
6.5.3. IDP Rules ................................................................................. 190
6.5.4. Insertion/Evasion Attack Prevention .............................................. 191
6.5.5. IDP Pattern Matching ................................................................. 192
6.5.6. IDP Signature Groups ................................................................. 192
6.5.7. IDP Actions .............................................................................. 194
6.5.8. SMTP Log Receiver for IDP Events .............................................. 194
6.6. Denial-Of-Service (DoS) Attacks ............................................................ 198
6.6.1. Overview ................................................................................. 198
6.6.2. DoS Attack Mechanisms ............................................................. 198
6.6.3. Ping of Death and Jolt Attacks ..................................................... 198
6.6.4. Fragmentation overlap attacks: Teardrop, Bonk, Boink and Nestea ...... 199
6.6.5. The Land and LaTierra attacks .....................................................199
6.6.6. The WinNuke attack ................................................................... 199
6.6.7. Amplification attacks: Smurf, Papasmurf, Fraggle ........................... 200
6.6.8. TCP SYN Flood Attacks ............................................................. 201
6.6.9. The Jolt2 Attack ........................................................................ 201
6.6.10. Distributed DoS Attacks ............................................................ 201
6.7. Blacklisting Hosts and Networks ............................................................. 202
7. Address Translation ........................................................................................ 204
7.1. Dynamic Network Address Translation .................................................... 204
7.2. NAT Pools .......................................................................................... 207
7.3. Static Address Translation ..................................................................... 210
7.3.1. Translation of a Single IP Address (1:1) ......................................... 210
7.3.2. Translation of Multiple IP Addresses (M:N) .................................... 213
7.3.3. All-to-One Mappings (N:1) ......................................................... 215
7.3.4. Port Translation ......................................................................... 216
7.3.5. Protocols handled by SAT ...........................................................216
7.3.6. Multiple SAT rule matches .......................................................... 217
7.3.7. SAT and FwdFast Rules .............................................................. 217
8. User Authentication ........................................................................................ 220
8.1. Overview ............................................................................................220
8.2. Authentication Setup ............................................................................. 221
8.2.1. Setup Summary .........................................................................221
8.2.2. The Local Database .................................................................... 221
8.2.3. External Authentication Servers .................................................... 221
8.2.4. Authentication Rules .................................................................. 222
8.2.5. Authentication Processing ........................................................... 223
8.2.6. HTTP Authentication ................................................................. 223
9. VPN ............................................................................................................. 229
9.1. Overview ............................................................................................229
9.1.1. The Need for VPNs .................................................................... 229
9.1.2. VPN Encryption ........................................................................ 229
9.1.3. VPN Planning ........................................................................... 229
9.1.4. Key Distribution ........................................................................ 230
9.2. VPN Quickstart Guide ..........................................................................231
9.2.1. IPsec LAN to LAN with Pre-shared Keys ....................................... 231
9.2.2. IPsec Roaming Clients with Pre-shared Keys ..................................232
6
Page 7
User Manual
9.2.3. IPsec Roaming Clients with Certificates ......................................... 234
9.2.4. L2TP Roaming Clients with Pre-Shared Keys ................................. 234
9.2.5. L2TP Roaming Clients with Certificates ........................................ 236
9.2.6. PPTP Roaming Clients ............................................................... 236
9.2.7. VPN Troubleshooting .................................................................237
9.3. IPsec .................................................................................................. 240
9.3.1. Overview ................................................................................. 240
9.3.2. Internet Key Exchange (IKE) ....................................................... 240
9.3.3. IKE Authentication ....................................................................245
9.3.4. IPsec Protocols (ESP/AH) ...........................................................247
9.3.5. NAT Traversal ..........................................................................248
9.3.6. Proposal Lists ........................................................................... 249
9.3.7. Pre-shared Keys ........................................................................ 250
9.3.8. Identification Lists ..................................................................... 251
9.4. IPsec Tunnels ......................................................................................253
9.4.1. Overview ................................................................................. 253
9.4.2. LAN to LAN Tunnels with Pre-shared Keys ................................... 253
9.4.3. Roaming Clients ........................................................................ 253
9.4.4. Fetching CRLs from an alternate LDAP server ................................ 259
9.5. PPTP/L2TP ......................................................................................... 260
9.5.1. PPTP .......................................................................................260
9.5.2. L2TP .......................................................................................261
10. Traffic Management ...................................................................................... 267
10.1. Traffic Shaping .................................................................................. 267
10.1.1. Introduction ............................................................................267
10.1.2. Traffic Shaping in NetDefendOS ................................................. 268
10.1.3. Simple Bandwidth Limiting ....................................................... 269
10.1.4. Limiting Bandwidth in Both Directions ........................................ 270
10.1.5. Creating Differentiated Limits with Chains ................................... 271
10.1.6. Precedences ............................................................................272
10.1.7. Guarantees .............................................................................. 274
10.1.8. Differentiated Guarantees .......................................................... 274
10.1.9. Groups ................................................................................... 275
10.1.10. Recommendations .................................................................. 276
10.1.11. A Summary of Traffic Shaping .................................................277
10.2. Threshold Rules .................................................................................279
10.2.1. Overview ................................................................................ 279
10.2.2. Connection Rate/Total Connection Limiting ..................................279
10.2.3. Grouping ................................................................................ 279
10.2.4. Rule Actions ........................................................................... 279
10.2.5. Multiple Triggered Actions ........................................................ 280
10.2.6. Exempted Connections .............................................................. 280
10.2.7. Threshold Rules and ZoneDefense .............................................. 280
10.2.8. Threshold Rule Blacklisting .......................................................280
10.3. Server Load Balancing ........................................................................ 281
10.3.1. Overview ................................................................................ 281
10.3.2. Identifying the Servers .............................................................. 282
10.3.3. The Load Distribution Mode ...................................................... 282
10.3.4. The Distribution Algorithm ........................................................282
10.3.5. Server Health Monitoring .......................................................... 284
10.3.6. SLB_SAT Rules ...................................................................... 284
11. High Availability .......................................................................................... 289
11.1. Overview .......................................................................................... 289
11.2. High Availability Mechanisms .............................................................. 291
11.3. High Availability Setup ....................................................................... 293
11.3.1. Hardware Setup ....................................................................... 293
11.3.2. NetDefendOS Setup ................................................................. 294
11.3.3. Verifying Cluster Functioning .................................................... 294
11.4. High Availability Issues .......................................................................296
12. ZoneDefense ................................................................................................ 298
12.1. Overview .......................................................................................... 298
12.2. ZoneDefense Switches ......................................................................... 299
12.3. ZoneDefense Operation ....................................................................... 300
7
Page 8
User Manual
12.3.1. SNMP .................................................................................... 300
12.3.2. Threshold Rules ....................................................................... 300
12.3.3. Manual Blocking and Exclude Lists ............................................. 300
12.3.4. Limitations .............................................................................302
13. Advanced Settings ......................................................................................... 304
13.1. IP Level Settings ................................................................................304
13.2. TCP Level Settings ............................................................................. 307
13.3. ICMP Level Settings ........................................................................... 311
13.4. ARP Settings ..................................................................................... 312
13.5. Stateful Inspection Settings ................................................................... 314
13.6. Connection Timeouts ..........................................................................316
13.7. Size Limits by Protocol ........................................................................ 318
13.8. Fragmentation Settings ........................................................................ 320
13.9. Local Fragment Reassembly Settings ..................................................... 324
13.10. DHCP Settings ................................................................................. 325
13.11. DHCPRelay Settings ......................................................................... 326
13.12. DHCPServer Settings ........................................................................ 327
13.13. IPsec Settings ................................................................................... 328
13.14. Logging Settings ............................................................................... 330
13.15. Time Synchronization Settings ............................................................ 331
13.16. PPP Settings .................................................................................... 333
13.17. Hardware Monitor Settings ................................................................. 334
13.18. Packet Re-assembly Settings ...............................................................335
13.19. Miscellaneous Settings .......................................................................336
A. Subscribing to Security Updates ........................................................................ 338
B. IDP Signature Groups ..................................................................................... 340
C. Checked MIME filetypes ................................................................................. 344
D. The OSI Framework ....................................................................................... 348
E. D-Link worldwide offices ................................................................................ 349
Alphabetical Index ............................................................................................. 351
8
Page 9
List of Figures
1.1. Packet Flow Schematic Part I ...........................................................................19
1.2. Packet Flow Schematic Part II ..........................................................................20
1.3. Packet Flow Schematic Part III .........................................................................20
3.1. An Example GRE Scenario ..............................................................................64
4.1. A Route Failover Scenario for ISP Access ...........................................................94
4.2. Virtual Links Example 1 ................................................................................ 106
4.3. Virtual Links Example 2 ................................................................................ 107
4.4. Multicast Forwarding - No Address Translation .................................................111
4.5. Multicast Forwarding - Address Translation ...................................................... 112
4.6. Multicast Snoop ........................................................................................... 114
4.7. Multicast Proxy ........................................................................................... 115
4.8. Transparent mode scenario 1 .......................................................................... 121
4.9. Transparent mode scenario 2 .......................................................................... 122
6.1. DNSBL SPAM Filtering ................................................................................ 147
6.2. Dynamic Content Filtering Flow ..................................................................... 172
6.3. IDP Database Updating .................................................................................189
9.1. The AH protocol .......................................................................................... 247
9.2. The ESP protocol .........................................................................................247
10.1. Pipe rule set to Pipe Packet Flow ................................................................... 269
10.2. The Eight Pipe Precedences. ......................................................................... 272
10.3. Minimum and Maximum Pipe Precedence. ...................................................... 273
10.4. Traffic grouped per IP address. ......................................................................275
10.5. A Server Load Balancing configuration .......................................................... 281
10.6. Connections from Three Clients ....................................................................283
10.7. Stickiness and Round-Robin ......................................................................... 283
10.8. Stickiness and Connection Rate ..................................................................... 284
11.1. High Availability Setup ............................................................................... 293
D.1. The 7 layers of the OSI model ........................................................................ 348
9
Page 10
List of Examples
1. Example Notation .............................................................................................12
2.1. Enabling SSH Remote Access ..........................................................................25
2.2. Enabling remote management via HTTPS. ..........................................................28
2.3. Listing Configuration Objects ...........................................................................29
2.4. Displaying a Configuration Object .....................................................................30
2.5. Editing a Configuration Object .........................................................................31
2.6. Adding a Configuration Object .........................................................................31
2.7. Deleting a Configuration Object ........................................................................32
2.8. Undeleting a Configuration Object ....................................................................32
2.9. Listing Modified Configuration Objects ..............................................................32
2.10. Activating and Committing a Configuration .......................................................33
2.11. Enable Logging to a Syslog Host .....................................................................36
2.12. Sending SNMP Traps to an SNMP Trap Receiver ...............................................37
2.13. Enabling SNMP Monitoring ...........................................................................44
2.14. Configuration Backup and Restore ...................................................................45
2.15. Complete Hardware Reset to Factory Defaults ...................................................46
3.1. Adding an IP Host ..........................................................................................49
3.2. Adding an IP Network .....................................................................................49
3.3. Adding an IP Range ........................................................................................49
3.4. Deleting an Address Object ..............................................................................50
3.5. Adding an Ethernet Address .............................................................................50
3.6. Listing the Available Services ...........................................................................52
3.7. Viewing a Specific Service ..............................................................................52
3.8. Adding a TCP/UDP Service .............................................................................54
3.9. Adding an IP Protocol Service ..........................................................................56
3.10. Enabling DHCP ...........................................................................................59
3.11. Defining a VLAN .........................................................................................61
3.12. Configuring a PPPoE client on the wan interface with traffic routed over PPPoE. .....62
3.13. Creating an Interface Group ............................................................................66
3.14. Displaying the ARP Cache .............................................................................69
3.15. Flushing the ARP Cache ................................................................................69
3.16. Defining a Static ARP Entry ...........................................................................70
3.17. Setting up a Time-Scheduled Policy .................................................................77
3.18. Uploading an X.509 Certificate .......................................................................80
3.19. Associating X.509 Certificates with IPsec Tunnels ..............................................81
3.20. Setting the Current Date and Time ...................................................................82
3.21. Setting the Time Zone ...................................................................................83
3.22. Enabling DST ..............................................................................................83
3.23. Enabling Time Synchronization using SNTP ......................................................84
3.24. Manually Triggering a Time Synchronization ....................................................84
3.25. Modifying the Maximum Adjustment Value ......................................................85
3.26. Forcing Time Synchronization ........................................................................85
3.27. Enabling the D-Link NTP Server .....................................................................86
3.28. Configuring DNS Servers ...............................................................................87
4.1. Displaying the Routing Table ...........................................................................92
4.2. Displaying the Core Routes ..............................................................................93
4.3. Creating a Policy-Based Routing table .............................................................. 100
4.4. Creating the Route ........................................................................................100
4.5. Policy Based Routing Configuration ................................................................101
4.6. Importing Routes from an OSPF AS into the Main Routing Table .........................108
4.7. Exporting the Default Route into an OSPF AS ................................................... 109
4.8. Forwarding of Multicast Traffic using the SAT Multiplex Rule ............................. 112
4.9. Multicast Forwarding - Address Translation ...................................................... 113
4.10. IGMP - No Address Translation .................................................................... 115
4.11. Configuration if1 ........................................................................................116
4.12. Configuration if2 - Group Translation .............................................................117
4.13. Setting up Transparent Mode - Scenario 1 .......................................................121
4.14. Setting up Transparent Mode - Scenario 2 .......................................................122
10
Page 11
User Manual
5.1. Setting up a DHCP server ..............................................................................128
5.2. Checking the status of a DHCP server ..............................................................129
5.3. Setting up Static DHCP ................................................................................. 130
5.4. Setting up a DHCP relayer ............................................................................. 131
5.5. Creating an IP Pool ....................................................................................... 133
6.1. Setting up an Access Rule .............................................................................. 137
6.2. Protecting an FTP Server with an ALG ............................................................. 141
6.3. Protecting FTP Clients .................................................................................. 144
6.4. Protecting Phones Behind D-Link Firewalls ...................................................... 157
6.5. H.323 with private IP addresses ......................................................................159
6.6. Two Phones Behind Different D-Link Firewalls .................................................160
6.7. Using Private IP Addresses ............................................................................ 161
6.8. H.323 with Gatekeeper .................................................................................. 162
6.9. H.323 with Gatekeeper and two D-Link Firewalls .............................................. 164
6.10. Using the H.323 ALG in a Corporate Environment ...........................................165
6.11. Configuring remote offices for H.323 ............................................................. 167
6.12. Allowing the H.323 Gateway to register with the Gatekeeper .............................. 167
6.13. Stripping ActiveX and Java applets ................................................................ 170
6.14. Setting up a white and blacklist ..................................................................... 171
6.15. Enabling Dynamic Web Content Filtering ....................................................... 173
6.16. Enabling Audit Mode .................................................................................. 174
6.17. Reclassifying a blocked site .......................................................................... 176
6.18. Activating Anti-Virus Scanning ..................................................................... 186
6.19. Configuring an SMTP Log Receiver .............................................................. 194
6.20. Setting up IDP for a Mail Server .................................................................... 195
7.1. Adding a NAT rule ....................................................................................... 205
7.2. Using NAT Pools ......................................................................................... 208
7.3. Enabling Traffic to a Protected Web Server in a DMZ ......................................... 210
7.4. Enabling Traffic to a Web Server on an Internal Network ....................................212
7.5. Translating Traffic to Multiple Protected Web Servers ........................................ 214
8.1. Creating an authentication user group ............................................................... 226
8.2. User Authentication Setup for Web Access. ....................................................... 226
8.3. Configuring a RADIUS server. ....................................................................... 227
9.1. Using a Proposal List .................................................................................... 249
9.2. Using a Pre-Shared key ................................................................................. 250
9.3. Using an Identity List .................................................................................... 251
9.4. Setting up a PSK based VPN tunnel for roaming clients ....................................... 254
9.5. Setting up a Self-signed Certificate based VPN tunnel for roaming clients ............... 255
9.6. Setting up a CA Server issued Certificate based VPN tunnel for roaming clients ....... 256
9.7. Setting Up Config Mode ................................................................................ 258
9.8. Using Config Mode with IPsec Tunnels ............................................................ 258
9.9. Setting up an LDAP server ............................................................................. 259
9.10. Setting up a PPTP server .............................................................................. 260
9.11. Setting up an L2TP server ............................................................................ 261
9.12. Setting up an L2TP Tunnel ...........................................................................262
10.1. Applying a Simple Bandwidth Limit .............................................................. 269
10.2. Limiting Bandwidth in Both Directions ........................................................... 270
10.3. Setting up SLB ........................................................................................... 285
12.1. A simple ZoneDefense scenario .................................................................... 301
11
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 sub-sections. Numbered sub-sections 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 chapter/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.
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
12
Page 13
Highlighted Content Preface
Highlighted Content
Special sections of text which the reader should pay special attention to are indicated by icons on the
left hand side of the page followed by a short paragraph in italicized text. Such sections are of the
following types with the following purposes:
Note
This indicates some piece of information that is an addition to the preceding text. It
may concern something that is being emphasized, 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.
13
Page 14
Chapter 1. Product Overview
This chapter outlines the key features of NetDefendOS.
• About D-Link NetDefendOS, page 14
• NetDefendOS Architecture, page 16
• NetDefendOS State Engine Packet Flow, page 19
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, as well as multicast
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
high-performance scanning and detection of attacks and can
perform blocking and optional black-listing of attacking
14
Page 15
1.1. About D-Link NetDefendOS Chapter 1. Product Overview
hosts. For more information about the IDP capabilities of
NetDefendOS, please see Section 6.5, “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 Scanning”, 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.3, “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, VPN.
With the support of Traffic Shaping, Threshold Rules and
Server Load Balancing features, NetDefendOS is optimal for
traffic management. The Traffic Shaping feature enables
fine-granular 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
Management, 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,
Management 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.
15
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 eliminates any possibility to detect and analyze
complex protocols and enforce corresponding security policies.
Stateful Inspection
NetDefendOS employs a technique called stateful inspection which means that it inspects and
forwards traffic on a per-connection basis. NetDefendOS detects when a new connection is being
established, and keeps a small piece of information or state in it's state table for the lifetime of that
connection. By doing this, NetDefendOS is able to understand the context of the network traffic,
which enables it to perform in-depth traffic scanning, apply bandwidth management and much
more.
The stateful inspection approach additionally provides high throughput performance with the added
advantage of a design that is highly scalable. The NetDefendOS subsystem that implements stateful
inspection will sometimes be referred to in documentation as the NetDefendOS state-engine.
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
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.
Interface Symmetry
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
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 are the Application Layer Gateway (ALG) objects which are used to define additional
parameters on specific protocols such as HTTP, FTP, SMTP and H.323.
NetDefendOS Rule Sets
Finally, rules which are defined by the administrator in the various rule sets are used for actually
implementing NetDefendOS security policies. The most fundamental set of rules are the IP Rules,
which are 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
IDP Rules control the behavior of the intrusion prevention engine and so on.
16
Page 17
1.2.3. Basic Packet Flow Chapter 1. Product Overview
1.2.3. Basic Packet Flow
This section outlines the basic flow in the state-engine for packets received and forwarded by
NetDefendOS. Please note that this description is simplified 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.
• 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 on. 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 and IP protocol.
If a match cannot be found, a connection establishment process starts which includes steps
from here to 9 below. If a match is found, the forwarding process continues at step 10 below.
5. 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.
6. A route lookup is being made using the appropriate routing table. The destination interface for
the connection has now been determined.
7. The IP rules are now searched for a rule that matches the packet. The following parameters are
part of the matching process:
• Source and destination interfaces
• Source and destination network
• IP protocol (for example TCP, UDP, ICMP)
• TCP/UDP ports
• ICMP types
• Point in time in reference to a pre-defined schedule
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
17
Page 18
1.2.3. Basic Packet Flow Chapter 1. Product Overview
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.
8. 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 connection.
9. 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.
10. 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 on, to further
analyze or transform the traffic.
• If the contents of the packet is encapsulated (such as with IPsec, L2TP/PPTP or some other
type of tunneled protocol), then 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.
11. 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 or encapsulation might occur.
The following section provides a set of diagrams which illustrate the flow of packets through
NetDefendOS.
18
Page 19
1.3. NetDefendOS State Engine Packet Flow
Chapter 1. Product Overview
1.3. NetDefendOS State Engine 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.
19
Page 20
1.3. NetDefendOS State Engine Packet
Flow
Figure 1.2. Packet Flow Schematic Part II
Chapter 1. Product Overview
The packet flow is continued on the following page.
Figure 1.3. Packet Flow Schematic Part III
20
Page 21
1.3. NetDefendOS State Engine Packet
Flow
Chapter 1. Product Overview
21
Page 22
1.3. NetDefendOS State Engine Packet
Flow
Chapter 1. Product Overview
22
Page 23
Chapter 2. Management and Maintenance
This chapter describes the management, operations and maintenance related aspects of
NetDefendOS.
• Managing NetDefendOS, page 23
• Events and Logging, page 35
• RADIUS Accounting, page 39
• Monitoring, page 43
• Maintenance, page 45
2.1. Managing 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.
Management Interfaces
NetDefendOS provides the following management interfaces:
The WebUI
The CLI
The Web User Interface (WebUI) provides a user-friendly and intuitive graphical
management interface, accessible from a standard web browser.
The Command Line Interface (CLI), accessible locally via serial console port or
remotely using the Secure Shell (SSH) protocol, provides the most fine-grain
control over all parameters in NetDefendOS.
Note
Microsoft Internet Explorer (version 6 and later), Firefox and Netscape (version 8 and
later) are the recommended web-browsers to use with the WebUI. Other browsers may
also provide full support.
Access to remote management interfaces can be regulated by a remote management policy so the
administrator can restrict management access based on source network, source interface and
credentials. Access to the web interface can be permitted for 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 Administrator Accounts
23
Page 24
2.1.3. The CLI Chapter 2. Management and Maintenance
By default, NetDefendOS has a local user database, AdminUsers, with one user account pre-defined:
• Username admin with password admin.
This account has full administrative read/write privileges.
Important
For security reasons, it is recommended to change the default password of the default
account as soon as possible after connecting with the D-Link Firewall.
Creating New Accounts
Extra user accounts can be created if required. Accounts can either can belong to the
Administrators group of users in which case they have complete read/write administrative access,
or they can belong to the Auditors user group in which case they have read-only access.
2.1.3. The 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.
This section only provides a summary only of using the CLI. For a complete reference for all CLI
commands see the separate D-Link CLI Reference Guide.
Serial Console CLI Access
The serial console port is a RS-232 port on the D-Link Firewall that allows access to the CLI
through a serial connection to a PC or terminal. To locate the serial console port on your D-Link
system, see the D-Link Quickstart Guide .
To use the console port, you need the following equipment:
• A terminal or a computer with a serial port and the ability to emulate a terminal (such as using
the Hyper Terminal software included in some Microsoft Windows editions). 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.
24
Page 25
2.1.3. The CLI Chapter 2. Management and Maintenance
SSH (Secure Shell) CLI Access
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. Many SSH clients are feely available for almost all
hardware platforms.
NetDefendOS supports version 1, 1.5 and 2 of the SSH protocol and SSH access is regulated by the
remote management policy in NetDefendOS, and is disabled by default.
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, eg. ssh_policy
3. Select the following from the dropdown lists:
• User Database: AdminUsers
• Interface: lan
• Network: lannet
4. Click OK
LocalUserDatabase=AdminUsers
Logging on to the CLI
When access to the CLI has been established to NetDefendOS through the serial console or an SSH
client, the administrator will 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 auditing.
When accessing the CLI, the system will respond with a login prompt. Enter your username and
press Enter, followed by your password and then Enter again. 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 advisable to disable or anonymize the CLI welcome message.
Changing the CLI Prompt
The default CLI prompt is
Device:/>
where Device is the model number of the D-Link Firewall. This can be customized, for example, to
gw-world:/>, by using the CLI command:
25
Page 26
2.1.4. The WebUI Chapter 2. Management and Maintenance
Device:/> set device name="gw-world"
The CLI Reference Guide uses the command prompt gw-world:/> throughout.
Note
When the command line prompt is changed to a new string value, this string also
appears as the new device name in the top level node of the WebUI tree-view.
Activate and Committing Changes
If any changes are made to the current configuration through the CLI, those changes won't be
uploaded to NetDefendOS until the command
gw-world:/> activate
is issued. Immediately following the activate command, the command:
gw-world:/> commit
should be issued to make those changes permanent. If a commit command is not issued within a
default time period of 30 seconds then the changes are automatically undone and the old
configuration restored.
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.
2.1.4. The WebUI
NetDefendOS provides a highly versatile web user interface (WebUI) for management of the
system using a standard web browser. This allows the administrator to perform remote management
from virtually anywhere in the world without having to install any third-party clients.
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.
When performing this initial connection to NetDefendOS, the administrator MUST use https:// as
the URL protocol in the browser (for example: https://192.168.1.1). Using HTTPS as the protocol
protects the username and password with encryption when they are sent to NetDefendOS.
If communication with the NetDefendOS is successfully established, a user authentication dialog
similar to the one shown below will then be shown in the browser window.
26
Page 27
2.1.4. The WebUI Chapter 2. Management and Maintenance
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.
Multi-language Support
The WebUI login dialog offers the option to select a language other than english for the interface.
Language support is provided by a separate set of resource files provided with NetDefendOS.
It may occasionally be the case that a NetDefendOS upgrade might contain features that temporarily
lack a complete non-english translation because of time constraints. In this case the original english
will be used as a temporary solution.
The Web Browser Interface
On the left hand side of the WebUI is a tree which allows navigation to the various NetDefendOS
modules. The central area of the WebUI displays information about those modules. Current
performance information is shown by default.
For information about the default user name and password, please see Section 2.1.2, “Default
Administrator Accounts”.
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.
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.
27
Page 28
2.1.4. The WebUI Chapter 2. Management and Maintenance
• 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
during 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
diagnostics.
• 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
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.
Main Window
The main window contains configuration or status details corresponding to the
section selected in the navigator or the menu bar.
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.
CLI
gw-world:/> add RemoteManagement RemoteMgmtHTTP https
Network=all-nets Interface=any LocalUserDatabase=AdminUsers HTTPS=Yes
Web Interface
1. Go to System > Remote Management > Add > HTTP/HTTPS Management
2. Enter a Name for the HTTP/HTTPS remote management policy, eg. https
3. Check the HTTPS checkbox
4. Select the following from the dropdown lists:
28
Page 29
2.1.5. Working with Configurations Chapter 2. Management and Maintenance
• User Database: AdminUsers
• Interface: any
• Network: all-nets
5. Click OK
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.
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.
Tip
If there is a problem with the management interface when communicating alongside
VPN tunnels, check the main routing table and look for an all-nets route to the VPN
tunnel. If no specific route exists to the management interface then all management
traffic coming from NetDefendOS will automatically be routed to the VPN tunnel. If
this is the case then a route should be added by the administrator to route management
traffic destined for the management network to the correct interface.
2.1.5. Working with Configurations
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 on. 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.
The following examples show how to manipulate objects.
Example 2.3. Listing Configuration Objects
To find out what configuration objects exist, you can retrieve a listing of the objects. This example shows how to
list all service objects.
CLI
29
Page 30
2.1.5. Working with Configurations Chapter 2. Management and Maintenance
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.
Example 2.4. 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. 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
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
30
Page 31
2.1.5. Working with Configurations Chapter 2. Management and Maintenance
Example 2.5. 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. 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
Property Value
Name: telnet
SourcePorts: 0-65535
MaxSessions: 1000
Type: TCP
SYNRelay: No
ALG: (none)
Comments: Modified Comment
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.
Important
Changes to a configuration object will not be applied to a running system until you
activate and commit the changes.
Example 2.6. Adding a Configuration Object
This example shows how to add a new IP4Address object, here creating the IP address 192.168.10.10, to the
Address 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
Property Value
Name: myhost
Address: 192.168.10.10
Comments: (none)
31
Page 32
2.1.5. Working with Configurations Chapter 2. Management and Maintenance
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
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.
Example 2.8. Undeleting a Configuration Object
A deleted object can always be restored until the configuration has been activated and committed. This example
shows how to restore the deleted IP4Address object shown in the previous example.
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.
32
Page 33
2.1.5. Working with Configurations Chapter 2. Management and Maintenance
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
After 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 administrator 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. As described
previously, if the configuration was activated via the CLI with the activate command then a commit
command must be issued within that period. If a lost connection could not be re-established or if the
commit command was not issued, then NetDefendOS will revert to using the previous configuration.
This is a fail-safe mechanism and, amongst others things, can help prevent a remote administrator
from locking themselves out.
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.
33
Page 34
2.1.5. Working with Configurations Chapter 2. Management and Maintenance
Note
The configuration must be committed before changes are saved. All changes to a
configuration can be ignored simply by not committing a changed configuration.
34
Page 35
2.2. Events and Logging Chapter 2. Management and Maintenance
2.2. Events and Logging
2.2.1. Overview
The ability to log and analyze system activities is an essential feature of NetDefendOS. Logging
enables not only monitoring of system status and health, but also allows auditing of network usage
and assists in trouble-shooting.
NetDefendOS defines a number of event messages, which are generated as a result of corresponding
system events. Examples of such events are the establishment and teardown of connections, receipt
of malformed packets as well as the dropping of traffic according to filtering policies.
Whenever an event message is generated, it can be filtered and distributed to all configured Event
Receivers. Multiple event receivers can be configured by the administrator, 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 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 format, with attributes that include category, severity,
recommended actions. These attributes enable easy filtering of messages, either within
NetDefendOS prior to sending to an event receiver, or as part of the analysis after logging and
storing messages on an external log server.
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. The severity of each event is
predefined and, in order of severity, can be one of:
Emergency
Alert
Critical
Error
Warning
Notice
Info
Debug
By default all messages of level Info and above are sent. The Debug category of designed for
troubleshooting only and should only be turned on if required to try and solve a problem. Messages
of all severity levels are found listed in the NetDefendOS Log Reference Guide.
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 in the following ways:
35
Page 36
2.2.3. Event Message Distribution Chapter 2. Management and Maintenance
Memlog
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.
Syslog
The de-facto standard for logging events from network devices. If other network devices
are already logging to Syslog servers, using syslog with NetDefendOS messages can
simplify overall administration.
2.2.3.1. Logging to Syslog Hosts
Syslog is a standardized protocol for sending log data although there is no standardized format for
the log messages themselves. The format used by NetDefendOS is well suited to automated
processing, filtering and searching.
Although the exact format of each log entry depends on how a Syslog receiver works, most are very
much alike. The way in which logs are read is also dependent on how the syslog receiver 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 information as the Severity field
for D-Link 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, eg. my_syslog
3. Enter 195.11.22.55 as the IP Address
4. Select an appropriate facility from the Facility 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.
36
Page 37
2.2.3. Event Message Distribution Chapter 2. Management and Maintenance
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.
2.2.3.2. SNMP Traps
The SNMP protocol
Simple Network Management Protocol (SNMP) is a means for communicating between a Network
Management System (NMS) and a managed device. SNMP defines 3 types of messages: a Read
command for an NMS to examine a managed device, a Write command to alter the state of a
managed device and a Trap which is used by managed devices to send messages asynchronously to
an NMS about a change of state.
SNMP Traps in NetDefendOS
NetDefendOS takes the concept of an SNMP Trap one step further by allowing any event message
to be sent as an SNMP trap. This means that the administrator can set up SNMP Trap notification of
events that you consider significant for the operation of a network.
The file DFLNNN-TRAP.MIB (where NNN indicates the model number of the firewall) is provided
by D-Link and defines the SNMP objects and datatypes that are used to describe an SNMP Trap
received from NetDefendOS.
Note
There is a different MIB file for each model of D-Link Firewall. Make sure that the
correct file is used.
For each D-Link Firewall model there is one generic trap object called DLNNNosGenericTrap, that
is used for all traps (where NNN indicates the model number). This object includes the following
parameters:
• System - The system generating the trap
• Severity - Severity of the message
• Category - What NetDefendOS subsystem is reporting the problem
• ID - Unique identification within the category
• Description - A short textual description
• Action - What action is NetDefendOS taking
This information can be cross-referenced to the Log Reference Guide.
Note
NetDefendOS sends SNMP Traps which are based on the SNMPv2c standard as
defined by RFC1901, RFC1905 and RFC1906.
Example 2.12. Sending SNMP Traps to an SNMP Trap Receiver
To enable generation of SNMP traps for all events with a severity greater than or equal to Alert to an SNMP trap
receiver with an IP address of 195.11.22.55, follow the steps outlined below:
37
Page 38
2.2.3. Event Message Distribution Chapter 2. Management and Maintenance
CLI
gw-world:/> add LogReceiver EventReceiverSNMP2c my_snmp IPAddress=195.11.22.55
Web Interface
1. Goto Log & Event Receivers > Add > EventReceiverSNMP2c
2. Specify a name for the event receiver, eg. my_snmp
3. Enter 195.11.22.55 as the IP Address
4. Enter an SNMP Community String if needed by the trap receiver)
5. Click OK
The system will now be sending SNMP traps for all events with a severity greater than or equal to Alert to an
SNMP trap receiver at 195.11.22.55.
38
Page 39
2.3. RADIUS Accounting Chapter 2. Management 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 Setup”).
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.
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
was authenticated via RADIUS, or LOCAL if the user was authenticated via a local user
39
Page 40
2.3.3. Interim Accounting Messages Chapter 2. Management and Maintenance
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 signaling 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 Output Bytes has wrapped, and if the Output Bytes attribute is sent.
Note
The (*) symbol in the above list indicates that the sending of the parameter is user
configurable.
40
Page 41
2.3.4. Activating RADIUS Accounting Chapter 2. Management and Maintenance
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
specified.
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
server 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
Authenticator 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
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:
41
Page 42
2.3.7. Handling Unresponsive Servers Chapter 2. Management and Maintenance
• 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 problem with accounting information synchronization could occur if an active unit has an
authenticated user for whom the associated connection times out before it is synchronized on 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. NetDefendOS 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
NetDefendOS is trying to contact to the accounting server.
Only after NetDefendOS has made three attempts to reach the server will it conclude that the
accounting server is unreachable. The administrator can use the NetDefendOS advanced setting
AllowAuthIfNoAccountingResponse 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,
the accounting server will never be able to update its user statistics, but will most likely believe that
the session is still active. 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
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 using NAT to allow
network access through a single external IP address. This means that as soon as one user is
authenticated, traffic coming through that NAT gateway IP address could be assumed to be coming
from that one authenticated user even though it may come from other users on the same network.
NetDefendOS RADIUS Accounting will therefore gather statistics for all the users on the network
together as though they were one user instead of individuals.
42
Page 43
2.4. Monitoring Chapter 2. Management and Maintenance
2.4. Monitoring
2.4.1. SNMP Monitoring
Overview
Simple Network Management Protocol (SNMP) is a standardized protocol for management of
network devices. An SNMP compliant client can connect to a network device which supports the
SNMP protocol to query and control it.
NetDefendOS supports SNMP version 1 and version 2. Connection can be made by any SNMP
compliant clients to devices running NetDefendOS. however only query operations are permitted for
security reasons. Specifically, NetDefendOS supports the following SNMP request operations by a
client:
• The GET REQUEST operation
• The GET NEXT REQUEST operation
• The GET BULK REQUEST operation (SNMP Version 2c only)
The NetDefendOS MIB
The Management Information Base (MIB) is a database, usually in the form of a file, which defines
the parameters on a network device that an SNMP client can query or change. The MIB file for a
device running NetDefendOS is distributed with the standard NetDefendOS distribution pack as a
file with the name DFLNNN-TRAP.MIB (where NNN indicates the model number of the firewall)
and this should be transferred to the hard disk of the workstation that will run the SNMP client so it
can be imported by the client software. When the client runs, the MIB file is accessed to inform the
client of the values that can be queried on a NetDefendOS device.
Defining SNMP Access
SNMP access is defined through the definition of a NetDefendOS Remote object with a Mode of
SNMP. The Remote object requires the entry of:
• Interface - The NetDefendOS interface on which SNMP requests will arrive.
• Network - The IP address or network from which SNMP requests will come.
• Community - The community string which provides password security for the accesses.
The Community String
Security for SNMP Versions 1 and 2c is handled by the Community String which is the same as a
password for SNMP access. The Community String should be difficult to guess and therefore be
constructed in the same way that any other password, using combinations of upper and lower case
letters with digits.
Enabling an IP Rule for SNMP
The advanced setting SNMPBeforeRules in the RemoteAdmin section controls if the IP rule set
checks all accesses by SNMP clients. This is by default disabled and the recommendation is to
always enable this setting.
The effect of enabling this setting is to add an invisible Allow rule at the top of the IP rule set which
automatically permits accesses on port 161 from the network and on the interface specified for
43
Page 44
2.4.1. SNMP Monitoring Chapter 2. Management and Maintenance
SNMP access. Port 161 is usually used for SNMP and NetDefendOS always expects SNMP traffic
on that port.
Remote Access Encryption
It should be noted that SNMP Version 1 or 2c access means that the community string will be sent
as plain text over a network. This is clearly insecure if a remote client is communicating over the
public Internet. It is therefore advisable to have remote access take place over an encrypted VPN
tunnel or similarly secure means of communication.
Preventing SNMP Overload
The advanced setting SNMPReqLimit restricts the number of SNMP requests allowed per second.
This can help prevent attacks through SNMP overload.
Example 2.13. Enabling SNMP Monitoring
This example enables SNMP access through the internal lan interface from the network mgmt-net using the
community string Mg1RQqR. (Since the management client is on the internal network we don't need to implement
a VPN tunnel for it.)
CLI
gw-world:/> add RemoteManagement RemoteMgmtSNMP my_snmp Interface=lan
Should it be necessary to enable SNMPBeforeRules (which is enabled by default) then the command is:
gw-world:/> set Settings RemoteMgmtSettings SNMPBeforeRules=Yes
Web Interface
1. Goto System > Remote Management > Add > SNMP management
2. For Remote access type enter:
• Name: a suitable name
• Community: Mg1RQqR
3. For Access Filter enter:
• Interface: lan
• Network: mgmt-net
4. Click OK
Should it be necessary to enable SNMPBeforeRules (which is enabled by default) then the setting can be found
in System > Remote Management > Advanced Settings.
Network=mgmt-net SNMPGetCommunity=Mg1RQqR
44
Page 45
2.5. Maintenance Chapter 2. Management and Maintenance
2.5. Maintenance
2.5.1. 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.5, “Intrusion Detection and Prevention”
• Section 6.4, “Anti-Virus Scanning”
• Section 6.3, “Web Content Filtering”
• Appendix A, Subscribing to Security Updates
2.5.2. Configuration Backup and Restore
The NetDefendOS configuration of a D-Link Firewall 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.14. Configuration Backup and Restore
Web Interface
To create a backup of the currently running configuration:
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.5.3. Resetting to Factory Defaults
A restore to factory defaults can be applied so that it is possible to return to the original hardware
state that existed when the D-Link Firewall was shipped by D-Link. When a restore is applied all
data such as the IDP and Ant-Virus databases are lost and must be reloaded.
45
Page 46
2.5.3. Resetting to Factory Defaults Chapter 2. Management and Maintenance
Example 2.15. Complete Hardware Reset to Factory Defaults
CLI
gw-world:/> reset -unit
Web Interface
1. Go to Maintenance > Reset
2. Select Restore the entire unit to factory defaults then confirm and wait for the restore 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, that is to say 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
D-Link Firewall can cease to function properly.
46
Page 47
2.5.3. Resetting to Factory Defaults Chapter 2. Management and Maintenance
47
Page 48
Chapter 3. Fundamentals
This chapter describes the fundamental logical objects upon which NetDefendOS is built. These
objects include such things as addresses, services and schedules. In addition, the chapter explains
how the various supported interfaces work, it outlines how secuirty policies are constructed and how
basic system settings are configured.
• The Address Book, page 48
• Services, page 52
• Interfaces, page 57
• ARP, page 68
• The IP Rule Set, page 73
• Schedules, page 77
• X.509 Certificates, page 79
• Setting Date and Time, page 82
• DNS Lookup, page 87
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 or a range of IP addresses.
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 on. The numbers 0-32 correspond to the number of binary ones in the
netmask.
48
Page 49
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 for the IP Address
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 as the IP Address
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
49
Page 50
3.1.3. Ethernet Addresses Chapter 3. Fundamentals
Web Interface
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 as the IP Address
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, eg. wwwsrv1_mac
3. Enter 08-a3-67-bc-2e-f2 as the MAC Address
4. Click OK
50
Page 51
3.1.4. Address Groups Chapter 3. Fundamentals
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 and so on. 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
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
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 acquired 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 (In other words, the IP
address is 0.0.0.0).
all-nets
The all-nets IP address object is initialized to the IP address
0.0.0.0/0, thus representing all possible IP addresses. This object is
used extensively throughout the configuration.
51
Page 52
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.
However, 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 passive objects in that they cannot carry out any action in the system on their own.
Instead, Service objects are used frequently in the various security policies defined by rule sets. 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 D-Link Firewall. For more information on how service objects are being
used wit IP rules, see Section 3.5, “The IP Rule Set”.
A large number of Service objects come pre-defined with NetDefendOS. These include common
services such as HTTP, FTP, Telnet and SSH. Pre-defined Services can be used and also modified
just like user-defined Services. However, it is recommended NOT to make any changes to
pre-defined 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
52
Page 53
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 on. For these types of Service, 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.
53
Page 54
3.2.2. TCP and UDP Based Services Chapter 3. Fundamentals
Tip
The above methods of specifying port numbers are used not just for destination ports.
Source port definitions can follow the same conventions, although it is most usual that
the source ports are left as the default value which is 0-65535 and this corresponds to
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, eg. 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
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”.
Passing ICMP Errors
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.
Application Layer Gateway
A TCP/UDP Service can be linked to an Application Layer
Gateway to enable deeper inspection of certain protocols. For
more information see Section 6.2, “Application Layer
Gateways”.
Max Sessions
An important parameter associated with a Service is Max Sessions. This parameter is allocated a
default value when the Service is associated with an ALG. The default value varies according to the
ALG it is associated with. If the default is, for example 100, this would mean that only 100
connections are allowed in total for this Service across all interfaces.
For a Service involving, for instance an HTTP ALG, the default value can often be too low if there
are large numbers of clients connecting through the D-Link Firewall. It is therefore recommended to
consider if a higher value is required for a particular scenario.
Using All Services
54
Page 55
3.2.3. ICMP Services Chapter 3. Fundamentals
When setting up rules that filter by services it is possible to use the service grouping all_services to
refer to all protocols. If just referring to the main protocols of TCP, UDP and ICMP then the service
group all_tcpudpicmp can be used.
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.
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
packet. 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 using the concept of Custom IP Protocol
Services. A Custom IP Protocol service is a service definition giving a name to an IP protocol
55
Page 56
3.2.4. Custom IP Protocol Services Chapter 3. Fundamentals
number. Some of the common IP protocols, such as IGMP, are already pre-defined in the
NetDefendOS 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
Example 3.9. Adding an 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, eg. VRRP
3. Enter 112 in the IP Protocol control
4. Optionally enter Virtual Router Redundancy Protocol in the Comments control
5. Click OK
56
Page 57
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,
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
sub-interfaces:
• 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, “VLAN”.
• 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.3, “IPsec”.
• PPTP/L2TP interfaces are used as end-points for PPTP or
57
Page 58
3.3.2. Ethernet Chapter 3. Fundamentals
L2TP tunnels. For more information about PPTP/L2TP,
please see Section 9.5, “PPTP/L2TP”.
• GRE interfaces are used to establish GRE tunnels. For more
information about GRE, please see Section 3.3.5, “GRE
Tunnels”.
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.
Warning
If an interface definition is removed from a NetDefendOS configuration, it is important
to first remove or change any references to that interface. For instance rules in the IP
rule set that refer to that interface should be removed or changed.
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.
Ethernet Interface Names
58
Page 59
3.3.2. Ethernet Chapter 3. Fundamentals
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 interface named wan and so on.
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.
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.
Ethernet 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. (For more information, see 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, in other words those 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.
The Default Gateway
A Default Gateway address can optionally 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 all-nets) over the actual interface using the specified gateway. For natural reasons, only one
Ethernet interface at a time can be assigned a default gateway.
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
59
Page 60
3.3.3. VLAN Chapter 3. Fundamentals
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
3. Enable the Enable DHCP client option
4. Click OK
3.3.3. VLAN
Overview
Virtual LANs (VLANs) are useful in several different scenarios, for instance, when filtering of
traffic is needed between different VLANs in an organization, or for any other reason where the
administrator would like to expand the number of interfaces.
Virtual LAN support in NetDefendOS allows the definition of one or more Virtual LAN interfaces
to be associated with a particular physical interface. These are then considered to be logical
interfaces by NetDefendOS and can be treated like physical interfaces in rule sets and routing tables.
VLAN Operation
NetDefendOS follows the IEEE 802.1Q specification for VLAN. On a protocol level, VLAN works
by adding a Virtual LAN Identifier (VLAN ID) to Ethernet frame headers. The VLAN ID is a
number from 0 up to 4095 which is used to identify the specific Virtual LAN to which the frame
belongs. In this way, Ethernet frames can belong to different Virtual LANs, but can still share the
same physical interface. With NetDefendOS, the VLAN ID must be unique for the physical
interface and the same VLAN ID can be used on different physical interfaces.
Packets received through Ethernet frames on a physical interface by NetDefendOS, are examined
for a VLAN ID. If a VLAN ID is found and a matching VLAN interface has been defined for that
interface, NetDefendOS will use the VLAN interface as the source interface in further processing
with rule sets.
If there is no VLAN ID attached to an Ethernet frame received on the physical interface then the
frame is treated as being received on the physical interace and not on any VLAN interface that may
be defined.
License Limitations
The number of VLAN interfaces that can be defined for a NetDefendOS installation is limited by
the parameters of the license used. Different hardware models have different licenses and different
limits on VLANs.
Summary of VLAN Setup
It's important to understand that the administrator should treat a VLAN interface just like a physical
interface in that they require at least IP rules and routes to be defined in order to function. If, for
instance, no Allow rule is defined in the IP rule set for a VLAN interface then packets arriving on
that interface will be dropped. Below are the key steps for setting up a VLAN interface.
1. Assign a name to the VLAN interface.
2. Select the physical interface for the VLAN.
60
Page 61
3.3.4. PPPoE Chapter 3. Fundamentals
3. Assign a VLAN ID that is unique on the physical interface.
4. Optionally specify an IP address for the VLAN.
5. Optionally specify an IP broadcast address for the VLAN.
6. Create the required route(s) for the VLAN in the appropriate routing table.
7. Create rules in the IP rule set to allow traffic through on the VLAN interface.
Example 3.11. Defining a VLAN
This simple example defines a virtual LAN called VLAN10 with 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. Enter a suitable name for the VLAN, in this case VLAN10
3. Now enter:
• Interface: lan
• VLAN ID: 10
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
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
61
Page 62
3.3.4. PPPoE Chapter 3. Fundamentals
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
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
Network=all-nets Username=exampleuser Password=examplepw
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)
62
Page 63
3.3.5. GRE Tunnels Chapter 3. Fundamentals
• 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
• Under Authentication specify which authentication protocol to use
(the default settings will be used if not specified)
• Disable the option Enable dial-on-demand
• Under Advanced, if Add route for remote network is enabled then a new route will be added for the
interface
3. Click OK
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. GRE Tunnels
Overview
The Generic Router Encapsulation (GRE) protocol is a simple, encapsulating protocol that can be
used whenever there is a need to tunnel traffic across networks and/or through network devices.
GRE does not provide any security features but this means that its use has extremely low overhead.
Using GRE
GRE is typically used to provide a method of connecting two networks together across a third
network such as the Internet. The two networks being connected together communicate with a
common protocol which is tunneled using GRE through the intervening network. Examples of GRE
usage are:
• Traversing network equipment that blocks a particular protocol.
• Tunneling IPv6 traffic across an IPv4 network.
• Where a UDP data stream is to be multicast and it is necessary to transit through a network
device which does not support multicasting. GRE allows tunneling though the network device.
GRE Security and Performance
A GRE tunnel does not use any encryption for the communication and is therefore not, in itself,
secure. Any security must come from the protocol being tunneled. The advantage of GRE's lack of
encryption is the high performance which is achievable because of the low traffic processing
overhead. The lack of encryption can be acceptable in some circumstances if the tunneling is done
across an internal network that is not public.
Setting Up GRE
Like other tunnels in NetDefendOS such as an IPsec tunnel, a GRE Tunnel is treated as a logical
interface by NetDefendOS, with the same filtering, traffic shaping and configuration capabilities as
a standard interface. The GRE options are:
63
Page 64
3.3.5. GRE Tunnels Chapter 3. Fundamentals
• IP Address - This is the IP address of the sending interface. This is optional and can be left
blank. If it is left blank then the sending IP address will default to the local host address of
127.0.0.1.
• Remote Network - The remote network which the GRE tunnel will connect with.
• Remote Endpoint - This is the IP address of the remote device which the tunnel will connect
with.
• Use Session Key - A unique number can optionally specified for this tunnel. This allows more
than one GRE tunnel to run between the same two endpoints. The Session Key value is used to
distinguish between them.
• Additional Encapsulation Checksum - The GRE protocol allows for an additional checksum
over and above the IPv4 checksum. This provides an extra check of data integrity.
The Advanced settings for a GRE interface are:
• Automatically add route for remote network - This option would normally be checked in
order that the routing table is automatically updated. The alternative is to manually create the
required route.
• Address to use as source IP - It is possible to specify a particular IP address as the source
interface IP for the tunnel.
GRE and the IP Rule Set
An established GRE tunnel does not automatically mean that all traffic coming from or to that GRE
tunnel is trusted. On the contrary, network traffic coming from the GRE tunnel will be transferred to
the NetDefendOS IP rule set for evaluation. The source interface of the network traffic will be the
name of the associated GRE Tunnel. The same is true for traffic in the opposite direction, that is,
going into a GRE tunnel. Furthermore a Route has to be defined so NetDefendOS knows what IP
addresses should be accepted and sent through the tunnel.
An Example GRE Scenario
The diagram below illustrates a typical GRE scenario, where two D-Link Firewalls A and B must
communicate with each other through the intervening internal network 172.16.0.0/16.
Any traffic passing between A and B is tunneled through the intervening network using a GRE
tunnel and since the network is internal and not public there is no need for encryption.
Figure 3.1. An Example GRE Scenario
64
Page 65
3.3.5. GRE Tunnels Chapter 3. Fundamentals
Setup for D-Link Firewall "A"
Assuming that the network 192.168.10.0/24 is lannet on the lan interface, the steps for setting up
NetDefendOS on A are:
1. In the address book set up the following IP objects:
• remote_net_B: 192.168.11.0/24
• remote_gw: 172.16.1.1
• ip_GRE: 192.168.0.1
2. Create a GRE Tunnel object called GRE_to_B with the following parameters:
• IP Address: ip_GRE
• Remote Network: remote_net_B
• Remote Endpoint: remote_gw
• Use Session Key: 1
• Additional Encapulation Checksum: Enabled
3. Define a route in the main routing table which routes all traffic to remote_net_B on the
GRE_to_B GRE interface. This is not necessary if the option Add route for remote network
is enabled in the Advanced tab, since this will add the route automatically.
4. Create the following rules in the IP rule set that allow traffic to pass through the tunnel:
Name Action Src Interface Src Network Dest Interface Dest Network Service
To_B Allow lan lannet GRE_to_B remote_net_B All
From_B Allow GRE_to_B remote_net_B lan lannet All
Setup for D-Link Firewall "B"
Assuming that the network 192.168.11.0/24 is lannet on the lan interface, the steps for setting up
NetDefendOS on B are as follows:
65
Page 66
3.3.6. Interface Groups Chapter 3. Fundamentals
1. In the address book set up the following IP objects:
• remote_net_A: 192.168.10.0/24
• remote_gw: 172.16.0.1
• ip_GRE: 192.168.0.2
2. Create a GRE Tunnel object called GRE_to_A with the following parameters:
• IP Address: ip_GRE
• Remote Network: remote_net_A
• Remote Endpoint: remote_gw
• Use Session Key: 1
• Additional Encapulation Checksum: Enabled
3. Define a route in the main routing table which routes all traffic to remote_net_A on the
GRE_to_A GRE interface. This is not necessary if the option Add route for remote network
is enabled in the Advanced tab, since this will add the route automatically.
4. Create the following rules in the IP rule set that allow traffic to pass through the tunnel:
Name Action Src Interface Src Network Dest Interface Dest Network Service
To_A Allow lan lannet GRE_to_A remote_net_A All
From_A Allow GRE_to_A remote_net_A lan lannet All
3.3.6. 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
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
66
Page 67
3.3.6. Interface Groups Chapter 3. Fundamentals
3. Click OK
67
Page 68
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. Higher level protocols such as IP make use of IP addresses
which are fundamentally different from a lower level hardware addressing scheme like the MAC
address. ARP is used to retrieve the Ethernet MAC address of a host by using its IP address.
When a host needs to resolve an IP address to the corresponding 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.
68
Page 69
3.4.4. Static and Published ARP Entries
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
specifies 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.
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 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
69
Page 70
3.4.4. Static and Published ARP
Entries
NetDefendOS supports defining static ARP entries (static binding of IP addresses to Ethernet
addresses) 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.
70
Page 71
3.4.5. Advanced ARP Settings Chapter 3. Fundamentals
There are two publishing modes; Publish and XPublish. The difference between the two is that
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.4, “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 behaviour 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.
Allowing 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
71
Page 72
3.4.5. Advanced ARP Settings Chapter 3. Fundamentals
situations are to be logged.
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.
72
Page 73
3.5. The IP Rule Set Chapter 3. Fundamentals
3.5. The IP Rule Set
3.5.1. Security Policies
Policy Characteristics
NetDefendOS Security Policies designed by the administrator, regulate the way in which traffic can
flow through a D-Link Firewall. Policies in NetDefendOS are defined by different NetDefendOS
rule sets. These rule sets share a common means of specifying filtering criteria which determine the
type of traffic to which they will apply. This set of criteria consists of:
Source Interface
Source Network
Destination Interface
Destination Network
Service
The NetDefendOS rule sets, all of which use the same five filtering parameters, include:
• IP rules.
• Pipe rules (see Section 10.1, “Traffic Shaping”).
• Policy-based Routing rules (see Section 4.3, “Policy-based Routing”).
An Interface or Interface Group where the packet is received at
the D-Link Firewall. This can also be a VPN tunnel.
The network that contains the source IP address of the packet.
This might be a NetDefendOS IP object which could define a
single IP address or range of addresses.
An Interface or an Interface Group from which the packet
would leave the D-Link Firewall. This can also be a VPN tunnel.
The network to which the destination IP address of the packet
belongs. This might be a NetDefendOS IP object which could
define a single IP address or range of addresses.
The protocol type to which the packet belongs. Service objects
define a protocol/port type. Examples might be HTTP or ICMP.
Custom services can also be defined.(see Section 3.2, “Services”
for more information.)
• IDP rules (see Section 6.5, “Intrusion Detection and Prevention”).
• Authentication rules (source net/interface only - see Chapter 8, User Authentication).
Specifying Any Interface or Network
When specifying the filtering criteria in any of the rule sets specified above there are three useful
pre-defined options that can be used :
• For a Source or Destination Network, the all-nets option is equivalent to the IP address 0.0.0.0/0
which will mean that any IP address is acceptable.
• For Source or Destination Interface, the any option can be used so that NetDefendOS will not
care about the interface which the traffic is going to or coming from.
• The Destination Interface can be specified as core. This means that traffic, such as an ICMP
Ping is destined for the D-Link Firewall itself and it is NetDefendOS that will respond to it.
73
Page 74
3.5.2. IP Rule Evaluation Chapter 3. Fundamentals
IP Rules
The IP rule set is the most important of these security policy rule sets. It determines the critical
packet filtering function of NetDefendOS, regulating what is allowed or not allowed to pass through
the D-Link Firewall, and if necessary, how address translations like NAT are applied.
There are two possible approaches to how traffic traversing a NetDefendOS could be dealt with:
• Everything is denied unless specifically permitted
• Everything is permitted unless specifically denied
To provide the best security, the first of these approaches is adopted by NetDefendOS and the Drop
action is the default policy of the IP rule set meaning that everything is denied. In order to permit
any traffic (including NetDefendOS responding to ICMP Ping requests) IP rules must be defined by
the administrator that allow traffic to traverse the D-Link Firewall.
Although dropping packets is achieved without an explicit IP rule, for logging purposes it is
recommended that a Drop IP rule with logging enabled is placed as the last rule in the IP rule set.
3.5.2. IP 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 the new connection is
found. The rule's Action is then performed.
If the action allows it then the establishment of the new connection will go ahead. A new entry or
state representing the new connection will then be added to NetDefendOS's internal state table
which allows monitoring of opened and active connections passing through the D-Link Firewall. If
the action is Drop or Reject then the new connection is refused.
Stateful Inspection
After initial rule evaluation of the opening connection, subsequent packets belonging to that
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 but also by means of "pseudo-connections" to stateless protocols such as UDP and ICMP. 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 throughput.
The First Matching Principle
If several rules match the same parameters, the first matching rule in a scan from top to bottom is
the one that decides how the connection will be handled.
The exception to this is SAT rules since these rely on a pairing with a second rule to function. After
encountering a matching SAT rule the search will therefore continue on looking for a matching
second rule (see Section 7.3, “Static Address Translation” for more information on this).
Non-matching Traffic
Incoming packets that don't match any rule in the rule set and that don't have an already opened
matching connection in the state table, will automatically be subject to a Drop action. For
explicitness there should be a rule called DropAll as the final rule in the rule set with an action of
Drop with Source/Destination Network all-nets and Source/Destination Interface all.
74
Page 75
3.5.3. IP Rule Actions Chapter 3. Fundamentals
3.5.3. IP Rule Actions
A rule consists of two parts: the filtering parameters and the action to take if there is a match with
those parameters. As described above, the parameters of any NetDefendOS rule, including IP rules
are:
• Source Interface
• Source Network
• Destination Interface
• Destination Network
• Service
The Service in an IP rule is also important because if an Application Layer Gateway object is to be
applied to traffic then it must be associated with a Service object (see Section 6.2, “Application
Layer Gateways”).
When an IP rule is triggered by a match then one of the following Actions can occur:
Allow
FwdFast
NAT
SAT
Drop
Reject
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 NetDefendOS's
"stateful engine".
Let the packet pass through the D-Link Firewall without setting up a state for it in the
state table. This means that the stateful inspection process is bypassed and is therefore
less secure than Allow or NAT rules. Packet processing time is also slower than Allow
rules since every packet is checked against the entire rule set.
This functions like an Allow rule, but with dynamic address translation (NAT) enabled
(see Section 7.1, “Dynamic Network Address Translation” in Chapter 7, Address
Translation for a detailed description).
This tells NetDefendOS to perform static address translation. A SAT rule always
requires a matching Allow, NAT or FwdFast rule further down the rule set (see
Section 7.3, “Static Address Translation” in Chapter 7, Address Translation for a
detailed description).
This tells NetDefendOS to immediately discard the packet. This is an "impolite"
version of Reject in that no reply is sent back to the sender. It is often preferable since
it gives a potential attacker no clues about what happened to their packets.
This acts like Drop, but will return a "TCP RST" or "ICMP Unreachable message",
informing the sending computer that the packet was disallowed. This is a "polite"
version of the Drop action.
Bi-directional Connections
A common mistake when setting up IP Rules is to define two rules, one rule for traffic in one
direction and another rule for traffic coming back in the other direction. In fact nearly all IP Rules
types allow bi-directional traffic flow once the initial connection is set up. The Source Network
and Source Interface in the rule means the source of the initial connection request. Once a
connection is permitted and established traffic can then flow in either direction over it.
The exception to this bi-directional flow is FwdFast rules. If the FwdFast action is used then the
rule will not allow traffic to flow from the destination back to the source. If bi-directional flow is
required then two FwdFast rules are needed, one for either direction. This is also the case if a
FwdFast rule is used with a SAT rule.
75
Page 76
3.5.4. Editing IP rule set Entries Chapter 3. Fundamentals
Using Reject
In certain situations the Reject action is recommended instead of the Drop action because a polite
reply is required from NetDefendOS. An example of such a situation is when responding to the
IDENT user identification protocol.
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
76
Page 77
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 and Intrusion Detection and Prevention (IDP) 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
77
Page 78
3.6. Schedules Chapter 3. Fundamentals
• Action: NAT
• Service: http
• Schedule: OfficeHours
• SourceInterface: lan
• SourceNetwork lannet
• DestinationInterface: any
• DestinationNetwork: all-nets
4. Click OK
78
Page 79
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.
Certificates with VPN Tunnels
The predominate usage of certificates in NetDefendOS is with VPN tunnels. The simplest and
fastest way to provide security between the ends of a tunnel is to use Pre-shared Keys (PSKs). As a
VPN network grows so does the complexity of using PSKs. Certificates provide a means to better
manage security in much larger networks.
Certificate Components
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.
Certification Authorities
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.
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
79
Page 80
3.7.2. X.509 Certificates in NetDefendOS
has to be issued.
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
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.
Trusting Certificates
When using certificates, NetDefendOS 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:
Chapter 3. Fundamentals
• 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.
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.
Reusing Root Certificates
In NetDefendOS, root certificates should be seen as global entities that can be reused between VPN
tunnels. Even though a root certificate is associated with one VPN tunnel in NetDefendOS, it can
still be reused with any number of other, different VPN tunnels.
3.7.2. 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.
80
Page 81
3.7.2. X.509 Certificates in
NetDefendOS
3. Now select one of the following:
• Upload self-signed X.509 Certificate
• Upload a remote certificate
4. Click OK and follow the instructions.
Example 3.19. Associating X.509 Certificates with IPsec Tunnels
To associate an imported certificate with an IPsec tunnel.
Web Interface
1. Go to Interfaces > IPsec
2. Display the properties the IPsec tunnel
3. Select the Authentication tab
4. Select the X509 Certificate option
5. Select the correct Gateway and Root certificates
6. Click OK
Chapter 3. Fundamentals
81
Page 82
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 the IDP and Anti-Virus databases, 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
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.20. 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.
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.
82
Page 83
3.8.2. Time Servers Chapter 3. Fundamentals
Example 3.21. 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
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.22. 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.
Time Synchronization Protocols
83
Page 84
3.8.2. Time Servers Chapter 3. Fundamentals
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.
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.23. 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.
Example 3.24. Manually Triggering a Time Synchronization
Time synchronization can be triggered from the CLI. The output below shows a typical response.
84
Page 85
3.8.2. Time Servers Chapter 3. Fundamentals
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.
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.25. 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.26. Forcing Time Synchronization
This example demonstrates how to force time synchronization, overiding the maximum adjustment setting.
CLI
gw-world:/> time -sync -force
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.
85
Page 86
3.8.2. Time Servers Chapter 3. Fundamentals
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.27. 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.
86
Page 87
3.9. DNS Lookup Chapter 3. Fundamentals
3.9. DNS Lookup
A DNS server can resolve a Fully Qualified Domain Name (FQDN) into the corresponding numeric
IP address. FQDNs are unambiguous textual domain names which specify a node's unique position
in the Internet's DNS tree hierarchy. FQDN resolution allows the actual physical IP address to
change while the FQDN can stay the same.
A Uniform Resource Locator (URL) differs from an FQDN in that the URL includes the access
protocol along with the FQDN. For example the protocol might be specified http//: for world wide
web pages.
FQDNs are used in many aspects 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.28. 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
87
Page 88
3.9. DNS Lookup Chapter 3. Fundamentals
88
Page 89
Chapter 4. Routing
This chapter describes how to configure IP routing in NetDefendOS.
• Overview, page 89
• Static Routing, page 90
• Policy-based Routing, page 98
• Dynamic Routing, page 103
• Multicast Routing, page 110
• Transparent Mode, page 119
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.
NetDefendOS offers support for the following types of routing mechanisms:
• Static routing.
• Dynamic routing.
NetDefendOS additionally supports route monitoring to achieve route and link redundancy with
fail-over capability.
89
Page 90
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.
4.2.1. Basic Principles of Routing
IP routing is the mechanism used in TCP/IP based networks 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 all-nets 195.66.77.4
The above 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 all-nets 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
all-nets 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.
90
Page 91
4.2.2. Static Routing Chapter 4. Routing
4.2.2. Static Routing
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”).
The 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.
NetDefendOS 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.255.255.255 255.255.255.255 10.4.2.143 10.4.2.143 50
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
10.4.2.143 255.255.255.255 127.0.0.1 127.0.0.1 50
85.11.194.33 255.255.255.255 192.168.0.1 192.168.0.10 20
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
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
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
91
Page 92
4.2.2. Static Routing 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
92
Page 93
4.2.2. Static Routing 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
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. In other words, it is processed by NetDefendOS 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
93
Page 94
4.2.3. Route Failover Chapter 4. Routing
Web Interface
1. Select the Routes item in the Status dropdown menu in the menu bar
2. Check the Show all routes checkbox and click the Apply button
3. 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.3. 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
94
Page 95
4.2.3. Route Failover Chapter 4. Routing
methods must be chosen:
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.
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 (for example "10"), and a secondary, failover
route should have a higher Metric value (for example "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 all-nets 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 all-nets 195.66.77.1 10 On
2 wan all-nets 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
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
95
Page 96
4.2.4. Proxy ARP Chapter 4. Routing
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 all-nets 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 all-nets 195.66.77.1 10 On
2 dsl all-nets 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.6, “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 be controlled by the advanced setting RFO_GratuitousARPOnFail.
4.2.4. 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
96
Page 97
4.2.4. Proxy ARP Chapter 4. Routing
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.
97
Page 98
4.3. Policy-based Routing Chapter 4. Routing
4.3. Policy-based Routing
4.3.1. Overview
Policy-based Routing (PBR) is an extension to the standard routing described previously. It offers
administrators significant flexibility in implementing routing decision policies by being able to
define rules so alternative routing tables are used.
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 routes chosen for traffic can be based on specific traffic parameters.
Policy-based Routing can allow:
Source based routing
Service-based Routing
User based Routing
Policy-based Routing implementation in NetDefendOS is based on two building blocks:
• One or more user-defined alternate Policy-based Routing Tables in addition to the standard
default main routing table.
A different routing table may need to be chosen based on the
source of 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.
A different routing table might need to be chosen based on the
service. Policy-based Routing can route a given protocol such as
HTTP, through proxies such as Web caches. Specific services
might also be routed to a specific ISP so that one ISP handles all
HTTP traffic.
A different routing table might need to be chosen based on the
user identity or the group to which the user belongs. This is
particularly useful in provider-independent metropolitan area
networks where all users share a common active backbone, but
each can use different ISPs, subscribing to different providers.
• One or more Policy-based routing rules which determines which routing table to use for which
traffic.
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 these 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 using alternate tables 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
98
Page 99
4.3.4. Policy-based Routing Table Selection
Policy-based Routing rule can be triggered by the type of Service (HTTP for example) 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 packet corresponding to a new connection first arrives, the processing steps are as follows
to determine which routing table is chosen:
1. The PBR Rules must first be looked up but to do this the packet's destination interface must be
determined and this is always done by a lookup in the main routing table. It is therefore
important a match for the destination network is found or at least a default all-nets route exists
which can catch anything not explicitly matched.
2. A search is now made for a Policy-based Routing Rule that matches the packets's
source/destination interface/network as well as service. If a matching rule is found then this
determines the routing table to use. If no PBR Rule is found then the main table will be used.
3. Once the correct routing table has been located, a check is made to make sure that the source IP
address in fact belongs on the receiving interface. The Access Rules are firstly examined to see
if they can provide this check (see Section 6.1, “Access Rules” for more details of this feature).
If there are no Access Rules or a match with the rules cannot be found, a reverse lookup in the
previously selected routing table is done using the source IP address. If the check fails then a
Default access rule log error message is generated.
Chapter 4. Routing
4. At this point, using the routing table selected, the actual route lookup is done to find the
packet's destination interface. At this point the ordering parameter is used to determine how the
actual lookup is done and the options for this are described in the next section. To implement
virtual systems, the Only ordering option should be used.
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.
(Note that the original route lookup to find the destination interface used for all rule look-ups
was done with the original, untranslated address.)
6. If allowed by the IP rule set, the new connection is opened in the NetDefendOS state table and
the packet forwarded through this connection.
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 route in the main table. If no matching
route is found, or the default route is found (the route with the destination all-nets - 0.0.0.0/0),
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 used for the lookup. The default all-nets
route will be counted as a match in the alternate table if it exists there.
3. Only - This option ignores the existence of any other table except the alternate table so the
alternate table is the only one used for the lookup. One application of this is to give the
administrator a way to dedicate a single routing table to one set of interfaces. Only is the
option to use when creating virtual systems since it can dedicate one routing table to a set of
99
Page 100
4.3.5. The Ordering parameter Chapter 4. Routing
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 the default route with a
destination interface of all-nets in the default main routing table. If there is no route
that is an exact match then the absence a default all-nets route will mean that the
connection will be dropped.
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 (all-nets),
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, that is to say 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
interface. 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
100
Loading...