Clavister cOS Core Administration Guide

Clavister cOS Core
Administration Guide
Version: 10.11.02
Clavister AB
Sjögatan 6J
SE-89160 Örnsköldsvik
SWEDEN
Phone: +46-660-299200
www.clavister.com
Published 2013-02-19
Copyright © 2013 Clavister AB
Clavister cOS Core
Administration Guide
Version: 10.11.02
Published 2013-02-19
Copyright © 2013 Clavister AB
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 the written consent of Clavister.
Disclaimer
The information in this document is subject to change without notice. Clavister makes no
representations or warranties with respect to the contents hereof and specifically disclaims any
implied warranties of merchantability or fitness for a particular purpose. Clavister reserves the
right to revise this publication and to make changes from time to time in the content hereof
without any obligation to notify any person or parties of such revision or changes.
Limitations of Liability
UNDER NO CIRCUMSTANCES SHALL CLAVISTER 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 CLAVISTER PRODUCT OR
FAILURE OF THE PRODUCT, EVEN IF CLAVISTER IS INFORMED OF THE POSSIBILITY OF SUCH
DAMAGES. FURTHERMORE, CLAVISTER WILL NOT BE LIABLE FOR THIRD-PARTY CLAIMS AGAINST
CUSTOMER FOR LOSSES OR DAMAGES. CLAVISTER WILL IN NO EVENT BE LIABLE FOR ANY
DAMAGES IN EXCESS OF THE AMOUNT CLAVISTER RECEIVED FROM THE END-USER FOR THE
PRODUCT.
2
Table of Contents
Preface ............................................................................................................... 14
1. cOS Core Overview ........................................................................................... 17
1.1. Features ............................................................................................... 17
1.2. cOS Core Architecture ............................................................................. 22
1.2.1. State-based Architecture .............................................................. 22
1.2.2. cOS Core Building Blocks .............................................................. 22
1.2.3. Basic Packet Flow ......................................................................... 23
1.3. cOS Core State Engine Packet Flow ........................................................... 26
2. Management and Maintenance .......................................................................... 31
2.1. Managing cOS Core ................................................................................ 31
2.1.1. Overview .................................................................................... 31
2.1.2. Default Administrator Accounts ..................................................... 33
2.1.3. The Web Interface ........................................................................ 33
2.1.4. The CLI ....................................................................................... 38
2.1.5. CLI Scripts ................................................................................... 50
2.1.6. Secure Copy ................................................................................ 54
2.1.7. The Console Boot Menu ................................................................ 56
2.1.8. Management Advanced Settings ................................................... 59
2.1.9. Working with Configurations ......................................................... 60
2.2. Events and Logging ................................................................................ 67
2.2.1. Overview .................................................................................... 67
2.2.2. Log Messages ............................................................................. 67
2.2.3. Creating Log Receivers ................................................................. 68
2.2.4. Logging to MemoryLogReceiver .................................................... 69
2.2.5. Logging to Syslog Hosts ............................................................... 69
2.2.6. Logging to the Clavister Logger ..................................................... 70
2.2.7. Severity Filter and Message Exceptions ........................................... 71
2.2.8. SNMP Traps ................................................................................ 72
2.2.9. Advanced Log Settings ................................................................. 73
2.3. RADIUS Accounting ................................................................................ 75
2.3.1. Overview .................................................................................... 75
2.3.2. RADIUS Accounting Messages ....................................................... 75
2.3.3. Interim Accounting Messages ........................................................ 77
2.3.4. Configuring RADIUS Accounting .................................................... 77
2.3.5. RADIUS Accounting Security ......................................................... 79
2.3.6. RADIUS Accounting and High Availability ........................................ 79
2.3.7. Handling Unresponsive RADIUS Servers .......................................... 79
2.3.8. Accounting and System Shutdowns ............................................... 80
2.3.9. Limitations with NAT .................................................................... 80
2.3.10. Advanced RADIUS Settings .......................................................... 80
2.4. Monitoring ............................................................................................ 82
2.4.1. Real-time Monitoring Counters ...................................................... 82
2.4.2. Real-time Monitor Alerts ............................................................... 87
2.4.3. The Link Monitor ......................................................................... 87
2.4.4. SNMP Monitoring ........................................................................ 90
2.4.5. Hardware Monitoring ................................................................... 93
2.4.6. Memory Monitoring Settings ......................................................... 96
2.5. Diagnostic Tools .................................................................................... 98
2.5.1. Overview .................................................................................... 98
2.5.2. Diagnostic CLI Commands ............................................................ 98
2.5.3. The pcapdump CLI Command ........................................................ 99
2.5.4. Hardware Fault Troubleshooting .................................................. 101
2.6. Maintenance ....................................................................................... 103
2.6.1. Software Upgrades .................................................................... 103
2.6.2. Auto-Update Mechanism ............................................................ 105
2.6.3. Backing Up Configurations .......................................................... 105
3
Clavister cOS Core
2.6.4. Restore to Factory Defaults .......................................................... 108
2.6.5. Listing and Adding Ethernet Interfaces .......................................... 109
2.7. Licensing ............................................................................................ 111
3. Fundamentals ................................................................................................ 116
3.1. The Address Book ................................................................................ 116
3.1.1. Overview .................................................................................. 116
3.1.2. IP Addresses ............................................................................. 117
3.1.3. Ethernet Addresses .................................................................... 119
3.1.4. Address Groups ......................................................................... 120
3.1.5. Auto-Generated Address Objects ................................................. 121
3.1.6. Address Book Folders ................................................................. 121
3.2. IPv6 Support ....................................................................................... 123
3.3. Services .............................................................................................. 130
3.3.1. Overview .................................................................................. 130
3.3.2. Creating Custom Services ............................................................ 132
3.3.3. ICMP Services ............................................................................ 135
3.3.4. Custom IP Protocol Services ........................................................ 136
3.3.5. Service Groups .......................................................................... 137
3.3.6. Custom Service Timeouts ............................................................ 138
3.4. Interfaces ............................................................................................ 139
3.4.1. Overview .................................................................................. 139
3.4.2. Ethernet Interfaces ..................................................................... 141
3.4.3. VLAN ....................................................................................... 151
3.4.4. PPPoE ...................................................................................... 155
3.4.5. GRE Tunnels .............................................................................. 158
3.4.6. Loopback Interfaces ................................................................... 162
3.4.7. Interface Groups ........................................................................ 166
3.5. ARP .................................................................................................... 168
3.5.1. Overview .................................................................................. 168
3.5.2. The ARP Cache .......................................................................... 168
3.5.3. ARP Publish .............................................................................. 170
3.5.4. Using ARP Advanced Settings ...................................................... 173
3.5.5. ARP Advanced Settings Summary ................................................ 174
3.6. IP Rules and IP Policies .......................................................................... 178
3.6.1. Security Policies ......................................................................... 178
3.6.2. IP Rule Set Evaluation ................................................................. 181
3.6.3. IP Rule Actions .......................................................................... 182
3.6.4. Multiple IP Rule Sets ................................................................... 184
3.6.5. IP Rule Set Folders ..................................................................... 186
3.6.6. Configuration Object Groups ....................................................... 187
3.6.7. IP Policies ................................................................................. 191
3.6.8. Application Control .................................................................... 194
3.7. Schedules ........................................................................................... 203
3.8. Certificates .......................................................................................... 206
3.8.1. Overview .................................................................................. 206
3.8.2. Certificates in cOS Core ............................................................... 208
3.8.3. CA Certificate Requests ............................................................... 210
3.9. Date and Time ..................................................................................... 212
3.9.1. Overview .................................................................................. 212
3.9.2. Setting Date and Time ................................................................ 212
3.9.3. Time Servers ............................................................................. 214
3.9.4. Settings Summary for Date and Time ............................................ 217
3.10. DNS .................................................................................................. 219
3.11. Internet Access Setup .......................................................................... 222
3.11.1. Static Address Setup ................................................................. 222
3.11.2. DHCP Setup ............................................................................ 223
3.11.3. The Minimum Requirements for Traffic Flow ................................ 224
3.11.4. Creating a Route ...................................................................... 225
3.11.5. Creating IP Rules or IP Policies .................................................... 226
3.11.6. Defining DNS Servers ................................................................ 228
4. Routing ......................................................................................................... 231
4
Clavister cOS Core
4.1. Overview ............................................................................................ 231
4.2. Static Routing ...................................................................................... 232
4.2.1. The Principles of Routing ............................................................ 232
4.2.2. Static Routing ........................................................................... 236
4.2.3. Route Failover ........................................................................... 242
4.2.4. Host Monitoring for Route Failover ............................................... 245
4.2.5. Advanced Settings for Route Failover ............................................ 247
4.2.6. Proxy ARP ................................................................................. 248
4.3. Policy-based Routing ............................................................................ 251
4.4. Route Load Balancing ........................................................................... 259
4.5. Virtual Routing .................................................................................... 267
4.5.1. Overview .................................................................................. 267
4.5.2. A Simple Scenario ...................................................................... 267
4.5.3. Advantages Over Routing Rules ................................................... 269
4.5.4. IP Rules with Virtual Routing ........................................................ 272
4.5.5. Multiple IP rule sets .................................................................... 273
4.5.6. Trouble Shooting ....................................................................... 273
4.6. OSPF .................................................................................................. 275
4.6.1. Dynamic Routing ....................................................................... 275
4.6.2. OSPF Concepts .......................................................................... 278
4.6.3. OSPF Components ..................................................................... 283
4.6.4. Dynamic Routing Rules ............................................................... 289
4.6.5. Setting Up OSPF ........................................................................ 292
4.6.6. An OSPF Example ...................................................................... 297
4.6.7. OSPF Troubleshooting ................................................................ 302
4.7. Multicast Routing ................................................................................. 305
4.7.1. Overview .................................................................................. 305
4.7.2. Multicast Forwarding with SAT Multiplex Rules ............................... 306
4.7.3. IGMP Configuration ................................................................... 311
4.7.4. Advanced IGMP Settings ............................................................. 316
4.8. Transparent Mode ................................................................................ 319
4.8.1. Overview .................................................................................. 319
4.8.2. Enabling Internet Access ............................................................. 324
4.8.3. Transparent Mode Scenarios ....................................................... 326
4.8.4. Spanning Tree BPDU Support ...................................................... 332
4.8.5. MPLS Pass Through .................................................................... 333
4.8.6. Advanced Settings for Transparent Mode ...................................... 334
5. DHCP Services ................................................................................................ 338
5.1. Overview ............................................................................................ 338
5.2. DHCP Servers ...................................................................................... 339
5.2.1. Static DHCP Hosts ...................................................................... 343
5.2.2. Custom Options ........................................................................ 344
5.3. DHCP Relaying ..................................................................................... 346
5.3.1. DHCP Relay Advanced Settings .................................................... 347
5.4. IP Pools .............................................................................................. 349
6. Security Mechanisms ...................................................................................... 353
6.1. Access Rules ........................................................................................ 353
6.1.1. Overview .................................................................................. 353
6.1.2. IP Spoofing ............................................................................... 354
6.1.3. Access Rule Settings ................................................................... 354
6.2. ALGs .................................................................................................. 357
6.2.1. Overview .................................................................................. 357
6.2.2. The HTTP ALG ........................................................................... 358
6.2.3. The FTP ALG ............................................................................. 361
6.2.4. The TFTP ALG ............................................................................ 371
6.2.5. The SMTP ALG ........................................................................... 372
6.2.6. The POP3 ALG ........................................................................... 381
6.2.7. The PPTP ALG ............................................................................ 381
6.2.8. The SIP ALG .............................................................................. 383
6.2.9. The H.323 ALG ........................................................................... 396
6.2.10. The TLS ALG ............................................................................ 412
5
Clavister cOS Core
6.3. Web Content Filtering ........................................................................... 416
6.3.1. Overview .................................................................................. 416
6.3.2. Active Content Handling ............................................................. 416
6.3.3. Static Content Filtering ............................................................... 417
6.3.4. Dynamic Web Content Filtering ................................................... 420
6.4. Anti-Virus Scanning .............................................................................. 434
6.4.1. Overview .................................................................................. 434
6.4.2. Implementation ........................................................................ 434
6.4.3. Activating Anti-Virus Scanning ..................................................... 435
6.4.4. The Signature Database .............................................................. 436
6.4.5. Subscribing to the Clavister Anti-Virus Service ................................ 436
6.4.6. Anti-Virus Options ..................................................................... 436
6.5. Intrusion Detection and Prevention ........................................................ 441
6.5.1. Overview .................................................................................. 441
6.5.2. Subscribing to Clavister IDP ......................................................... 442
6.5.3. IDP Rules .................................................................................. 443
6.5.4. Insertion/Evasion Attack Prevention ............................................. 445
6.5.5. IDP Pattern Matching ................................................................. 446
6.5.6. IDP Signature Groups ................................................................. 447
6.5.7. IDP Actions ............................................................................... 448
6.5.8. Deploying IDP ........................................................................... 451
6.6. Denial-of-Service Attacks ....................................................................... 453
6.6.1. Overview .................................................................................. 453
6.6.2. DoS Attack Mechanisms .............................................................. 453
6.6.3. Ping of Death Attacks .................................................................. 453
6.6.4. Fragmentation Overlap Attacks .................................................... 454
6.6.5. The Land and LaTierra Attacks ...................................................... 454
6.6.6. The WinNuke attack .................................................................... 454
6.6.7. Amplification Attacks ................................................................. 455
6.6.8. TCP SYN Flood Attacks ................................................................ 456
6.6.9. The Jolt2 Attack ......................................................................... 456
6.6.10. Distributed DoS Attacks ............................................................ 457
6.7. Blacklisting Hosts and Networks ............................................................. 458
7. Address Translation ........................................................................................ 461
7.1. Overview ............................................................................................ 461
7.2. NAT ................................................................................................... 463
7.3. NAT Pools ........................................................................................... 470
7.4. SAT .................................................................................................... 474
7.4.1. Translation of a Single IP Address (1:1) .......................................... 474
7.4.2. Translation of Multiple IP Addresses (M:N) ..................................... 481
7.4.3. All-to-One Mappings (N:1) ........................................................... 484
7.4.4. Port Translation ......................................................................... 485
7.4.5. Protocols Handled by SAT ........................................................... 485
7.4.6. Multiple SAT Rule Matches .......................................................... 486
7.4.7. SAT and FwdFast Rules ................................................................ 487
8. User Authentication ........................................................................................ 490
8.1. Overview ............................................................................................ 490
8.2. Authentication Setup ............................................................................ 492
8.2.1. Setup Summary ......................................................................... 492
8.2.2. Local User Databases .................................................................. 492
8.2.3. External RADIUS Servers ............................................................. 495
8.2.4. External LDAP Servers ................................................................ 497
8.2.5. Authentication Rules .................................................................. 503
8.2.6. Authentication Processing .......................................................... 505
8.2.7. HTTP Authentication .................................................................. 506
8.3. Customizing Authentication HTML Pages ................................................ 511
8.4. User Identity Awareness ........................................................................ 515
8.5. Two Factor Authentication .................................................................... 521
9. VPN .............................................................................................................. 524
9.1. Overview ............................................................................................ 524
9.1.1. VPN Usage ................................................................................ 524
6
Clavister cOS Core
9.1.2. VPN Encryption ......................................................................... 525
9.1.3. VPN Planning ............................................................................ 526
9.1.4. Key Distribution ......................................................................... 526
9.1.5. The TLS Alternative for VPN ......................................................... 527
9.2. VPN Quick Start .................................................................................... 528
9.2.1. IPsec LAN to LAN with Pre-shared Keys .......................................... 529
9.2.2. IPsec LAN to LAN with Certificates ................................................ 530
9.2.3. IPsec Roaming Clients with Pre-shared Keys ................................... 531
9.2.4. IPsec Roaming Clients with Certificates ......................................... 534
9.2.5. L2TP Roaming Clients with Pre-Shared Keys ................................... 534
9.2.6. L2TP Roaming Clients with Certificates .......................................... 536
9.2.7. PPTP Roaming Clients ................................................................. 537
9.2.8. iOS Setup ................................................................................. 538
9.3. IPsec Components ............................................................................... 540
9.3.1. Overview .................................................................................. 540
9.3.2. Internet Key Exchange (IKE) ......................................................... 540
9.3.3. IKE Authentication ..................................................................... 546
9.3.4. IPsec Protocols (ESP/AH) ............................................................. 548
9.3.5. NAT Traversal ............................................................................ 549
9.3.6. Algorithm Proposal Lists ............................................................. 550
9.3.7. Pre-shared Keys ......................................................................... 552
9.3.8. Identification Lists ...................................................................... 553
9.4. IPsec Tunnels ....................................................................................... 556
9.4.1. Overview .................................................................................. 556
9.4.2. LAN to LAN Tunnels with Pre-shared Keys ...................................... 558
9.4.3. Roaming Clients ........................................................................ 558
9.4.4. Fetching CRLs from an alternate LDAP server ................................. 565
9.4.5. Troubleshooting with ikesnoop .................................................... 566
9.4.6. IPsec Advanced Settings ............................................................. 573
9.5. PPTP/L2TP .......................................................................................... 576
9.5.1. PPTP Servers ............................................................................. 576
9.5.2. L2TP Servers ............................................................................. 577
9.5.3. L2TP/PPTP Server advanced settings ............................................. 583
9.5.4. PPTP/L2TP Clients ...................................................................... 584
9.5.5. L2TP Version 3 ........................................................................... 585
9.6. SSL VPN .............................................................................................. 591
9.6.1. Overview .................................................................................. 591
9.6.2. Configuring SSL VPN in cOS Core ................................................. 592
9.6.3. Installing the SSL VPN Client ........................................................ 594
9.6.4. Setup Example .......................................................................... 597
9.7. CA Server Access .................................................................................. 600
9.8. VPN Troubleshooting ............................................................................ 603
9.8.1. General Troubleshooting ............................................................ 603
9.8.2. Troubleshooting Certificates ....................................................... 604
9.8.3. IPsec Troubleshooting Commands ............................................... 604
9.8.4. Management Interface Failure with VPN ........................................ 605
9.8.5. Specific Error Messages ............................................................... 605
9.8.6. Specific Symptoms ..................................................................... 608
10. Traffic Management ...................................................................................... 611
10.1. Traffic Shaping ................................................................................... 611
10.1.1. Overview ................................................................................ 611
10.1.2. Traffic Shaping in cOS Core ........................................................ 612
10.1.3. Simple Bandwidth Limiting ....................................................... 615
10.1.4. Limiting Bandwidth in Both Directions ........................................ 616
10.1.5. Creating Differentiated Limits Using Chains ................................. 618
10.1.6. Precedences ............................................................................ 619
10.1.7. Pipe Groups ............................................................................ 624
10.1.8. Traffic Shaping Recommendations ............................................. 627
10.1.9. A Summary of Traffic Shaping .................................................... 628
10.1.10. More Pipe Examples ............................................................... 629
10.2. IDP Traffic Shaping ............................................................................. 633
7
Clavister cOS Core
10.2.1. Overview ................................................................................ 633
10.2.2. Setting Up IDP Traffic Shaping ................................................... 633
10.2.3. Processing Flow ....................................................................... 634
10.2.4. The Importance of Specifying a Network ...................................... 634
10.2.5. A P2P Scenario ......................................................................... 635
10.2.6. Viewing Traffic Shaping Objects ................................................. 636
10.2.7. Guaranteeing Instead of Limiting Bandwidth ................................ 637
10.2.8. Logging .................................................................................. 637
10.3. Threshold Rules .................................................................................. 638
10.4. Server Load Balancing ......................................................................... 641
10.4.1. Overview ................................................................................ 641
10.4.2. SLB Distribution Algorithms ....................................................... 642
10.4.3. Selecting Stickiness .................................................................. 643
10.4.4. SLB Algorithms and Stickiness .................................................... 644
10.4.5. SLB Server Monitoring .............................................................. 645
10.4.6. Setting Up SLB_SAT Rules .......................................................... 647
11. High Availability ........................................................................................... 653
11.1. Overview .......................................................................................... 653
11.2. HA Mechanisms ................................................................................. 656
11.3. Setting Up HA .................................................................................... 659
11.3.1. HA Hardware Setup .................................................................. 659
11.3.2. cOS Core Setup with the HA Wizard ............................................ 661
11.3.3. cOS Core Manual HA Setup ........................................................ 662
11.3.4. Verifying the Cluster Functions ................................................... 663
11.3.5. Unique Shared Mac Addresses ................................................... 664
11.4. HA Issues .......................................................................................... 665
11.5. Upgrading an HA Cluster ..................................................................... 667
11.6. Link Monitoring and HA ...................................................................... 669
11.7. HA Advanced Settings ......................................................................... 670
12. Advanced Settings ........................................................................................ 672
12.1. IP Level Settings ................................................................................. 672
12.2. TCP Level Settings .............................................................................. 676
12.3. ICMP Level Settings ............................................................................ 681
12.4. State Settings .................................................................................... 682
12.5. Connection Timeout Settings ............................................................... 684
12.6. Length Limit Settings .......................................................................... 686
12.7. Fragmentation Settings ....................................................................... 689
12.8. Local Fragment Reassembly Settings ..................................................... 693
12.9. SSL Settings ....................................................................................... 694
12.10. Miscellaneous Settings ...................................................................... 696
A. Update Subscriptions ..................................................................................... 699
B. IDP Signature Groups ...................................................................................... 702
C. Verified MIME filetypes .................................................................................... 706
D. The OSI Framework ........................................................................................ 710
E. Third Party Licenses ........................................................................................ 711
Alphabetical Index ............................................................................................. 717
8
List of Figures
1.1. Packet Flow Schematic Part I ............................................................................ 26
1.2. Packet Flow Schematic Part II ........................................................................... 27
1.3. Packet Flow Schematic Part III .......................................................................... 28
1.4. Expanded Apply Rules Logic ............................................................................. 29
2.1. cOS Core Firmware Structure ......................................................................... 103
3.1. VLAN Connections ....................................................................................... 153
3.2. A Simple Network with Loopback Interfaces ..................................................... 164
3.3. Components of Loopback Interface Setup ........................................................ 165
3.4. An ARP Publish Ethernet Frame ...................................................................... 172
3.5. Simplified cOS Core Traffic Flow ..................................................................... 181
4.1. A Typical Routing Scenario ............................................................................ 233
4.2. Using Local IP Address with an Unbound Network .............................................. 235
4.3. A Route Failover Scenario for ISP Access .......................................................... 242
4.4. A Proxy ARP Example .................................................................................... 249
4.5. The RLB Round Robin Algorithm ..................................................................... 260
4.6. The RLB Spillover Algorithm ........................................................................... 261
4.7. A Route Load Balancing Scenario .................................................................... 263
4.8. A Simple OSPF Scenario ................................................................................ 276
4.9. OSPF Providing Route Redundancy ................................................................. 277
4.10. Virtual Links Connecting Areas ..................................................................... 281
4.11. Virtual Links with Partitioned Backbone ......................................................... 282
4.12. cOS Core OSPF Objects ................................................................................ 283
4.13. Dynamic Routing Rule Objects ..................................................................... 291
4.14. Setting Up OSPF ......................................................................................... 293
4.15. OSPF Over IPsec ......................................................................................... 295
4.16. An OSPF Example ....................................................................................... 297
4.17. Multicast Forwarding - No Address Translation ................................................ 307
4.18. Multicast Forwarding - Address Translation .................................................... 309
4.19. Multicast Snoop Mode ................................................................................ 311
4.20. Multicast Proxy Mode .................................................................................. 312
4.21. Non-transparent Mode Internet Access .......................................................... 324
4.22. Transparent Mode Internet Access ................................................................ 325
4.23. Transparent Mode Scenario 1 ....................................................................... 326
4.24. Transparent Mode Scenario 2 ....................................................................... 328
4.25. An Example BPDU Relaying Scenario ............................................................. 332
5.1. DHCP Server Objects .................................................................................... 342
6.1. Deploying an ALG ........................................................................................ 357
6.2. HTTP ALG Processing Order ........................................................................... 361
6.3. FTP ALG Hybrid Mode ................................................................................... 363
6.4. SMTP ALG Processing Order ........................................................................... 374
6.5. Anti-Spam Filtering ...................................................................................... 376
6.6. PPTP ALG Usage ........................................................................................... 382
6.7. TLS Termination ........................................................................................... 413
6.8. Dynamic Web Content Filtering Flow .............................................................. 421
6.9. IDP Database Updating ................................................................................. 442
6.10. IDP Signatures ........................................................................................... 444
6.11. IDP Signature Selection ............................................................................... 444
7.1. NAT IP Address Translation ............................................................................ 463
7.2. A NAT Example ............................................................................................ 465
7.3. Anonymizing with NAT ................................................................................. 468
7.4. The Role of the DMZ ..................................................................................... 475
8.1. Normal LDAP Authentication ......................................................................... 502
8.2. LDAP for PPP with CHAP, MS-CHAPv1 or MS-CHAPv2 ......................................... 503
8.3. User Identity Awareness ................................................................................ 515
8.4. The Identity Awareness Agent Interface ........................................................... 519
9.1. The AH protocol ........................................................................................... 548
9
Clavister cOS Core
9.2. The ESP protocol .......................................................................................... 549
9.3. PPTP Client Usage ........................................................................................ 585
9.4. An L2TPv3 Example ...................................................................................... 587
9.5. SSL VPN Browser Connection Choices ............................................................. 595
9.6. The SSL VPN Client Login ............................................................................... 595
9.7. The SSL VPN Client Statistics .......................................................................... 596
9.8. Certificate Validation Components .................................................................. 601
10.1. Pipe Rules Determine Pipe Usage .................................................................. 614
10.2. FwdFast Rules Bypass Traffic Shaping ............................................................. 615
10.3. Differentiated Limits Using Chains ................................................................ 619
10.4. The Eight Pipe Precedences ......................................................................... 620
10.5. Minimum and Maximum Pipe Precedence ...................................................... 621
10.6. Traffic Grouped By IP Address ....................................................................... 625
10.7. A Basic Traffic Shaping Scenario .................................................................... 629
10.8. IDP Traffic Shaping P2P Scenario ................................................................... 636
10.9. A Server Load Balancing Configuration .......................................................... 641
10.10. Connections from Three Clients .................................................................. 644
10.11. Stickiness and Round-Robin ....................................................................... 645
10.12. Stickiness and Connection-rate ................................................................... 645
D.1. The 7 Layers of the OSI Model ........................................................................ 710
10
List of Examples
1. Example Notation ............................................................................................. 14
2.1. Enabling remote management via HTTPS .......................................................... 37
2.2. Setting the Console Line Speed ........................................................................ 45
2.3. Enabling SSH Remote Access ........................................................................... 45
2.4. Listing Configuration Objects ........................................................................... 61
2.5. Displaying a Configuration Object .................................................................... 62
2.6. Editing a Configuration Object ......................................................................... 62
2.7. Adding a Configuration Object ......................................................................... 63
2.8. Deleting a Configuration Object ....................................................................... 64
2.9. Undeleting a Configuration Object ................................................................... 64
2.10. Listing Modified Configuration Objects ............................................................ 65
2.11. Activating and Committing a Configuration ..................................................... 66
2.12. Enable Logging to a Syslog Host ..................................................................... 70
2.13. Enabling Logging to Clavister Loggers ............................................................. 71
2.14. Sending SNMP Traps to an SNMP Trap Receiver ................................................. 73
2.15. RADIUS Accounting Server Setup .................................................................... 78
2.16. Enabling SNMP Monitoring ............................................................................ 91
2.17. Performing a Complete System Backup ......................................................... 107
2.18. Complete Hardware Reset to Factory Defaults ................................................ 108
3.1. Adding an IP Host Address ............................................................................. 117
3.2. Adding an IP Network ................................................................................... 118
3.3. Adding an IP Range ...................................................................................... 118
3.4. Deleting an Address Object ........................................................................... 119
3.5. Adding an Ethernet Address .......................................................................... 119
3.6. Adding IPv6 Host Addresses .......................................................................... 123
3.7. Enabling IPv6 Globally .................................................................................. 124
3.8. Enabling IPv6 on an Interface ......................................................................... 125
3.9. Enabling IPv6 Advertisements ........................................................................ 126
3.10. Adding an IPv6 Route and Enabling Proxy ND ................................................. 127
3.11. Listing the Available Services ........................................................................ 130
3.12. Viewing a Specific Service ............................................................................ 131
3.13. Creating a Custom TCP/UDP Service .............................................................. 134
3.14. Adding an IP Protocol Service ....................................................................... 137
3.15. Defining a VLAN ......................................................................................... 155
3.16. Configuring a PPPoE Client .......................................................................... 157
3.17. Creating a Loopback Interface Pair ................................................................ 165
3.18. Creating an Interface Group ......................................................................... 166
3.19. Displaying the ARP Cache ............................................................................ 169
3.20. Flushing the ARP Cache ............................................................................... 169
3.21. Defining an ARP/Neighbor Discovery Object ................................................... 172
3.22. Adding an Allow IP Rule ............................................................................... 187
3.23. Setting up a Policy to Allow Connections to a DMZ .......................................... 193
3.24. Setting up a SAT Policy to an Internal Web Server ............................................ 193
3.25. Specifying an Application Control Policy ........................................................ 195
3.26. Using an Application Control Rule Set ............................................................ 197
3.27. Setting up a Time-Scheduled Security Policy ................................................... 204
3.28. Uploading a Certificate with Web Interface or InControl ................................... 209
3.29. Associating Certificates with IPsec Tunnels ..................................................... 209
3.30. Setting the Current Date and Time ................................................................ 212
3.31. Setting the Time Zone ................................................................................. 213
3.32. Enabling DST ............................................................................................. 214
3.33. Enabling Time Synchronization using SNTP .................................................... 215
3.34. Manually Triggering a Time Synchronization .................................................. 216
3.35. Modifying the Maximum Adjustment Value .................................................... 216
3.36. Forcing Time Synchronization ...................................................................... 217
3.37. Configuring DNS Servers ............................................................................. 219
11
Clavister cOS Core
3.38. Enabling DHCP .......................................................................................... 224
3.39. Adding an all-nets Route .............................................................................. 225
3.40. Creating IP Policy Objects for Internet Access .................................................. 226
3.41. Configuring DNS Servers ............................................................................. 228
4.1. Displaying the main Routing Table .................................................................. 238
4.2. Adding a Route to the main Table ................................................................... 240
4.3. Displaying the Core Routes ............................................................................ 241
4.4. Creating a Routing Table ............................................................................... 252
4.5. Adding Routes ............................................................................................. 253
4.6. Creating a Routing Rule ................................................................................. 254
4.7. Policy-based Routing with Multiple ISPs ........................................................... 257
4.8. Setting Up RLB ............................................................................................. 264
4.9. Creating an OSPF Router Process ...................................................................... 297
4.10. Add an OSPF Area ....................................................................................... 298
4.11. Add OSPF Interface Objects .......................................................................... 299
4.12. Import Routes from an OSPF AS into the Main Routing Table ............................. 300
4.13. Exporting the Routes into an OSPF AS ............................................................ 301
4.14. Enabling OSPF Debug Log Events ................................................................. 303
4.15. Forwarding of Multicast Traffic using the SAT Multiplex Rule ............................. 307
4.16. Multicast Forwarding - Address Translation .................................................... 309
4.17. IGMP - No Address Translation ...................................................................... 312
4.18. if1 Configuration ........................................................................................ 314
4.19. if2 Configuration - Group Translation ............................................................. 315
4.20. Setting up Transparent Mode for Scenario 1 ................................................... 326
4.21. Setting up Transparent Mode for Scenario 2 ................................................... 328
5.1. Setting up a DHCP server ............................................................................... 341
5.2. Static DHCP Host Assignment ........................................................................ 343
5.3. Setting up a DHCP Relayer ............................................................................. 346
5.4. Creating an IP Pool ....................................................................................... 351
6.1. Setting up an Access Rule .............................................................................. 355
6.2. Protecting an FTP Server with an ALG .............................................................. 365
6.3. Protecting FTP Clients ................................................................................... 368
6.4. SIP with Local Clients, Proxy on Internet ........................................................... 389
6.5. Protecting Phones Behind Clavister Security Gateways ....................................... 398
6.6. H.323 with Private IPv4 Addresses ................................................................... 400
6.7. Two Phones Behind Different Clavister Security Gateways .................................. 401
6.8. Using Private IPv4 Addresses ......................................................................... 403
6.9. H.323 with Gatekeeper .................................................................................. 404
6.10. H.323 with Gatekeeper and two Clavister Security Gateways ............................. 406
6.11. Using the H.323 ALG in a Corporate Environment ............................................ 408
6.12. Configuring remote offices for H.323 ............................................................. 410
6.13. Allowing the H.323 Gateway to register with the Gatekeeper ............................ 411
6.14. Stripping ActiveX and Java applets ................................................................ 417
6.15. Setting up a white and blacklist .................................................................... 418
6.16. Enabling Dynamic Web Content Filtering ....................................................... 422
6.17. Enabling Audit Mode .................................................................................. 424
6.18. Reclassifying a blocked site .......................................................................... 426
6.19. Editing Content Filtering HTTP Banner Files .................................................... 432
6.20. Activating Anti-Virus Scanning ..................................................................... 438
6.21. Setting up IDP for a Mail Server ..................................................................... 449
6.22. Adding a Host to the Whitelist ...................................................................... 459
7.1. Specifying a NAT IP Rule ................................................................................ 465
7.2. Specifying a NAT IP Policy .............................................................................. 466
7.3. Using NAT Pools .......................................................................................... 472
7.4. Enabling Traffic to a Protected Web Server in a DMZ .......................................... 475
7.5. Enabling Traffic to a Web Server on an Internal Network ..................................... 478
7.6. Allowing Traffic to a Protected Web Server with an IP Policy ................................ 480
7.7. Translating Traffic to Multiple Protected Web Servers ........................................ 481
7.8. Translating Traffic to a Single Protected Web Server (N:1) ................................... 484
8.1. Creating an Authentication Database .............................................................. 494
8.2. Configuring a RADIUS Server ......................................................................... 496
12
Clavister cOS Core
8.3. User Authentication Setup for Web Access ....................................................... 508
8.4. Editing Content Filtering HTTP Banner Files ...................................................... 512
8.5. Enabling User Identity Awareness ................................................................... 517
9.1. Using an Algorithm Proposal List .................................................................... 551
9.2. Using a Pre-Shared key ................................................................................. 552
9.3. Using an Identity List .................................................................................... 553
9.4. Setting up a PSK based VPN tunnel for roaming clients ...................................... 559
9.5. Setting up a Self-signed Certificate based VPN tunnel for roaming clients ............. 560
9.6. Setting up CA Server Certificate based VPN tunnels for roaming clients ................ 562
9.7. Setting Up Config Mode ................................................................................ 564
9.8. Using Config Mode with IPsec Tunnels ............................................................ 564
9.9. Setting up an LDAP server ............................................................................. 565
9.10. Setting up a PPTP server .............................................................................. 577
9.11. Setting up an L2TP server ............................................................................ 578
9.12. Setting up an L2TP Tunnel Over IPsec ............................................................ 579
9.13. L2TPv3 Server Setup ................................................................................... 587
9.14. L2TPv3 Server Setup For VLANs .................................................................... 589
9.15. Setting Up an SSL VPN Interface .................................................................... 597
9.16. Setting SSL VPN Interface Client Routes ......................................................... 599
10.1. Applying a Simple Bandwidth Limit ............................................................... 615
10.2. Limiting Bandwidth in Both Directions ........................................................... 617
10.3. Setting up SLB ........................................................................................... 648
13
Preface
Intended Audience
The target audience for this reference guide is Administrators who are responsible for
configuring and managing Clavister Security Gateways which are running the cOS Core
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 Chapter 9, VPN) 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 a term is being introduced for the first time or being stressed it may appear in italics.
Where console interaction is shown in the main text outside of an example, it will appear in a box
with a gray background.
Device:/>
Where a web address reference is shown in the text, clicking it will open the specified URL in a
browser in a new window (some systems may not allow this).
For example, http://www.clavister.com.
Screenshots
This guide contains a minimum of screenshots. This is deliberate and is done because the manual
deals specifically with cOS Core and administrators have a choice of management user
interfaces. It was decided that the manual would be less cluttered and easier to read if it
concentrated on describing how cOS Core functions rather than including large numbers of
screenshots showing how the various interfaces are used. Examples are given but these are
largely textual descriptions of management interface usage.
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
cOS Core 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.
Command-Line Interface
The Command Line Interface example would appear here. It would start with the command
14
Preface
prompt followed by the command:
Device:/> somecommand someparameter=somevalue
InControl
The InControl actions for the example are shown here. They are typically a numbered list
showing what actions in the interface need to be taken followed by information about the data
items that need to be entered:
In many cases the actions are identical to the actions required for the Web Interface and when
that is the case the text indicates this.
Web Interface
The Web Interface actions for the example are shown here. They are also typically a numbered
list showing what items 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
Highlighted Content
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.
15
Preface
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.
Documentation Feedback
Despite all efforts, unintentional typographic errors, factual errors or omissions may regrettably
occur in documentation. Clavister appreciates all feedback pointing out such problems or other
suggestions for content improvement. Email all feedback to mailto:[email protected].
Trademarks
Certain names in this publication are the trademarks of their respective owners.
cOS Core and CorePlus are trademarks of Clavister AB.
Windows, Windows XP, Windows Vista and Windows 7 are either registered trademarks or
trademarks of Microsoft Corporation in the United States and/or other countries.
16
Chapter 1: cOS Core Overview
This chapter outlines the key features of cOS Core.
• Features, page 17
• cOS Core Architecture, page 22
• cOS Core State Engine Packet Flow, page 26
1.1. Features
Clavister cOS Core is the base software engine that drives and controls the range of Clavister
Security Gateway hardware products. cOS Core can also be deployed on the administrator's
preferred choice of server hardware as a software only product.
cOS Core as a Network Security Operating System
Designed as a network security operating system, cOS Core features high throughput performance
with high reliability plus super-granular control. In contrast to products built on top of standard
operating systems such as Unix or Microsoft Windows, cOS Core offers seamless integration of all
its subsystems, in-depth administrative control of all functionality, as well as a minimal attack
surface which helps to negate the risk from security attacks.
cOS Core Objects
From the administrator's perspective the conceptual approach of cOS Core is to visualize
operations through a set of logical building blocks or objects. These objects allow the
configuration of cOS Core in an almost limitless number of different ways. This granular control
allows the administrator to meet the requirements of the most demanding network security
scenarios.
Key Features
cOS Core has an extensive feature set. The list below presents the key features of the product:
IP Routing
cOS Core provides a variety of options for IP routing
including static routing, dynamic routing (with OSPF) ,
virtual routing as well as multicast routing capabilities. In
17
Chapter 1: cOS Core Overview
addition, cOS Core supports features such as Virtual LANs,
Route Monitoring, Proxy ARP and Transparency.
For more information, please see Chapter 4, Routing.
Firewalling Policies
cOS Core provides stateful inspection-based firewalling for
a wide range of protocols such as TCP, UDP and ICMP. The
administrator can define detailed firewalling policies based
on source/destination network/interface, protocol, ports,
user credentials, time-of-day and more.
Section 3.6, “IP Rules and IP Policies” describes how to set up
these policies to determine what traffic is allowed or
rejected by cOS Core.
Address Translation
For functionality as well as security reasons, cOS Core
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.
ALGs
cOS Core provides a range of Application Level Gateways
(ALGs) which provide security features that examine traffic
at higher OSI layers such as checking that file download
content agrees with the given filetype. Another example is
the SIP ALG which examines the SIP message exchanges
that take place during the setup of peer to peer data
exchanges.
For detailed information, see Section 6.2, “ALGs”.
VPN
cOS Core supports a range of Virtual Private Network (VPN)
solutions. Support exists for IPsec, L2TP, L2TPv3, PPTP as
well as SSL VPN with security policies definable for
individual VPN connections.
This topic is covered in Chapter 9, VPN.
TLS Termination
cOS Core supports TLS termination so that the Clavister
Security Gateway can act as the end point for connections
by HTTP web-browser clients (this feature is sometimes
called SSL termination).
For detailed information, see Section 6.2.10, “The TLS ALG”.
Application Control
cOS Core is able to identify data connections relating to
particular applications and perform defined actions for
those data streams such as blocking or traffic shaping. An
example of an application is BitTorrent peer to peer
streaming but could also relate to accessing certain
websites such as Facebook.
For detailed information, see Section 3.6.8, “Application
Control”.
Anti-Virus Scanning
cOS Core features integrated anti-virus functionality. Traffic
passing through the Clavister Security Gateway can be
subjected to in-depth scanning for viruses, and virus
sending hosts can be black-listed and blocked.
18
Chapter 1: cOS Core Overview
For details of this feature, seeSection 6.4, “Anti-Virus
Scanning”.
Intrusion Detection and
Prevention
To mitigate application-layer attacks towards vulnerabilities
in services and applications, cOS Core 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
hosts.
More information about IDP can be found in Section 6.5,
“Intrusion Detection and Prevention”.
Web Content Filtering
cOS Core provides various mechanisms for filtering web
content that is deemed inappropriate according to a web
usage policy. With Web Content Filtering (WCF) web content
can be blocked based on category (Dynamic WCF),
malicious objects can be removed from web pages and
web sites can be whitelisted or blacklisted.
More information about this topic can be found in
Section 6.3, “Web Content Filtering”.
Traffic Management
cOS Core provides broad traffic management capabilities
through Traffic Shaping, Threshold Rules and Server Load
Balancing.
Traffic Shaping enables limiting and balancing of
bandwidth; Threshold Rules allow specification of
thresholds for sending alarms and/or limiting network
traffic; Server Load Balancing enables a device running cOS
Core to distribute network load to multiple hosts.
These features are discussed in detail in Chapter 10, Traffic
Management.
User Authentication
A cOS Core device can be used for authenticating users
before allowing access to protected resources. Multiple
local user databases are supported as well as multiple
external RADIUS servers, and separate authentication
policies can be defined to support separate authentication
schemes for different kinds of traffic.
In addition, cOS Core supports User Identity Awareness. This
means Windows based clients need only be authenticated
once by a Windows Active Directory™ server and the
authenticated state is then relayed to cOS Core.
See Chapter 8, User Authentication for detailed information.
Operations and Maintenance
Administrator management of cOS Core is possible through
either a Web-based User Interface (the Web Interface or
WebUI) or via a Command Line Interface (the CLI). Both
interfaces allow management of a single Clavister Security
Gateway at a time. cOS Core also provides detailed event
and logging capabilities plus support for monitoring
through SNMP.
More detailed information about this topic can be found in
19
Chapter 1: cOS Core Overview
Chapter 2, Management and Maintenance.
High Availability
High Availability (HA) is supported through automatic
fault-tolerant fail-over to a secondary Clavister Security
Gateway device. The two devices act together as a cluster,
with one being active while the other is passive but
constantly mirroring the state of the active unit.
This feature is described in more detail in Chapter 11, High
Availability.
Virtualization
cOS Core supports virtualization using one of two
techniques:
•
Using separate cOS Core routing tables, as mentioned
above under IP routing, it is possible to create separate
virtual routers. Although a single version of cOS Core is
being run it is possible to create separate sets of IP rules
and other policies.
See Section 4.5, “Virtual Routing” for more information
about this topic.
•
Using VMware it is possible to have multiple,
independent versions of cOS Core running on a single
computer. This option is not available on Clavister
hardware but runs, instead, as a software-only
installation on non-Clavister hardware that has VMware
installed.
Installation with VMware is described in the separate
Clavister V Series Getting Started Guide.
IPv6
IPv6 addresses are supported on interfaces and within rule
sets. This feature is not enabled by default and must be
explicitly enables on an Ethernet interface.
More information about this topic can be found in
Section 3.2, “IPv6 Support”.
In addition to the list above, cOS Core includes a number of other features such as RADIUS
Accounting, DHCP services, protection against Denial-of-Service (DoS) attacks, support for PPPoE,
GRE, dynamic DNS services and much more.
cOS Core Documentation
Reading through the available documentation carefully will ensure getting the most out of the
cOS Core product. In addition to this document, the reader should also be aware of the
companion reference guides:
•
Separate Getting Started Guides detail how to set up a new installation of cOS Core.
•
The CLI Reference Guide which details all cOS Core CLI commands.
•
The cOS Core Log Reference Guide which details all cOS Core log event messages.
Together, these documents form the essential reference material for cOS Core operation.
Additional, related documentation consists of:
20
Chapter 1: cOS Core Overview
•
The Hardware Replacement Guide for swapping out Clavister hardware with the same or
different unit.
•
The Migration Guide for upgrading cOS Core from an older CorePlus 8.nn version to a cOS
Core 10.nn version. The guide also discusses downgrading from cOS Core 10.nn to CorePlus
8.nn.
•
The InControl Administration Guide which covers all aspects of using the separate InControl
product for cOS Core management.
cOS Core Education and Certification
Clavister offers a full range of product courses and product certifications. For details about
classroom and online cOS Core education as well as cOS Core certification, visit the Clavister
company website at http://www.clavister.com or contact a local sales representative.
21
Chapter 1: cOS Core Overview
1.2. cOS Core Architecture
1.2.1. State-based Architecture
The cOS Core 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
cOS Core employs a technique called stateful inspection which means that it inspects and
forwards traffic on a per-connection basis. cOS Core detects when a new connection is being
established, and keeps a small piece of information or state in its state table for the lifetime of
that connection. By doing this, cOS Core is able to understand the context of the network traffic
which enables it to perform in-depth traffic scanning, apply bandwidth management and a
variety of other functions.
The stateful inspection approach additionally provides high throughput performance with the
added advantage of a design that is highly scalable. The cOS Core subsystem that implements
stateful inspection will sometimes be referred to in documentation as the cOS Core state-engine.
1.2.2. cOS Core Building Blocks
The basic building blocks in cOS Core are interfaces, logical objects and various types of rules (or
rule sets).
Interfaces
Interfaces are the doorways through which network traffic enters or leaves the Clavister Security
Gateway. Without interfaces, a cOS Core system has no means for receiving or sending traffic.
The following types of interface are supported in cOS Core:
•
Physical interfaces - These correspond to the actual physical Ethernet interfaces.
•
Sub-interfaces - These include VLAN and PPPoE interfaces.
•
Tunnel interfaces - Used for receiving and sending traffic through VPN tunnels.
Interface Symmetry
The cOS Core 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 predefined 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 which represent specific protocol and port
22
Chapter 1: cOS Core Overview
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.
cOS Core Rule Sets
Finally, rules which are defined by the administrator in the various rule sets are used for actually
implementing cOS Core 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.
1.2.3. Basic Packet Flow
This section outlines the basic flow in the state-engine for packets received and forwarded by
cOS Core. The following description is simplified and might not be fully applicable in all
scenarios, however, the basic principles will be valid for all cOS Core deployments.
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 cOS Core 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.
cOS Core 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 10 below. If a match is found, the forwarding process continues at step 11
below.
5.
The source interface is examined to find out if the interface is a member of a specific routing
table. Routing Rules are also evaluated to determine the correct routing table for the
connection.
6.
The Access Rules are evaluated to find out if the source IP address of the new connection is
allowed on the received interface. If no Access Rule matches then a reverse route lookup will
be done in the routing tables.
In other words, by default, an interface will only accept source IP addresses that belong to
networks routed over that interface. A reverse lookup means that we look in the routing
23
Chapter 1: cOS Core Overview
tables to confirm that there is a route with this network as the destination on the same
interface.
If the Access Rule lookup or the reverse route lookup determine that the source IP is invalid,
then the packet is dropped and the event is logged.
7.
A route lookup is being made using the appropriate routing table. The destination interface
for the connection has now been determined.
8.
The IP rules are now searched for a rule that matches the packet. 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 predefined 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 cOS Core should do with the connection. If the action is Drop, the packet is dropped
and the event is logged according to the log settings for the rule.
If the action is Allow, the packet is allowed through the system. A corresponding state will
be added to the connection table for matching subsequent packets belonging to the same
connection. In addition, the service object which matched the IP protocol and ports might
have contained a reference to an Application Layer Gateway (ALG) object. This information
is recorded in the state so that cOS Core 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: Additional actions
There are actually a number of additional actions available such as address
translation and server load balancing. The basic concept of dropping and allowing
traffic is still the same.
9.
The Intrusion Detection and Prevention (IDP) Rules are now evaluated in a similar way to the
IP rules. If a match is found, the IDP data is recorded with the state. By doing this, cOS Core
will know that IDP scanning is supposed to be conducted on all packets belonging to this
connection.
10. The Traffic Shaping and the Threshold Limit rule sets are now searched. If a match is found,
the corresponding information is recorded with the state. This will enable proper traffic
management on the connection.
11. From the information in the state, cOS Core 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
24
Chapter 1: cOS Core Overview
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, PPTP/L2TP 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 cOS Core again, now with source interface being the matched tunnel interface.
In other words, the process continues at step 3 above.
•
If traffic management information is present, the packet might get queued or otherwise
be subjected to actions related to traffic management.
12. Eventually, the packet will be forwarded out on the destination interface according to the
state. If the destination interface is a tunnel interface or a physical sub-interface, additional
processing such as encryption or encapsulation might occur.
The next section provides a set of diagrams illustrating the flow of packets through cOS Core.
25
Chapter 1: cOS Core Overview
1.3. cOS Core State Engine Packet Flow
The diagrams in this section provide a summary of the flow of packets through the cOS Core
state-engine. There are three diagrams, each flowing into the next. It is not necessary to
understand these diagrams, however, they can be useful as a reference when configuring cOS
Core in certain situations.
Figure 1.1. Packet Flow Schematic Part I
The packet flow is continued on the following page.
26
Chapter 1: cOS Core Overview
Figure 1.2. Packet Flow Schematic Part II
The packet flow is continued on the following page.
27
Chapter 1: cOS Core Overview
Figure 1.3. Packet Flow Schematic Part III
28
Chapter 1: cOS Core Overview
Apply Rules
The figure below presents the detailed logic of the Apply Rules function in Figure 1.2, “Packet Flow
Schematic Part II” above.
Figure 1.4. Expanded Apply Rules Logic
29
Chapter 1: cOS Core Overview
30
Chapter 2: Management and Maintenance
This chapter describes the management, operations and maintenance related aspects of cOS
Core.
• Managing cOS Core, page 31
• Events and Logging, page 67
• RADIUS Accounting, page 75
• Monitoring, page 82
• Diagnostic Tools, page 98
• Maintenance, page 103
• Licensing, page 111
2.1. Managing cOS Core
2.1.1. Overview
cOS Core 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 cOS Core 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
cOS Core provides the following management interfaces:
Clavister InControl
InControl is a separate Clavister software product for the
centralized administration of multiple Clavister Security Gateways.
The product provides an intuitive graphical client which runs on a
standard Windows based PC. One or multiple clients communicate
with an InControl server running on the same or different Windows
31
Chapter 2: Management and Maintenance
based computer. The server serves as a repository for all cOS Core
configuration data and mediates all management commands sent
by clients.
More information about InControl can be found in the separate
InControl Administrators Guide.
The Web Interface
The Web Interface (also known as the Web User Interface or WebUI)
is built into cOS Core and provides a user-friendly and intuitive
graphical management interface, accessible from a standard web
browser.
The browser connects to one of the hardware's Ethernet interfaces
using HTTP or HTTPS and the cOS Core responds like a web server,
allowing web pages to be used as the management interface.
The Web Interface does not provide centralized management
control of multiple Clavister Security Gateways. One browser
window can communicate with one Clavister Security Gateway,
although it is possible to have multiple browser windows open at
the same time.
This feature is fully described in Section 2.1.3, “The Web Interface”.
The CLI
The Command Line Interface (CLI), accessible locally via serial
console port or remotely using the Secure Shell (SSH) protocol,
provides the most fine-grained control over all parameters in cOS
Core.
This feature is fully described in Section 2.1.4, “The CLI”.
Secure Copy
Secure Copy (SCP) is a widely used communication protocol for file
transfer. No specific SCP client is provided with cOS Core
distributions but there exists a wide selection of SCP clients
available for nearly all workstation platforms.
SCP is a complement to CLI usage and provides a secure means of
file transfer between the administrator's workstation and the
Clavister Security Gateway. Various files used by cOS Core can be
both uploaded and downloaded with SCP.
This feature is fully described in Section 2.1.6, “Secure Copy”.
Console Boot Menu
Before cOS Core starts running, a console connected directly to the
Clavister Security Gateway's RS232 port can be used to do basic
configuration through the boot menu. This menu can be entered
by pressing any console key between power-up and cOS Core
starting. It is the Clavister firmware loader that is being accessed
with the boot menu.
The menu is fully described in Section 2.1.7, “The Console Boot
Menu”.
Remote Management Policies
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 username/password credentials.
32
Chapter 2: Management and Maintenance
2.1.2. Default Administrator Accounts
By default, cOS Core has a local user database, AdminUsers, which contains two predefined user
accounts:
•
Username admin with password admin.
This account has full administrative read/write privileges.
•
Username audit with password audit.
This account is for monitoring purposes only and has read-only privileges.
Important
For security reasons, it is recommended to change the default passwords of the default
accounts as soon as possible after connecting with the Clavister Security Gateway.
Creating Additional Accounts
Extra user accounts can be created as required. Accounts can either belong to the Administrator
user group, in which case they have complete read/write administrative access. Alternatively,
they can belong to the Auditor user group, in which case they have read-only access.
Multiple Administration Logins
cOS Core does not allow more than one administrator account to be logged in at the same time.
If one administrator logs in, then a second or more will be allowed to login but they will only
have audit privileges. In other words the second or more administrators who login will only be
able to read configurations and will not be able to change them.
2.1.3. The Web Interface
cOS Core provides an intuitive Web Interface (WebUI) for management of the system via an
Ethernet interface using a standard web browser. This allows the administrator to perform
remote management from anywhere on a private network or the public Internet using a
standard computer without having to install client software.
Note: Recommended web browsers
The recommended browsers to use with the Web Interface are:
•
•
•
•
•
Microsoft Internet Explorer
Firefox
Safari
Chrome
Opera
Assignment of a Default IP Address
For new Clavister product models with factory defaults, a default internal IP address of
192.168.1.1 is assigned by cOS Core to the interface indicated in the list below.
33
Chapter 2: Management and Maintenance
Clavister Product
Default Web Interface Management Interface
Lynx X8
G1
Eagle E7
gesw
Wolf W3/W5
M1
V Series (under VMware)
If1
The Management Interface on Non-Clavister Hardware
For the Clavister Software Series product, when cOS Core runs on non-Clavister hardware, cOS
Core scans the available interfaces and allocates the 192.168.1.1 IP address to the first interface it
finds and gives this the logical name If1. Subsequent interfaces are then named If2, If3 and so on.
Trying to connect to each interface in turn with a web browser can reveal which has been
selected if it is not clear. cOS Core running under VMware names the virtual interfaces found in a
similar way.
Setting the Management Workstation IP
The default management Ethernet interface of the security gateway and the external
workstation computer's Ethernet interface must be members of the same logical IP network for
communication between them to succeed. Therefore, the connecting Ethernet interface of the
workstation must be manually assigned the following static IP values:
•
IP address: 192.168.1.30
•
Subnet mask: 255.255.255.0
•
Default gateway: 192.168.1.1
For details on how to set the static IP address for Windows and MacOS workstations, see the
relevant Clavister Getting Started Guide for the platform being used.
Logging on to the Web Interface
To access the Web Interface using the factory default settings, launch a web browser on the
external workstation computer and point the browser at the IPv4 address: 192.168.1.1.
When performing initial connection to cOS Core, the administrator should use https:// as the
URL protocol in the browser (in other words, https://192.168.1.1 ). Using HTTPS ensures that
communication with cOS Core is secure.
Alternatively, http:// can be used for logon but this is not secure and should be used only across
internal, private networks.
If communication with the cOS Core is successfully established, a user authentication dialog
similar to the one shown below will then be shown in the browser window.
34
Chapter 2: Management and Maintenance
After entering a valid username and password the Login button is clicked. If the user credentials
are valid, the administrator is taken to the main Web Interface page.
Note: Password caching is prevented
The Web Interface prevents the caching of the password from the login credentials. This
is also done in other cOS Core features where a password is requested through a
browser screen. For example, VPN authentication.
First Time Web Interface Logon and the Setup Wizard
When logging on for the first time, the default username is always admin and the password is
admin .
After successful login, the Web Interface user interface will be presented in the browser window.
If no configuration changes have yet been uploaded to the Clavister Security Gateway, the cOS
Core Setup Wizard will start automatically to take a new user through the essential steps for cOS
Core setup and establishing public Internet access.
Important: Switch off popup blocking
Popup blocking must be disabled in the web browser to allow the cOS Core Setup
Wizard to run since this appears in a popup window.
The wizard can be terminated and setup up done as a series of separate steps through the Web
Interface if desired or alternatively through the CLI. Initial setup and the wizard are described in
detail in the relevant Getting Started Guide.
Multi-language Support
The Web Interface login dialog offers the option to select a language other than English for the
interface. Language support is provided by a set of separate resource files.
It may occasionally be the case that a cOS Core upgrade can 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 in place of a translation to the selected language.
The Web Browser Interface
On the left hand side of the Web Interface is a tree which allows navigation to the various sets of
cOS Core objects. The central area of the Web Interface displays information about those
35
Chapter 2: Management and Maintenance
modules. Current performance information is shown by default.
Note: Remote management access
Access to the Web Interface is regulated by the configured 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:
A. Menu bar
The menu bar located at the top of the Web Interface contains a series of
buttons for accessing different aspects of the configuration.
B. Object Navigator
C. Main Window
The navigator located on the left-hand side of the Web Interface
is divided into a number of sections related to the chosen menu
bar item.
The main window contains configuration or status details corresponding
to the section selected in the menu bar or object navigator.
When displaying tables of information in the main window, right clicking
a line (for example, an IP rule) will bring up a context menu.
This context menu can be used to add a new object, delete the current,
change the ordering and other operations. The Clone function is used to
make a complete copy of the current object and then add it as the last
36
Chapter 2: Management and Maintenance
object in the table. Below is a typical example of the context menu.
Controlling Access to the Web Interface
By default, the Web Interface is accessible only from the internal network. If it is required to have
access from other parts of the network, this can be done by modifying the remote management
policy.
Example 2.1. Enabling remote management via HTTPS
Command-Line Interface
Device:/> add RemoteManagement RemoteMgmtHTTP https
Network=all-nets
Interface=any
LocalUserDatabase=AdminUsers
HTTPS=Yes
Web Interface
1.
Go to: System > Device > Remote Management > Add > HTTP/HTTPS Management
2.
Enter a Name for the HTTP/HTTPS remote management policy, for example https
3.
Enable the HTTPS option
4.
Select the following:
5.
•
User Database: AdminUsers
•
Interface: any
•
Network: all-nets
Click OK
Caution: Don't expose the management interface to the Internet
37
Chapter 2: Management and Maintenance
The above example is provided for illustrative purposes only. It is never recommended to
expose any management interface to any user on the Internet.
Restarting cOS Core with the Web Interface
The Web Interface can be used to restart cOS Core by selecting the option Status >
Maintenance > Reset & Restore. The following restart options are available:
•
Reconfigure
This does not restart the hardware but only reloads the configuration. This is equivalent to
the reconf CLI command. In most cases, all connections including VPN tunnels are unaffected.
Apart from reloading the configuration, many of cOS Core's internal data structures related to
rules and traffic processing are reinitialized and this can sometimes be a way to solve
problems related to memory management.
•
Restart
This restarts the hardware and is equivalent to the shutdown CLI command. Only cOS Core
restarts and not the cOS Core loader. This is the usual method of performing a restart.
•
Reboot
This restarts the hardware and is equivalent to the shutdown -reboot CLI command. It is
similar to the previous Restart option with a graceful shutdown but is also equivalent to
switching power off and on so that the cOS Core boot program is also reloaded. This option is
not normally used in standard operation and also requires longer for the restart.
Logging out from the Web Interface
After finishing working with the Web Interface, it is advisable to always logout to prevent other
users with access to the workstation getting unauthorized access to cOS Core. Logout is
achieved by clicking on the Logout button at the right of the menu bar.
Management Traffic Routing with VPN Tunnels
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.
Management traffic may be using this route.
If no specific route is set up for the management interface then all management traffic coming
from cOS Core will automatically be routed into 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.4. The CLI
cOS Core provides a Command Line Interface (CLI) for administrators who prefer or require a
command line approach to administration, or who need more granular control of system
configuration. The CLI is available either locally through the serial console port (connection to
this is described below), or remotely via an Ethernet interface using the Secure Shell (SSH)
protocol from an SSH client.
38
Chapter 2: Management and Maintenance
The CLI provides a comprehensive set of commands that allow the display 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 for using the CLI. For a complete reference for all CLI
commands, see the separate Clavister CLI Reference Guide.
The most often used CLI commands are:
•
add - Adds an object such as an IP address or a rule to a cOS Core configuration.
•
set - Sets some property of an object to a value. For example, this might be used to set the
source interface on an IP rule.
•
show - Displays the current categories or display the values of a particular object.
•
delete - Deletes a specific object.
CLI Command Structure
CLI commands usually have the structure:
<command> <object_category> <object_type> <object_name>
For example, to display an IP address object called my_address, the command would be:
Device:/> show Address IP4Address my_address
The object category in this case is Address and the type within this category is IPAddress.
When typing commands, the object category can be left out where the command's meaning is
unambiguous. For example, the show command above could have been entered as:
Device:/> show IPAddress my_address
However, tab completion will always assume the category is included. For example, tab
completion would not be able to help complete the above command if the tab is pressed during
or after the IPAddress object type.
The same object name could be used within two different categories or types although this is
best avoided in order to avoid ambiguity when reading configurations.
Note: The terms Category and Context
When describing the CLI, the terms object category and object context are used
interchangeably.
A command like add can also include object properties. To add a new IP4Address object with an IP
address of 10.49.02.01, the command would be:
Device:/> add IP4Address my_address Address=10.49.02.01
The object type can be optionally preceded by the object category. A category groups together a
set of types and mainly used with tab completion which is described below.
39
Chapter 2: Management and Maintenance
CLI Help
The CLI help command will show all available command options. A screen shot of the first part of
the output from the help command is shown below:
Tip: Getting help about help
Typing the CLI command:
Device:/> help help
will give information about the help command itself.
The CLI Command History
Just like the console in many versions of Microsoft Windows™, the up and down arrow keys allow
the user to move through the list of commands in the CLI command history. For example,
pressing the up arrow key once will make the last command executed appear at the current CLI
prompt. After a command appears it can be re-executed in its original form or changed first
before execution.
Tab Completion
Remembering all the commands and their options can be difficult. cOS Core provides a feature
called tab completion which means that pressing the tab key will cause automatically completion
of the current part of the command. If completion is not possible then pressing the tab key will
alternatively display the possible command options that are available.
Optional Parameters Are Tab Completed Last
Tab completion does not work with optional parameters until all the mandatory parameters
have been entered.
For example, when creating an IP rule for a particular IP rule set, the command line might begin:
Device:/> add IPRule
40
Chapter 2: Management and Maintenance
If the tab key is now pressed, the mandatory parameters are displayed by cOS Core:
A value is required for the following properties:
Action
DestinationInterface
DestinationNetwork
Service
SourceInterface
SourceNetwork
The Name parameter is not in this list since it is not mandatory because rules can be referenced
with their index number. Similarly, the following might be entered:
Device:/> add IPRule Na
If the tab key is now pressed, the letters Na will not be completed to be Name= because Name is
optional and all the mandatory parameters must be entered before tab completion works for
optional parameters.
Note: CLI commands in this guide are reformatted
In order to make the individual elements of CLI commands in this guide clearer, they are
broken into indented separate lines. In a console window they would appear as a single
continuous line which folds at the right margin.
For example, if the following command is typed:
Device:/> add IPRule
SourceInterface=If2
SourceNetwork=all-nets
DestinationInterface=If2
DestinationNetwork=all-nets
Action=Allow
Service=all_services
Na
If the tab key is now pressed, the letters Na will now be completed to be Name= because all the
mandatory parameters have already been entered.
Note: Rule names are recommended
Even when it is optional, it is recommended that a Name value is assigned to a rule. This
makes examining and understanding the configuration easier.
Getting the Default or Current Property Value
The period "." character before a tab can be used to automatically fill in the default value for an
object property in an Add command. For example:
Device:/> add LogReceiver LogReceiverSyslog log_example
Address=example_ip
LogSeverity=.<tab>
This will fill in the default value for LogSeverity:
Device:/> add LogReceiverSyslog example
Address=example_ip
LogSeverity=Emergency,Alert,Critical,Error,Warning,Notice,Info
This severity list can then be edited with the back arrow and backspace keys. A default value is
not always available. For example, the Action of an IP rule has no default.
This same sequence can be used to get the current property value in a Set command. For
41
Chapter 2: Management and Maintenance
example:
Device:/> set LogReceiver LogReceiverSyslog log_example Address=.<tab>
This will display the current value for the Address property.
Appending Property Values
Another usage of the period character before a tab is to automatically fill in the current value of
an object property in a command line. This is very useful when there is a need to append a new
value to a list of pre-existing values.
For example, the following unfinished command may have been typed:
Device:/> set Address IP4Address If1_ip Address=
If a period "." followed by a tab is now entered, cOS Core displays the current value for Address. If
that value were the IPv4 list 10.6.58.10,192.168.2.1 then the unfinished command line will
automatically become:
Device:/> set Address IPAddress If1_ip Address=10.6.58.10,192.168.2.1
The displayed values can then be added to or changed with the backspace and back arrow keys
before completing the command.
Object Categories
It has been mentioned that objects are grouped by type, such as IP4Address. Types themselves
are grouped by category. The type IP4Address belongs to the category Address. The main use of
categories is in tab completion when searching for the right object type to use.
If a command such as add is entered and then the tab key is pressed, cOS Core displays all the
available categories. By choosing a category and then pressing tab again all the object types for
that category is displayed. Using categories means that the user has a simple way to specify what
kind of object they are trying to specify and a manageable number of options are displayed after
pressing tab.
Not all object types belong in a category. The object type UserAuthRule is a type without a
category and will appear in the category list after pressing tab at the beginning of a command.
The category is sometimes also referred to as the CLI context. The category does not have to be
entered for the command to be valid but always appears when using tab completion. As
discussed later, when commands are created automatically using CLI scripting, cOS Core omits
the category in the commands it creates.
Selecting Object Categories
With some categories, it is necessary to first choose a member of that category with the cc
(change category) command before individual objects can be manipulated. This is the case, for
example, with routes. There can be more than one routing table, so when adding or
manipulating a route we first have to use the cc command to identify which routing table we are
interested in.
Suppose a route is to be added to the routing table main. The first command would be:
Device:/> cc RoutingTable main
Device:/main>
Notice that the command prompt changes to indicate the current category. The route can now
42
Chapter 2: Management and Maintenance
be added:
Device:/main> add Route Name=new_route1 Interface=lan Network=If1_net
To deselect the category, the command is cc on its own:
Device:/main> cc
Device:/>
The categories that require an initial cc command before object manipulation have a "/"
character following their names when displayed by a show command. For example:
RoutingTable/ .
Specifying Multiple Property Values
Sometimes a command property may need multiple values. For example, some commands use
the property AccountingServers and more than one value can be specified for this property. When
specifying multiple values, they should be separated by a comma "," character. For example, if
three servers server1, server2, server3 need to be specified then the property assignment in the
command would be:
AccountingServers=server1,server2,server3
Inserting into Rule Lists
Rule lists such as the IP rule set have an ordering which is important. When adding using the CLI
add command, the default is to add a new rule to the end of a list. When placement at a
particular position is crucial, the add command can include the Index= parameter as an option.
Inserting at the first position in a list is specified with the parameter Index=1 in an add command,
the second position with the parameter Index=2 and so on.
Referencing by Name
The naming of some objects is optional and is done with the Name= parameter in an add
command. An object, such as a threshold rule, will always have an Index value which indicates its
position in the rule list but can optionally be allocated a name as well. Subsequent manipulation
of such a rule can be done either by referring to it by its index, that is to say its list position, or by
alternatively using the name assigned to it.
The CLI Reference Guide lists the parameter options available for each cOS Core object, including
the Name= and Index= options.
Using Unique Names
For convenience and clarity, it is recommended that a name is assigned to all objects so that it
can be used for reference if required. Reference by name is particularly useful when writing CLI
scripts. For more on scripts see Section 2.1.5, “CLI Scripts”.
The CLI will enforce unique naming within an object type. For reasons of backward compatibility
to earlier cOS Core releases, an exception exists with IP rules which can have duplicate names,
however it is strongly recommended to avoid this. If a duplicate IP rule name is used in two IP
rules then only the Index value can uniquely identify each IP rule in subsequent CLI commands.
Referencing an IP rule with a duplicated name will fail and result in an error message.
43
Chapter 2: Management and Maintenance
Using Hostnames in the CLI
For certain CLI commands, IP addresses can optionally be specified as a textual hostname instead
an IP4Address object or raw IP address such as 192.168.1.10. When this is done, the hostname
must be prefixed with the letters dns: to indicate that a DNS lookup must be done to resolve the
hostname to an IP address. For example, the hostname host.company.com would be specified as
dns:host.company.com in the CLI.
The parameters where this might be used with the CLI are:
•
The Remote Endpoint for IPsec, L2TP and PPTP tunnels.
•
The Host for LDAP servers.
When DNS lookup needs to be done, at least one public DNS server must be configured in cOS
Core for hostnames to be translated to IP addresses.
InControl Domains
When using InControl as the means of configuring cOS Core, it is possible to use the logical
concept of a Domain to share the same object between security gateways.
The Domain is a construct that only exists in InControl and not in individual security gateway
configurations. For this reason, the CLI cannot be used to manipulate domains.
Furthermore, an object in a InControl domain may not necessarily be used in the configuration of
a security gateway which is a child of that domain. If this is the case, the CLI cannot be used to
manipulate a domain object on a security gateway that does not use it.
Serial Console CLI Access
The serial console port is a local RS-232 port on the Clavister Security Gateway that allows direct
access to the cOS Core CLI through a serial connection to a PC or dumb terminal. To locate the
serial console port on Clavister hardware, see the corresponding hardware installation guide.
To use the console port, the following equipment is required:
•
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 bps, No parity, 8 data 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 the
Clavister Security Gateway system.
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 cOS Core login prompt should appear on the
terminal screen.
44
Chapter 2: Management and Maintenance
Changing the Serial Console Line Speed
The console line speed can be changed either through the Web Interface or through the CLI.
Example 2.2. Setting the Console Line Speed
In this example the console line speed is set to 19200 bps.
Command-Line Interface
Device:/> set COMPortDevice COM1 BitsPerSecond=19200
InControl
Follow the same steps used for the Web Interface below.
Web Interface
Go to: System > Advanced Settings > Com Port Devices
Click the console port line, configure the speed and then click OK
Note: A cOS Core restart is required after changing the speed
After changing the speed, the new setting will only come into effect after restarting cOS
Core which can be done with the command:
Device:/> shutdown
A shutdown always restarts cOS Core.
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. SSH clients are freely available for almost all
hardware platforms.
cOS Core supports version 1, 1.5 and 2 of the SSH protocol. SSH access is regulated by the remote
management policy in cOS Core, and is disabled by default.
Example 2.3. Enabling SSH Remote Access
This example shows how to enable remote SSH access from the lan_net network through the lan
interface by adding a rule to the remote management policy.
Command-Line Interface
Device:/> add RemoteManagement RemoteMgmtSSH ssh
Network=lan_net
Interface=lan
LocalUserDatabase=AdminUsers
45
Chapter 2: Management and Maintenance
Web Interface
1.
Go to: System > Device > Remote Management > Add > Secure Shell Management
2.
Enter a Name for the SSH remote management policy, for example ssh_policy
3.
Select the following:
4.
•
User Database: AdminUsers
•
Interface: lan
•
Network: lan_net
Click OK
Logging on to the CLI
When access to the CLI has been established to cOS Core 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 remotely through SSH, cOS Core will respond with a login prompt. Enter
the username and press the Enter key, followed by the password and then Enter again. After the
first startup, cOS Core will allow administrator login with the username admin and the password
admin. This default password should be changed as soon as possible.
After a successful logon, the CLI command prompt will appear:
Device:/>
If a welcome message has been set then it will be displayed directly after the logon. For security
reasons, it is advisable to either disable or anonymize the CLI welcome message.
Changing the admin User Password
It is recommended to change the default password of the admin account from admin to
something else as soon as possible after initial startup. User passwords can be any combination
of characters and cannot be greater than 256 characters in length. It is recommended to use only
printable characters.
To change the password to, for example, my-password the following CLI commands are used.
First we must change the current category to be the LocalUserDatabase called AdminUsers (which
exists by default):
Device:/> cc LocalUserDatabase AdminUsers
We are now in AdminUsers and can change the password of the admin user:
Device:/AdminUsers> set User admin Password="my-password"
Finally, we return the current category to the top level:
Device:/AdminUsers> cc
46
Chapter 2: Management and Maintenance
Note: The console password is separate
The password that can be set to protect direct serial console access is a separate
password and should not be confused with the passwords related to user accounts. The
console password is described in Section 2.1.7, “The Console Boot Menu”.
Changing the CLI Prompt
The default CLI prompt is:
Device:/>
This can be customized, for example, to my-prompt:/>, by using the CLI command:
Device:/> set device name="my-prompt"
The CLI Reference Guide uses the command prompt Device:/> throughout.
Tip: The CLI prompt is the Web Interface device name
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 Web Interface navigation
tree.
Activating and Committing Changes
If any changes are made to the current configuration through the CLI, those changes will not be
uploaded to cOS Core until the command:
Device:/> activate
is issued. Immediately following the activate command, the command:
Device:/> 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.
A possible side effect of committing changes though the CLI is that any Web Interface browser
session that is logged in at the time of the commit will require that the user logs in again. This is
because the Web Interface view of the configuration may no longer be valid.
Restarting and Rebooting cOS Core with the CLI
The CLI can be used to reboot cOS Core using the command:
Device:/> shutdown
This command performs a graceful shutdown of all connections and VPN tunnels before the
restart and is sufficient for most situations that require a system restart. In includes a reloading of
the configuration (in other words, a reconfiguration operation).
47
Chapter 2: Management and Maintenance
To shutdown and restart both cOS Core and completely reinitialize the hardware, including the
cOS Core loader (equivalent to switching the hardware off then on), use the command:
Device:/> shutdown -reboot
The -reboot option is rarely needed in normal circumstances and because it requires more time
for the restart it is best not to use it. When cOS Core is upgraded the -reboot option is executed
automatically during the upgrade process.
The same restart functions can be performed with the Web Interface by selecting the option
Status > Maintenance > Reset & Restore > Restart.
Reconfiguring cOS Core with the CLI
cOS Core can be forced to reread and reload the current configuration with the command:
Device:/> reconf
Apart from reloading the configuration, many of cOS Core's internal data structures related to
rules and traffic processing are reinitialized. It is not usual to execute a reconfigure during normal
operation but it can sometimes be a way to solve transient problems related to cOS Core
memory management.
Unlike the system restart described above, a reconfiguration does not usually affect current
connections or VPN tunnels. However, with some IPsec tunnel changes, a reconfiguration will
mean the tunnels are lost and have to be re-established because the tunnel SAs are no longer
valid.
Checking Configuration Integrity
After changing a cOS Core configuration and before issuing the activate and commit commands,
it is possible to explicitly check for any problems in a configuration using the command:
Device:/> show -errors
This will cause cOS Core to scan the configuration about to be activated and list any problems. A
possible problem that might be found in this way is a reference to an IP object in the address
book that does not exist in a restored configuration backup.
Logging off from the CLI
After finishing working with the CLI, it is recommended to logout in order to avoid letting
anyone getting unauthorized access to the system. Log off by using the exit or the logout
command.
Configuring Remote Management Access on an Interface
Remote management access may need to be configured through the CLI. Suppose management
access is to be through Ethernet interface If2 which has an IP address 10.8.1.34.
Firstly, we set the values for the IPv4 address objects for If2 which already exist in the cOS Core
address book, starting with the interface IP:
Device:/> set Address IP4Address If2_ip Address=10.8.1.34
The network IP address for the interface must also be set to the appropriate value:
48
Chapter 2: Management and Maintenance
Device:/> set Address IP4Address If2_net Address=10.8.1.0/24
In this example, local IP addresses are used for illustration but these could be public IPv4
addresses instead.
Next, create a remote HTTP management access object, in this example called HTTP_If2:
Device:/> add RemoteManagement RemoteMgmtHTTP HTTP_If2
Interface=If2
Network=all-nets
LocalUserDatabase=AdminUsers
AccessLevel=Admin
HTTP=Yes
If we now activate and commit the new configuration, remote management access via the IPv4
address 10.8.1.34 is now possible using a web browser. If SSH management access is required
then a RemoteMgmtSSH object should be added.
The assumption made with the above commands is that an all-nets route exists to the ISP's
gateway. In other words, Internet access has been enabled for the Clavister Security Gateway.
Managing Management Sessions with sessionmanager
The CLI provides a command called sessionmanager for managing management sessions
themselves. The command can be used to manage all types of management sessions, including:
•
Secure Shell (SSH) CLI sessions.
•
Any CLI session through the serial console interface.
•
Secure Copy (SCP) sessions.
•
Web Interface sessions connected by HTTP or HTTPS.
•
Sessions based on the Clavister proprietary NetCon protocol.
The command without any options gives a summary of currently open sessions:
Device:/> sessionmanager
Session Manager status
---------------------Active connections
Maximum allowed connections
Local idle session timeout
NetCon idle session timeout
:
:
:
:
3
64
900
600
To see a list of all sessions use the -list option. Below is some typical output showing the local
console session:
Device:/> sessionmanager -list
User
Database
IP
-------- ---------------- --------local
<empty>
0.0.0.0
Type
Mode
------- ------local
console
Access
-------admin
If the user has full administrator privileges, they can forcibly terminate another management
session using the -disconnect option of the sessionmanager command.
The sessionmanager command options are fully documented in the CLI Reference Guide.
49
Chapter 2: Management and Maintenance
2.1.5. CLI Scripts
To allow the administrator to easily store and execute sets of CLI commands, cOS Core provides a
feature called CLI scripting. A CLI script is a predefined sequence of CLI commands which can be
executed after they are saved to a file and the file is then uploaded to the Clavister Security
Gateway.
The steps for creating a CLI script are as follows:
1.
Create a text file with a text editor containing a sequential list of CLI commands, one per
line.
The Clavister recommended convention is for these files to use the file extension .sgs
(Security Gateway Script). The filename, including the extension, should not be more than 16
characters.
2.
Upload the file to the Clavister Security Gateway using Secure Copy (SCP). Script files must
be stored in a directory under the root called /scripts. SCP uploading is discussed in detail in
Section 2.1.6, “Secure Copy”.
3.
Use the CLI command script -execute to run the script file.
The CLI script command is the tool used for script management and execution. The complete
syntax of the command is described in the CLI Reference Guide and specific examples of usage are
detailed in the following sections. See also Section 2.1.4, “The CLI” in this manual.
Note
Uploaded CLI script files are not held in permanent memory and will disappear after
system restarts.
Only Four Commands are Allowed in Scripts
The commands allowed in a script file are limited to four and these are:
• add
• set
• delete
• cc
If any other command appears in a script file, it is ignored during execution and a warning
message is output. For example, the ping command will be ignored.
Executing Scripts
As mentioned above, the script -execute command launches a named script file that has been
previously uploaded to the Clavister Security Gateway. For example, to execute the script file
my_script.sgs which has already been uploaded, the CLI command would be:
Device:/> script -execute -name=my_script.sgs
Script Variables
50
Chapter 2: Management and Maintenance
A script file can contain any number of script variables which are called:
$1, $2, $3, $4......$n
The values substituted for these variable names are specified as a list at the end of the script
-execute command line. The number n in the variable name indicates the variable value's position
in this list. $1 comes first, $2 comes second and so on.
Note: The symbol $0 is reserved
Notice that the name of the first variable is $1. The variable $0 is reserved and is always
replaced before execution by the name of the script file itself.
For example, a script called my_script.sgs is to be executed with IP address 126.12.11.01 replacing
all occurrences of $1 in the script file and the string If1 address replacing all occurrences of $2.
The file my_script.sgs contains the single CLI command line:
add IP4Address If1_ip Address=$1 Comments=$2
To run this script file after uploading, the CLI command would be:
Device:/> script -execute -name=my_script.sgs 126.12.11.01 "If1 address"
When the script file runs, the variable replacement would mean that the file becomes:
add IP4Address If1_ip Address=126.12.11.01 Comments="If1 address"
Script Validation and Command Ordering
CLI scripts are not, by default, validated. This means that the written ordering of the script does
not matter. There can be a reference to a configuration object at the beginning of a script which
is only created at the end of the script.
Although this approach might seem illogical, it is done to improve the readability of scripts. If
something always has to be created before it is referred to then this can result in confused and
disjointed script files and in large script files it is often preferable to group together related CLI
commands.
Error Handling
If an executing CLI script file encounters an error condition, the default behavior is for the script
to terminate. This behavior can be overridden by using the -force option.
For example, to run a script file called my_script2.sgs in this way so that errors do not terminate
execution, the CLI command would be:
Device:/> script -execute -name=my_script2.sgs -force
If -force is used, the script will continue to execute even if errors are returned by a command in
the script file.
Script Output
Any output from script execution will appear at the CLI console. Normally this output only
consists of any error messages that occur during execution. To see the confirmation of each
51
Chapter 2: Management and Maintenance
command completing, the -verbose option should be used:
Device:/> script -execute -name=my_script2.sgs -verbose
Saving Scripts
When a script file is uploaded to the Clavister Security Gateway, it is initially kept only in
temporary RAM memory. If cOS Core restarts then any uploaded scripts will be lost from this
volatile memory and must be uploaded again to run. To store a script between restarts, it must
explicitly be moved to non-volatile cOS Core disk memory by using the script -store command.
For example, to move my_script.sgs to non-volatile memory, the command would be:
Device:/> script -store -name=my_script.sgs
Alternatively, all scripts can be moved to non-volatile memory with the command:
Device:/> script -store -all
Removing Scripts
To remove a saved script, the script -remove command can be used. For example, to remove the
my_script.sgs script file, the command would be:
Device:/> script -remove -name=my_script.sgs
Listing Scripts
The script on its own, command without any parameters, lists all the scripts currently available
and indicates the size of each script as well as the type of memory where it resides (residence in
non-volatile memory is indicated by the word "Disk" in the Memory column).
Device:/> script
Name
-------------my_script.sgs
my_script2.sgs
Storage
-----------RAM
Disk
Size (bytes)
-------------8
10
To list the content of a specific uploaded script file, for example my_script.sgs the command
would be:
Device:/> script -show -name=my_script.sgs
Creating Scripts Automatically
When the same configuration objects needs to be copied between multiple Clavister Security
Gateways, then one way to do this with the CLI is to create a script file that creates the required
objects and then upload to and run the same script on each device.
If we already have a cOS Core installation that already has the objects configured that need to be
copied, then running the script -create command on that installation provides a way to
automatically create the required script file. This script file can then be downloaded to the local
management workstation and then uploaded to and executed on other Clavister Security
Gateways to duplicate the objects.
52
Chapter 2: Management and Maintenance
For example, suppose the requirement is to create the same set of IP4Address objects on
several Clavister Security Gateways that already exist on a single unit. The administrator would
connect to the single unit with the CLI and issue the command:
Device:/> script -create Address IP4Address -name new_script.sgs
This creates a script file called new_script_sgs which contains all the CLI commands necessary to
create all IP4Address address objects in that unit's configuration. The created file's contents
might, for example, be:
add
add
add
add
IP4Address
IP4Address
IP4Address
IP4Address
If1_ip Address=10.6.60.10
If1_net Address=10.6.60.0/24
If1_br Address=10.6.60.255
If1_dns1 Address=141.1.1.1
"
"
"
The file new_script_sgs can then be downloaded with SCP to the local management workstation
and then uploaded and executed on the other Clavister Security Gateways. The end result is that
all units will have the same IP4Address objects in their address book.
Note: Automatically created scripts omit the object category
In the created script example above, adding an IP address is done with the command:
add IP4Address...
This is instead of the usual way of qualifying the object with its category name:
add Address IP4Address...
Both are valid forms of the command. If an object type can be uniquely identified with
its name, its object category need not be specified. With automatically generated scripts,
this is always the case. This shortened form can also be used when typing the entire
command in a CLI console although tab completion will always include the object
category.
The name of the file created using the -create option cannot be greater than 16 characters in
length (including the extension) and the filetype should be .sgs.
Objects Excluded from Script Files
Certain aspects of a configuration which are hardware dependent cannot have a script file entry
created when using the -create option. This is true when the CLI node type in the script -create
command is one of:
•
•
•
•
COMPortDevice
Ethernet
EthernetDevice
Device
These node types are skipped when the script file is created and cOS Core gives the message No
objects of selected category or type.
53
Chapter 2: Management and Maintenance
Tip: Listing commands at the console
To list the created CLI commands on the console instead of saving them to a file, leave
out the option -name= in the script -create command.
Commenting Script Files
Any line in a script file that begins with the # character is treated as a comment. For example:
# The following line defines the If1 IP address
add IP4Address If1_ip Address=10.6.60.10
Scripts Running Other Scripts
It is possible for one script to run another script. For example, the script my_script.sgs could
contain the line:
script -execute -name my_script2.sgs
cOS Core allows the script file my_script2.sgs to execute another script file and so on. The
maximum depth of this script nesting is 5.
2.1.6. Secure Copy
To upload and download files to or from the Clavister Security Gateway, the secure copy (SCP)
protocol can be used. SCP is based on the SSH protocol and many freely available SCP clients
exist for almost all platforms. The command line examples below are based on the most
common command format for SCP client software.
SCP Command Format
SCP command syntax is straightforward for most console based clients. The basic command
used here is scp followed by the source and destination for the file transfer.
Upload is performed with the command:
> scp <local_filename> <destination_gateway>
Download is done with the command:
> scp <source_gateway> <local_filename>
The source or destination Clavister Security Gateway is of the form:
<user_name>@<gateway_ip_address>:<filepath>.
For example: [email protected]:config.bak. The <user_name> must be a defined cOS Core user
in the administrator user group.
Note: SCP examples do not show the password prompt
SCP will normally prompt for the user password after the command line but that prompt
54
Chapter 2: Management and Maintenance
is not shown in the examples given here.
The following table summarizes the operations that can be performed between an SCP client
and cOS Core:
File type
Upload possible
Download possible
Configuration Backup (config.bak)
Yes (also with WebUI)
Yes (also with WebUI)
System Backup (full.bak)
Yes (also with WebUI)
Yes (also with WebUI)
Firmware upgrades
Yes
No
Licenses (license.lic)
Yes (also with WebUI)
No
Certificates
Yes
No
SSH public keys
Yes
No
Web auth banner files
Yes
Yes
Web content filter banner files
Yes
Yes
cOS Core File organization
cOS Core maintains a simple 2 level directory structure which consists of the top level root and a
number of sub-directories. However, these "directories" such as sshlclientkey should be more
correctly thought of as object types. All the files stored in the cOS Core root as well as all the
object types can be displayed using the CLI command ls.
The resulting output is shown below:
Device:/> ls
HTTPALGBanners/
HTTPAuthBanners/
certificate/
config.bak
full.bak
license.lic
script/
sshclientkey/
Apart from the individual files, the objects types listed are:
•
HTTPALGBanners/ - The banner files for user authentication HTML. Uploading these is
described further in Section 6.3.4.4, “Customizing WCF HTML Pages”.
•
HTTPAuthBanner/ - The banner files for HTML ALG dynamic content filtering. Uploading these
is described further in Section 6.3.4.4, “Customizing WCF HTML Pages”.
•
certificate/ - The object type for all digital certificates.
•
script/ - The object type for all CLI scripts. Scripts are described further in Section 2.1.5, “CLI
Scripts”.
•
sshclientkey/ - The SSH client key object type.
Examples of Uploading and Downloading
In some cases, a file is located in the cOS Core root. The license file (license.lic) falls into this
category, as well as configuration backup files (config.bak) and the complete system backup files
55
Chapter 2: Management and Maintenance
(full.bak).
When uploading, these files contain a unique header which identifies what they are. cOS Core
checks this header and ensures the file is stored only in the root (all files do not have a header).
If an administrator username is admin1 and the IPv4 address of the Clavister Security Gateway is
10.5.62.11 then to upload a configuration backup, the SCP command would be:
> scp config.bak [email protected]:
To download a configuration backup to the current local directory, the command would be:
> scp [email protected]:config.bak ./
To upload a file to an object type under the root, the command is slightly different. If we have a
local CLI script file called my_script.sgs then the upload command would be:
> scp my_script.sgs [email protected]:script/
If we have the same CLI script file called my_scripts.sgs stored on the Clavister Security Gateway
then the download command would be:
> scp [email protected]:script/my_script.sgs ./
Activating Uploads
Like all configuration changes, SCP uploads only become active after the CLI commands activate
have been issued and this must be followed by commit to make the change permanent.
Uploads of firmware upgrades (packaged in .upg files) or a full system backup (full.bak) are the
exception. Both of these file types will result in an automatic system reboot. The other exception
is for script uploads which do not affect the configuration.
2.1.7. The Console Boot Menu
The Clavister firmware loader is the base software on top of which cOS Core runs and the
administrator's direct interface to this loader is called the console boot menu. This section
discusses the boot menu and also how the serial console can be used to issue cOS Core CLI
commands.
The boot menu is only accessible from the serial console located on the hardware chassis, and is
only available if cOS Core has been shutdown or not yet started and power is on to the hardware.
Initial Menu without a Password Set
After powering up the Clavister Security Gateway, there is a five second interval before cOS Core
starts up, and in that time the message Press any key to abort and load boot menu is displayed on
the console. If any console key is pressed during these 5 seconds then cOS Core startup pauses
and the following menu is displayed:
•
Start System
This initiates the startup of cOS Core.
•
Display Latest Shutdown Message
This shows the last console message shown before system shutdown.
56
Chapter 2: Management and Maintenance
•
Display Latest Crash Dump Message
This shows the latest crash dump message caused by a cOS Core problem.
•
Reset Options
This displays a sub-menu of reset options which are described below.
•
Enable Console Password
Set a password for console access. Until a password is set, anyone can utilize the console so
selecting this option is recommended. The console will prompt for a password and ask for
confirmation.
The console password can be any sequence of characters but must be no greater than 64
characters in length. It is recommended to use only printable characters.
Options after Setting a Password
After a password is set with the Enable Console Password step above, the following menu
options are displayed (and this menu will be displayed after a successful logon):
•
Start System
This initiates the startup of cOS Core.
•
Display Latest Shutdown Message
This shows the last console message shown before system shutdown.
•
Display Latest Crash Dump Message
This shows the latest crash dump message caused by a cOS Core problem.
•
Reset Options
This displays a sub-menu of reset options which are described below.
•
Change Console Password
This option allows the administrator to change the current password for console access and it
is recommended this is set as soon as possible. If it is not set, anyone can gain access to the
local console port to reconfigure cOS Core.
Note: The console password is just for console access
The console password is just used for console access and is not related to the
username/password combinations used for login through other management
interfaces, such as the Web Interface. The console password is used only with a console
connected directly to the local RS232 port and no username is associated with it.
Initial Menu with a Password Set
Once a password is set by the administrator, the initial menu that is displayed on interrupting
startup will become altered so that it contains the following options:
•
Login
•
Start System
This initiates the startup of cOS Core.
•
Display Latest Shutdown Message
This shows the last console message shown before system shutdown.
57
Chapter 2: Management and Maintenance
•
Display Latest Crash Dump Message
This shows the latest crash dump message caused by a cOS Core problem.
The Reset Menu
The Reset Options menu offers the following choices:
•
Reset to Factory Defaults
This option will restore the hardware to its initial factory state. The operations performed if
this option is selected are the following:
i.
Remove the cOS Core configuration files. This includes all certificates as well as HA and
DHCP lease settings.
ii.
Reset the loader settings.
iii.
Remove console security so there is no console password.
iv.
Restore default cOS Core and loader executables. If the hardware was delivered with
CorePlus 8.nn preinstalled then the Web Interface will no longer function and the
separate Clavister migration wizard executable will have to be run to upgrade to a cOS
Core 10.nn version.
If the hardware came preinstalled with a CorePlus 9.nn version then the reset will
reinstate this version and an upgrade to cOS Core 10 is achieved by installing the desired
10.nn version. Configuration conversion will take place automatically on initial system
startup.
v.
The license will NOT be removed.
•
Reset to Base Configuration
This will only reset the configuration to be the original, default cOS Core configuration file.
Other options, such as console security, will not be affected.
•
Transfer System
This option is for software only installations running on non-Clavister hardware. It makes it
possible to transfer (or copy) an image of the complete cOS Core system to another portable
media, such as a USB stick. Booting can then be done using this media on another computer
so that the cOS Core system can be installed there on local disk with another "Transfer
System" operation.
•
Return to main menu - Go back to the previous, main menu.
Note: A reset does not delete all files from memory
Resetting to factory defaults will not delete any auxiliary files that have been created in
the Clavister Security Gateway memory. For example, any files created by the
pcapdump command will not be deleted. Files related to Anti-Virus or IDP will also not
be deleted.
If any of these undeleted files need to be deleted then this must be done explicitly
through the appropriate CLI command.
Using the Console for CLI Commands
cOS Core will start up either because the initial start up sequence wasn't interrupted to enter the
58
Chapter 2: Management and Maintenance
boot menu or because start up was commenced from the boot menu. Once cOS Core is up and
running, the serial console can also be used to enter any CLI command in the same way that a
SSH client can.
If a console password has been set and a login has not yet been performed then cOS Core will
prompt for the console password before CLI commands can be entered and it is therefore
recommended the console password is enabled as soon as possible in order to prevent
unauthorized access.
Note: Output buffer limitations
The only limitation with issuing CLI commands through the serial console is that there is
a finite buffer allocated for output. This buffer limit means that a large volume of
console output may be truncated. This happens rarely and usually only with data
dumps from certain diagnostic commands. In such cases it is better to issue the
commands using an SSH client instead.
2.1.8. Management Advanced Settings
Under the Remote Management section of the Web Interface or InControl a number of
advanced settings can be found. These are:
SSH Before Rules
Enable SSH traffic to the security gateway regardless of configured IP Rules.
Default: Enabled
WebUI Before Rules
Enable HTTP(S) traffic to the security gateway regardless of configured IP Rules.
Default: Enabled
Local Console Timeout
Number of seconds of inactivity until the local console user is automatically logged out.
Default: 900
NetCon Idle Timeout
Number of seconds of inactivity until the Netcon session is close.
Default: 600
NetCon Before Rules
For NetCon traffic to cOS Core: add an invisible rule to the IP rule set to allow Netcon traffic. If this
setting is disabled then NetCon traffic will be subject to the IP rule set like any other traffic.
Default: Enabled
59
Chapter 2: Management and Maintenance
NetConMaxChannels
For NetCon traffic to cOS Core the following number of connections are guaranteed for each
connection type:
•
Consoles: 4
•
Realtime loggers: 4
•
Stat pollers: 4
•
Receive contexts: 2
•
Send contexts: 4
NetConMaxChannels is the maximum total allowed for all these connection types. This means
that with the default value of 18, 2 extra connections are allowed and they can be of any of the
above types.
Default: 18
Validation Timeout
Specifies the amount of seconds to wait for the administrator to log in before reverting to the
previous configuration.
Default: 30
WebUI HTTP port
Specifies the HTTP port for the Web Interface.
Default: 80
WebUI HTTPS port
Specifies the HTTP(S) port for the Web Interface.
Default: 443
HTTPS Certificate
Specifies which certificate to use for HTTPS traffic. Only RSA certificates are supported.
Default: HTTPS
2.1.9. Working with Configurations
Configuration Objects
The system configuration is built up by Configuration Objects, where each object represents a
configurable item of any kind. Examples of configuration objects are routing table entries,
address book entries, service definitions, IP rules and so on. Each configuration object has a
number of properties that constitute the values of the object.
60
Chapter 2: Management and Maintenance
Object Types
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.
Object Organization
In the Web 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 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.4. 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.
Command-Line Interface
Device:/> show Service
A list of all services will be displayed, grouped by their respective type.
InControl
Follow the same steps used for the Web Interface below.
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 display
61
Chapter 2: Management and Maintenance
a menu which gives the option to edit or delete the object as well as modify the order of the
objects.
Example 2.5. Displaying a Configuration Object
The simplest operation on a configuration object is 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.
Command-Line Interface
Device:/> show Service ServiceTCPUDP telnet
Property
----------------Name:
DestinationPorts:
Type:
SourcePorts:
SYNRelay:
PassICMPReturn:
ALG:
MaxSessions:
Comments:
Value
------telnet
23
TCP
0-65535
No
No
<empty>
1000
Telnet
The Property column lists the names of all properties in the ServiceTCPUDP class and the Value
column lists the corresponding property values.
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Objects > Services
2.
Select the telnet entry in the list
3.
A web page displaying the telnet service will be presented
Example 2.6. Editing a Configuration Object
When the behavior of cOS Core is changed, it is most likely necessary to modify one or several
configuration objects. This example shows how to edit the Comments property of the telnet
service.
Command-Line Interface
Device:/> set Service ServiceTCPUDP telnet Comments="Modified Comment"
Show the object again to verify the new property value:
Device:/> show Service ServiceTCPUDP telnet
Property
----------------Name:
Value
------telnet
62
Chapter 2: Management and Maintenance
DestinationPorts:
Type:
SourcePorts:
SYNRelay:
PassICMPReturn:
ALG:
MaxSessions:
Comments:
23
TCP
0-65535
No
No
<empty>
1000
Modified Comment
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Objects > Services
2.
Select the telnet entry in the list
3.
In the Comments textbox, a suitable comment
4.
Click OK
Verify that the new comment has been updated in the list.
Important: Configuration changes must be activated
Changes to a configuration object will not be applied to a running system until the new
cOS Core configuration is activated.
Example 2.7. Adding a Configuration Object
This example shows how to add a new IP4Address object, here creating the IPv4 address
192.168.10.10, to the address book.
Command-Line Interface
Device:/> add Address IP4Address myhost Address=192.168.10.10
Show the new object:
Device:/> show Address IP4Address myhost
Property
--------------------Name:
Address:
UserAuthGroups:
NoDefinedCredentials:
Comments:
Value
------------myhost
192.168.10.10
<empty>
No
<empty>
InControl
Follow the same steps used for the Web Interface below.
63
Chapter 2: Management and Maintenance
Web Interface
1.
Go to: Objects > Address Book
2.
Click on the Add button
3.
In the dropdown menu displayed, select IP 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.8. Deleting a Configuration Object
This example shows how to delete the newly added IP4Address object.
Command-Line Interface
Device:/> delete Address IP4Address myhost
InControl
Follow the same steps used for the Web Interface below.
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.9. 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.
Command-Line Interface
Device:/> undelete Address IP4Address myhost
InControl
Follow the same steps used for the Web Interface below.
64
Chapter 2: Management and Maintenance
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.10. Listing Modified Configuration Objects
This example shows how to list configuration objects that have been modified.
Command-Line Interface
Device:/> show -changes
*
Type
------------IP4Address
ServiceTCPUDP
Object
-----myhost
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 cOS Core will attempt to initialize affected subsystems
with the new configuration data.
Important: Committing IPsec Changes
The administrator should be aware that if any changes that affect 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, cOS Core will wait for a short period (30 seconds by default)
during which a connection to the administrator must be re-established. If a lost connection could
not be re-established then cOS Core will revert to using the previous configuration. This is a
fail-safe mechanism and, amongst others things, can help prevent a remote administrator from
65
Chapter 2: Management and Maintenance
locking themselves out.
Example 2.11. Activating and Committing a Configuration
This example shows how to activate and commit a new configuration.
Command-Line Interface
Device:/> activate
The system will validate and start using the new configuration. When the command prompt is
shown again:
Device:/> commit
The new configuration is now committed.
InControl
Activating and committing changes with InControl is done in a different way to the Web
Interface
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 cOS Core as confirmation that remote
management is still working. The new configuration is then automatically committed.
Note: Changes must be committed
The configuration must be committed before changes are saved. All changes to a
configuration can be ignored simply by not committing a changed configuration.
Configuration Revision Numbers
Every time a new configuration version is created and activated, a configuration revision number
is allocated to the version. This number has two parts and is of the form nn:mm.
The first part of the number, nn, is incremented every time a new configuration is activated
through a non-InControl interface such as the Web Interface or CLI. The second part of the
number, mm, is incremented every time a new configuration is activated through a InControl
client. In the Web Interface, only the first part is displayed as the Configuration number in the start
page.
66
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 cOS Core. Logging
enables not only monitoring of system status and health, but also allows auditing of network
usage and assists in trouble-shooting.
Log Message Generation
cOS Core defines a large number of different log 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.
Log events are always generated for various aspects of cOS Core processing such as buffer usage,
DHCP clients, High Availability and IPsec. The generation of events for other cOS Core
subsystems such as DHCP Relay, DHCP Servers and IP Rules can be enabled as needed.
Whenever an event message is generated, it can be filtered and distributed to a variety of Event
Receivers, including Syslog and SNMP Trap receivers. Up to eight event receivers can be defined
per Clavister Security Gateway, with each receiver having its own customizable event filter.
2.2.2. Log Messages
Event Types
cOS Core defines several hundred events for which log 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 example, 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.
Message Format
All event messages have a common format, with attributes that include category, severity and
recommended actions. These attributes enable easy filtering of messages, either within cOS Core
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 cOS Core Log Reference Guide. That guide also
describes the design of event messages, the meaning of severity levels and the various attributes
available.
Event Severity
The default severity of each log event is predefined and it can be, in order of highest to lowest
severity, one of:
67
Chapter 2: Management and Maintenance
•
•
•
•
•
•
•
•
Emergency
Alert
Critical
Error
Warning
Notice
Info
Debug
By default, cOS Core sends all messages of level Info and above to any configured log servers but
the level for sending can be changed by the administrator. The Debug severity is intended for
system troubleshooting only and should only be used if required. All log event messages of all
severity levels are listed in the separate cOS Core Log Reference Guide.
Event Message Timestamping
When a log messages are sent by cOS Core to external log receivers, they are always
timestamped with time expressed as UTC/GMT (Greenwich Mean Time). This means that it is easy
to compare events from a network consisting of many security gateways spread over different
time zones.
The exception to this is log messages displayed through Memlog which are always stamped with
the current system time.
2.2.3. Creating Log Receivers
To distribute and log the event messages generated by cOS Core, it is necessary to define one or
more event receivers that specify what events to capture, and where to send them.
cOS Core can distribute event messages to different types of receivers and these are enabled by
creating any of the following Log Receiver objects.
•
MemoryLogReceiver
cOS Core has its own logging mechanism also known as the MemLog. This retains all event
log messages in memory and allows direct viewing of recent log messages through the Web
Interface.
This is enabled by default but can be disabled.
This receiver type is discussed further below in Section 2.2.4, “Logging to MemoryLogReceiver”.
•
Syslog Receiver
Syslog is the de-facto standard for logging events from network devices. If other network
devices are already logging to Syslog servers, using syslog with cOS Core messages can
simplify overall administration.
This receiver type is discussed further below in Section 2.2.5, “Logging to Syslog Hosts”.
•
FWLog
The Clavister proprietary format for logging event messages, the FWLog format has a high
level of detail and is suitable for analyzing large amounts of log data.
This receiver type is discussed further below in Section 2.2.6, “Logging to the Clavister Logger”.
•
SNMP Traps
68
Chapter 2: Management and Maintenance
An SNMP2c Event Receiver can be defined to collect SNMP Trap log messages. These receivers
are typically used to collect and respond to critical alerts from network devices.
This receiver type is discussed further below in Section 2.2.8, “SNMP Traps”.
2.2.4. Logging to MemoryLogReceiver
The MemoryLogReceiver (also known as Memlog) is an optional cOS Core feature that allows
logging direct to memory in the Clavister Security Gateway instead of sending messages to an
external server. These messages can be examined through the standard user interfaces.
Memory for Logging is Limited
Memlog memory available for new messages is limited to a fixed predetermined size. When the
allocated memory is filled up with log messages, the oldest messages are discarded to make
room for newer incoming messages. This means that MemLog holds a limited number of
messages since the last system initialization and once the buffer fills they will only be the most
recent. This means that when cOS Core is creating large numbers of messages in systems with,
for example, large numbers of VPN tunnels, the Memlog information becomes less meaningful
since it reflects a limited recent time period.
Memlog Timestamps
The timestamp shown is Memlog console output is always the local system time of the security
gateway. This is different from the timestamp on log messages sent to defined Log Receiver
objects which are always timestamped with GMT time.
Disabling Memory Logging
The MemoryLogReceiver object exists by default in cOS Core. If this receiver is not required then it
can be deleted and this type of logging will be switched off.
2.2.5. Logging to Syslog Hosts
Overview
Syslog is a standardized protocol for sending log data although there is no standardized format
for the log messages themselves. The format used by cOS Core 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
similar. 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.
Message Format
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.
69
Chapter 2: Management and Maintenance
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, cOS Core 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 and Severity fields
The Prio= field in SysLog messages contains the same information as the Severity field
for Clavister Logger messages. However, the ordering of the numbering is reversed.
Example 2.12. 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:
Command-Line Interface
Device:/> add LogReceiverSyslog my_syslog IPAddress=195.11.22.55
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: System > Device > Log and Event Receivers > Add > Syslog Receiver
2.
Specify a suitable name for the event receiver, for example 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.
Note: Syslog server configuration
The syslog server may have to be configured to receive log messages from cOS Core.
Please see the documentation for specific Syslog servers in order to correctly configure it.
2.2.6. Logging to the Clavister Logger
The Clavister Logger is a proprietary Clavister logging product that uses the proprietary Clavister
70
Chapter 2: Management and Maintenance
FWLog message format for sending and storing log data. This logger is also referred to as the
FWLog Receiver.
For backwards compatibility, cOS Core versions older than 8.90 support output to this logger but
the software itself is not included with the distribution packet since analysis of logger output is
only possible through older versions of cOS Core.
Example 2.13. Enabling Logging to Clavister Loggers
To enable logging of all events with a severity greater than or equal to Notice to the Clavister
Logger (FWLog Receiver) with IP address 195.11.22.55 listening on port 999 (the default), follow
the steps below:
Command-Line Interface
Device:/> add LogReceiver LogReceiverFWLog my_fwlog
IPAddress=195.11.22.55
Port=999
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: System > Device > Log and Event Receivers > Add > InControl Log Receiver
(FWLog)
2.
Specify a suitable name for the event receiver, for example my_fwlog
3.
Enter 195.11.22.55 as the IP Address
4.
Click OK
The system will now be logging all events with a severity greater than or equal to Notice to the
Clavister FWLogger at 195.11.22.55.
2.2.7. Severity Filter and Message Exceptions
For each log receiver it is possible to impose rules on what log message categories and severities
are sent to that receiver. It is also possible to lower or raise the severity of specific events.
The Severity Filter
The Severity Filter is a means of specifying what severities, if any, are sent to the receiver. By
default, all log messages except Debug are sent. This can be restricted further so, for example,
only Emergency, Alert and Critical messages are sent.
Log Message Exceptions
After the severity filter is applied, any Log Message Exceptions are applied to generated messages.
There can be more than one message exception for a log receiver and each consists of the
following:
71
Chapter 2: Management and Maintenance
•
Category and ID
This specifies the log messages that will be affected by the exception. If the ID number of the
log message is not specified then all log messages for the specified category will be included.
The ID of specific log messages can be found in the Log Reference Guide.
•
Type
This can be one the following:
i.
Exclude - This will exclude the specified log message(s) even if they are allowed by the
severity filter.
ii.
Include - This will include the specified log message(s) even if they are excluded by the
severity filter.
In addition, the Severity of the included message(s) can be specified. If this is set to
Default the original severity is used. Otherwise, the severity is set to the specified value.
This provides the ability to raise (or lower) the severity of specific log messages.
2.2.8. 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 cOS Core
cOS Core 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 are considered significant in the operation of a network.
The file Clavister-TRAP.MIB which is included under the SNMP directory in the cOS Core
distribution, defines the SNMP objects and data types that are used to describe an SNMP Trap
received from cOS Core.
There is one generic trap object called OSGenericTrap, that is used for all traps. This object
includes the following parameters:
•
System - The system generating the trap
•
Severity - Severity of the message
•
Category - What cOS Core subsystem is reporting the problem
•
ID - Unique identification within the category
•
Description - A short textual description
•
Action - What action is cOS Core taking
This information can be cross-referenced to the Log Reference Guide.
72
Chapter 2: Management and Maintenance
Note: SNMP Trap standards
cOS Core sends SNMP Traps which are based on the SNMPv2c standard as defined by
RFC1901, RFC1905 and RFC1906.
Example 2.14. 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:
Command-Line Interface
Device:/> add LogReceiver EventReceiverSNMP2c my_snmp
IPAddress=195.11.22.55
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Log & Event Receivers > Add > SNMP2cEventReceiver
2.
Specify a name for the event receiver, for example 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.
2.2.9. Advanced Log Settings
The following advanced settings for cOS Core event logging are available to the administrator:
Send Limit
This setting specifies the maximum log messages that cOS Core will send per second. This value
should never be set too low as this may result in important events not being logged, and it
should it be set too high. When the maximum is exceeded, the excess messages are dropped and
are not buffered.
The administrator must make a case by case judgement about the message load that log servers
can deal with. This can often depend on the server hardware platform being used and if the
resources of the platform are being shared with other tasks.
Default: 2000
73
Chapter 2: Management and Maintenance
Alarm Repeat Interval
The delay in seconds between alarms when a continuous alarm is used. As discussed in
Section 2.4.5, “Hardware Monitoring”, the log event messages generated by hardware monitoring
are continuous and this setting should be used to limit the frequency of those messages.
Minimum 0, Maximum 10,000.
Default: 60 (one minute)
74
Chapter 2: Management and Maintenance
2.3. RADIUS Accounting
2.3.1. Overview
The Central Database Approach
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 such dedicated servers
contains all user credentials as well as details of connections. This 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 central database approach and is used
by cOS Core to implement user accounting.
RADIUS Architecture
The RADIUS protocol is based on a client/server architecture. The Clavister Security Gateway acts
as the client of the RADIUS server, creating and sending requests to a dedicated server(s). In
RADIUS terminology the security gateway 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" reply to the requesting
client.
With the RFC 2866 standard, RADIUS was extended to handle the delivery of accounting
information and this is the standard followed by cOS Core for user accounting. In this way, all the
benefits of centralized servers are thus extended to user connection accounting.
The usage of RADIUS for cOS Core authentication is discussed in Section 8.2, “Authentication
Setup”.
2.3.2. RADIUS Accounting Messages
Message Generation
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
Clavister Security Gateway, cOS Core 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 cOS
Core, 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 cOS Core 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
75
Chapter 2: Management and Maintenance
Parameters included in START messages sent by cOS Core are:
•
Type - Marks this AccountingRequest as signalling the beginning of the service (START).
•
ID - A unique random 7 character string 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 Clavister Security Gateway.
•
NAS Port - The port of the NAS on which the user was authenticated (this is a physical
interface 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
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 1st January, 1970. Used to set a timestamp when
this packet was sent from cOS Core.
STOP Message Parameters
Parameters included in STOP messages sent by cOS Core are:
•
Type - Marks this accounting request as signalling the end of a session (STOP).
•
ID - An identifier matching a previously sent AccountingRequest packet, with
Acct-Status-Type set to START.
•
User Name - The user name of the authenticated user.
•
NAS IP Address - The IP address of the Clavister Security Gateway.
•
NAS Port - The port on the NAS on which the user was authenticated. (This is a physical
interface 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.
76
Chapter 2: Management and Maintenance
•
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 Clavister Security Gateway.
In addition, two more attributes may be 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.
Tip: The meaning of the asterisk after a list entry
The asterisk (*) symbol after an entry in the list above indicates that the sending of the
parameter is optional and is configurable.
2.3.3. Interim Accounting Messages
In addition to START and STOP messages cOS Core can optionally periodically send Interim
Accounting Messages to update the accounting server with the current status of an authenticated
user.
Messages are Snapshots
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 accounting request STOP
message, except that the Acct-Terminate-Cause is not included (as the user has not disconnected
yet).
Message Frequency
The frequency of interim accounting messages can be specified either on the authentication
server or in cOS Core. Switching on the setting in cOS Core will override the setting on the
accounting server.
2.3.4. Configuring RADIUS Accounting
In order to activate RADIUS accounting a number of steps must be followed:
•
The RADIUS server must be defined in cOS Core.
•
A user authentication object must have a rule associated with it where a RADIUS server is
specified.
77
Chapter 2: Management and Maintenance
•
The external RADIUS server itself must be correctly configured.
Important: The RADIUS Vendor ID must be set to 5089
When configuring the external RADIUS server to communicate with cOS Core, it is
necessary to enter a value for the Vendor ID (vid). This value should be specified as
5089.
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 cOS Core to deal with the event when the
primary server is unreachable.
Example 2.15. RADIUS Accounting Server Setup
This example shows configuring of cOS Core with a local RADIUS server called my-accounting
using IP address 192.168.03.01 and port 1813. Assume the shared secret is 231562514098273.
Command-Line Interface
Device:/> add RadiusAccounting my-accounting
IPAddress=192.168.03.01
SharedSecret=231562514098273
Port=1813
RetryTimeout=2
RoutingTable=main
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Policies > User Authentication > RADIUS > Add > RADIUS Server
2.
Now enter:
•
Name: my-accounting
•
IP Address: 192.168.03.01
•
Port: 1813
•
Retry Timeout: 2
•
Shared Secret: 231562514098273
•
Confirm Secret: 231562514098273
78
Chapter 2: Management and Maintenance
•
3.
Routing Table: main
Click OK
2.3.5. RADIUS Accounting Security
Communication between cOS Core 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 cOS Core 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 synchronized between the active and passive
Clavister Security Gateways. This means that accounting information is automatically updated on
both cluster members whenever a connection is closed.
Special Accounting Events
Two special accounting events are also used by the active unit to keep the passive unit
synchronized:
•
An AccountingStart event is sent to the inactive member in an HA setup whenever a
response has been received from the accounting server. This specifies that accounting
information should be stored for a specific authenticated user.
•
A 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 RADIUS Servers
It can happen that a RADIUS client sends an AccountingRequest START packet which a RADIUS
server never replies to. If this happens, cOS Core will re-send the request after the user-specified
number of seconds. This will mean, however, that a user will still have authenticated access while
cOS Core is trying to contact to the accounting server.
Three Connection Attempts are Made
Only after cOS Core has made three attempts to reach the server will it conclude that the
accounting server is unreachable. The administrator can use the cOS Core advanced setting
Allow on error to determine how this situation is handled.
79
Chapter 2: Management and Maintenance
If the Allow on error setting is enabled, an already authenticated user's session will be
unaffected. If it is not enabled, any affected 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 Clavister Security Gateway administrator issues a shutdown command while
authenticated users are still online, the AccountingRequest STOP packet will potentially never be
sent. To avoid this, the advanced setting Logout at shutdown allows the administrator to
explicitly specify that cOS Core 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 cOS Core is based on the user's IP address. Problems can
therefore occur with users who have the same IP address.
This can happen, for example, 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 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.
cOS Core RADIUS Accounting will therefore gather statistics for all the users on the network
together as though they were one user instead of individuals.
2.3.10. Advanced RADIUS Settings
The following advanced settings are available with RADIUS accounting:
Allow on error
If there is no response from a configured RADIUS accounting server when sending accounting
data for a user that has already been authenticated, then enabling this setting means that the
user will continue to be logged in.
Disabling the setting will mean that the user will be logged out if the RADIUS accounting server
cannot be reached even though the user has been previously authenticated.
Default: Enabled
Logout at shutdown
If there is an orderly shutdown of the Clavister Security Gateway by the administrator, then cOS
Core will delay the shutdown until it has sent RADIUS accounting STOP messages to any
configured RADIUS server.
If this option is not enabled, cOS Core will shutdown even though there may be RADIUS
accounting sessions that have not been correctly terminated. This could lead to the situation
that the RADIUS server will assume users are still logged in even though their sessions have been
terminated.
Default: Enabled
80
Chapter 2: Management and Maintenance
Maximum Radius Contexts
The maximum number of contexts allowed with RADIUS. This applies to RADIUS use with both
accounting and authentication.
Default: 1024
81
Chapter 2: Management and Maintenance
2.4. Monitoring
The real-time performance of cOS Core can be monitored in a number of ways. They are:
•
Using the real-time monitoring functionality in InControl.
•
cOS Core real-time monitor alerts.
•
The cOS Core link monitor.
•
Monitoring through an SNMP client.
•
Hardware monitoring for specific hardware models.
2.4.1. Real-time Monitoring Counters
cOS Core status and operational statistics are available to InControl for graphical display in a
variety of display formats. This is achieved by InControl routinely polling cOS Core to gather the
latest values of operational parameters. The following counters are available through this
feature:
Throughput Statistics
CPU – The percentage load on the gateway CPU.
Forwarded bps - The number of bits forwarded through the gateway per second.
Forwarded pps - The number of packets forwarded through the gateway per second.
Buf use – Percentage of gateway packet buffers used.
Conns – The number of connections opened via Allow or NAT rules. No connections are opened
for traffic allowed via FwdFast rules; such traffic is not included in this statistic.
Timers – The amount of timers used by the system.
Total mem usage – Percentage of the RAM memory that is currently being used.
Connection Rate Statistics
Conns opened per sec – The number of connections opened per second.
Conns closed per sec – The number of connections closed per second.
State Engine Statistics
ICMP Connections - Total number of ICMP connections.
UDP Connections - Total Number of UDP connections.
OPEN TCP - Total number of open TCP connections.
82
Chapter 2: Management and Maintenance
TCP SYN - Total number of TCP connections in the SYN phase.
TCP FIN - Total number of TCP connections in the FIN phase.
Other - Total number of other connections types such as IPsec.
TCP Buffer Statistics
Total small receive window usage - The number of small TCP receive windows currently being
used.
Total large receive window usage - The number of large TCP receive windows currently being
used.
Total small send window usage - The number of small TCP send windows currently being used.
Total large send window usage - The number of large TCP send windows currently being used.
Rule Usage Statistics
Each of the rules in a rule set has a counter associated with it which has the same name as the
rule type. These counters indicates the number of matches that have taken place for each rule.
The rule sets that exist are:
•
IP Rules
•
PBR Rules
•
DHCP Rules
•
User-authentication rules
Interface/VLAN/VPN Statistics
Rx/Tx Ring counters - Some drivers support plotting of FIFO-errors, saturation, flooding and
other values depending on the driver.
Pps counters – The number of packets received, sent and summed together.
Bbs – The number of bits received, sent and summed together.
Drops – The number of packets received by this interface that were dropped due to rule set
decisions or failed packet consistency checks.
IP errors – The number of packets received by this interface that were mutilated so badly that
they would have had difficulty passing through a router to reach to the Clavister Security
Gateway. They are therefore unlikely to be the result of an attack.
Send Fails – The number of packets that could not be sent, either due to internal resource
starvation caused by heavy loading or hardware problems or congested half-duplex
connections.
83
Chapter 2: Management and Maintenance
Frags received – The number of IP packet fragments received by this interface.
Frag reass – The number of complete packets successfully reassembled from the fragments
received.
Frag reass fail – The number of packets that could not be reassembled, either due to resource
starvation, illegal fragmentation, or just packet loss.
Active SAs - Current active number of SAs in use (VPN only).
Pipe Statistics
Total Pipe Statistics
Num users – The current number of users, as defined by the grouping settings of each pipe,
being tracked in the pipes system. Note that this value corresponds to the number of users active
in each time slice of 1/20th of a second, and not to the number of users having "open"
connections.
Per Pipe Statistics
Num Users - The current number of users as above but on a per pipe basis.
Current bps – The current throughput of the pipe, in bits per second, per precedence and as a
sum of all precedences.
Current pps – The current throughput of the pipe, in packets per second, per precedence and as
a sum of all precedences.
Reserved bps – The current bandwidth allocated to each precedence; lower precedences are
not allowed to use this bandwidth. Note that there is no reserved bandwidth for precedence 0,
as it is simply given what is left of the total limit after all higher precedence reservations are
subtracted.
Dyn limit bps – The current bandwidth limit applied to the respective precedences. This is
related to the Reserved bps statistic, but is usually higher, as it shows how much bandwidth is left
after higher precedence reservations have been subtracted from the total limit.
Delayed Packets – The number of times packets have been delayed as a result of a pipe,
precedence, or pipe user having used up its allotted bandwidth. Note that one single packet may
be delayed several times; if a pipe is really full, this count may exceed the number of packets
actually passing through the pipe.
Dropped Packets – The number of packets dropped. Packets are dropped when cOS Core is
running out of packet buffers. This occurs when excessive amounts of packets need to be
queued for later delivery. The packet dropped is always the one that has been queued the
longest time globally, which means that the connection suffering from packet loss will be the
one most overloading the system .
Dyn User Limit bps – The current bandwidth limit per user of the pipe. If dynamic bandwidth
balancing is enabled, this value may be lower than the configured per-user limits.
DHCP Server Statistics
Total Rejected requests – Total number of rejected packets (all rules).
84
Chapter 2: Management and Maintenance
Per Rule Statistics
Usage – Number of used IPs in the pool.
Usage (%) – Above value calculated as a percentage.
Active Clients – Number of currently active clients (BOUND).
Active Clients (%) – Above value calculated as a percentage.
Reject requests – Number of rejected requests.
Total number of leases – Total number of leases in the pool.
DHCP Relay Statistics
Total active relayed clients - Number of active relays in the Clavister Security Gateway.
Ongoing transactions - DHCP transactions in the gateway.
Total rejected - Number of packets rejected by the DHCPRelay.
Active relayed clients - Number of active relays that uses this specific rule.
Rejected packets per rule - Number of packets rejected from clients using this rule.
General ALG Statistics
Total ALG sessions - Total number of ALG sessions.
Total connections - Total number of connections.
Total TCP Streams - Total number of TCP streams.
HTTP ALG, Web Content Filtering and Antivirus Statistics
Total requests - Total number of requests.
Total allowed - Total number allowed.
Total blocked - Total number of blocks.
URLs requested - Requests per URL category.
URLs allowed - Allowed requests per URL category.
URLs rejected - Rejected requests per URL category.
SMTP ALG DNSBL Statistics
Total Sessions Checked - Total number of URLs checked.
85
Chapter 2: Management and Maintenance
Total Sessions Spam - Total number of URLs found to be Spam.
Total Sessions Dropped - Total number of sessions dropped.
SMTP ALG DNSBL Server Statistics
For each DNSBL server:
Total Sessions Checked - Total number of URLs checked by server.
Total Sessions Matched - Total number of URLs found to be Spam by server.
Total Failed Checks - Total number of checks where no response was received.
User Authentication Statistics
PPP – Number of PPP authenticated users.
HTTPAuth – Number of HTTP authenticated users.
Secure HTTP – Number of secure HTTP authenticated users.
XAUTH – Number of XAUTH authenticated users.
Link Monitor Statistics
PPP – Number of PPP authenticated users.
Packets lost/sec – Number of packets lost per second in polling.
Short Term Loss – % of short term packet loss.
Hosts Up – % of hosts available.
Packet Reassembly Statistics
Input Drops – Number of packet drops on input.
Load Factor – Loading of reassembly subsystem.
Allowed Buffers – Allowed buffers per connection.
IP Pools Statistics
Prepared – Number of prepared IP addresses.
Free – Number of addresses free.
Used – Number of addresses used.
86
Chapter 2: Management and Maintenance
Misses – Number of requests not met.
High Availability Statistics
Interface Queue – Size of the queue used for the sync interface.
Queue Usage Packets – Amount of the queue used in packets.
Queue Usage Bytes – Amount of the queue used in bytes.
Packets Sent – Number of packets sent on Sync.
Resent Packets – Number of packets resent on Sync.
2.4.2. Real-time Monitor Alerts
A number of cOS Core statistical values can graphically monitored through the Real-time
Monitoring feature. Real-time Monitor Alert thresholds can be specified in cOS Core for any of
these monitored values so that they can have a maximum and/or a minimum numerical
threshold.
Should a specified maximum or minimum threshold be crossed, cOS Core will automatically
generate a log message which will be sent to all configured log receivers. All such log messages
belong to the REALTIMEMONITOR message category which has the identity number 54.
The log message identity will therefore take the form 054XXXXX where XXXXX represents the
position of the statistic generating the event in the list of alert rules. A log message with identity
05400003, for example, identifies the third rule in the rule list.
Monitor Alert Rules
Each Monitor Alert Rule consists of the following fields:
Name
User assigned name for the rule.
Sample time
The interval in seconds between checking the statistic.
Low threshold
The lower threshold (if specified).
High threshold
A higher threshold (if specified).
Continuous
This determines if an event is also generated when the threshold is
crossed in the other direction. In other words, the statistic moves back to
within acceptable limits. This field can be Yes or No.
Backoff
The minimum number of seconds between consecutive Monitor Threshold
Rule log messages. This value can be useful in preventing a flood of log
messages when a statistic is repeatedly passing a threshold and then
receding from it again.
2.4.3. The Link Monitor
Overview
87
Chapter 2: Management and Maintenance
The Link Monitor is a cOS Core feature that allows monitoring of the connectivity to one or more
IP addresses external to the Clavister Security Gateway. This monitoring is done using standard
ICMP "Ping" requests and allows cOS Core to assess the availability of the network pathways to
these IP addresses. The administrator can select one of a number of actions to occur should a
pathway appear to be broken for some reason.
Link Monitor Actions
If sufficient replies are not received to link monitor polling, cOS Core makes the assumption that
the common link to those IP address is down and can then initiate one of 3 configurable actions:
•
A cOS Core reconfigure.
•
A High Availability (HA) cluster failover.
•
An HA cluster failover followed by a cOS Core reconfigure.
The Link Monitor Reconfigure is Different
The reconfigure that can be triggered by the link monitor has one special aspect to it. The link
monitor reconfigure has the additional action of restarting all interfaces. This means that if there
is a problem related to a particular Ethernet NIC, perhaps due to overload, then this can be
cleared by interface initialization. This results in only a momentary delay in throughput while the
reconfigure takes place.
Link Monitor Uses
The Link Monitor is useful in two distinct scenarios:
•
An external device develops an occasional problem with its link to the Clavister Security
Gateway and the physical link needs to be renegotiated. Such problems can occur sometimes
with some older equipment such as ADSL Modems. For this scenario action 1. Reconfigure
should be selected.
A reconfigure means that the cOS Core configuration will be reloaded. All connections and
states are saved but reloading means all traffic is suspended for a short period and all
interface links to external devices are renegotiated.
•
In an HA cluster setup, the link from the master to the external Internet (or other part of a
network) can be continually monitored so that should the link fail, the slave will take over
(assuming that the slave has a different physical connection to the monitored address). The
action chosen for HA should be either 2. Failover or 3. Failover and reconfigure.
If the first action option 1. Reconfigure is chosen in an HA cluster, then the reconfigure will
also cause a failover since it will temporarily suspend the master's operation while the
reconfigure takes place and the slave will take over when it detects this inactivity. If
reconfiguration with failover is desirable it is better to select the option 3. Failover and
reconfigure since this performs the failover first and is nearly instantaneous with almost no
traffic interruption. Reconfiguration first is slower and results in some traffic interruption.
To preserve all tunnels in a VPN scenario, it is best to choose the 2. Failover option since a
reconfiguration can cause some tunnels to be lost.
Link Monitoring with HA Clusters
The most common use for link monitoring is in the HA cluster scenario described above. It is
88
Chapter 2: Management and Maintenance
important that the master and slave do not duplicate the same condition that triggered the link
monitor. For example, if a particular router connected to the master Clavister Security Gateway
was being "pinged" by link monitoring, the slave should not also be connected to that router. If it
is, the continued triggering of a reconfiguration by the link monitor will then cause the slave to
failover back to the master, which will then failover back to the slave again and so on.
If it is important to not allow a failover during reconfiguration of the active unit in an HA cluster
then the advanced setting Reconf Failover Time should be set to a value which is neither too
low or too high.
Reconf Failover Time controls how long the inactive unit will wait for the active unit to
reconfigure before taking over. Setting this value too low will mean the inactive unit does not
wait long enough. Setting the value too high could mean significant downtime if the active unit
fails during reconfiguration and the inactive unit needs to take over.
More information on clusters can be found in Chapter 11, High Availability.
IPsec Tunnels and HA Clusters
If the triggered link monitor action is a failover or failover and reconfigure, any IPsec tunnels are
automatically closed and the tunnel SAs deleted at both ends. After the failover takes place the
following will occur:
•
If the IPsec tunnel was a LAN-to-LAN tunnel, it will be automatically re-established provided
traffic flows within the keepalive time specified for the tunnel.
•
Any IPsec tunnels from external clients will be lost and will not be re-established
automatically. The client must initiate a new connection.
Link Monitoring Parameters
The Link Monitor takes the following parameters:
Action
Specifies which of the 3 actions described above cOS Core
should take.
Addresses
Specifies a group of hosts to monitor. If at least half of them
do not respond, cOS Core assumes that there is a link
problem. A host's responses are ignored until cOS Core has
been able to reach it at least once. This means that an
unreachable host can be responsible for triggering an
action once but not twice.
A group of three hosts where one has been unreachable
since the last configuration will therefore be treated as a
two-host group until the third host becomes reachable.
This also means that if a link problem triggers an action and
the problem is not solved, cOS Core will not attempt to
repeat the same action until the problem is solved and the
hosts are again reachable.
Maximum Loss
A single host is considered unreachable if this number of
consecutive ping responses to that host are not replied to.
Grace Period
Do not allow the link monitor to trigger an action for this
number of seconds after the last reconfiguration. This
avoids false positives during initial link negotiation. The
default value is 45 seconds.
89
Chapter 2: Management and Maintenance
Send from Shared IP Address
This option only appears in an HA cluster and should be
used if individual public IPv4 addresses are not available to
the devices in a cluster.
2.4.4. 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.
cOS Core supports SNMP version 1 and version 2. Connection can be made by any SNMP
compliant clients to devices running cOS Core. However, only query operations are permitted for
security reasons. Specifically, cOS Core 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 cOS Core MIB
The Management Information Base (MIB) is a database, usually in the form of a text file, which
defines the parameters on a network device that an SNMP client can query or change. The MIB
file for a device running cOS Core is distributed with the standard cOS Core distribution pack as a
file with the name CLAVISTER-MIB.
This MIB file 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 SNMP client runs, the MIB file is read
and tells the client which values can be queried on a cOS Core device.
Each entry in the MIB includes a textual explanation of what the value is and a complete list is not
reproduced in this guide. A typical MIB file entry for the total number of packets transmitted by
an interface appears as follows:
clvIfPktsTotCnt OBJECT-TYPE
SYNTAX
Counter32
MAX-ACCESS read-only
STATUS
current
DESCRIPTION
"Total number of packets transmited by the interface"
::= { clvIfStatsEntry 10 }
Defining SNMP Access
SNMP access is defined through the definition of a cOS Core Remote object with a Mode value of
SNMP. The Remote object requires the entry of:
•
Interface - The cOS Core 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.
90
Chapter 2: Management and Maintenance
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 should
therefore be constructed in the same way as any other password, using combinations of upper
and lower case letters along with digits.
Enabling an IP Rule for SNMP
The advanced setting SNMP Before Rules 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 SNMP access. Port 161 is usually used for SNMP and cOS Core 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 SNMP Request Limit restricts the number of SNMP requests allowed per
second. This can help prevent attacks through SNMP overload.
Example 2.16. 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, there is no need for it to communicate
via a VPN tunnel.
Command-Line Interface
Device:/> add RemoteManagement RemoteMgmtSNMP my_snmp
Interface=lan
Network=mgmt-net
SNMPGetCommunity=Mg1RQqR
Should it be necessary to enable SNMP Before Rules (which is enabled by default) then the
command is:
Device:/> set Settings RemoteMgmtSettings SNMPBeforeRules=Yes
InControl
Follow the same steps used for the Web Interface below.
91
Chapter 2: Management and Maintenance
Web Interface
1.
Go to: System > Device > Remote Management > Add > SNMP management
2.
For Remote access type enter:
3.
4.
•
Name: a suitable name, for example snmp_access
•
Community: Mg1RQqR
For Access Filter enter:
•
Interface: lan
•
Network: mgmt-net
Click OK
Should it be necessary to enable SNMP Before Rules (which is enabled by default) then the
setting can be found in System > Device > Remote Management > Advanced Settings.
SNMP Advanced Settings
The following SNMP advanced settings can be found under the Remote Management section in
the Web Interface or InControl. They can also be set through the CLI.
SNMP Before RulesLimit
Enable SNMP traffic to the security gateway regardless of configured IP Rules.
Default: Enabled
SNMP Request Limit
Maximum number of SNMP requests that will be processed each second by cOS Core. Should
SNMP requests exceed this rate then the excess requests will be ignored by cOS Core.
Default: 100
System Contact
The contact person for the managed node.
Default: N/A
System Name
The name for the managed node.
Default: N/A
System Location
92
Chapter 2: Management and Maintenance
The physical location of the node.
Default: N/A
Interface Description (SNMP)
What to display in the SNMP MIB-II ifDescr variables.
Default: Name
Interface Alias
What to display in the SNMP ifMIB ifAlias variables.
Default: Hardware
2.4.5. Hardware Monitoring
Feature Availability
Certain Clavister hardware models allow the administrator to use the CLI to query the current
value of various hardware operational parameters such as the current temperature inside the
security gateway. This feature is referred to as Hardware Monitoring.
Caution: Do NOT use this feature with non-Clavister hardware
Hardware monitoring is NOT supported on non-Clavister hardware. Using the HWM
command by mistake on non-Clavister hardware could cause cOS Core to cease
executing and a hardware restart may be required to resolve the problem.
Configuring and performing hardware monitoring can be done either through the CLI or
through the Web Interface.
Enabling Hardware Monitoring
The System > Device > Hardware Monitoring section of the Web Interface provides the
administrator with the following settings for enabling hardware monitoring when it is available:
Enable Sensors
Enable/disable all hardware monitoring functionality.
Default: Disabled
Poll Interval
Polling interval for the Hardware Monitor which is the delay in milliseconds between readings of
hardware monitor values. Minimum value: 100, Maximum value: 10000.
Default: 500
Using the hwm CLI Command
93
Chapter 2: Management and Maintenance
To get a list current values from all available sensors, the following command can be used:
Device:/> hwm -all
This can be abbreviated to:
Device:/> hwm -a
Some typical output from this command for two temperature sensors is shown below:
Device:/> hwm -a
Name
Current value (unit)
---------------------------------SYS Temp
=
44.000 (C)
(x)
CPU Temp
=
41.500 (C)
(x)
Note
The "(x)" on the left side of the sensor listing indicates that the sensor is enabled.
The -verbose option displays the current values plus the configured ranges. Some typical output
from this command is shown below:
Device:/> hwm -a -v
4 sensors available
Poll interval time = 500ms
Name [type][number] = low_limit] current_value [high_limit (unit)
----------------------------------------------------------------SYS Temp
[TEMP ][ 0] =
44.000]
45.000 [ 0.000 (C)
CPU Temp
[TEMP ][ 1] =
42.000]
42.500 [ 0.000 (C)
AUX Temp
[TEMP ][ 2] =
41.000]
43.000 [ 0.000 (C)
CPU Fan1
[FANRPM][ 1] = 6125.000] 6250.000 [ 0.000 (RPM)
Time to probe sensors: 2.980000e-05 seconds
Each physical attribute listed on the left is given a minimum and maximum range within which it
should operate. When the value returned after polling falls outside this range, cOS Core
automatically generates an HWM log message that is sent to the configured log servers. If an
SNMP trap receiver is one of the receivers configured, an SNMP trap is sent.
The temperature sensor names should be interpreted as follows:
•
The SYS temperature should be used as an indication of the overall temperature inside the
entire hardware unit.
•
The CPU temperature relates specifically to the unit's central processor which can be lower
than the overall temperature due to the method of cooling.
•
The AUX sensor is found in some other arbitrary location and should be used as an
alternative indication of the overall temperature. Hotspots can cause variations between this
and the SYS temperature.
Note: Sensors can differ depending on hardware type
Each hardware model can have a different set of sensors in different locations and with
different operating ranges. The above output example and its values are for illustration
only.
94
Chapter 2: Management and Maintenance
Setting the Minimum and Maximum Range
The minimum and maximum values shown in the output from the hwm command are set
through the Web Interface by going to System > Device > Hardware Monitoring > Add and
selecting the hardware parameter to monitor. The desired operating range can then be specified.
A sensor is identified in the Web Interface by specifying a unique combination of the following
parameters:
•
Type
This is the type of sensor shown in the CLI output above and is presented as a list of choices in
the Web Interface. For example, Temp.
•
Sensor
This is the number of the sensor as shown in the CLI output above. For example, the SYS Temp
number is 0.
•
Name
This is the Name of the sensor as shown in the CLI output above. For example, SYS Temp.
•
Enabled
An individual sensor can be enabled or disabled used this setting. When enabled, an "(x)" is
displayed next to the sensor in the output from the hwm command.
Controlling the Event Sending Frequency
The maximum frequency of log event generation when hardware monitoring values fall outside
their preset range can be limited using the AlarmRepeatInterval setting in the LogSettings object.
This setting is used because the monitored values are continuous.
For example, to change the interval from the default of 60 seconds to a new value of 900
seconds, use the CLI command:
Device:/> set Settings LogSettings AlarmRepeatInterval=900
This means that a new event message must now wait for 900 seconds after the previous one has
been sent.
All the options for LogSettings can be found in Section 2.2.9, “Advanced Log Settings”.
Sensors for Clavister Products
The following are the available sensors for the current range of Clavister hardware products.
Note that the Eagle E7 product does not provide any monitoring support.
•
Lynx X8
Sensor Name
Sensor Type
Sensor Number
Minimum Limit
Maximum Limit
CPUTemp
Temp
0
0
65
SysTemp
Temp
1
65
65
•
Wolf W3
95
Chapter 2: Management and Maintenance
Sensor Name
Sensor Type
Sensor Number
Minimum Limit
CPUFan1
FanRPM
6
4000
CPUFan2
FanRPM
5
4000
CPUFan3
FanRPM
7
4000
PSUFan
FanRPM
4
4000
SysTemp1
Temp
2
70
SysTemp2
Temp
3
70
CpuTemp
Temp
256
PSU
GPIO
256
1
Sensor Name
Sensor Type
Sensor Number
Minimum Limit
Right_CPUFan1
FanRPM
2
4000
Right_CPUFan2
FanRPM
1
4000
Right_CPUFan1
FanRPM
3
4000
Right_PSUFan
FanRPM
0
4000
Left_CPUFan1
FanRPM
6
4000
Left_CPUFan2
FanRPM
5
4000
Left_CPUFan3
FanRPM
7
4000
Left_PSUFan
FanRPM
4
4000
SysTemp1
Temp
2
70
SysTemp2
Temp
3
70
CpuTemp
Temp
256
Right_PSU
GPIO
256
1
Left_PSU
GPIO
257
1
•
Maximum Limit
80
Wolf W5
Maximum Limit
80
The W5 product can be fitted with dual redundant power supply units (PSUs). When this is the
case, the PSU sensors can take the following values:
•
0 - No PSU inserted.
•
1 - PSU inserted, not powered up.
•
2 - PSU inserted, powered up.
2.4.6. Memory Monitoring Settings
The System > Device > Hardware Monitoring section of the Web Interface or InControl
provides the administrator with a number of settings related to the monitoring of available
memory. These are:
Memory Poll Interval
Memory polling interval which is the delay in minutes between readings of memory values.
Minimum 1, Maximum 200.
Default: 15 minutes
Memory Use Percentage
96
Chapter 2: Management and Maintenance
True if the memory monitor uses a percentage as the unit for monitoring, False if megabytes are
used. Applies to Alert Level, Critical Level and Warning Level.
Default: True
Memory Log Repetition
Should we send a log message for each poll result that is in the Alert, Critical or Warning level, or
should we only send when a new level is reached. If True, a message is sent each time Memory
Poll Interval is triggered. If False, a message is sent when a value goes from one level to another.
Default: False
Alert Level
Generate an Alert log message if free memory is below this number of bytes. Disable by setting
to 0. Maximum value is 10,000.
Default: 0
Critical Level
Generate a Critical log message if free memory is below this number of bytes. Disable by setting
to 0. Maximum value is 10,000.
Default: 0
Warning Level
Generate a Warning log message if free memory is below this number of bytes. Disable by
setting to 0. Maximum value 10,000.
Default: 0
97
Chapter 2: Management and Maintenance
2.5. Diagnostic Tools
2.5.1. Overview
In the case of a serious system problem cOS Core provides some tools to aid in identifying the
cause. These are:
•
Diagnostic CLI commands
•
The pcapdump CLI command
Both of these provide output which can be sent to support staff at Clavister to help identify the
circumstances that led to the problem in question.
2.5.2. Diagnostic CLI Commands
The stat CLI Command
If a serious cOS Core problem is suspected then the first step should be to use the CLI command:
Device:/> stat
The stat command will indicate the date and time of the last system shutdown and can indicate if
there has been a serious error in cOS Core operation. It should be remembered however that the
buffer which stat uses is cleared by certain operations such as reconfigure and the output will not
therefore show what occurred prior to buffer clearance.
The dconsole CLI Command
The next step is to use the CLI command:
Device:/> dconsole
This can be abbreviated to:
Device:/> dcon
The dconsole command provides a list of important events that have occurred during cOS Core
operation and can help to establish the date, time and nature of events leading up to a serious
problem occurring. The output might look similar like the following:
Showing diagnose entries since 2008-05-22:
2008-06-21 11:54:58
Start (10.11.02-0:131)
2008-06-21 11:56:16
Stop (RECONFIGURE)
2008-06-21 11:56:21
Start (10.11.02-0:131)
2008-06-21 11:57:29
Stop (RECONFIGURE)
2008-06-21 11:59:31
Start (10.11.02-0:131)
2008-06-21 11:59:49
Stop (NORMAL)
"
"
Output from dconsole can include a dump of the system memory in the case of serious runtime
errors. Such a dump will look similar to the following:
'
'
Reason: Exception 'DataAbort' occurred at address 0x7aaea34
98
Chapter 2: Management and Maintenance
Generation date/time: 2008-07-04 14:23:56 List of loaded PE-modules:
fwloader(1.07.04): BA:0x00100000, EP:0x00101028, SS:0x0, IS:0xe7000
fwcore(810.11.02-2336): BA:0x07761038, EP:0x0007c630 Register dump:
---------------------------------------------------r0 : 0xe1a0003c, r1 : 0x07c685dc, r2 : 0x00000004, r3 : 0x50013700,
r4 : 0x06cb2d04, r5 : 0x0753a740, r6 : 0x050ce1f8, r7 : 0x00000000,
r8 : 0x0753a79c, r9 : 0x050ce1f8, r10: 0x00000000, r11: 0x0775ff34,
r12: 0x00000004, sp : 0x0775fcec, lr : 0x079de7e4 Stack dump:
5da89306 c33613f4 c330cfc5 04411507 45515a49 86619f8b c0db0a81
4e395861 cb25b796 e3108934 932766c5 4dcff9e9 711c3463 b9cd5d1e
52149961 9324dea3 d340dc25 15458610 63582ded 689a0c54 dfb43131
02c7d971 a0ebb72c bfaae832 db216923 08ba693b 95e4de97 98d121a2
'
'
Although dconsole output may be difficult to interpret by the administrator, it can be emailed to
Clavister support representatives for further investigation.
The dconsole command supersedes the crashdump command found in earlier versions of cOS
Core.
2.5.3. The pcapdump CLI Command
A valuable diagnostic tool is the ability to examine the packets that enter and leave the
interfaces of a Clavister Security Gateway. For this purpose, cOS Core provides the CLI command
pcapdump which not only allows the examination of packet streams entering and leaving
interfaces but also allows the filtering of these streams according to specified criteria.
The packets that are filtered out by pcapdump can then be saved in a file of type .cap which is the
defacto libpcap library file format standard for packet capture.
The complete syntax of the pcapdump CLI command is described in the CLI Reference Guide.
A Simple Example
An example of pcapdump usage is the following sequence:
Device:/>
Device:/>
Device:/>
Device:/>
Device:/>
pcapdump
pcapdump
pcapdump
pcapdump
pcapdump
-size 1024 -start lan
-stop lan
-show
-write lan -filename=cap_lan.cap
-cleanup
Going through this line by line we have:
1. Recording is started for the lan interface using a buffer size of 1024 Kbytes.
Device:/> pcapdump -size 1024 -start lan
2. The recording is stopped for the lan interface.
Device:/> pcapdump -stop lan
3. The dump output is displayed on the console in a summarized form.
Device:/> pcapdump -show
4. The same information is written in its complete form to a file called cap_lan.cap.
Device:/> pcapdump -write lan -filename=cap_lan.cap
99
Chapter 2: Management and Maintenance
At this point, the file cap_lan.cap should be downloaded to the management workstation for
analysis.
5. A final cleanup is performed and all memory taken is released.
Device:/> pcapdump -cleanup
Re-using Capture Files
Since the only way to delete files from the Clavister Security Gateway is through the serial
console, the recommendation is to always use the same filename when using the pcapdump
-write option. Each new write operation will then overwrite the old file.
Running on Multiple Interfaces
It is possible to have multiple pcapdump executions being performed at the same time. The
following points describe this feature:
1.
All capture from all executions goes to the same memory buffer.
The command can be launched multiple times with different interfaces specified. In this
case the packet flow for the different executions will be grouped together in different
sections of the report.
If a clearer picture of packets flowing between interfaces is required in the output then it is
best to issue one pcapdump command with the interfaces of interest specified.
2.
If no interface is specified then the capture is done on all interfaces.
3.
The -stop option without an interface specified will halt capture on all interfaces.
4.
pcapdump prevents capture running more than once on the same interface by detecting
command duplication.
Filter Expressions
Seeing all packets passing through a particular interface often provides an excess of information
to be useful. To focus on particular types of traffic the pcapdump command has the option to add
a filter expression which has one of the following forms:
-eth=<macaddr> - Filter on source or destination MAC address.
-ethsrc=<macaddr> - Filter on source MAC address.
-ethdest=<macaddr> - Filter on destination MAC address.
-ip=<ipaddr> - Filter source or destination IP address.
-ipsrc=<ipaddr> - Filter on source IP address.
-ipdest=<ipaddr> - Filter on destination IP address.
-port=<portnum> - Filter on source or destination port number.
-srcport=<portnum> - Filter on source port number.
-destport=<portnum> - Filter on destination port number.
-proto=<id> - Filter on protocol where id is the decimal protocol id.
-<protocolname> - Instead of using -proto=, the protocol name alone can be specified and can be
one of -tcp, -udp or -icmp.
Downloading the Output File
As shown in one of the examples above, the -write option of pcapdump can save buffered packet
100
Chapter 2: Management and Maintenance
information to a file on the Clavister Security Gateway.
These output files are placed into the cOS Core root directory and the file name is specified in the
pcapdump command line, usually with a filetype of .cap. The name of output files must follow
certain rules which are described below. Files can be downloaded to the local workstation using
Secure Copy (SCP) (see Section 2.1.6, “Secure Copy”). A list of all files in the cOS Core root directory
can be viewed by issuing the ls CLI command.
The -cleanup option will erase the files so cleanup should only be done after file download is
complete.
Output File Naming Restrictions
The name of the file used for pcapdump output must comply with the following rules:
•
Excluding the filename extension, the name may not exceed 8 characters in length.
•
The filename extension cannot exceed 3 characters in length.
•
The filename and extension can only contain the characters A-Z, 0-9, "-" and "_".
Combining Filters
It is possible to use several of these filter expressions together in order to further refine the
packets that are of interest. For example we might want to examine the packets going to a
particular destination port at a particular destination IP address.
Compatibility with Wireshark
The open source tool Wireshark (formerly called Ethereal) is an extremely useful analysis tool for
examining logs of captured packets. The industry standard .pcap file format used by pcapdump
with its -write option means that it is compatible with Wireshark.
For more complete information about this topic, see http://www.wireshark.org.
2.5.4. Hardware Fault Troubleshooting
It may be the case that operational problems are caused by a problem with the hardware
platform and not cOS Core. For this reason, the CLI command selftest is provided to perform tests
on various aspects of hardware functioning.
Warning: Do NOT conduct tests with live traffic!
It is important to remember that the selftest command should not be used on a system
that is carrying live traffic. The command can cause connections and associated data to
be lost.
A Simple Example
A simple use of selftest is to test the system memory:
Device:/> selftest -memory
This writes a one megabyte block of data to memory and reads it back. The number of
101
Chapter 2: Management and Maintenance
megabytes written can be varied using the -num= option. By default, the memory test is
repeated once but could, for example, be repeated 10 times with the command:
Device:/> selftest -memory -num=10
The -burnin Option
If the -burnin option is used, a set of tests, known as the test subset, is repeated continuously for a
period of time. The default test period is two hours and the default subset is -memory, -ping,
-throughput, -traffic and -cryptoaccel.
The duration of the -burnin test can be changed, as can the test subset. For example, a test of the
memory and media that is repeated for 30 minutes would be:
Device:/> selftest -burnin -minutes=30 -memory -media
The -burnin option could, for example, be used to detect errors that only occur sporadically or
possibly only occur after some hardware component has reached a certain critical operating
temperature.
The full list of options for selftest CLI command can be found in the CLI Reference Guide along with
more command line examples.
102
Chapter 2: Management and Maintenance
2.6. Maintenance
2.6.1. Software Upgrades
Clavister Security Gateways are driven and controlled by cOS Core and this consists of two major
components: the cOS Core Core and the cOS Core Loader. Usually it is the cOS Core Core which is
the main concern of the administrator since this is the executable binary of cOS Core and
contains all its principal components. The Loader, as described below, is a low level firmware
loader used by the Core that is updated only with some major revisions of cOS Core.
Figure 2.1. cOS Core Firmware Structure
2.6.1.1. The Core Executable
Whenever new functionality is added to cOS Core, or when defects have been found and
corrected, a new Core is produced which is the cOS Core executable binary. The new Core is
packaged as a single file which is digitally signed and made available for download from the
Clavister web site https://www.clavister.com.
In the distribution of software upgrades, a Core file name will indicate that it is either a x86
version designed for most hardware models or the file name will indicate a specific hardware
model. If there is a Core file with a filename related to a specific hardware model then use that
file for an upgrade. If no hardware specific version is available, use the version with x86 in the
filename.
Important: Some Core files are hardware model specific
The cOS Core Core executable file for some Clavister hardware models are specific to
these hardware models and such a model specific file will have a filename which
includes the model number. Only use the model specific files for upgrading if they exist.
The Types of Upgrade
There are different types of cOS Core upgrades:
•
Minor Upgrades
103
Chapter 2: Management and Maintenance
These involve bug fixes and minor feature enhancements. They are freely available to all
customers who are licensed to run the base version involved in the upgrade. The last two
digits in the version number will change for this type of upgrade. For example, version
10.15.01 might become version 10.15.02.
•
Major Upgrades
These involve the addition of major new functionality to cOS Core. They are available to
customers who have a valid software subscription service contract. The middle two digits of
the version number will change for this type of upgrade. For example, version 10.15.nn might
become version 10.20.nn.
•
CorePlus 9.nn to cOS Core 10.nn Upgrades
The upgrade from a CorePlus 9.nn to a 10.nn cOS Core version does not require any special
steps. After the 10.nn version is loaded and started for the first time, the existing CorePlus
configuration will be automatically converted by into the required cOS Core internal format.
•
CorePlus 8.nn to cOS Core 10.nn Upgrades
Upgrading a CorePlus 8.nn version to a cOS Core 10.nn version is done using the Migration
Wizard which is available as a separate Windows executable. It is done in the same way as
upgrading from CorePlus 8.nn to CorePlus 9.nn except the upgrade file chosen in the wizard
should be for the target 10.nn version. This wizard is fully described in the separate Migration
Guide document which is included with cOS Core distributions and is available from the
Clavister website.
An alternative to running the Migration Wizard software is to perform the upgrade from
within the InControl client. This is recommended if InControl is the principle management
interface used by the administrator.
The Upgrade Procedure
Upgrading to a new version of cOS Core is a simple procedure. A cOS Core upgrade is packaged
as a single file with filetype .upg and this can be downloaded from the Clavister website. This file
is then uploaded to the Clavister Security Gateway by using either of the following two methods:
•
Go to: Status > Maintenance > Upgrade in the Web Interface. Then choose the option
Upgrade Unit's Firmware to select and upload the correct .upg file.
•
Upload the file using Secure Copy (SCP). When cOS Core receives the file, it recognizes what
the purpose of the file is.
When the upload of a .upg file is complete, the Clavister Security Gateway will initiate a full
system restart. Any live traffic will therefore be interrupted and connections lost while this takes
place.
It can be advisable to make a full system backup before performing a system upgrade. If there is
a requirement to wind back the upgrade, the system backup file can be uploaded as it contains
both the original configuration and the original pre-upgrade version of cOS Core.
Upgrades Under VMware
104
Chapter 2: Management and Maintenance
When running cOS Core under a VMware server, upgrades of cOS Core can be done just as they
are done on a single physical computer. It is not necessary to create a new virtual machine for a
new version.
Checking the Dynamic High Buffers Setting
Make sure that the advanced setting Dynamic High Buffers is enabled after an upgrade. This
setting ensures that sufficient memory is allocated for handling connections.
This setting requires a hardware restart for a new value to take effect. A reconfiguration is not
sufficient. This can be achieved using the CLI command:
Device:/> shutdown
Where cOS Core is handling tens of thousands of simultaneous connections then it may be
necessary to manually set a value above the automatic value. However, if the HighBuffers value is
set too high this may impact throughput latency.
New Release Notifications
Clavister maintains an RSS feed of announcements that can be subscribed to at:
https://forums.clavister.com/rss-feeds/announcements/.
It is recommended to subscribe to this feed in order to receive notifications when new releases
of cOS Core versions are available for download and installation. Alternatively, announcements
can be read directly from the Clavister forums which can be found at:
https://forums.clavister.com/.
2.6.2. Auto-Update Mechanism
A number of the cOS Core 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 Clavister maintains a global infrastructure of servers
providing update services for Clavister Security Gateways. To ensure availability and low
response times, cOS Core 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, Update Subscriptions
2.6.3. Backing Up Configurations
The administrator has the ability to take a snapshot of a cOS Core system at a given point in time
and restore it when necessary. The snapshot can be of two types:
•
A Configuration Backup
105
Chapter 2: Management and Maintenance
This is the entire current cOS Core configuration saved into a single file. It does not include
the installed cOS Core version. This is useful when restoring only the configuration.
It is important to create, at the minimum, a configuration backup on a regular basis so that a
configuration can be easily recreated in the event of hardware replacement. The alternative is
to recreate a configuration by manually adding its contents, piece by piece.
•
A System Backup
This a complete backup of both the configuration and the installed cOS Core software saved
into a single file. This is useful if restoring both the configuration and the cOS Core version
upgraded.
A complete system backup is a much larger file than a configuration backup and can be
many megabytes, it is therefore not recommended to perform this on a regular basis because
of the time involved. However, it is recommended to create this at least once when the
Clavister Security Gateway is initially configured and goes live. This is because it a full system
backup makes it easier to restore the current configuration on new hardware.
Warning: Do not upload a system backup to dissimilar hardware
Do not try to upload a full system backup (configuration plus cOS Core) to hardware
that is not the same model as the original.
This will cause the configuration to be automatically activated and cOS Core rebooted,
with the possibility that cOS Core becomes unreachable. Upload of full system backups
must be done to similar hardware since there is no opportunity to change the
configuration before it is activated.
Version Compatibility
Since a full system backup includes a cOS Core version, compatibility is not an issue with these
types of backup.
With configuration only backups, the following should be noted:
•
A configuration backup created on a higher cOS Core version should never be uploaded to a
lower cOS Core version. For example, a backup created from a 10.00.00 version should never
be uploaded to a 9.30.02 version.
•
A configuration backup created on a lower version can be uploaded to a higher version,
however there can be compatibility issues in certain cases which will be indicated by
messages from cOS Core when the uploaded configuration is activated. Such problems can
result in a cOS Core reboot.
For this reason, a full system backup is useful when trying to transfer a saved configuration to
new hardware where the new hardware comes preloaded with a higher cOS Core version.
First, upload the full system backup to get a system with the right version and then upload
the latest configuration backup. If there is a requirement to move to a higher cOS Core
version, an cOS Core upgrade can then be performed.
The Management Interfaces Used
Both types of backup, configuration and system, can be performed either by downloading the
file directly from the Clavister Security Gateway using SCP (Secure Copy) or alternatively using
106
Chapter 2: Management and Maintenance
the Web Interface. Backup cannot be done using CLI commands.
Similarly, restoring a backup is done in the reverse fashion. Either by uploading the backup file
using SCP or alternatively through the Web Interface. A restore cannot be done with CLI
commands.
Operation Interruption
Backups can be created at any time without disturbing cOS Core operation. For restores,
however, it is not recommended to have live traffic flowing since the restored configuration may
significantly alter the security policies of the security gateway.
After restoring a backup it is necessary to Activate the new configuration, as is done with a
normal configuration change.
A complete system restore will require that cOS Core reinitializes, with the loss of all existing
connections. Initialization may require some seconds to complete depending on the hardware
type and normal operation will not be possible during this time.
Backup and Restore using SCP
There are two files located in the cOS Core root directory:
•
config.bak - This is the backup of the current configuration.
•
full.bak - This is the backup of the complete system.
SCP can be used to download either of these files. When the download is complete the filename
will be altered to include the date. For example, full.bak might become full-20081121.bak to show
it is a snapshot of the state on November 21st, 2008.
To restore a backup file, the administrator should upload the file to the Clavister Security
Gateway. The name of the file does not need to be changed in any way and can retain the date
since cOS Core will read a header in the file to determine what it is.
Backup and Restore using the Web Interface
As an alternative to using SCP, the administrator can initiate a backup or restore of the
configuration or complete system directly through the Web Interface. The example below
illustrates how this is done.
Example 2.17. Performing a Complete System Backup
In this example we will backup the entire system.
InControl
Backing up the system with InControl is done in a different way to the Web Interface
Web Interface
1.
Go to: Status > Maintenance > Backup and Restore > Backup System
2.
A file dialog is shown - choose a directory for the created file and change the filename from
the default if desired.
107
Chapter 2: Management and Maintenance
3.
Download of the backup file will then start
Note: Backups do not contain everything
Backups include only static information from the cOS Core configuration. Dynamic
information such as the DHCP server lease database or Anti-Virus/IDP databases will not
be backed up.
2.6.4. Restore 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 Clavister Security Gateway was shipped by Clavister. When a restore
is applied, data such as the IDP and Anti-Virus databases as well as pcapdump files are not
deleted. These must be explicitly removed by using the appropriate command.
Example 2.18. Complete Hardware Reset to Factory Defaults
Command-Line Interface
Device:/> reset -unit
InControl
This operation cannot be performed with InControl.
Web Interface
1.
Go to: Status > Maintenance > Reset & Restore > Reset
2.
Select Restore the entire unit to factory defaults then confirm and wait for the restore to
complete.
Important: Any upgrades will be lost after a factory reset
It should be understood that a reset to factory defaults is exactly that. Any cOS Core
upgrades performed since the unit left the factory will be lost.
Reset via the Console Boot Menu
Connect the serial cable and connect with a console using a terminal emulator software product.
The HyperTerminal application shipped with some Microsoft PCs can be used for this purpose.
Restart the Clavister Security Gateway and press a key when the "Press any key to abort and load
boot menu" message appears at the console. When the console boot menu appears, select the
hardware reset option, then confirm and wait for the process to complete. Using the console
boot menu is fully described in Section 2.1.7, “The Console Boot Menu”.
108
Chapter 2: Management and Maintenance
Warning: Do NOT abort a reset to defaults
If the process of resetting to factory defaults is aborted before it finishes, the Clavister
Security Gateway can then cease to function properly with the complete loss of all
stored user data.
The IP Address of Non-management Interfaces
Except for the default management interface, a reset operation will also reset the IPv4 address of
all other Ethernet interfaces to be 127.0.x.1 in the network 127.0.x.0/24. The value "x" is a number
that starts with "1" and increases by one for each consecutive interface, skipping the
management interface.
The IPv4 address 127.0.0.1 is not used since this is reserved for the loopback interface.
End of Life Procedures
The restore to factory defaults option should also be used as part of the end of life procedure
when a Clavister Security Gateway is taken out of operation and will no longer be used. As part of
the decommissioning procedure, a restore to factory defaults should always be run in order to
remove all sensitive information such as VPN settings.
Note: Original CorePlus 8.nn systems need two resets
If an upgrade from a CorePlus 8.nn version has been done previously on Clavister
hardware that was delivered with 8.nn, the restore to factory defaults operation must be
done twice since the first time will only return the device to the state it was in before the
upgrade.
As a further precaution at the end of the product's life, it also recommended that the memory
media in a Clavister Security Gateway is destroyed and certified as destroyed by a suitable
provider of computer disposal services.
2.6.5. Listing and Adding Ethernet Interfaces
The CLI command pciscan is a tool that is used in listing and upgrading the Ethernet ports for the
Clavister Security Gateway. It is usually relevant only for non-Clavister hardware although it can
be used for examining the PCI hardware in Clavister devices.
Checking Ethernet Interfaces
If the pciscan command is used without parameters then a list of all the supported Ethernet
interfaces in the Clavister Security Gateway is obtained:
Device:/> pciscan
Idx
012
013
020
021
022
"
"
VendorID
0x8086
0x8086
0x8086
0x8086
0x8086
DeviceID Bus
0x1010
2
0x1010
2
0x1012
5
0x1012
5
0x1012
6
Slot
4
4
4
4
4
IRQ Driver
0 "E1000"
1 "E1000"
0 "E1000"
1 "E1000"
0 "E1000"
109
Info
Intel
Intel
Intel
Intel
Intel
NETWORK
NETWORK
NETWORK
NETWORK
NETWORK
-
ETHERNET
ETHERNET
ETHERNET
ETHERNET
ETHERNET
Chapter 2: Management and Maintenance
Each line in the output shows the current configuration for each Ethernet interface.
To see all Ethernet interfaces on the Clavister Security Gateway, regardless if they are supported
or not, the relevant command is:
Device:/> pciscan -ethernet
To see all hardware on the PCI bus, both Ethernet and non-Ethernet, the command is:
Device:/> pciscan -all
Automatic Reconfiguration
If a new Ethernet interface is added to the Clavister Security Gateway, this can be detected and
the configuration updated automatically with the command:
Device:/> pciscan -cfgupdate
Forcing the Choice of Driver
When using non-Clavister hardware, there may be PCI cards installed that require a driver that
cannot be automatically selected using the -cfgupdate option. In such a case the administrator
can explicitly choose the driver from a list using the -force_driver option.
The index number of the PCI card is first identified from the output of the pciscan -all command.
If the card number index is found to be 7 and the driver to choose is E1000 then the command is:
Device:/> pciscan -force_driver 7 E1000
The command offers tab completion for the available driver names so it is not necessary to know
them in advance. It may be the case that a process of trial and error is required to identify the
correct driver for the card.
110
Chapter 2: Management and Maintenance
2.7. Licensing
Overview
To use cOS Core in a live environment, a cOS Core license file must be installed. A unique license
file is needed for each processor on which cOS Core runs.
The purpose of a license is to define what the capabilities and limitations a cOS Core installation
has. Such capabilities include parameters such as the number of VPN tunnels allowed and the
maximum number of routing tables.
For details about license pricing and purchase, contact a local Clavister sales office
Demonstration Mode
Without correct licensing, cOS Core will only operate for 2 hours from start up in demonstration
mode. After 2 hours, cOS Core will cease to function and will output a time expiry message to the
local console.
cOS Core must be restarted to enable it for a further 2 hour period and there is no limit on how
many times this can be done. The 2 hours allows a reasonable time for product evaluation. To
remove the limit, a valid license must be installed.
License Files
A cOS Core license consists of a single license file with filetype .lic. This is a text file that defines all
the cOS Core capabilities allowed by the license plus a digital signature to ensure the file cannot
be altered. License files can be opened and read in a normal text editor.
Installing a License
There are three methods for installing a license:
1.
Manually through the Web Interface or SCP
This consists of the following steps:
i.
In a web browser, go to the Clavister website https://www.clavister.com, select My
Clavister, log in and go to Licenses > Register License.
ii.
Select the option Register by Service Tag and Hardware Serial Number.
iii.
Enter the Serial Number and Service Tag codes then download a license to the
computer's local disk. For Clavister hardware products, these codes are found on a label
on the unit. The label also has a QR code containing the website and codes which can
be read by a mobile device.
iv.
The license file is uploaded to the security gateway through the cOS Core Web
Interface by going to Status > Maintenance > License and pressing the Upload
button to select the license file. Following upload, cOS Core will install the file.
Alternatively, the license file can be uploaded using SCP. cOS Core automatically
recognizes an uploaded license file but it is then necessary to manually to perform a
reconfigure or reboot operation to complete installation.
License installation must be done manually if the cOS Core installation has already had a
111
Chapter 2: Management and Maintenance
license installed before.
2.
Automatically through the Web Interface
Go to Status > Maintenance > License and enter the customer username and password,
then press Activate. The license is fetched automatically across the public Internet and
installed.
This option is also only available once and that is when installing a license in a Clavister
hardware product for the first time.
3.
Automatically through the CLI
In the CLI, enter the command:
Device:/> license -activate -request -username=myname -password=mypass
The customer username and password is included in the command with the license fetched
automatically across the public Internet. It is then necessary to manually enter the reconf or
shutdown command to complete installation.
This option is also only available once and that is when installing a license in a Clavister
hardware product for the first time.
Important: A reboot is recommended after installing a license
Some license changes, such as increasing the number of allowed VPN tunnels, change
memory requirements and will not take effect until after cOS Core is rebooted.
Rebooting will disrupt traffic flows but is recommended in order that all license
parameters become active. If only a reconfiguration operation is performed, not all
license parameters may come into effect although this does not disrupt traffic.
When installing a license through the Web Interface or when using the startup wizard,
the option to reboot or reconfigure are presented to the administrator. With the CLI and
SCP, these options are not presented and reboot must be initiated by the administrator.
For rebooting via the Web Interface, go to Status > Maintenance > Reset & Restore.
With the CLI, use the command:
Device:/> shutdown -reboot
License Installation with the Setup Wizard
When cOS Core is started on a Clavister hardware product for the first time, a Setup Wizard runs
that leads the administrator through a number of steps to simplify such tasks as enabling
Internet access.
The last few optional setup wizard steps allow the automatic retrieval across the Internet of a
license for the hardware and requires only that the customer username and password is entered.
If these setup wizard steps are skipped, a license can be installed later as a separate operation
using any of the methods described above.
The setup wizard is discussed further in the separate Getting Starting Guide for each hardware
product.
112
Chapter 2: Management and Maintenance
Lockdown Mode
cOS Core will enter a state known as Lockdown Mode if certain license violations occur. While in
lockdown mode, only remote management traffic is allowed by the Clavister Security Gateway
and all other traffic will be dropped. Unlike the two hour time limit of Demonstration Mode, there
is no time limit with lockdown mode.
Causes of Lockdown Mode
Lockdown Mode is usually caused by the license file bound to the Clavister Security Gateway
being in some way invalid. Conditions that trigger lockdown mode include license date expiry,
using the license on the wrong hardware or an invalid license file signature. It is also triggered if
the administrator tries to configure cOS Core beyond the limits of its license file. An example of
this is trying to configure more VPN tunnels than the license allows.
Ending Lockdown Mode
When lockdown mode is entered, the condition can be terminated by installing a valid license or
removing the configuration violation that triggered the condition. Removing the current license
will cause cOS Core to enter the 2 hour demonstration mode from lockdown mode. This might
be necessary to allow traffic to flow to the Internet in order to download a new license file.
SCP License Uploading
When a license file needs to be uploaded to the security gateway, SCP can be used.
Only one license file can exist on the Clavister Security Gateway. The name of the file is not
mandatory, and neither is the location since cOS Core will detect the file by examining its
contents. By convention, the license file should be called license.lic and it is uploaded to the top
level of the cOS Core directory structure.
Under Linux the SCP upload command to a security gateway called sgw_name might be:
> scp license.lic user@sgw_name:license.lic
Under windows the SCP upload would be done using an appropriate utility with SCP support.
The License Maximum Connections Should Be Adequate
The cOS Core license file specifies the maximum number of concurrent traffic connections that
cOS Core will allow. This is the parameter Max Connections in the file. It is important to have the
appropriate value for this parameter so that it is never exceeded.
If the limit is exceeded then a connection table full condition occurs and the action specified by
the advanced setting Connection Replace is followed.
By default, this action is ReplaceLog which means that the log message connection_table_full is
generated and the oldest connection is dropped by cOS Core to allow the new connection to
succeed.
See Section 12.4, “State Settings” for more information about the Connection Replace setting.
Replacing Licenses
If an installed license needs to be replaced, similar procedures are followed to upload it into the
security gateway. Replacement may be required because of license expiry or a change in the
113
Chapter 2: Management and Maintenance
capabilities allowed by a license such as becoming part of an HA cluster. The new license simply
overwrites the old.
The automatic methods of license installation described above are not available for replacement
and it requires the new license to be first downloaded to a computer and then uploaded with the
Web Interface or SCP.
Replacing Hardware
If the hardware unit is replaced with another unit but the same license is to be used, the same
procedures should be followed for installing the license in the new unit. The separate Hardware
Replacement Guide covers this topic in detail.
HA Cluster Licensing
In a cOS Core High Availability Cluster, two identical licenses must be purchased, one for the
master and one for the slave unit. Both licenses must include the ability to allow HA clustering.
Important: Use the correct license for the correct hardware unit
In any installation with more than one Clavister Security Gateway, it is important to
always use the correct license file for the correct security gateway.
If licenses are not matched correctly to the hardware, complex administrative problems
can arise later which can cause delays in rectifying hardware problems.
Licensing with VMware
When cOS Core runs with VMware as a virtual Clavister Security Gateway, it requires a special
license from Clavister in order to allow virtualization. The required parameter in the license is the
number of virtual Ethernet interfaces allowed.
A cOS Core license for VMware is not obtained in the same way as a non-VMware installation
which is described above. Instead the license can only be downloaded from the Clavister website
and it requires the MAC address of one of the virtual Ethernet interfaces. Once downloaded, the
license is installed in the same way as described above, using the Web Interface or SCP.
VMware license installation is described in more depth in the separate Clavister V Series Getting
Started Guide.
114
Chapter 2: Management and Maintenance
115
Chapter 3: Fundamentals
This chapter describes the fundamental logical objects which make up a cOS Core configuration.
These objects include such items as IP addresses and IP rules. Some exist by default and some
must be defined by the administrator.
In addition, the chapter explains the different interface types and explains how security policies
are constructed by the administrator.
• The Address Book, page 116
• IPv6 Support, page 123
• Services, page 130
• Interfaces, page 139
• ARP, page 168
• IP Rules and IP Policies, page 178
• Schedules, page 203
• Certificates, page 206
• Date and Time, page 212
• DNS, page 219
• Internet Access Setup, page 222
3.1. The Address Book
3.1.1. Overview
The cOS Core Address Book contains named objects representing various types of IP addresses,
including single IP addresses, networks as well as ranges of IP addresses. Ethernet MAC addresses
can also be defined in the address book.
Using address book objects has a number of important benefits:
•
It increases understanding of the configuration by using meaningful symbolic names.
116
Chapter 3: Fundamentals
•
Using address object names instead of entering numerical addresses reduces errors.
•
By defining an IP address object just once in the address book, changing the definition
automatically also changes all references to it.
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 single IP
address (a specific host), a network or a range of IP addresses and even a DNS name.
In addition, IP Address objects can be used for specifying the credentials used in user
authentication. For more information about this topic, 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 Classless Inter Domain Routing (CIDR) form.
CIDR uses a forward slash and a digit (0-32) to denote the size of the network as
a postfix. This is also known as the 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. For
example: 192.168.0.0/24.
IP Range
A range of IPv4 addresses is represented with the form a.b.c.d - e.f.g.h.
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 Address
This example adds the IPv4 host www_srv1 with IP address 192.168.10.16 to the address book:
Command-Line Interface
Device:/> add Address IP4Address www_srv1 Address=192.168.10.16
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Objects > Address Book > Add > IP4 Address
2.
Specify a suitable name for the IP host, in this case wwww_srv1
3.
Enter 192.168.10.16 for the IP Address
117
Chapter 3: Fundamentals
4.
Click OK
Example 3.2. Adding an IP Network
This example adds an IPv4 network named wwwsrvnet with address 192.168.10.0/24 to the
address book:
Command-Line Interface
Device:/> add Address IP4Address wwwsrvnet Address=192.168.10.0/24
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Objects > Address Book > Add > IP4 Address
2.
Specify a suitable name for the IP network, for example 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 IPv4 addresses from 192.168.10.16 to 192.168.10.21 and names the
range wwwservers:
Command-Line Interface
Device:/> add Address IP4Address wwwservers
Address=192.168.10.16-192.168.10.21
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Objects > Address Book > Add > IP4 Address
2.
Specify a suitable name for the IP Range, for example wwwservers.
3.
Enter 192.168.10.16-192.168.10.21 as the IP Address
4.
Click OK
118
Chapter 3: Fundamentals
Example 3.4. Deleting an Address Object
To delete an object named wwwsrv1 in the address book, do the following:
Command-Line Interface
Device:/> delete Address IP4Address wwwsrv1
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Objects > Address Book
2.
Select the address object wwwsrv1
3.
Choose Delete from the menu
4.
Click OK
Deleting In-use IP Objects
If an IP object is deleted that is in use by another object then cOS Core will not allow the
configuration to be deployed and will generate a warning message. In other words, it will appear
that the object has been successfully deleted but cOS Core will not allow the configuration to be
saved to the Clavister Security Gateway.
3.1.3. Ethernet Addresses
Ethernet Address objects are used to define symbolic names for MAC addresses. This is useful, for
example, 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 the
numerical MAC address 08-a3-67-bc-2e-f2.
Command-Line Interface
Device:/> add Address EthernetAddress wwwsrv1_mac
Address=08-a3-67-bc-2e-f2
InControl
119
Chapter 3: Fundamentals
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Objects > Address Book > Add > Ethernet Address
2.
Specify a suitable name for the Ethernet Address object, for example wwwsrv1_mac
3.
Enter 08-a3-67-bc-2e-f2 as the MAC Address
4.
Click OK
3.1.4. Address Groups
Groups Simplify Configuration
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 example web-servers, could 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.
IP Addresses Can Be Excluded
When groups are created with the Web Interface or InControl, it is possible to not only add
address objects to a group but also to explicitly exclude addresses from the group. However,
exclusion is not possible when creating groups with the CLI.
For example, if a network object is the network 192.168.2.0/24 and this is added to a group, it is
possible to then explicitly exclude the IPv4 address 192.168.2.1. This means that the group will
then contain the range 192.168.2.2 to 192.168.2.255.
Groups Can Contain Different Subtypes
Address Group objects are not restricted to contain members of the same subtype. IP host
objects can be teamed up with IP ranges, IP networks , with DNS names and so on. All addresses
of all group members are then combined by cOS Core, effectively resulting in the union of all the
addresses.
For example, if a group contains the following two IP address ranges:
•
192.168.0.10 - 192.168.0.15
•
192.168.0.14 - 192.168.0.19
The result of combining these two will be a single address range containing 192.168.0.10 192.168.0.19.
120
Chapter 3: Fundamentals
Note: IP and MAC Addresses
Address book objects can never contain both IP addresses and Ethernet MAC addresses
since these are entirely different in their usage. MAC address book objects are primarily
used with the cOS Core Proxy ARP feature.
3.1.5. Auto-Generated Address Objects
To simplify the configuration, a number of address objects in the address book are automatically
created by cOS Core when the system starts for the first time and these objects are used in
various parts of the initial configuration.
The following address objects are auto-generated:
Interface Addresses
For each Ethernet interface in the system, two IP Address
objects are predefined; one object for the IPv4 address of
the actual interface, and one object representing the local
network for that interface.
Interface
IPv4
address
objects
are
named
<interface-name>_ip and network objects are named
<interface-name>_net. As an example, an interface named
If1 will have an associated interface IP object named If1_ip,
and a network object named If1_net.
On some older Clavister hardware models, the underscore
is left out from the auto-generated interface network name.
For example, the lan interface will have the network object
lan_net.
The Default Gateway Address
On most platforms, an IPv4 Address object with the suffix
"_gw" is also auto-generated for the default interface used
for connection to the public Internet. For example, if the
Internet connection is assumed to be on interface wan then
the default gateway address gets the name wan_gw. This IP
address represents the external router which acts as the
gateway to the Internet.
This address is used primarily by the routing table, but is
also used by the DHCP client subsystem to store gateway
address information acquired through DHCP. The object
will have an empty IP address (0.0.0.0/0), and the correct IP
address for the default gateway needs to be defined unless
DHCP is being used and assigns it automatically.
all-nets
The all-nets IP address object is initialized to the IPv4
address 0.0.0.0/0, which represents all possible IP addresses.
The all-nets IP object is used extensively in the
configuration of cOS Core and it is important to understand
its significance.
3.1.6. Address Book Folders
In order to help organise large numbers of entries in the address book, it is possible to create
address book folders. These folders are just like a folder in a computer's file system. They are
created with a given name and can then be used to contain all the IP address objects that are
related together as a group.
121
Chapter 3: Fundamentals
Using folders is simply a way for the administrator to conveniently divide up address book
entries and no special properties are given to entries in different folders. cOS Core continues to
see all entries as though they were in a large table of IP address objects.
The folder concept is also used by cOS Core in other contexts such as IP rule sets, where related
IP rules can be grouped together in administrator created folders.
122
Chapter 3: Fundamentals
3.2. IPv6 Support
All the IP addresses discussed so far are of the IPv4 type. The IP address standard IPv6 is designed
as a successor to IPv4 with the principal advantage of providing a much larger 128 bit address
space. Among many other advantages, the large number of available global IPv6 addresses
means that NAT is no longer required to share a limited number of public IPv4 addresses.
IPv6 is supported by cOS Core from version 9.30.00 onwards. This section discusses how IPv6
objects are created, how usage is enabled, how stateless auto-configuration by clients is enabled
and how to create IP rules and routes that use IPv6 address objects.
cOS Core Configuration Objects Supporting IPv6
The following parts of cOS Core provide IPv6 support:
•
The address book.
•
Routing tables.
•
Routing rules.
•
IP rules (excluding some actions).
Adding an IPv6 Address
IPv6 address objects are created in the cOS Core address book as objects which are distinct from
IPv4 objects.
Only the all-nets6 object (IPv6 address ::/0) already exists in the address book. This means that the
IPv6 address and network objects associated with an interface must first be created.
Example 3.6. Adding IPv6 Host Addresses
Assume that an IPv6 address and network have to be associated with the wan interface. This
example adds two new IPv6 address objects to the address book consisting of the network
wan_net6 (the IPv6 prefix 2001:DB8::/32) and the single IP address wan_ip6 (2001:DB8::1) within
that network.
Command-Line Interface
Device:/> add Address IP6Address wan_net6 Address=2001:DB8::/32
Device:/> add Address IP6Address wan_ip6 Address=2001:DB8::1
InControl
Follow the same steps used for the Web Interface below.
Web Interface
Add the network address (the IPv6 prefix):
1.
Go to: Objects > Address Book > Add > IP6 Address
123
Chapter 3: Fundamentals
2.
Specify a suitable name for the object, in this case: wan_net6
3.
Enter 2001:DB8::/32 for the IP6 Address
4.
Click OK
Add the IP address:
1.
Go to: Objects > Address Book > Add > IP6 Address
2.
Specify a suitable name for the object, in this case: wan_ip6
3.
Enter 2001:DB8::1 for the IP6 Address
4.
Click OK
Note: The prefix 2001:DB8::/32 is reserved for documentation
As described in RFC3849, the IPv6 prefix 2001:DB8::/32 is specifically reserved for
documentation purposes. All IPv6 examples in this manual therefore use this network or
addresses from it.
IPv6 Must be Enabled Globally and on an Interface
IPv6 must be explicitly enabled in cOS Core for it to function. This is done in the two ways:
A. Enable IPv6 globally.
B. Enable IPv6 on an Ethernet interface.
These are described next.
A. Enable IPv6 Globally
There is a global advanced setting that enables IPv6 and if it is not enabled, all IPv6 traffic is
ignored. By default, this setting is disabled.
Example 3.7. Enabling IPv6 Globally
This example enables all IPv6 features across the whole of cOS Core. If an IPv6 feature is used and
this setting is not enabled, a warning will be generated when the configuration is activated.
Command-Line Interface
Device:/> set Settings IPSettings EnableIPv6=Yes
InControl
Follow the same steps used for the Web Interface below.
124
Chapter 3: Fundamentals
Web Interface
1.
Go to: System > Advanced Settings > IP Settings
2.
Enable the setting: Enable IPv6
3.
Click OK
B. Enable IPv6 on an Interface
Once IPv6 is enabled globally, IPv6 should then be enabled on any Ethernet interface with
which it is to be used. At the same time that an interface is enabled for IPv6, an IPv6 address
and IPv6 network (prefix) must be assigned to it. The interface can then be used in rules and
routes with IPv6 properties. By default, this setting is disabled for all interfaces.
Example 3.8. Enabling IPv6 on an Interface
This example enables IPv6 on the wan Ethernet interface using the address objects created
previously.
Command-Line Interface
Device:/> set Interface Ethernet wan
EnableIPv6=Yes
IPv6IP=wan_ip6
IPv6Network=wan_net6
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Network > Interfaces and VPN > Ethernet > wan
2.
Enable the option: Enable IPv6
3.
Now enter:
4.
•
IP Address: wan_ip6
•
Network: wan_net6
Click OK
An IPv6 gateway address could also be entered for the interface if it is connected to an ISP router.
An Interface Route is Added Automatically
When an IPv6 address and network are assigned to an Ethernet interface (both are required) then
an IPv6 route for that interface should be added to the main routing table.
The route is added provided the automatic route creation for the interface is enabled (it is
125
Chapter 3: Fundamentals
enabled by default).
Enabling IPv6 Router Advertisement
An additional option for an Ethernet interface is to enable IPv6 router advertisement. This means
that any external client connected to the interface can solicit and receive IPv6 messages to allow
it to perform Stateless Address Auto-Configuration (SLAAC). The SLAAC process allows the client to
create its own unique global IPv6 address based on the MAC address of its interface and the
prefix of the IPv6 address for the cOS Core interface it is connected to.
Example 3.9. Enabling IPv6 Advertisements
This example enables IPv6 advertisements on the wan Ethernet interface.
Command-Line Interface
Device:/> set Interface Ethernet wan EnableRouterAdvertisement=Yes
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Network > Interfaces and VPN > Ethernet > wan
2.
Go to: Advanced and enable the option: Enable router advertisement for this interface
3.
Click OK
IPv4 and IPv6 Cannot Share an Address Group Object
IPv6 address objects are created and managed in a similar way to IPv4 objects They are called an
IP6 Address and can be used in cOS Core rules and other objects in the same way as an IPv4
address. However, it is not possible to combine the two in one configuration object.
For example, it is not possible to create an Address Group that contains both. The standard
Address Group object can contain only IPv4 address objects. For IPv6 there is a special object
called an IP6 Group object that can contain only IPv6 addresses.
Similarly, the predefined all-nets address object is a catch-all object for all IPv4 addresses.
Another object, all-nets6, represents all IPv6 addresses and only IPv6 addresses.
Furthermore, it is not possible to combine all-nets (all IPv4 addresses) with all-nets6 in a single
Address Group object. For example, if a DropAll rule is needed as the last "catch-all" rule in an IP
rule set, two rules are required to catch all IPv4 and IPv6 traffic. This is discussed further in
Section 3.6, “IP Rules and IP Policies”.
In the same way, a routing table could route traffic for either a IPv4 network or an IPv6 network
to the same interface but this must be done with two separate routes in the routing table, one
for IPv4 and one for IPv6. It cannot be achieved using a single route.
IPv6 Neighbour Discovery
126
Chapter 3: Fundamentals
IPv6 Neighbor Discovery (ND) is the IPv6 equivalent of the IPv4 ARP protocol (see Section 3.5,
“ARP”).
When IPv6 is enabled for a given Ethernet interface, cOS Core will respond to any IPv6 Neighbor
Solicitations (NS) sent to that interface with IPv6 Neighbor Advertisements (NA) for the IPv6
address configured for that interface. cOS Core will also respond with neighbor advertisements
for any networks configured using Proxy Neighbor Discovery.
Proxy Neighbor Discovery
The IPv6 feature of Proxy Neighbor Discovery (Proxy ND) in cOS Core functions in the same way as
Proxy ARP does with IPv4 (described in Section 4.2.6, “Proxy ARP”). There are two ways of enabling
proxy ND:
A. Directly publish an address on an interface.
This is done in exactly the same way as ARP publish by setting option on an Ethernet
interface. Both the options Publish and Xpublish are supported for IPv6. These options are
explained in Section 3.5.3, “ARP Publish”.
B. Publish an address as part of a static route.
When a route for an IPv6 address on a given Ethernet interface is created, IPv6 should already
be enabled for the interface which means that IPv6 neighbor discovery is operational.
Optionally, Proxy Neighbour Discovery (Proxy ND) can also be enabled for an IPv6 route so that
all or selected interfaces will also respond to any neighbor solicitations for the route's
network.
An example of using this second method is given below.
Example 3.10. Adding an IPv6 Route and Enabling Proxy ND
Assume that a route needs to be in the main routing table so that the IPv6 network my_ipv6_net
is routed on the interface If1 where that interface already has IPv6 enabled.
In addition, proxy neighbor discovery for my_ipv6_net needs to be enabled for the If3 interface.
Command-Line Interface
First, change the CLI context to be the main routing table:
Device:/> cc RoutingTable main
Add the IPv6 route:
Device:/main> add Route6 Network=my_ipv6_net
Interface=If1
ProxyNDInterfaces=If3
Lastly, return to the default CLI context:
Device:/main> cc
Device:/>
InControl
Follow the same steps used for the Web Interface below.
127
Chapter 3: Fundamentals
Web Interface
1.
Go to: Network > Routing > Routing Tables > main > Add > RouteIPv6
2.
Now enter:
•
Interface: If1
•
Network: my_ipv6_net
3.
Go to: Proxy ND and move the interface If3 from Available to Selected
4.
Click OK
Troubleshooting IPv6 with ICMP Ping
The CLI command ping can be used for both IPv4 and IPv6 addresses. For example:
Device:/> ping 2001:DB8::2
This provides the means to determine if an IPv6 host is reachable and responding.
Ping can also be initiated in the Web Interface by going to: Status > Tools > Ping.
Outgoing ICMP messages from the security gateway do not require an IP rule which allows them
since the gateway is trusted. However, if the security gateway is to be pinged by an external host
then an IP rule must be set up to allow this. Such an IP rule would use the predefined Service
object called ping6-inbound The service object called all_icmpv6 covers all IPv6 ICMP messages
except mobile ICMP messages.
IPv6 Usage Restrictions
The following is a summary of IPv6 restrictions in the current version of cOS Core:
•
Management access with any cOS Core management interface is not possible using IPv6.
•
IP rules using IPv4 and IPv6 addresses can coexist in the same IP rule set but a single rule
cannot combine IPv4 and IPv6.
•
IPv6 addresses are not currently supported in IP rules with the following actions:
i.
NAT
ii.
SAT
iii.
SLB SAT
iv.
Multiplex SAT
•
Routes using IPv4 and IPv6 addresses can coexist in the same routing table set but a single
route cannot combine IPv4 and IPv6.
•
Routing rules using IPv4 and IPv6 addresses coexist but a single rule cannot combine IPv4
and IPv6.
•
IPv6 cannot be used for VPN or with ALGs, IDP or traffic shaping.
128
Chapter 3: Fundamentals
IPv6 and High Availability
cOS Core High Availability (HA) does not fully support IPv6. Any IPv6 configuration objects will be
mirrored on both the HA master and slave units. However, if a failover occurs, state information
will be lost when one unit takes over processing from the other and IPv6 connections will be lost.
In an HA configuration where interfaces have IPv6 enabled and IPv6 addresses assigned, there is
no private and shared IPv6 IP for each pair of interfaces. Each interface pair will have the same
IPv6 IP address on both master and slave. A private IPv6 interface address for each interface in a
pair is not possible.
IPv6 and Transparent Mode
Transparent Mode in cOS Core does not directly support IPv6 since Switched Routes cannot be
defined for IPv6 networks (see Section 4.8, “Transparent Mode”).
However, it is possible to split networks transparently in the same way that Proxy ARP is used for
this with IPv4. Doing this for IPv4 is explained in Section 4.2.6, “Proxy ARP”. The only difference
with IPv6 is that Neighbor Discovery (ND) is used instead of proxy ARP. The method is otherwise
the same and the two can be used alongside each other to split both IPv4 and IPv6 networks at
the same time.
129
Chapter 3: Fundamentals
3.3. Services
3.3.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 which is
associated with a specific source and/or destination port number(s). For example, the HTTP
service is defined as using the TCP protocol with the associated destination port 80 and any
source port.
However, service objects are not restricted to just the TCP or UDP protocols. They can be used to
encompass ICMP messages as well as a user-definable IP protocol.
A Service is Passive
Services are passive cOS Core objects in that they do not themselves carry out any action in the
configuration. Instead, service objects must be associated with the security policies defined by
various cOS Core rule sets and then act as a filter to apply those rules only to a specific type of
traffic.
For example, an IP rule in a cOS Core IP rule set has a service object associated with it as a
filtering parameter to decide whether or not to allow a specific type of traffic to traverse the
Clavister Security Gateway. Inclusion in IP rules is one the most important usage of service
objects and it is also how ALGs become associated with IP rules since an ALG is associated with a
service and not directly with an IP rule.
For more information on how service objects are used with IP rules, see Section 3.6, “IP Rules and
IP Policies”.
Predefined Services
A large number of service objects are predefined in cOS Core. These include common services
such as HTTP, FTP, Telnet and SSH.
Predefined services can be used and also modified just like custom, user defined services.
However, it is recommended to not make any changes to predefined services and instead create
custom services with the desired characteristics.
Custom service creation in detail later in Section 3.3.2, “Creating Custom Services”.
Example 3.11. Listing the Available Services
To produce a listing of the available services in the system:
Command-Line Interface
Device:/> show Service
The output will look similar to the following listing with the services grouped by type with the
service groups appearing first:
ServiceGroup
Name
-----------all_services
Comments
-------------------------------------------------All ICMP, TCP and UDP services
130
Chapter 3: Fundamentals
all_tcpudp
ipsec-suite
l2tp-ipsec
l2tp-raw
pptp-suite
All TCP and UDP services
The IPsec+IKE suite
L2TP using IPsec for encryption and authentication
L2TP control and transport, unencrypted
PPTP control and transport
ServiceICMP
Name
-----------all_icmp
"
"
Comments
-------------------------------------------------All ICMP services
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Objects > Services
Example 3.12. Viewing a Specific Service
To view a specific service in the system:
Command-Line Interface
Device:/> show Service ServiceTCPUDP echo
The output will look similar to the following listing:
Property
----------------Name:
DestinationPorts:
Type:
SourcePorts:
PassICMPReturn:
ALG:
MaxSessions:
Comments:
Value
---------------echo
7
TCPUDP (TCP/UDP)
0-65535
No
<empty>
1000
Echo service
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Objects > Services
2.
Select the specific service object in the table
3.
A listing all services will be presented
131
Chapter 3: Fundamentals
3.3.2. Creating Custom Services
If the list of predefined cOS Core service objects does not meet the requirements for certain
traffic then a new service can be created. Reading this section will explain not only how new
services are created but also provides an understanding of the properties of predefined services.
The Type of service created can be one of the following:
•
TCP/UDP Service
A service based on the UDP or TCP protocol or both. This type of service is discussed further
in this section.
•
ICMP Service
A service based on the ICMP protocol. This is discussed further in Section 3.3.3, “ICMP Services”.
•
IP Protocol Service A service based on a user defined protocol. This is discussed further in
Section 3.3.4, “Custom IP Protocol Services”.
•
Service Group
A service group consisting of a number of services. This is discussed further in Section 3.3.5,
“Service Groups”.
TCP and UDP Based Services
Most applications use TCP and/or UDP as transport protocol for transferring data over IP
networks.
Transmission Control Protocol (TCP) is a connection-oriented protocol that includes mechanisms
for reliable point to point transmission of data. TCP is used by many common applications where
error-free transfers are mandatory, such as HTTP, FTP and SMTP.
UDP Orientated Applications
For applications where data delivery speed is of greatest importance, for example with streaming
audio and video, the User Datagram Protocol (UDP) is the preferred protocol. UDP is
connectionless, provides minimal transmission error recovery, and has a much lower overhead
when compared with TCP. Due to the lower overhead, UDP is also used for some non-streaming
services and in those cases the applications themselves must provide any error recovery
mechanisms.
TCP and UDP Service Definition
To define a TCP or UDP based protocol to cOS Core, a TCP/UDP service object is used. Apart from
a unique name describing the service, the object contains information about what protocol (TCP,
UDP or both) and what source and destination ports are applicable for the service.
Specifying Port Numbers
Port numbers are specified with all types of services and it is useful to understand how these can
be entered in user interfaces. They can be specified for both the Source Port and/or the
Destination Port of a service in the following ways:
132
Chapter 3: Fundamentals
Single Port
For many services, a single destination port is sufficient. For
example, HTTP usually uses destination port 80. The SMTP
protocol uses port 25 and so on. For these types of service,
the single port number is simply specified in the service
definition as a single number.
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 ability to cover a
wide range of ports using only a single TCP/UDP service
object.
For example, all Microsoft Windows networking can be
covered using a port definition specified as 135-139,445.
HTTP and HTTPS can be covered by specifying destination
ports 80,443.
Tip: Specifying source ports
It is usual with many services that the source ports are left as their default value which is
the range 0-65535 (corresponding to all possible source ports).
With certain application, it can be useful to also specify the source port if this is always
within a limited range of values. Making the service definition as narrow as possible is
the recommended approach.
Other Service Properties
Apart from the basic protocol and port information, TCP/UDP service objects also have several
other properties:
•
SYN Flood Protection
This option allows a TCP based service to be configured with protection against SYN Flood
attacks. This option only exists for the TCP/IP service type.
For more details on how this feature works see Section 6.6.8, “TCP SYN Flood Attacks”.
•
Pass ICMP Errors
If an attempt to open a TCP connection is made by a user application behind the Clavister
Security Gateway and the remote server is not in operation, an ICMP error message is
returned as the response. Such ICMP messages are interpreted by cOS Core as new
connections and will be dropped unless an IP rule explicitly allows them.
The Pass returned ICMP error messages from destination option allows such ICMP
messages to be automatically passed back to the requesting application. In some cases, it is
useful that the ICMP messages are not dropped. For example, if an ICMP quench message is
133
Chapter 3: Fundamentals
sent to reduce the rate of traffic flow. On the other hand, dropping ICMP messages increases
security by preventing them being used as a means of attack.
•
ALG
A TCP/UDP service can be linked to an Application Layer Gateway (ALG) to enable deeper
inspection of certain protocols. This is the way that an ALG is associated with an IP rule. First,
associate the ALG with a service and then associate the service with an IP rule.
For more information on this topic see Section 6.2, “ALGs”.
•
Max Sessions
An important parameter associated with a service is Max Sessions. This parameter is given 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 example, an HTTP ALG the default value can often be too low if
there are large numbers of clients connecting through the Clavister Security Gateway. It is
therefore recommended to consider if a higher value is required for a particular scenario.
Specifying All Services
When setting up rules that filter by services it is possible to use the service object called
all_services to refer to all protocols. However, using this is not recommended and specifying a
narrower service provides better security.
If, for example, the requirement is only to filter using the principal protocols of TCP, UDP and
ICMP then the service group all_tcpudpicmp can be used instead.
Tip: The http-all service does not include DNS
A common mistake is to assume that the predefined service http-all includes the DNS
protocol. It does not so the predefined service dns-all is usually also required for most
web surfing. This could be included in a group with http-all and then associated with
the IP rules that allow web surfing.
Restrict Services to the Minimum Necessary
When choosing a service object to construct a policy such as an IP rule, the protocols included in
that object should be as few as necessary to achieve the traffic filtering objective. Using the
all_services object may be convenient but removes any security benefits that a more specific
service object could provide.
The best approach is to narrow the service filter in a security policy so it allows only the protocols
that are absolutely necessary. The all_tcpudpicmp service object is often a first choice for general
traffic but even this may allow many more protocols than are normally necessary and the
administrator can often narrow the range of allowed protocols further.
Example 3.13. Creating a Custom TCP/UDP Service
134
Chapter 3: Fundamentals
This example shows how to add a TCP/UDP service, using destination port 3306, which is used by
MySQL:
Command-Line Interface
Device:/> add Service ServiceTCPUDP MySQL
DestinationPorts=3306
Type=TCP
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Objects > Services > Add > TCP/UDP service
2.
Specify a suitable name for the service, for example MySQL
3.
Now enter:
4.
•
Type: TCP
•
Source: 0-65535
•
Destination: 3306
Click OK
3.3.3. ICMP Services
Another type of custom service that can be created is an ICMP Service.
The Internet Control Message Protocol (ICMP) is a protocol that is integrated with IP for error
reporting and transmitting control information. For example, the ICMP Ping feature uses ICMP to
test Internet connectivity.
ICMP Types and Codes
ICMP messages are delivered in IP packets, and includes a Message Type that specifies 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.
Either all ICMP message types can be accepted by a service (there are 256 possible types) or it is
possible to filter the types.
Specifying Codes
If a type is selected then the codes for that type can be specified in the same way that port
numbers are specified. For example, if the Destination Unreachable type is selected with the
comma delimited code list 0,1,2,3 then this will filter Network unreachable, Host unreachable,
Protocol unreachable and Port unreachable.
135
Chapter 3: Fundamentals
When a message type is selected but no code values are given then all codes for that type is
assumed.
ICMP Message Types
The message types that can be selected are 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:
Redirect
•
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
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.3.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.
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. For example, specifying the range 1-4,7 will
match the protocols ICMP, IGMP, GGP, IP-in-IP and CBT.
136
Chapter 3: Fundamentals
IP protocol numbers
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.14. Adding an IP Protocol Service
This example shows how to add an IP Protocol service, with the Virtual Router Redundancy
Protocol.
Command-Line Interface
Device:/> add Service ServiceIPProto VRRP IPProto=112
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Objects > Services > Add > IP protocol service
2.
Specify a suitable name for the service, for example VRRP
3.
Enter 112 in the IP Protocol control
4.
Optionally enter Virtual Router Redundancy Protocol in the Comments control
5.
Click OK
3.3.5. Service Groups
A Service Group is, exactly as the name suggests, a cOS Core object that consists of a collection of
services. Although the group concept is simple, it can be very useful when constructing security
policies since the group can be used instead of an individual service.
The Advantage of Groups
For example, there may be a need for a set of IP rules that are identical to each other except for
the service parameter. By defining a service group which contains all the service objects from all
the individual rules, we can replace all of them with just one IP rule that uses the group.
Suppose that we create a service group called email-services which combines the three services
objects for SMTP, POP3 and IMAP. Now only one IP rule needs to be defined that uses this group
service to allow all email related traffic to flow.
Groups Can Contain Other Groups
When a group is defined then it can contain individual services and/or service groups. This ability
to have groups within groups should be used with caution since it can increase the complexity of
137
Chapter 3: Fundamentals
a configuration and decrease the ability to troubleshoot problems.
3.3.6. Custom Service Timeouts
Any service can have its custom timeouts set. These can also be set globally in cOS Core but it is
more usual to change these values individually in a custom service.
The timeout settings that can be customized are as follows:
•
Initial Timeout
This is the time allowed for a new connection to be open.
•
Establish (Idle) Timeout
If there is no activity on a connection for this amount of time then it is considered to be
closed and is removed from the cOS Core state table. The default setting for this time with
TCP/UDP connections is 3 days.
•
Closing Timeout
The is the time allowed for the connection to be closed.
The administrator must make a judgement as what the acceptable values should be for a
particular protocol. This may depend, for example, on the expected responsiveness of servers to
which clients connect.
138
Chapter 3: Fundamentals
3.4. Interfaces
3.4.1. Overview
An Interface is an important logical building block in cOS Core. All network traffic that transits
through, originates from or is terminated in the Clavister Security Gateway, does so through one
or more interfaces.
Source and Destination Interfaces
An interface can be viewed as a doorway through which network traffic passes to or from cOS
Core. A cOS Core interface has one of two functions:
•
The Source Interface
When traffic arrives through an interface, that interface is referred to in cOS Core as the source
interface (also sometimes known as the receiving or incoming interface).
•
The Destination Interface
When traffic leaves after being checked against cOS Core's security policies, the interface
used to send the traffic is referred to in cOS Core as the destination interface (also sometimes
known as the sending interface).
All traffic passing through cOS Core has both a source and destination interface. As explained in
more depth later, the special logical interface core is used when cOS Core itself is the source or
destination for traffic.
Interface Types
cOS Core supports a number of interface types, which can be divided into the following four
major groups:
•
Ethernet Interfaces
Each Ethernet interface represents a physical Ethernet interface on a cOS Core-based product.
All network traffic that originates from or enters a Clavister Security Gateway will pass
through one of the physical interfaces.
cOS Core currently supports Ethernet as the only physical interface type. For more
information about Ethernet interfaces, see Section 3.4.2, “Ethernet Interfaces”.
Note: Ethernet interfaces under hypervisors
When cOS Core runs under a hypervisor such as VMware then the physical cOS Core
interfaces are not in fact physical but are virtual. However, cOS Core still treats them
as though they were physical.
•
Sub-interfaces
Some interfaces require a binding to an underlying physical interface in order to transfer
data. This group of interfaces is called Physical Sub-Interfaces.
cOS Core has support for two types of sub-interfaces:
139
Chapter 3: Fundamentals
•
•
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.4.3, “VLAN”.
•
PPPoE (PPP-over-Ethernet) interfaces for connections to PPPoE servers. More information
about this topic can be found in Section 3.4.4, “PPPoE”.
Tunnel Interfaces
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. VPN
tunnels are often used to implement virtual private networks (VPNs) which can secure
communication between two security gateways.
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. For example, when routing traffic over an IPsec interface, the
payload is usually encrypted to achieve confidentiality.
cOS Core supports the following tunnel interface types:
•
i.
IPsec interfaces are used as end-points for IPsec VPN tunnels. More information about
this topic can be found in Section 9.3, “IPsec Components”.
ii.
PPTP/L2TP interfaces are used as end-points for PPTP or L2TP tunnels. More information
about this topic can be found in Section 9.5, “PPTP/L2TP”.
iii.
GRE interfaces are used to establish GRE tunnels. More information about this topic can
be found in Section 3.4.5, “GRE Tunnels”.
Loopback Interfaces
A loopback interface is a special type of interface that will take all packets sent through it and
pass them on out through the loopback interface configured as the one to loop to. These are
almost exclusively used for Virtual Routing scenarios.
More information about loopback interfaces can be found in Section 3.4.6, “Loopback
Interfaces”.
All Interfaces are Logically Equivalent
Even though the different types of interfaces may be very different in the way they function, cOS
Core treats all interfaces as logically equivalent. This is an important and powerful concept and
means that all types of interfaces can be used almost interchangeably in the various cOS Core
rule sets and other configuration objects. This results in a high degree of flexibility in how traffic
can be examined, controlled and routed.
Interfaces have Unique Names
Each interface in cOS Core is given a unique name to be able to identify and select it for use with
other cOS Core objects in a configuration. Some interface types, such as physical Ethernet
interfaces, are already provided by cOS Core with relevant default names that are possible to
modify if required. New interfaces defined by the administrator will always require a
user-provided name to be specified.
The any and core Interfaces
140
Chapter 3: Fundamentals
In addition, cOS Core provides two special logical interfaces which are named any and core. The
meaning of these are:
•
any represents all possible interfaces including the core interface.
•
core indicates that it is cOS Core itself that will deal with traffic to and from this interface.
Examples of the use of core are when the Clavister Security Gateway acts as a PPTP or L2TP
server or responds to ICMP "Ping" requests. By specifying the Destination Interface of a
route as core, cOS Core will then know that it is itself that is the ultimate destination of the
traffic.
Disabling an Interface
Should it be desirable to disable an interface so that no traffic can flow through it, this can be
done with the CLI using the command:
Device:/> set Interface Ethernet <interface-name> -disable
Where <interface-name> is the interface to be disabled.
To re-enable an interface, the command is:
Device:/> set Interface Ethernet <interface-name> -enable
Disabling interfaces can also be done through the Web Interface or InControl.
3.4.2. Ethernet Interfaces
cOS Core supports Ethernet, Fast Ethernet and Gigabit Ethernet interfaces as defined by the IEEE
802.3 standard.
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.
Note: Usage of the terms "interface" and "port"
The terms Ethernet interface and Ethernet port can be used interchangeably. In this
document, the term Ethernet interface is used throughout so it is not confused with the
port associated with IP communication.
Ethernet Frames
Devices broadcast data as Ethernet frames and 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 plus 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 is progressively smaller with the faster data
transmission speeds found in normal Ethernet, then Fast Ethernet and finally Gigabit Ethernet.
Physical Ethernet Interfaces
141
Chapter 3: Fundamentals
Each logical Ethernet interface in the cOS Core usually corresponds to a physical Ethernet
interface in the system. The number of interfaces, their link speed and the way the interfaces are
realized, is dependent on the hardware model. A smaller Clavister model will have a limited
number of Fast Ethernet interfaces as integrated product components, while a more powerful
unit designed for telecom applications might be expandable with separate interface modules.
If cOS Core is being run on non-Clavister Intel x86 compatible server hardware, it is likely that the
Ethernet hardware interfaces are implemented using common Ethernet PCI adapters.
Note: Interface sockets connected via a switch fabric
Some hardware platforms for cOS Core use an integrated layer 2 switch for providing
additional physical Ethernet interface sockets. Externally there can be several separate
sockets but these are joined via an internal switch fabric.
Such joined interfaces are seen as a single interface by cOS Core and the cOS Core
configuration uses a single logical interface name to refer to all of them. The
specifications that relate to different hardware models will indicate where this is the
case.
Ethernet Interface Parameters
The following are the various parameters that can be set for an Ethernet interface:
•
Interface Name
The names of the Ethernet interfaces are predefined by the system, and are mapped to the
names of the physical interfaces.
The names of the Ethernet interfaces can be changed to better reflect their usage. For
example, 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 interface with the new name.
Note: Interface naming
In many of the examples in this guide, the name lan is often used for the interface
connected to a local protected network and wan is used for the interface connected
to the public internet. The names of the interfaces for the actual hardware model
used should be substituted in.
•
IP Address
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.
cOS Core IP4 Address objects are usually used to define the IPv4 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”. When the system is first started, all
unconfigured Ethernet interfaces will be assigned default addresses from the localhost
sub-network (127.0.0.0/8).
Tip: Specifying multiple IP addresses on an interface
142
Chapter 3: Fundamentals
Multiple IP addresses can be specified for an Ethernet interface by using the ARP
Publish feature. (For more information, see Section 3.5, “ARP”).
•
Network
In addition to the interface IP address, a Network address is also specified for an Ethernet
interface. The Network address provides information to cOS Core 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, cOS Core
will automatically create a direct route to the specified network over the actual interface.
•
Default Gateway
A Default Gateway address can optionally be specified for an Ethernet interface. This is
normally the address of a router and very often the router which acts as the gateway to the
Internet.
When a default gateway is specified then, by default, a route to the network all-nets is
automatically created in the cOS Core routing table for the interface. This means that any
traffic which does not have a more specific matching route will be sent via that interface to
the default gateway. This behaviour can be changed by disabling an interface's advanced
option for creating the default route automatically.
Normally, only one default all-nets route to the default gateway needs to exist in the routing
table.
Note: The all-nets IP address object
The all-nets IP object (IP address: 0.0.0.0/0) includes the multicast IP address range
(224.0.0.0 => 239.255.255.255). For more information about this topic, see
Section 4.7, “Multicast Routing”.
•
Receive Multicast Traffic
This option controls the reception of multicast IP packets on that interface. There are three
options available for multicast packet handling:
i.
Off - Multicast packets are silently dropped.
ii.
On - Multicast traffic can always be received by the interface.
iii.
Auto - If an IP rule exists in the rule set which applies to a multicast packet's destination
IP address, then the Ethernet interface is automatically enabled to receive multicast
packets.
Auto is the default behavior.
•
Enable DHCP Client
cOS Core includes a DHCP client feature for dynamic assignment of address information by a
connected DHCP server. This feature is often used for receiving external IP address
information from an ISP's DHCP server for public Internet connection.
The information that can be set using DHCP includes the IP and broadcast address of the
143
Chapter 3: Fundamentals
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”. However, the administrator
can specify their own set of address objects if there is a need to modify this behavior.
By default, DHCP is disabled on Ethernet interfaces. If the interface is being used for
connection to the public Internet via an ISP using fixed IP addresses then DHCP shouldn't be
used.
DNS server addresses received through DHCP on an interface named <interface-name> will
be allocated to cOS Core address objects with the names <interface-name>_dns1 and
<interface-name>_dns2.
Note: A gateway IP cannot be deleted with DHCP enabled
If DHCP is enabled for a given Ethernet interface then any gateway IP address that is
defined for that interface cannot be deleted. To remove the gateway address, the
DHCP option must be first disabled.
If DHCP is enabled then there is a set of interface specific advanced settings:
i.
A preferred IP address can be requested.
ii.
A preferred lease time can be requested.
iii.
Static routes can be sent from the DHCP server.
iv.
Do not allow IP address collisions with static routes.
v.
Do not allow network collisions with static routes.
vi.
Specify an allowed IP address for the DHCP lease.
vii. Specify an address range for DHCP servers from which leases will be accepted.
•
DHCP Hostname
In some, infrequent cases a DHCP server may require a hostname to be sent by the DHCP
client.
•
Enable Transparent Mode
The recommended way to enable Transparent Mode is to add switch routes, as described in
Section 4.8, “Transparent Mode”. An alternative method is to enable transparent mode directly
on an interface with this option.
When enabled, default switch routes are automatically added to the routing table for the
interface and any corresponding non-switch routes are automatically removed.
•
Hardware Settings
In some circumstances it may be necessary to change hardware settings for an interface. The
available options are:
i.
The speed of the link can be set. Usually this is best left as Auto.
144
Chapter 3: Fundamentals
ii.
•
The MAC address can be set if it needs to be different to the MAC address built into the
hardware. Some ISP connections might require this.
Virtual Routing
To implement virtual routing where the routes related to different interfaces are kept in
separate routing table, there are a number of options:
•
i.
Make the interface a member of all routing tables. This option is enabled by default and
means that traffic arriving on the interface will be routed according to the main routing
table. Routes for the interface IP will be inserted into all routing tables.
ii.
The alternative to the above is to insert the route for this interface into only a specific
routing table. The specified routing table will be used for all route lookups unless
overridden by a routing rule.
Automatic Route Creation
Routes can be automatically added for the interface. This addition can be of the following
types:
•
i.
Add a route for this interface for the given network. This is enabled by default.
ii.
Add a default route for this interface using the given default gateway. This is enabled by
default.
MTU
This determines the maximum size of packets in bytes that can be sent on this interface. By
default, the interface uses the maximum size supported.
•
High Availability
There are two options which are specific to high availability clusters:
•
1.
A private IPv4 address can be specified for this interface.
2.
An additional option is to disable the sending of HA cluster heartbeats from this
interface.
Quality Of Service
The option exists to copy the IP DSCP precedence to the VLAN priority field for any VLAN
packets. This is disabled by default.
Changing the IPv4 address of an Ethernet Interface
To change the IPv4 address on an interface, we can use one of two methods:
•
Change the IPv4 address directly on the interface. For example, if we want to change the IPv4
address of the lan interface to 10.1.1.2, we could use the CLI command:
Device:/> set Interface Ethernet lan IP=10.1.1.2
As explained next, this way of changing the IPv4 address is not recommended.
•
Instead, the ip_lan object in the cOS Core Address Book should be assigned the new address
since it is this object that is used by many other cOS Core objects such as IP rules. The CLI
command to do this would be:
145
Chapter 3: Fundamentals
Device:/> set Address IP4Address ip_lan Address=10.1.1.2
This same operation could also be done through the Web Interface or InControl.
A summary of CLI commands that can be used with Ethernet interfaces can be found in
Section 3.4.2.1, “Useful CLI Commands for Ethernet Interfaces”.
The Difference Between Logical and Physical Ethernet Interfaces
The difference between logical and physical interfaces can sometimes be confusing. The logical
Ethernet interfaces are those which are referred to in a cOS Core configuration. When using the
Web Interface or InControl, only the logical interfaces are visible and can be managed.
When using the CLI, both the logical and physical interfaces can be managed. For example, to
change the name of the logical interface If1 to be lan, the CLI command is:
Device:/> set Interface Ethernet If1 Name=lan
This changes the logical name of the interface (and all references to it) but does not change the
underlying physical name. For example, the CLI command ifstat shows the names of only the
physical interfaces and this list is unaffected by the above name change.
In the CLI, a physical interface is represented by the object EthernetInterface. To display all the
characteristics of an interface, for example for interface If1, the CLI command is:
Device:/> show EthernetDevice If1
The output from this command shows details about the physical Ethernet card including the bus,
slot and port number of the card as well as the Ethernet driver being used. These details are not
relevant to the logical interface object associated with the physical interface.
Ethernet Interfaces with VMware
When cOS Core runs under VMware in a virtual machine, it has a number of virtual interfaces. A
default number of interfaces is provided but can be increased if required provided VMware and
the cOS Core license allow it.
Virtual interfaces can be connected to physical interfaces with the VMware Bridged mode.
Alternatively, Custom (non-bridged) mode can be used to connect interfaces to a VMware virtual
network and another virtual machine running on the same VMware host.
cOS Core usage with VMware is more fully described in the separate Clavister V Series Getting
Started Guide.
3.4.2.1. Useful CLI Commands for Ethernet Interfaces
This section summarizes the CLI commands most commonly used for examining and
manipulating cOS Core Ethernet interfaces.
Ethernet interfaces can also be examined through the Web Interface or InControl, but for some
operations the CLI must be used.
Showing Assigned Interfaces
To show the current interface assigned to the IP address wan_ip:
146
Chapter 3: Fundamentals
Device:/> show Address IP4Address InterfaceAddresses/wan_ip
Property Value
--------------------- --------------------------Name: wan_ip
Address: 0.0.0.0
UserAuthGroups: <empty>
NoDefinedCredentials: No
Comments: IP address of interface wan
To show the current interface assigned to the network wan_net:
Device:/> show Address IP4Address InterfaceAddresses/wan_net
Property
--------------------Name:
Address:
UserAuthGroups:
NoDefinedCredentials:
Comments:
Value
-----------------------wan_net
0.0.0.0/0
<empty>
No
Network on interface wan
To show the current interface assigned to the gateway wan_gw:
Device:/> show Address IP4Address InterfaceAddresses/wan_gw
Property
--------------------Name:
Address:
UserAuthGroups:
NoDefinedCredentials:
Comments:
Value
--------------------------------wan_gw
0.0.0.0
<empty>
No
Default gateway for interface wan
By using the tab key at the end of a line, tab completion can be used to complete the command:
Device:/> show Address IP4Address InterfaceAddresses/wan_<tab>
[<Category>] [<Type> [<Identifier>]]:
InterfaceAddresses/wan_br
InterfaceAddresses/wan_dns1
InterfaceAddresses/wan_dns2
InterfaceAddresses/wan_gw
InterfaceAddresses/wan_ip
InterfaceAddresses/wan_net
Here, tab completion is used again at the end of the command line:
Device:/> set Address IP4Address<tab>
[<Category>] <Type> [<Identifier>]:
dnsserver1_ip
InterfaceAddresses/aux_ip
InterfaceAddresses/aux_net
InterfaceAddresses/dmz_ip
InterfaceAddresses/dmz_net
InterfaceAddresses/lan_ip
InterfaceAddresses/lan_net
InterfaceAddresses/wan_br timesyncsrv1_ip
InterfaceAddresses/wan_dns1
InterfaceAddresses/wan_dns2
InterfaceAddresses/wan_gw
InterfaceAddresses/wan_ip
InterfaceAddresses/wan_net
Server
Setting Interface Addresses
The CLI can be used to set the address of the interface:
Device:/> set Address IP4Address
InterfaceAddresses/wan_ip
Address=172.16.5.1
Modified IP4Address InterfaceAddresses/wan_ip.
147
Chapter 3: Fundamentals
Enabling DHCP
The CLI can be used to enable DHCP on the interface:
Device:/> set Interface Ethernet wan DHCPEnabled=yes
Modified Ethernet wan.
Ethernet Device Commands
Some interface settings provide direct management of the Ethernet settings themselves. These
are particularly useful if Clavister hardware has been replaced and Ethernet card settings are to
be changed, or if configuring the interfaces when running cOS Core on non-Clavister hardware.
For example, to display all Ethernet interface information use the command:
Device:/> show EthernetDevice
This command lists all Ethernet interfaces. Those defined as logical interfaces in the current
configuration are marked by a plus "+" symbol on the left of the listing.
Those interfaces that physically exist but are not part of the configuration are indicated with a
minus "-" symbol at the left. These will be deleted after the configuration is activated. If a deleted
interface in the interface list is to be restored, this can be done with the undelete command:
Device:/> undelete EthernetDevice <interface>
Individual interface details can be displayed, for example for the interface If1, with the command:
Device:/> show EthernetDevice If1
Property
--------------Name:
EthernetDriver:
PCIBus:
PCISlot:
PCIPort:
Value
---------------------If1
E1000EthernetPCIDriver
0
17
0
"
"
The set command can be used to control an Ethernet interface. For example, to disable an
interface lan, the following command can be used:
Device:/> set EthernetDevice lan -disable
To enable the interface lan:
Device:/> set EthernetDevice lan -enable
To set the driver on an Ethernet interface card the command is:
Device:/> set EthernetDevice lan EthernetDriver=<driver>
PCIBus=<X> PCISlot=<Y> PCIPort=<Z>
For example, if the driver name is IXP4NPEEthernetDriver for the bus, slot, port combination 0, 0, 2
on the wan interface, the set command would be:
Device:/> set EthernetDevice lan
EthernetDriver=IXP4NPEEthernetDriver
148
Chapter 3: Fundamentals
PCIBus=0
PCISlot=0
PCIPort=2
This command is useful when a restored configuration contains interface names that do not
match the interface names of new hardware. By assigning the values for bus, slot, port and driver
of a physical interface to a logical interface in the configuration, the logical interface is mapped
to the physical interface. However, this mapping must be done before the configuration is
activated.
For a complete list of all CLI options see the CLI Reference Guide.
3.4.2.2. Advanced Ethernet Interface Settings
This section details the advanced settings available for cOS Core Ethernet interfaces. The settings
are global and affect all physical interfaces.
DHCP Settings
Below is a list of the advanced DHCP settings for cOS Core Ethernet interfaces.
DHCP_AllowGlobalBcast
Allow DHCP server to assign 255.255.255.255 as broadcast. (Non-standard.)
Default: Disabled
DHCP_DisableArpOnOffer
Disable the ARP check done by cOS Core on the offered IP. The check issues an ARP request to
see if the IP address is already in use.
Default: Disabled
DHCP_UseLinkLocalIP
If this is enabled cOS Core will use a Link Local IP (169.254.*.*) instead of 0.0.0.0 while waiting for
a lease.
Default: Disabled
DHCP_ValidateBcast
Require that the assigned broadcast address is the highest address in the assigned network.
Default: Enabled
DHCP_MinimumLeaseTime
Minimum lease time (seconds) accepted from the DHCP server.
Default: 60
Hardware Settings
149
Chapter 3: Fundamentals
Below is a list of the advanced hardware settings that are available for cOS Core Ethernet
interfaces. These settings are only relevant to cOS Core running on non-Clavister hardware.
Ringsize_e1000_rx
Size of the rx buffer on e1000 cards.
Default: 64
Ringsize_e1000_tx
Size of the tx buffer on e1000 cards.
Default: 256
Ringsize_e100_rx
Size of the rx buffer on e100 cards.
Default: 32
Ringsize_e100_tx
Size of the tx buffer on e100 cards.
Default: 128
Ringsize_yukon_rx
Size of Yukon receive ring (per interface).
Default: 256
Ringsize_yukon_tx
Size of Yukon send ring (per interface).
Default: 256
Ringsize_yukonii_rx
Size of Yukon-II receive ring (per interface).
Default: 256
Ringsize_yukonii_tx
Size of Yukon-II send ring (per interface).
Default: 256
Interface Monitor Settings
150
Chapter 3: Fundamentals
Below is a list of the monitor settings that are available for cOS Core Ethernet interfaces.
IfaceMon_e1000
Enable interface monitor for e1000 interfaces.
Default: Enabled
IfaceMon_BelowCPULoad
Temporarily disable ifacemon if CPU load goes above this percentage.
Default: 80
IfaceMon_BelowIfaceLoad
Temporarily disable ifacemon on and interface if network load on the interface goes above this
percentage.
Default: 70
IfaceMon_ErrorTime
How long a problem must persist before an interface is reset.
Default: 10
IfaceMon_MinInterval
Minimum interval between two resets of the same interface.
Default: 30
IfaceMon_RxErrorPerc
Percentage of errors in received packets at which to declare a problem.
Default: 20
IfaceMon_TxErrorPerc
Percentage of errors in sent packets at which to declare a problem.
Default: 7
3.4.3. VLAN
Overview
Virtual LAN (VLAN) support in cOS Core allows the definition of one or more Virtual LAN interfaces
which are associated with a particular physical interface. These are then considered to be logical
interfaces by cOS Core and can be treated like any other interfaces in cOS Core rule sets and
routing tables.
151
Chapter 3: Fundamentals
VLANs are useful in several different scenarios. A typical application is to allow one Ethernet
interface to appear as many separate interfaces. This means that the number of physical Ethernet
interfaces on a Clavister Security Gateway need not limit how many totally separated external
networks can be connected.
Another typical usage of VLANs is to group together clients in an organisation so that the traffic
belonging to different groups is kept completely separate in different VLANs. Traffic can then
only flow between the different VLANs under the control of cOS Core and is filtered using the
security policies described by the cOS Core rule sets.
As explained in more detail below, VLAN configuration with cOS Core involves a combination of
VLAN trunks from the Clavister Security Gateway to switches and these switches are configured
with port based VLANs on their interfaces. Any physical security gateway interface can, at the
same time, carry both non-VLAN traffic as well VLAN trunk traffic for one or multiple VLANs.
VLAN Processing
cOS Core follows the IEEE 802.1Q specification. The specifies how VLAN functions by adding a
Virtual LAN Identifier (VLAN ID) to Ethernet frame headers which are part of a VLAN's traffic.
The VLAN ID is a number between 0 and 4095 which is used to identify the specific Virtual LAN to
which each frame belongs. With this mechanism, Ethernet frames can belong to different Virtual
LANs but can still share the same physical Ethernet link.
The following principles underlie the cOS Core processing of VLAN tagged Ethernet frames at a
physical interface:
•
Ethernet frames received on a physical interface by cOS Core, are examined for a VLAN ID. If a
VLAN ID is found and a matching VLAN interface has been defined for that interface, cOS
Core will use the VLAN interface as the logical source interface for further rule set processing.
•
If there is no VLAN ID attached to an Ethernet frame received on an interface then the source
of the frame is considered to be the physical interface and not a VLAN.
•
If VLAN tagged traffic is received on a physical interface and there is no VLAN defined for that
interface in the cOS Core configuration with a corresponding VLAN ID then that traffic is
dropped by cOS Core and an unknown_vlanid log message is generated.
•
The VLAN ID must be unique for a single cOS Core physical interface but the same VLAN ID
can be used on more than one physical interface. In other words, the same VLAN can span
many physical interfaces.
•
A physical interface does not need to be dedicated to VLANs and can carry a mixture of VLAN
and non-VLAN traffic.
Physical VLAN Connection with VLAN
The illustration below shows the connections for a typical cOS Core VLAN scenario.
152
Chapter 3: Fundamentals
Figure 3.1. VLAN Connections
With cOS Core VLANs, the physical connections are as follows:
•
One of more VLANs are configured on a physical Clavister Security Gateway interface and this
is connected directly to a switch. This link acts as a VLAN trunk. The switch used must support
port based VLANs. This means that each port on the switch can be configured with the ID of
the VLAN or VLANs that a port is connected to. The port on the switch that connects to the
security gateway should be configured to accept the VLAN IDs that will flow through the
trunk.
In the illustration above the connections between the interfaces if1 and if2 to the switches
Switch1 and Switch2 are VLAN trunks.
•
Other ports on the switch that connect to VLAN clients are configured with individual VLAN
IDs. Any device connected to one of these ports will then automatically become part of the
VLAN configured for that port. In Cisco switches this is called configuring a Static-access VLAN.
On Switch1 in the illustration above, one interface is configured to be dedicated to VLAN2 and
two others are dedicated to VLAN1.
The switch could also forward trunk traffic from the security gateway into another trunk if
required.
•
More than one interface on the security gateway can carry VLAN trunk traffic and these will
connect to separate switches. More than one trunk can be configured to carry traffic with the
same VLAN ID.
Note: 802.1ad is not supported
153
Chapter 3: Fundamentals
cOS Core does not support the IEEE 802.1ad (provider bridges) standard which allows
VLANs to be run inside other VLANs.
Forwarding DSCP QoS Information
cOS Core forwards, from exiting packets, the 6 bits which make up the Diffserv Differentiated
Services Code Point (DSCP) into VLANs. This is done by copying the bits into the quality of service
bits in VLAN Ethernet frames and applies only for data leaving Clavister Security Gateway
interfaces.
The Diffserv architecture provides quality of service (QoS) information to devices through which
packets of data pass. Diffserv is discussed further in Section 10.1, “Traffic Shaping”.
License Limitations
The number of VLAN interfaces that can be defined for a cOS Core installation is limited by the
parameters of the license used. Some licenses may restrict the total number of VLANs allowed in
a cOS Core installation. License upgrades can be purchased to increase this limit if required.
Summary of VLAN Setup
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.
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.
Port Based VLAN
VLANs on the gesw interfaces of the Clavister E7 hardware series are configured
differently from standard cOS Core VLANs and this is described fully in an appendix of
the separate Eagle E7 Getting Starting Guide.
The VLAN processing overhead for these gesw interfaces is performed by a switch fabric
that connects these interfaces and not cOS Core. This allows the interfaces to be divided
up into a number of different VLANs. The feature is referred to as Port Based VLAN.
It is important to understand that the administrator should treat a VLAN interface just like a
physical interface in that they require both appropriate IP rules and routes to exist in the cOS
Core configuration for traffic to flow through them. For example, if no IP rule with a particular
VLAN interface as the source interface is defined allowing traffic to flow then packets arriving on
that interface will be dropped.
154
Chapter 3: Fundamentals
VLAN advanced settings
There is a single advanced setting for VLAN:
Unknown VLAN Tags
What to do with VLAN packets tagged with an unknown ID.
Default: DropLog
Example 3.15. Defining a VLAN
This simple example defines a virtual LAN called VLAN10 with a VLAN ID of 10. The IP address of
the VLAN is assumed to be already defined in the address book as the object vlan10_ip.
Command-Line Interface
Device:/> add Interface VLAN VLAN10
Ethernet=lan
IP=vlan10_ip
Network=all-nets
VLANID=10
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Network > Interfaces and VPN > VLAN > Add > VLAN
2.
Now enter:
3.
•
Name: Enter a name, for example VLAN10
•
Interface: lan
•
VLAN ID: 10
•
IP Address: vlan10_ip
•
Network: all-nets
Click OK
3.4.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
155
Chapter 3: Fundamentals
broadband service. Using PPPoE the ISP 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
The PPP Protocol
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 layered OSI model, PPP provides a layer 2 encapsulation mechanism to allow
packets of any protocol to travel through IP networks. PPP uses Link Control Protocol (LCP) for
link establishment, configuration and testing. Once the LCP is initialized, one or several Network
Control Protocols (NCPs) can be used to transport traffic for a particular protocol suite, so that
multiple protocols can interoperate on the same link, for example, both IP and IPX traffic can
share a PPP link.
PPP Authentication
PPP authentication is optional with PPP. Authentication protocols supported are Password
Authentication Protocol (PAP), Challenge Handshake Authentication Protocol (CHAP) and 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.
PPPoE Client Configuration
Since the PPPoE protocol allows PPP to operate over Ethernet, the security gateway needs to use
one of the normal physical Ethernet interfaces to run PPPoE over.
Each PPPoE tunnel is interpreted as a logical interface by cOS Core, with the same routing and
configuration capabilities as regular interfaces and with IP rules being applied to all traffic.
Network traffic arriving at the security gateway 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 cOS Core 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 cOS Core 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 cOS
156
Chapter 3: Fundamentals
Core 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 security gateway 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.
Unnumbered PPPoE
When cOS Core acts as a PPPoE client, support for unnumbered PPPoE is provided by default. The
additional option also exists to force unnumbered PPPoE to be used in PPPoE sessions.
Unnumbered PPPoE is typically used when ISPs want to allocate one or more preassigned IP
addresses to users. These IP addresses are then manually entered into client computers. The ISP
does not assign an IP address to the PPPoE client at the time it connects.
A further option with the unnumbered PPPoE feature in cOS Core is to allow the specification of
a single IP address which is used as the address of the PPPoE client interface. This address can
serve the following purposes:
•
The IP address specified will be sent to the PPPoE server as the "preferred IP". If unnumbered
PPPoE is not forced, the server may choose to not accept the preferred IP and instead assign
another IP address to the PPPoE client.
When the option to force unnumbered PPPoE is selected, the client (that is to say cOS Core)
will not accept assignment of another IP address by the server.
•
The IP address specified, or possibly the address assigned by the PPPoE server when
unnumbered PPPoE is not forced, will serve as the IP address of the PPPoE client interface.
This will be used as the local IP address for traffic leaving the interface when the traffic is
originated or NATed by the Clavister Security Gateway.
Note: PPPoE has a discovery protocol
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.
PPPoE cannot be used with HA
For reasons connected with the way IP addresses are shared in a cOS Core high availability
cluster, PPPoE will not operate correctly. It should therefore not be configured with HA.
Example 3.16. Configuring a PPPoE Client
This example shows how to configure a PPPoE client on the wan interface with traffic routed over
PPPoE.
CLI
Device:/> add Interface PPPoETunnel PPPoEClient
EthernetInterface=wan
157
Chapter 3: Fundamentals
Network=all-nets
Username=exampleuser
Password=examplepw
Web Interface
1.
Go to: Network > Interfaces and VPN > PPPoE > Add > PPPoE Tunnel
2.
Then enter:
3.
•
Name: PPPoEClient
•
Physical Interface: wan
•
Remote Network: all-nets (as we will route all traffic into the tunnel)
•
Service Name: Service name provided by the service provider
•
Username: Username provided by the service provider
•
Password: Password provided by the service provider
•
Confirm Password: Retype the password
•
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
Click OK
3.4.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
158
Chapter 3: Fundamentals
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 cOS Core such as an IPsec tunnel, a GRE Tunnel is treated as a logical
interface by cOS Core, with the same filtering, traffic shaping and configuration capabilities as a
standard interface. The GRE options are:
•
IP Address
This is the IPv4 address of the inside of the tunnel on the local side. This cannot be left blank
and must be given a value.
The specified IP address is then used for the following:
•
i.
An ICMP Ping can be sent to this tunnel endpoint.
ii.
Log messages related to the tunnel will be generated with this IP address as the source.
iii.
If NAT is being used then it will not be necessary to set the source IP on the IP rule that
performs NAT on traffic going through the tunnel. This IP address will be used as the
source address for NAT.
Remote Network
The remote network which the GRE tunnel will connect with.
•
Remote Endpoint
This is the IPv4 address of the remote device which the tunnel will connect with.
•
Outer PBR Table
This defines the routing table to be used for the tunnel itself and not the traffic that it is
carrying. In other words, the table used to look up the tunnel endpoint.
•
Use Session Key
A unique number can optionally be specified for the 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 Virtual Routing options are used as with any other interface such as an Ethernet interface
159
Chapter 3: Fundamentals
(see Section 3.4.2, “Ethernet Interfaces”). The routing tables specified here apply to the traffic
carried by the tunnel and not the tunnel itself. The route lookup for the tunnel itself is specified
in the earlier option Outer PBR Table.
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 GRE tunnel. The tunnel setup will appear to be initiated by this IP address
instead of the IPv4 address of the interface that actually sets up the tunnel.
This might be done if, for example, if ARP publishing is being used and the tunnel is to be
setup using an ARP published IP address.
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 cOS Core 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 cOS Core knows what IP addresses should be accepted and sent
through the tunnel.
An Example GRE Scenario
The diagram above shows a typical GRE scenario, where two Clavister Security Gateways 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.
Setup for Clavister Security Gateway "A"
160
Chapter 3: Fundamentals
Assuming that the network 192.168.10.0/24 is lannet on the lan interface, the steps for setting up
cOS Core on A are:
1.
2.
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
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 Int
Src Net
Dest Int
Dest Net
Service
To_B
Allow
lan
lannet
GRE_to_B
remote_net_B
all_services
From_B
Allow
GRE_to_B
remote_net_B
lan
lannet
all_services
Setup for Clavister Security Gateway "B"
Assuming that the network 192.168.11.0/24 is lannet on the lan interface, the steps for setting up
cOS Core on B are as follows:
1.
2.
3.
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
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
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
161
Chapter 3: Fundamentals
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 Int
Src Net
Dest Int
Dest Net
Service
To_A
Allow
lan
lannet
GRE_to_A
remote_net_A
all_services
From_A
Allow
GRE_to_A
remote_net_A
lan
lannet
all_services
Checking GRE Tunnel Status
IPsec tunnels have a status of being either up or not up. With GRE tunnels in cOS Core this does
not really apply. The GRE tunnel is up if it exists in the configuration.
However, we can check on the what is going on with a GRE tunnel. For example, if the tunnel is
called gre_interface then we can use the ifstat CLI command:
Device:/> ifstat gre_interface
This will show us what is happening with the tunnel and the ifstat command options can provide
various details.
3.4.6. Loopback Interfaces
A Loopback Interface is an interface that will take all traffic sent through it and send it out through
a second configured loopback interface. Loopback interfaces are consequently always
configured in pairs with each referring to the other.
Suppose that there is a pair of loopback interfaces defined called LB1 and LB2. When traffic is sent
through LB1, it is simultaneously received on LB2 with the transfer occurring within cOS Core.
Similarly, when traffic is sent through LB2, it is received on LB1. This is exactly the same as if the
two interfaces were physical Ethernet interfaces and they were connected together.
Usage with Virtual Routing
Loopback interfaces are usually used with Virtual Routing. With virtual routing, it is possible to
divide up a single Clavister Security Gateway's operations so that it behaves as multiple virtual
security gateways. This is done by having multiple routing tables so that each table handles the
routing for one set of interfaces.
The routing tables and their associated routes can be totally isolated from each other so that
related traffic flows are completely separate. However, if some traffic needs to flow between
interfaces in separate routing tables, a loopback interface pair must be used (also see Section 4.5,
“Virtual Routing”).
Loopback Interface Parameters
The following are the parameters for a loopback interface:
Name
The name of the interface for display and reference in cOS Core.
Loop to
This is the name of the other loopback interface in the pair. The other interface
will have this loopback interface as its Loop to parameter.
For a pair, the Loop to parameter must be left blank when the first interface is
created and then filled in later after its partner is created.
162
Chapter 3: Fundamentals
IP Address
The IP address assigned to the loopback interface. This is the address that can
be "Pinged" and can be used as the source address for dynamically translated
connections.
Network
The network assigned to the loopback interface and to which the IP Address
above belongs. This does not have to be the same network as the other
loopback interface in the pair.
One of two options can then be selected depending on how the loopback interface is to be used
with routing tables:
•
Make the interface a member of all routing tables
Traffic arriving on this loopback interface will be routed according to the main routing table,
by default.
With this option (which is the default), routes for this interface's IP will be inserted
automatically into all routing tables.
•
Make interface a member of a specific routing table
Specifies the routing table to insert the interface IP route into. It also means that the specified
routing table will be used for all routing lookups for this interface unless overridden by a
routing rule.
With this option, a single route for this interface's IP will be inserted automatically the
specified routing table.
Note: Only the interface IP route is added automatically
Although routes are inserted automatically into routing tables when loopback
interfaces are created these are only for the IP specified for the interface. Extra routes will
most likely have to be added manually, such as the all-nets route in the example below.
Loopback Interface IP Addresses
Loopback interfaces are configured with IP addresses, just as with any other interface type.
However, these IP addresses can be fictitious and the addresses for the pair do not need to be on
the same network although they should be different.
The IP address assigned to a loopback interface is used as the source address for any dynamically
translated connections that are routed over the interface.
If the interface is not used for this purposes then it is more consistent to set the address to one in
the range of the standard loopback IP addresses which is 127.0.0.0 to 127.255.255.255.
A Summary of Loopback Interface Setup
It can be useful to outline the steps required to make use of loopback interfaces in the simplest
possible example.
163
Chapter 3: Fundamentals
Figure 3.2. A Simple Network with Loopback Interfaces
Consider a single Clavister Security Gateway like the one above that has one protected local
network called LAN1. The route to this network is contained in a single routing table called RT1
which is isolated from all other routing tables with its Ordering parameter set to Only.
The security gateway is also connected to the Internet but the all-nets route to the Internet is in a
totally separate and similarly isolated routing table called RT2. In this situation there is no way for
clients on LAN1 to reach the Internet since there is no all-nets route in RT1.
For LAN1 clients to have access to the Internet, loopback interfaces must be used and the setup
process can be summarized into three parts:
•
Define a loopback interface pair with membership in different routing tables.
•
Define routes which route traffic to the loopback interfaces.
•
Define IP rules which allow traffic to flow to and from the loopback interfaces.
A more detailed description of these steps is as follows:
1.
Create a pair of loopback interfaces called LB1 and LB2, each has the other as its Loop to
parameter. Also define LB1 as a member of routing table RT1 and LB2 as a member of RT2.
2.
Two configuration additions are now needed:
3.
i.
Define a route in RT1 that routes all-nets traffic (traffic to the Internet) to the loopback
interface LB1.
ii.
Define an IP rule which allows Internet traffic to flow from LAN1 to LB1.
The Internet traffic that is sent through loopback interface LB1 now automatically arrives at
its partner LB2. Because LB2 is a member of the routing table RT2 that contains the all-nets
route, it can be successfully routed to the Internet.
However, two additions are still needed:
i.
An IP rule needs to be defined which allows traffic to flow from LB2 to the Internet. This
could be in the same IP rule set as the previous rule and will probably be a NAT rule
which makes use of a single external IP address.
ii.
A route needs to be defined which routes LAN1 traffic on the LB2 interface. This is
needed for traffic returning from the Internet.
The relationship of loopback interfaces with the routing tables and networks in this example are
illustrated below.
164
Chapter 3: Fundamentals
Figure 3.3. Components of Loopback Interface Setup
The example below explains the detailed management user interface steps required for creating
a loopback pair.
Example 3.17. Creating a Loopback Interface Pair
This example shows how to create a Loopback Interfaces pair.
Web Interface
A. Create the first loopback interface
1.
Go to: Network > Interfaces and VPN > Loopback > Add > Loopback Interface
2.
Under General enter:
3.
4.
•
Name: enter a suitable name. For example vr1-main
•
Loop to: Leave this field blank for now
Under IP Address enter:
•
IP Address: the IP address of the interface
•
Network: the network for the interface
Click OK
B. Create the second loopback interface
165
Chapter 3: Fundamentals
1.
Go to: Network > Interfaces and VPN > Loopback > Add > Loopback Interface
2.
Under General enter:
3.
4.
•
Name: enter a suitable name, for example vr2-main
•
Loop to: vr1-main
Under IP Address enter:
•
IP Address: the IP address of the interface
•
Network: the network for the interface
Click OK
C. Now go back to the first loopback interface and fill in the Loop to: field as vr2-main
Two interfaces have now been added; main-vr1 and vr1-main. Packets being sent through the
main-vr1 interface will be received on the vr1-main interface and vice versa.
3.4.7. Interface Groups
Any set of cOS Core interfaces can be grouped together into an Interface Group. This then acts as
a single cOS Core configuration object which can be used in creating security policies in the
place of a single group. When a group is used, for example, as the source interface in an IP rule ,
any of the interfaces in the group could provide a match for the rule.
A group can consist of ordinary Ethernet interfaces or it could consist of other types such as
VLAN interfaces or VPN Tunnels. Also, the members of a group do not need to be of the same
type. A group might consist, for example, of a combination of two Ethernet interfaces and four
VLAN interfaces.
The Security/Transport Equivalent Option
When creating an interface group, the option Security/Transport Equivalent can be enabled (it is
disabled by default). Enabling the option means that the group can be used as the destination
interface in cOS Core rules where connections might need to be moved between two interfaces.
For example, the interface might change with route failover or OSPF.
If a connection is moved from one interface to another within a group and Security/Transport
Equivalent is enabled, cOS Core will not check the connection against the cOS Core rule sets with
the new interface.
With the option disabled, a connection cannot be moved to another interface in the group and is
instead dropped and must be reopened. This new connection is then checked against the cOS
Core rule sets. In some cases, such as an alternative interface that is much slower, it may not be
sensible to allow certain connections over the new interface.
Example 3.18. Creating an Interface Group
Command-Line Interface
Device:/> add Interface InterfaceGroup examplegroup
Members=exampleIf1,exampleIf2
166
Chapter 3: Fundamentals
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Network > Interfaces and VPN > Interface Groups > Add > InterfaceGroup
2.
Enter the following information to define the group:
3.
•
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.
•
Interfaces: Select the interfaces to be in the group
Click OK
167
Chapter 3: Fundamentals
3.5. ARP
3.5.1. Overview
Address Resolution Protocol (ARP) allows the mapping of a network layer protocol (OSI layer 3)
address to a data link layer hardware address (OSI layer 2). In data networks it is used to resolve
an IPv4 address into its corresponding Ethernet address. ARP operates at the OSI layer 2, data link
layer, and is encapsulated by Ethernet headers for transmission.
Tip: OSI Layers
See Appendix D, The OSI Framework for an overview of the different OSI layers.
IP Addressing Over Ethernet
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 IPv4 address to the corresponding Ethernet address, it
broadcasts an ARP request packet. The ARP request packet contains the source MAC address, the
source IPv4 address and the destination IPv4 address. Each host in the local network receives this
packet. The host with the specified destination address, sends an ARP reply packet to the
originating host with its MAC address.
3.5.2. The ARP Cache
The ARP Cache in network equipment, such as switches and security gateways, is an important
component in the implementation of ARP. It consists of a dynamic table that stores the
mappings between IP addresses and Ethernet MAC addresses.
cOS Core uses an ARP cache in exactly the same way as other network equipment. Initially, the
cache is empty at cOS Core startup and becomes populated with entries as traffic flows.
The typical contents of a minimal ARP Cache table might look similar to the following:
Type
IPv4 Address
Ethernet Address
Expires
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 explanation for the table contents are as follows:
•
The first entry in this ARP Cache is a dynamic ARP entry which tells us that IPv4 address
192.168.0.10 is mapped to an Ethernet address of 08:00:10:0f:bc:a5.
•
The second entry in the table dynamically maps the IPv4 address 193.13.66.77 to Ethernet
address 0a:46:42:4f:ac:65.
•
The third entry is a static ARP entry binding the IPv4 address 10.5.16.3 to Ethernet address
4a:32:12:6c:89:a4.
168
Chapter 3: Fundamentals
The Expires Column
The third column in the table, Expires, is used to indicate how much longer the ARP entry will be
valid for.
For example, the first entry 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 address after the expiration, cOS Core will issue a new ARP request.
The default expiration time for dynamic ARP entries is 900 seconds (15 minutes). This can be
changed by modifying the advanced setting ARP Expire.
The advanced setting ARP Expire Unknown specifies how long cOS Core will remember
addresses that cannot be reached. This limit is needed to ensure that cOS Core does not
continuously request such addresses. The default value for this setting is 3 seconds.
Example 3.19. Displaying the ARP Cache
The contents of the ARP Cache can be displayed from within the CLI.
Command-Line Interface
Device:/> arp -show
ARP cache of iface lan
Dynamic 10.4.0.1
Dynamic 10.4.0.165
= 1000:0000:4009
= 0002:a529:1f65
Expire=196
Expire=506
Flushing the ARP Cache
If a host in a network is replaced with new hardware and retains the same IP address then it will
probably have a new MAC address. If cOS Core has an old ARP entry for the host in its ARP cache
then that entry will become invalid because of the changed MAC address and this will cause data
to be sent to the host over Ethernet which will never reach its destination.
After the ARP entry expiration time, cOS Core will learn the new MAC address of the host but
sometimes it may be necessary to manually force the update. The easiest way to achieve this is
by flushing the ARP cache. This deletes all dynamic ARP entries from the cache and forces cOS
Core to issue new ARP queries to discover the MAC/IP address mappings for connected hosts.
Flushing can be done with the CLI command arp -flush.
Example 3.20. Flushing the ARP Cache
This example shows how to flush the ARP Cache from within the CLI.
Command-Line Interface
Device:/> arp -flush
ARP cache of all interfaces flushed.
169
Chapter 3: Fundamentals
The Size of the ARP Cache
By default, the ARP Cache is able to hold 4096 ARP entries at the same time. This is adequate for
most scenarios but on rare occasions, such as when there are several very large LANs directly
connected to the security gateway, it may be necessary to adjust this value upwards. This can be
done by modifying the ARP advanced setting ARP Cache Size.
Hash tables are used to rapidly look up entries in the ARP Cache. For maximum efficiency, a hash
table should be twice as large as the entries it is indexing, so if the largest directly connected LAN
contains 500 IP addresses, the size of the ARP entry hash table should be at least 1000. The
administrator can modify the ARP advanced setting ARP Hash Size to reflect specific network
requirements. The default value of this setting is 512.
The setting ARP Hash Size VLAN setting is similar to the ARP Hash Size setting, but affects the
hash size for VLAN interfaces only. The default value is 64.
3.5.3. ARP Publish
Overview
cOS Core supports the publishing of IP addresses on interfaces other than the one the IP address
is actually connected to. This can optionally be done along with a specific MAC address instead
of the publishing interface's MAC address. cOS Core will then send out ARP replies for ARP
requests received on the interface for the published IP addresses. This feature is referred to in
cOS Core as ARP Publish.
Usage
Publishing may be done for a number of reasons:
•
To give the impression that an interface in cOS Core has more than one IP address.
This 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 cOS Core interface.
•
Another use is publishing multiple addresses on an external interface, enabling cOS Core to
statically address translate traffic to these addresses and send it onwards to internal servers
with private IPv4 addresses.
•
A less common purpose is to aid nearby network equipment responding to ARP in an
incorrect manner.
Methods of Enabling ARP Publishing
ARP publishing is enabled in one of two ways:
•
An ARP object can be created for any interface by defining a single address which is to be ARP
published on that interface.
•
When a static route is created for an IPv4 address or network, the route option called Proxy
ARP can be used to publish the address or network on all or selected interfaces.
Using ARP objects, single IP addresses only can be published one at a time. However, the
Proxy ARP feature can publish entire networks. It also provides a single step to publish on all
interfaces.
170
Chapter 3: Fundamentals
Proxy ARP is covered in Section 4.2.6, “Proxy ARP” and is not discussed further in this section.
ARP Object Properties
An ARP object has the following properties:
Mode
The type of ARP object. As explained above, this can be one of:
•
Static - Create a fixed mapping in the local ARP cache.
•
Publish - Publish an IP address on a particular MAC address (or this
interface).
•
XPublish - Publish an IP address on a particular MAC address and "lie"
about the sending MAC address of the Ethernet frame containing the ARP
response.
Interface
The local physical Ethernet interface for the ARP object.
IP Address
The IP address for the MAC/IP mapping.
MAC Address
The MAC address for the MAC/IP mapping. If it is omitted, the MAC address of
the Ethernet interface is used.
The three publishing mode options for ARP objects of Static, Publish and XPublishare further
explained next.
Static Mode ARP Objects
A Static ARP object inserts a mapping into the cOS Core ARP cache which connects a specified IP
address with the associated Ethernet interface's MAC address.
This mode is not for publishing the address for external devices but rather for telling cOS Core
itself how to reach external devices. A static ARP entry tells cOS Core that a specific IP address
can be reached through a specific interface using a specific MAC address. This means, that when
cOS Core wants to communicate with the address, it consults the ARP table static entries and can
determine that it can be reached at a specific MAC address on a specific interface.
The most frequent use of static ARP objects is in situations where some external network device
is not responding to ARP requests correctly and is reporting an incorrect MAC address. Some
network devices, such as wireless modems, can have these problems.
It may also be used to lock an IP address to a specific MAC address for increasing security or to
avoid denial-of-service if there are rogue users in a network. However, such protection only
applies to packets being sent to that IP address. It does not apply to packets being sent from that
IP address.
Publish and XPublish Modes
With Publish and XPublish modes, the ARP object creates an association between an IP address
and a MAC address for publishing on the interface to external devices.
If the MAC address is not specified, the MAC address of the associated Ethernet interface is used.
The Difference Between Publish and XPublish Modes
171
Chapter 3: Fundamentals
To understand the difference between Publish and XPublish it is necessary to understand that
when cOS Core responds to an ARP query, there are two MAC addresses in the Ethernet frame
sent back with the ARP response:
1.
The MAC address in the Ethernet frame of the Ethernet interface sending the response.
2.
The MAC address in the ARP response which is contained within this frame. This is usually
the same as (1) the source MAC address in the Ethernet frame but does not have to be.
These are shown in the illustration below of an Ethernet frame containing an ARP response:
Figure 3.4. An ARP Publish Ethernet Frame
The Publish option uses the real MAC address of the sending interface for the address (1) in the
Ethernet frame.
In rare cases, some network equipment will require that both MAC addresses in the response (1
and 2 above) are the same. In this case XPublish is used since it changes both MAC addresses in
the response to be the published MAC address. In other words, XPublish "lies" about the source
address of the ARP response.
If a published MAC address is the same as the MAC address of the physical interface, it will make
no difference if Publish or XPublish is selected, the result will be the same.
ARP and Neighbor Discovery
Neighbor Discovery with IPv6 is the equivalent of ARP with IPv4. For this reason, ARP and
neighbor discovery are combined in The graphical interface to cOS Core uses the same dialog to
add either one. Neighbor Discovery is discussed further in Section 3.2, “IPv6 Support”.
Example 3.21. Defining an ARP/Neighbor Discovery Object
This example will create a static mapping between IPv4 address 192.168.10.15 and Ethernet
address 4b:86:f6:c5:a2:14 on the lan interface:
Command-Line Interface
172
Chapter 3: Fundamentals
Device:/> add ARPND Interface=lan
IP=192.168.10.15
Mode=Static
MACAddress=4b-86-f6-c5-a2-14
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Network > Interfaces and VPN > ARP/NeighborDiscovery > Add >
ARP/NeighborDiscovery
2.
Select the following:
3.
4.
•
Mode: Static
•
Interface: lan
Enter the following:
•
IP Address: 192.168.10.15
•
MAC: 4b-86-f6-c5-a2-14
Click OK
3.5.4. Using ARP Advanced 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. A summary
of all ARP advanced settings can be found in the next section.
Multicast and Broadcast
ARP requests and ARP replies containing multicast or broadcast addresses are usually never
correct, with the exception of certain load balancing and redundancy devices, which make use of
hardware layer multicast addresses.
The default behavior of cOS Core is to drop and log such ARP requests and ARP replies. This can,
however, be changed by modifying the advanced settings ARP Multicast and ARP Broadcast.
Unsolicited ARP Replies
It is possible for a host on a connected network to send an ARP reply to cOS Core even though a
corresponding ARP request was not issued. This is known as an unsolicited ARP reply.
According to the ARP specification, the recipient should accept these types of ARP replies.
However, because this could be a malicious attempt to hijack a connection, cOS Core will, by
default, drop and log unsolicited ARP replies.
This behavior can be changed by modifying the advanced setting Unsolicited ARP Replies.
173
Chapter 3: Fundamentals
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, cOS Core will normally not allow this.
To make the behavior compliant with the RFC 826 specification, the administrator can modify
the setting ARP Requests. Even if this is set to Drop (meaning that the packet is discarded
without being stored), cOS Core will reply to it provided that other rules approve the request.
Changes to the ARP Cache
A received ARP reply or ARP request can possibly alter an existing entry 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 since cOS Core will not accept
the new address until the previous ARP cache entry has timed out.
The advanced setting Static ARP Changes can modify this behavior. The default behavior is that
cOS Core will allow changes to take place, but all such changes will be logged.
A similar issue occurs when information in ARP replies or ARP requests could collide with static
entries in the ARP cache. This should not be allowed to happen and changing the setting Static
ARP Changes allows the administrator to specify whether or not such situations are logged.
Sender IP 0.0.0.0
cOS Core can be configured for handling ARP queries that have a sender IP of 0.0.0.0. Such
sender IPs are never valid as 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 setting ARP
Query No Sender.
Matching Ethernet Addresses
By default, cOS Core 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. The behavior can be changed by modifying the setting ARP Match Ethernet Sender.
3.5.5. ARP Advanced Settings Summary
The following advanced settings are available with ARP:
ARP Match Ethernet Sender
Determines if cOS Core will require the sender address at Ethernet level to comply with the
hardware address reported in the ARP data.
Default: DropLog
ARP Query No Sender
Handles 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.
174
Chapter 3: Fundamentals
Default: DropLog
ARP Sender IP
Determines if the IP sender address must comply with the rules in the Access section.
Default: Validate
Unsolicited ARP Replies
Determines how cOS Core will handle ARP replies that it has not asked for. According to the ARP
specification, the recipient should accept these. However, because this can facilitate hijacking of
local connections, it is not normally allowed.
Default: DropLog
ARP Requests
Determines if cOS Core will automatically add the data in ARP requests to its ARP table. The ARP
specification states that this should be done, but as this procedure can facilitate hijacking of local
connections, it is not normally allowed. Even if ARPRequests is set to "Drop", meaning that the
packet is discarded without being stored, cOS Core will, provided that other rules approve the
request, reply to it.
Default: Drop
ARP Changes
Determines how cOS Core will deal with situations where a received ARP reply or ARP request
would alter an existing item in the ARP table. Allowing this to take place may facilitate hijacking
of local connections. However, not allowing this may cause problems if, for example, a network
adapter is replaced, as cOS Core will not accept the new address until the previous ARP table
entry has timed out.
Default: AcceptLog
Static ARP Changes
Determines how cOS Core will handle situations where a received ARP reply or ARP request
would alter a static item in the ARP table. Of course, this is never allowed to happen. However,
this setting does allow the administrator to specify whether or not such situations are to be
logged.
Default: DropLog
Log ARP Resolve Failure
This determines whether cOS Core will log failed ARP resolve requests or not. Logging can be
used for monitoring purposes and can be helpful for troubleshooting network related problems.
However, disabling logging can prevent attempts to "spam" log receivers with failed resolve
requests.
Default: Enabled
175
Chapter 3: Fundamentals
ARP Expire
Specifies how long a normal dynamic item in the ARP table is to be retained before it is removed
from the table.
Default: 900 seconds (15 minutes)
ARP Expire Unknown
Specifies in seconds how long cOS Core is to remember addresses that cannot be reached. This is
done to ensure that cOS Core does not continuously request such addresses.
Default: 3
ARP Multicast
Determines how cOS Core is to deal with ARP requests and ARP replies that state that they are
multicast addresses. Such claims are usually never correct, with the exception of certain load
balancing and redundancy devices, which make use of hardware layer multicast addresses.
Default: DropLog
ARP Broadcast
Determines how cOS Core deals with ARP requests and ARP replies that state that they are
broadcast addresses. Such claims are usually never correct.
Default: DropLog
ARP cache size
How many ARP entries there can be in the cache in total.
Default: 4096
ARP Hash Size
Hashing is used to rapidly look up entries in a table. For maximum efficiency, the hash size
should be twice as large as the table it is indexing. If the largest directly-connected LAN contains
500 IP addresses then the size of the ARP entry hash should be at least 1000 entries.
Default: 512
ARP Hash Size VLAN
Hashing is used to rapidly look up entries in a table. For maximum efficiency, the hash size
should be twice as large as the table it is indexing, so if the largest directly-connected VLAN
contains 500 IP addresses, the size of the ARP entry hash should be at least 1000 entries.
Default: 64
ARP IP Collision
176
Chapter 3: Fundamentals
Determines the behavior when receiving an ARP request with a sender IP address that collides
with one already used on the receive interface. Possible actions: Drop or Notify.
Default: Drop
177
Chapter 3: Fundamentals
3.6. IP Rules and IP Policies
3.6.1. Security Policies
Before examining IP rule sets in detail, we will first look at the generic concept of security polices
to which IP rule sets belong.
Security Policy Characteristics
cOS Core security policies are configured by the administrator to regulate the way in which traffic
can flow through the Clavister Security Gateway. Such policies are described by the contents of
different cOS Core rule sets. These rule sets share a uniform means of specifying filtering criteria
which determine the type of traffic to which they will apply. The possible filtering criteria consist
of the following:
Source Interface
An Interface or Interface Group where the packet is received
at the Clavister Security Gateway. This could also be a VPN
tunnel.
Source Network
The network that contains the source IP address of the packet.
This might be a cOS Core IP object which could define a single
IP address or range of addresses.
Destination Interface
An Interface or an Interface Group from which the packet
would leave the Clavister Security Gateway. This could also be a
VPN tunnel.
Destination Network
The network to which the destination IP address of the packet
belongs. This might be a cOS Core IP object which could define
a single IP address or range of addresses.
Service
The protocol type to which the packet belongs. Service objects
define a protocol/port type. Examples are HTTP and ICMP.
Service objects also define any ALG which is to be applied to the
traffic
cOS Core provides a large number of predefined service objects
but administrator defined custom services can also be created.
Existing service objects can also be collected together into
service groups.
See Section 3.3, “Services” for more information about this topic.
The cOS Core Security Policy Rule Sets
The principle cOS Core rule sets that define cOS Core security policies, and which use the same
filtering parameters described above (networks/interfaces/service), include:
•
IP Rules
IP Rule objects determine which traffic is permitted to pass through the Clavister Security
Gateway as well as determining if the traffic is subject to address translation. The network
filter for these rules can be IPv4 or IPv6 addresses (but not both in a single rule). They are
described further later in this section.
•
IP Policies
178
Chapter 3: Fundamentals
The IP Policy object is an alternative to using IP Rule objects. They are designed to simply the
creation of policies and make it easier to define such common tasks as address translation. IP
Policy objects are implemented in the background by IP Rule objects and one IP Policy may
correspond to more than one IP Rule.
•
Pipe Rules
These determine which traffic triggers traffic shaping to take place and are described in
Section 10.1, “Traffic Shaping”.
•
Policy-based Routing Rules
These rules determine the routing table to be used by traffic and are described in Section 4.3,
“Policy-based Routing”. The network filter for these rules can be IPv4 or IPv6 addresses (but
not both in a single rule).
•
IDP Rules
These determine which traffic is subject to IDP scanning and are described in Section 6.5,
“Intrusion Detection and Prevention”.
•
Authentication Rules
These determine which traffic triggers authentication to take place (source net/interface
only) and are described in Chapter 8, User Authentication.
The Default main IP Rule Set
IP rule sets are the most important of these security policy rule sets. They determine the critical
packet filtering function of cOS Core, regulating what is allowed or not allowed to pass through
the Clavister Security Gateway, and if necessary, how address translations like NAT are applied. IP
rule sets can contain both IP Rule and IP Policy objects. By default, one IP rule set always exist and
this has the name main.
There are two possible approaches to how traffic traversing the Clavister Security Gateway could
be dealt with:
•
Everything is denied unless specifically permitted.
•
Or everything is permitted unless specifically denied.
To provide the best security, the first of these approaches is adopted by cOS Core. This means
that when first installed and started, the cOS Core has no rules defined in the main IP rule set and
all traffic is therefore dropped. In order to permit any traffic to traverse the Clavister Security
Gateway (as well as allowing cOS Core to respond to ICMP Ping requests), some IP rules must be
defined by the administrator.
Each IP rule or IP policy that is added by the administrator will define the following basic filtering
criteria:
•
From what interface to what interface traffic flows.
•
From what network to what network the traffic flows.
•
What kind of protocol is affected (the service).
•
What action the rule will take when a match on the filter triggers.
179
Chapter 3: Fundamentals
Specifying Any Interface or Network
When specifying the filtering criteria in any of the policy rule sets, there are several useful
predefined configuration objects 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 cOS Core 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 Clavister Security Gateway itself and cOS Core will respond to it.
New connections that are initiated by cOS Core itself do not need an explicit IP rule as they
are allowed by default. For this reason, the interface core is not used as the source interface.
Such connections include those needed to connect to the external databases needed for
such cOS Core features as IDP and dynamic web content filtering.
•
The Service can be specified as all_services which includes all possible protocols.
Creating a Drop All Rule
Traffic that does not match any rule in the IP rule set is, by default, dropped by cOS Core. In order
to be able to log the dropped connections, it is recommended that an explicit IP rule with an
action of Drop for all source/destination networks/interfaces is placed as the last IP rule in the IP
rule set. This is often referred to as a Drop All rule.
Tip: Include the rule set name in the drop all name
There may be several IP rule sets in use. It is recommended to include the IP rule set name
in the name of the drop all rule so it can be easily identified in log messages.
For example, the drop all rule for the main rule set should be called main_drop_all or
similar.
The IP Addresses in IP Rules can be IPv4 or IPv6
IP rules support either IPv4 or IPv6 addresses as the source and destination network for a rule's
filtering properties.
However both the source and destination network must be either IPv4 or IPv6. It is not
permissible to combine IPv4 and IPv6 addresses in a single rule. For this reason, two Drop All
rules will be required when using IPv6, one for IPv4 and one for IPv6 as shown below:
Name
Action
Source Iface
Source Net
Dest Iface
Dest Net
Service
DropAll
Drop
any
all-nets
any
all-nets
all_services
DropAll6
Drop
any
all-nets6
any
all-nets6
all_services
For further discussion of this topic, see Section 3.2, “IPv6 Support”.
Traffic Flow Needs an IP Rule and a Route
180
Chapter 3: Fundamentals
As stated above, when cOS Core is started for the first time, the default IP rules drop all traffic so
at least one IP rule must be added to allow traffic to flow. In fact, two cOS Core components need
to be present:
•
A route must exist in a cOS Core routing table which specifies on which interface packets
should leave in order to reach their destination.
A second route must also exist that indicates the source of the traffic is found on the interface
where the packets enter.
•
An IP rule in a cOS Core IP rule set which specifies the security policy that allows the packets
from the source interface and network bound for the destination network to leave the
Clavister Security Gateway on the interface decided by the route.
If the IP rule used is an Allow rule then this is bi-directional by default.
The ordering of these steps is important. The route lookup occurs first to determine the exiting
interface and then cOS Core looks for an IP rule that allows the traffic to leave on that interface. If
a rule does not exist then the traffic is dropped.
Figure 3.5. Simplified cOS Core Traffic Flow
This description of traffic flow is an extremely simplified version of the full flow description found
in Section 1.3, “cOS Core State Engine Packet Flow”.
For example, before the route lookup is done, cOS Core first checks that traffic from the source
network should, in fact, be arriving on the interface where it was received. This is done by cOS
Core performing a reverse route lookup which means that the routing tables are searched for a
route that indicates the network should be found on that interface.
This second route should logically exist if a connection is bi-directional and it must have a pair of
routes associated with it, one for each direction.
3.6.2. IP Rule Set Evaluation
When a new connection, such as a TCP/IP connection, is being established through the Clavister
Security Gateway, the IP rule set if scanned from top to bottom until a rule that matches the
parameters of the new connection is found. The first matching rule's Action is then performed.
If the action allows it, the establishment of the new connection will go ahead. A new entry or
state representing the new connection will then be added to the cOS Core internal state table
181
Chapter 3: Fundamentals
which allows monitoring of opened and active connections passing through the Clavister
Security Gateway. If the action is Drop or Reject then the new connection is refused.
Tip: Rules in the wrong order sometimes cause problems
It is important to remember the principle that cOS Core searches the IP rule set from top
to bottom, looking for the first matching rule.
If a rule set entry seems to be ignored, check that some other rule above it is not being
triggered first.
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 much faster
search of the state table is performed for each packet to determine if it belongs to an established
connection.
This approach to packet processing is known as stateful inspection and is applied not only to
stateful protocols such as TCP but is also applied to stateless protocols such as UDP and ICMP by
using the concept of "pseudo-connections" . 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
therefore 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.4, “SAT” for more information about this topic.
Non-matching Traffic
Incoming packets that do not match any rule in the rule set and that do not have an already
opened matching connection in the state table, will automatically be subject to a Drop action. As
mentioned above, to be able to log non-matching traffic, it is recommended to create an explicit
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. This allows logging to be turned on for
traffic that matches no IP rule.
3.6.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 cOS Core rule, including IP
rules are:
•
Source Interface
•
Source Network
•
Destination Interface
•
Destination Network
182
Chapter 3: Fundamentals
•
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, “ALGs”).
When an IP rule is triggered by a match then one of the following Actions can occur:
Allow
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 cOS Core
"stateful engine".
FwdFast
Let the packet pass through the Clavister Security Gateway 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.
NAT
This functions like an Allow rule, but with dynamic address translation (NAT) enabled
(see Section 7.2, “NAT” in Chapter 7, Address Translation for a detailed description).
SAT
This tells cOS Core to perform static address translation. A SAT rule always requires a
matching Allow, NAT or FwdFast IP rule further down the rule set (see Section 7.4,
“SAT” in Chapter 7, Address Translation for a detailed description).
Drop
This tells cOS Core 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.
Reject
This acts like Drop but will return a TCP RST or ICMP Unreachable message, informing
the sending computer that the packet was dropped. This is a "polite" version of the
Drop IP rule action.
Reject is useful where applications that send traffic wait for a timeout to occur before
realizing that the traffic was dropped. If an explicit reply is sent indicating that the
traffic was dropped, the application need not wait for the timeout.
Note: Some actions alter TCP sequence numbers
In some situations with certain types of network equipment, the TCP sequence number
needs to remain the same as data traffic traverses the security gateway.
It is therefore important to know that only the FwdFast action guarantees that the TCP
sequence number is unaltered. Other IP rule actions, such as Allow and NAT change the
TCP sequence number as traffic flows through cOS Core.
Logging
When an IP Rule or IP Policy object is created the default is that logging is enabled. This means
that a log message is generated whenever either is triggered. This behavior can be altered by
disabling logging on the individual rule or policy object.
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
183
Chapter 3: Fundamentals
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. If a
connection is permitted and then becomes established, traffic can flow in either direction over it.
The exception to this bi-directional flow is FwdFast rules. If the FwdFast action is used, 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.
Using Reject
In certain situations the Reject action is recommended instead of the Drop action because a
"polite" reply is required from cOS Core. An example of such a situation is when responding to
the IDENT user identification protocol. Some applications will pause for a timeout if Drop is used
and Reject can avoid such processing delays.
3.6.4. Multiple IP Rule Sets
Overview
cOS Core allows the administrator to define multiple IP rule sets which can both simplify and
provide greater flexibility when defining security policies. The default IP rule set is known as main
and is always present in cOS Core. Additional rule sets can be defined as needed and are given a
name by the administrator.
Multiple IP rule sets offer many advantages, among them:
•
The administrator can break a single large IP rule set into multiple, smaller and more
manageable rule sets.
•
A single named IP rule set can be associated with a routing table. This makes implementing
Virtual Routing much simpler since each router can have a dedicated IP Rules-set associated
with it. See Section 4.5, “Virtual Routing” for more information about this topic.
•
IP rule lookup speed can be increased for large numbers of rules by breaking one large rule
set down into several smaller ones.
Searching Multiple rule sets
When multiple rule sets are defined, the way they are processed for a new connection is as
follows:
•
The primary main IP rule set is always searched first for matches of source/destination
interface/network.
•
User-defined rule sets are used in a rule look-up only when the action specified for a
matching rule in main is Goto. The Goto action must have a named, administrator defined IP
rule set associated with it and if the traffic matches the Goto rule then the rule look-up
continues from the beginning of that named rule set.
A Goto may never use the main rule set as its target.
•
If the search in the named rule set finds no match then the connection is dropped.
•
If a match is found in the named rule set then the action is executed. The action might be
another Goto in which case the rule scanning jumps to the beginning of another named rule
set.
184
Chapter 3: Fundamentals
If the action is Return then the rule scanning resumes at the rule which follows the last Goto
action (if there was no last Goto then the connection is dropped and rule scanning stops).
Loop Avoidance
It is conceivable that a sequence of Goto actions results in an infinite looping scanning
sequence. cOS Core detects such logic when a configuration is initially uploaded. A new
configuration is rejected if multiple IP rule set logic is detected that could potentially cause a
loop condition.
The loop avoidance mechanism has to be efficient to enable fast configuration upload and for
this reason it uses an algorithm that might sometimes find a fault in correct but complex logic. In
this case it may be necessary to simplify the rule logic so the configuration can be uploaded.
A Usage Example
Below are two simple IP Rule set tables which illustrate how multiple rule sets might be used. The
main rule set contains a first rule which has a Goto action which references the named
administrator defined table called ExtraRules.
The administrator defined rule set ExtraRules contains a NAT and SAT rule. If neither are triggered
then the final rule has a Return action which will cause the scanning process to go back to the
rule in main which follows the Goto rule. In this case it will be the second rule in main.
The main IP rule set
#
Action
Src Iface
Src Net
Dest Iface
Dest Net
Service
1
Goto ExtraRules
any
all-nets
core
172.16.40.0/24
all_services
2
Allow
any
192.168.0.0/24
core
172.16.0.0/16
all_services
The ExtraRules IP rule set
#
Action
Src Iface
Src Net
Dest Iface
Dest Net
Service
1
SAT
any
all-nets
any
172.16.40.66
all_services
2
NAT
If2
176.16.0.0/16
any
all-nets
all_services
3
RETURN
If2
all-nets
any
all-nets
all_services
Increasing IP Rule Lookup Speed
When the main rule set starts to contain many thousands of rules, the speed of IP rule lookup can
become impaired and this can degrade the overall throughput of the security gateway. Typical
symptoms of this can be:
•
Consistently high CPU loads in the security gateway.
•
Unusually long loading times for Web Interface pages (which is a result of high CPU loads).
The solution is to break the large table up and place the rules into several new rule sets, each
containing the rules related to a generalized aspect of traffic throughput. A small number of IP
185
Chapter 3: Fundamentals
rules with a Goto action are then added to the main rule set, and these point to the rule set that
contains the individual rules that related to the traffic that triggers the Goto.
For example, the main IP rule set may contain many thousands of rules where the Destination
Network might be one of number of networks such as dmz_net, lan_net or wan_net. It can be
much more efficient to divide these rules based on Destination Network and place each group in
new rule sets which might be called dmz_rules, lan_rules and wan_rules.
In their place, a single IP rule is placed in the main rule set to point to these new rule sets:
Action
Src Iface
Src Net
Dest Iface
Dest Net
Service
Goto dmz_rules
any
all-nets
any
dmz_net
all_services
Goto lan_rules
any
all-nets
any
lan_net
all_services
Goto wan_rules
any
all-nets
any
wan_net
all_services
When a new connection is opened with dmz_net as the destination, cOS Core first performs a
lookup in the main table. The Goto rule triggers and the rule search continues in the rule set
called dmz_ip_rules. This example uses the destination network as the method of dividing up the
rules but another factor, such as an interface, could have been used. The diagram below
illustrates the example.
In essence, this approach is creating a two level tree structure, a technique which is used in many
situations for efficient searching of large amounts of data. The maximum number of IP rules
placed in the new rule sets created is decided on a case by case basis but it recommended that
they contain no more than one thousand rules.
3.6.5. IP Rule Set Folders
In order to help organise large numbers of entries in IP rule sets, it is possible to create IP rule set
folders. These folders are just like a folder in a computer's file system. They are created with a
given name and can then be used to contain all the IP rules that are related together as a group.
186
Chapter 3: Fundamentals
Using folders is simply a way for the administrator to conveniently divide up IP rule set entries
and no special properties are given to entries in different folders. cOS Core continues to see all
entries as though they were in a single set of IP rules.
The folder concept is also used by cOS Core in the address book, where related IP address objects
can be grouped together in administrator created folders.
Example 3.22. Adding an Allow IP Rule
This example shows how to create a simple Allow rule that will allow HTTP connections to be
opened from the lan_net network on the lan interface to any network (all-nets) on the wan
interface.
Command-Line Interface
Device:/> add IPRule
Action=Allow
Service=http
SourceInterface=lan
SourceNetwork=lan_net
DestinationInterface=wan
DestinationNetwork=all-nets
Name=lan_http
Configuration changes must be saved by then issuing an activate followed by a commit
command.
Web Interface
1.
Go to: Policies > Add > IPRule
2.
Specify a suitable name for the rule, for example LAN_HTTP
3.
Now enter:
4.
•
Name: A suitable name for the rule. For example lan_http
•
Action: Allow
•
Service: http
•
Source Interface: lan
•
Source Network: lan_net
•
Destination Interface: wan
•
Destination Network: all-nets
Click OK
3.6.6. Configuration Object Groups
The concept of folders can be used to organise groups of cOS Core objects into related
collections. These work much like the folders concept found in a computer's file system. Folders
are described in relation to the address book in Section 3.1.6, “Address Book Folders” and can also
187
Chapter 3: Fundamentals
be used when organizing IP rules.
A compliment and alternative to folders for organizing objects is using configuration object
groups. Object groups allows the administrator to gather together and color code configuration
objects under a specified title text so their relationships are more easily understood when they
are displayed in a cOS Core graphical user interface. Unlike folders, they do not require each
folder to be opened for individual objects to become visible. Instead, all objects in all groupings
are visible at once.
Object groups can be used not only for address book objects but in most cases where cOS Core
objects are displayed as tables and each line represents an object instance. The most common
usage of this feature is likely to be for either the cOS Core Address Book to arrange IP addresses
or for organizing rules in IP rule sets.
Tip: Object groups help to document configurations
Object groups are a recommended way to document the contents of cOS Core
configurations.
This can be very useful for someone seeing a configuration for the first time. In an IP rule
set that contains hundreds of rules, object groups provide a means to quickly identify
those rules associated with a specific aspect of cOS Core operation.
Object Group Usage with InControl
Object groups are used in the same way in both the Web Interface and InControl. The description
in this section applies to both user interfaces although the screen shots used come from the Web
Interface. Both interfaces provide the same options for manipulating groups although there are
small layout differences.
Object Groups and the CLI
The display function of object groups means they do not have relevance to the command line
interface (CLI). It is not possible to define or otherwise modify object groups with the CLI and
they will not be displayed in CLI output. Any group editing must be done through the Web
Interface or InControl and this is described next.
A Simple Example
As an example, consider the IP rule set main which contains just two rules to allow web surfing
from an internal network and a third Drop-all rule to catch any other traffic so that it can be
logged:
Note
The screen images used in this example show just the first few columns of the object
188
Chapter 3: Fundamentals
properties.
If it is desirable to create an object group for the two IP rules for web surfing, this is done with the
following steps:
•
Select the first object to be in the new group by right clicking it.
•
Select the New Group option from the context menu.
•
A group is now created with a title line and the IP rule as its only member. The default title of
"(new Group)" is used.
The entire group is also assigned a default color and the group member is also indented. The
object inside the group retains the same index number to indicate its position in the whole
table. The index is not affected by group membership. The group title line does not have or
need an index number since it is only a textual label.
Editing Group Properties
To change the properties of a group, right click the group title line and select the Edit option
from the context menu.
A Group editing dialog will be displayed which allows two functions:
•
Specify the Title
The title of the group can be any text that is required and can contain new lines as well as
empty lines. There is also no requirement that the group name is unique since it is used
purely as a label.
•
Change the Display Color
Any color can be chosen for the group. The color can be selected from the 16 predefined
color boxes or entered as a hexadecimal RGB value. In addition, when the hexadecimal value
189
Chapter 3: Fundamentals
box is selected, a full spectrum color palette appears which allows selection by clicking any
color in the box with the mouse.
In this example, we might change the name of the group to be Web surfing and also change the
group color to green. The resulting group display is shown below:
Adding Additional Objects
A new group will always contain just one object. Now, we must add more objects to the group.
By right clicking the object that immediately follows the group, we can select the Join
Preceding option to add it to the preceding group.
Once we do this for the second IP rule in our example then the result will be the following:
To add any object to the group we must first position it immediately following the group and
then select the Join Preceding option. This is explained in more detail next.
Adding Preceding Objects
If an object precedes a group or is in any position other than immediately following the group,
then this is done in a multi-step process:
i.
Right click the object and select the Move to option.
ii.
Enter the index of the position immediately following the target group.
iii.
After the object has been moved to the new position, right click the object again and select
the Join Preceding option.
190
Chapter 3: Fundamentals
Moving Group Objects
Once an object, such as an IP rule, is within a group, the context of move operations becomes the
group. For example, right clicking a group object and selecting Move to Top will move the
object to the top of the group, not the top of the entire table.
Moving Groups
Groups can be moved in the same way as individual objects. By right clicking the group title line,
the context menu includes options to move the entire group. For example, the Move to Top
option moves the entire group to the top of the table.
Leaving a Group
If an object in a group is right clicked then the context menu contains the option Leave Group.
Selecting this removes the object from the group AND moves it down to a position immediately
following the group.
Removing a Group
By right clicking on a group title, the displayed context menu includes the Ungroup option. This
removes the group, however all the group's member objects remain. The group title line
disappears and the individual members appear unindented in the normal ungrouped color.
Individual object index positions within the table are not affected.
A group is also removed if there are no members left. If there is only one member of a group,
when this leaves the group, the group will no longer exist and the title line will disappear..
Groups and Folders
It is important to distinguish between collecting together objects using a folder and collecting it
together using groups.
Either can be used to group objects but a folder is similar to the concept of a folder in a
computer's file system. However, a folder can not be part of a group. Groups collect together
related basic objects and a folder is not of this type. It is possible, on the other hand, to use
groups within a folder.
It is up to the administrator how to best use these features to best arrange cOS Core objects.
3.6.7. IP Policies
The IP Rule objects described previously provide very finely grained control over how arriving
traffic is handled by cOS Core. The IP Policy object provides the ability to achieve the same results
as IP rules but in a more intuitive way so that simple policies can be quickly defined.
The aim with an IP policy is to hide some of the potential complexities of IP rules. For example, a
NAT policy might require several IP rules but may be achievable with a single IP policy. The
several IP rules are still created in the background but the administrator is only aware of the IP
policy object.
It is up to the administrator to decide if they will use an IP rule or an IP policy to describe what is
required from cOS Core. Where there is a choice, using an IP policy is recommended.
191
Chapter 3: Fundamentals
Creating IP Policies
An IP policy has the following basic properties:
•
Allow or Deny Action
An IP policy either allows a particular type of traffic or it denies it. The action Deny is
equivalent to the action Drop in IP rules.
•
Source/Destination Interface/Network Filter
This filter identifies the traffic of interest in the same way that an IP rule filter does.
•
Service
This identifies the type of protocol for the policy. When using an IP policy with certain
options, only services that have the Protocol property set can be used. These are listed below.
•
Policy Option
The traffic identified by the filter is subject to one of more of possible options. These are:
i.
Logging - This is enabled or disabled.
ii.
Anti-Virus - An Anti-Virus policy can be selected. This requires a Service object with the
Protocol property set.
iii.
Web Content Filtering - A WCF policy can be selected. This requires a Service object with
the Protocol property set.
iv.
Application Control - An Application Control policy can be selected. Any Service object
can be used with this option.
v.
URL Filter - When the service has the protocol equal to HTTP, this can be selected to
whitelist or blacklist URLs. This requires a Service object with the Protocol property set.
vi.
File Control - This can block or allow specific filetypes. It is only applicable to the HTTP,
SMTP, POP3 and FTP protocols. This requires a Service object with the Protocol property
set.
vii. Advanced Actions - It is possible to specify the Reject action for denied connections (no
acknowledgement is sent to the source host).
Some Policy Options Require a Service with a Protocol Set
As mentioned above, certain IP policy options can be used only if the service used has the
Protocol property set. Certain predefined services already have a Protocol set. Any newly created,
custom services must have the protocol set if they are to be used with those options..
For example, if Dynamic Web Content Filtering is to be enabled with an IP Policy object then the
predefined service called http-outbound should be used and this has the Protocol set to HTTP. The
more general service object called http-all could not be used since the protocol is not be set
(although it could be set).
Application control is the one option which does not require a special Service object.
Viewing IP Rules Created by IP Policies
192
Chapter 3: Fundamentals
As mentioned previously, IP policies create IP rules in the background. These IP rules cannot be
viewed through the Web Interface. However, they can be seen in the output from the CLI
command:
Device:/> rules
Example 3.23. Setting up a Policy to Allow Connections to a DMZ
In this simple example, new HTTP connections will be allowed from the internal lan_net network
on the lan interface to the network dmz_net on the dmz interface.
Command-Line Interface
Device:/> add IPPolicy
Name=lan_to_dmz
SourceInterface=lan
SourceNetwork=lan_net
DestinationInterface=dmz
DestinationNetwork=dmz_net
Service=http-all
Action=Allow
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Policies > Firewalling > Add > IP Policy
2.
Now enter:
3.
•
Name: lan_to_dmz
•
Action: Allow
•
Source Interface: lan
•
Source Network: lan_net
•
Destination Interface: dmz
•
Destination Network: dmz_net
•
Service: http-all
Select OK
Example 3.24. Setting up a SAT Policy to an Internal Web Server
In this example, a SAT policy will be set up to allow external public Internet traffic to access an
internal web server with an IP of server_ip.
Command-Line Interface
193
Chapter 3: Fundamentals
Device:/> add IPPolicy
Name=http_to_server
Action=Allow
SourceInterface=wan
SourceNetwork=all-nets
DestinationInterface=core
DestinationNetwork=wan_ip
Service=http-all
DestinationAction=SAT
DestNewIP=server_ip
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Policies > Firewalling > Add > IP Policy
2.
Now enter:
•
Name: http_to_server
•
Action: Allow
•
Source Interface: wan
•
Source Network: all-nets
•
Destination Interface: core
•
Destination Network: wan_ip
•
Service: http-all
3.
Select Address Translation
4.
Select the SAT option
5.
Enter the web server's IP address for New IP
3.6.8. Application Control
IP rules or IP policies can be set up so they apply only to traffic related to specific applications. An
example of an application that might require this kind of administrator control is traffic related to
BitTorrent. Applying IP rules or IP policies based on the application type is known in cOS Core as
Application Control.
The application control subsystem is driven using a database of application signatures. Each
signature corresponding to one type of application. The entire signature database is listed in the
separate document entitled cOS Core Application Control Signatures.
For application control to work, the current cOS Core license must allow the feature and the
effect of not having a license that allows it is discussed later in this section.
Enabling Application Control
194
Chapter 3: Fundamentals
Application Control can be enabled in two ways:
•
Specifying applications directly for IP rules or IP policies.
This is the basic way of either allowing or denying the data flows associated with a given
application. This is often used when testing application control since it is simple but does not
provide much flexibility.
•
Associating an Application Rule Set with an IP rule or IP policy
This is the recommended method of using application control and provides more flexible
ways to handle the data flows associated with applications. An Application Rule Set is first
created which defines how an application is to be handled, then one or more Application Rule
objects are added to it. The entire rule set is then associated with an IP rule or IP policy object
These two methods of configuring application control and these are examined next.
Associating Directly with IP Rules or IP Policies
IP rules that use application control are created in the following way:
•
Create an IP rule or IP policy with a set of filter parameters to identify connections.
•
Use an Action of Allow or NAT.
•
Enable application control, select the option to use manual configuration and add the
applications that are to be allowed or denied.
If the Deny option is selected but no applications are selected then everything is allowed. If
the Allow option is selected but no applications are selected then nothing will be allowed.
Example 3.25. Specifying an Application Control Policy
This example creates an IP rule to deny connections originating from the lan network which
match the *_groups signature filter. These will include access to sites such as yahoo_groups and
google_groups.
Command-Line Interface
First, the appcontrol command must be used to create a list of the applications we are interested
in.
Device:/> appcontrol -filter -name=*_groups -save_list
This creates a list with a designation of 1. Next, the list is used in an IP rule.
Device:/> add IPRule Action=Allow
SourceInterface=lan
SourceNetwork=lan_net
DestinationInterface=all
DestinationNetwork=all-nets
Service=all_services
AppControl=Yes
AC_AppAction=Deny
AC_Applications=1
Name=Allow_Comp
195
Chapter 3: Fundamentals
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Policies > Add > IPRule
2.
Specify a suitable name for the rule, in this case Allow_Comp
3.
Now enter:
4.
5.
•
Action: Allow
•
Service: all_services
•
Source Interface: lan
•
Source Network: lan_net
•
Destination Interface: all
•
Destination Network: all-nets
Go to the Application Control tab and enter the following:
•
Application Control: Enable
•
Use Manual Configuration: Enable
•
Application Action: Deny
•
Using the Add button, select yahoo_groups and google_groups from the application
definitions.
Click OK
Using an Application Rule Set
As described previously, another, recommended way of controlling applications is to create an
Application Rule Set and associate this with an IP rule or IP Policy.
An Application Rule Set will contain one or more Application Rule objects which define an
application and what actions are to be taken when the application is recognized. This method of
using application control allows not only data for a certain application to be allowed or denied
but also the following additional controls:
•
Authentication Settings
For an Allow rule, the requesting client is only permitted the connection if they already been
authenticated by cOS Core and are one of the usernames specified for the rule or belong to
one of the specified groups.
For a Deny rule, the requesting client is denied the connection if they are authenticated and
are one of the usernames specified or belong to one of the specified groups.
Authentication may have performed using any of the methods available in cOS Core
196
Chapter 3: Fundamentals
Authentication Rule objects, including Identity Awareness.
If no groups or usernames are specified in the rule, authentication is ignored.
•
Traffic Shaping Settings
Predefined cOS Core Pipe objects can be associated with the rule so the bandwidth limit
specified by pipe objects can be placed on the either direction of data flow or both.
This feature therefore allows bandwidth limits to be placed on a given application and, if
used in conjunction with the authentication setting, on particular users or user groups using
that application.
Traffic shaping is only relevant if the Application Control Rule has an action of Allow.
Example 3.26. Using an Application Control Rule Set
Assume that an IP Policy object called lan_to_wan_policy has already been defined that allows
connections from a protected internal network to the public internet.
This example will limit the usage by the user called rogue_user to 0.25 Megabit of bandwidth for
both uploading and downloading of data using BitTorrent. Let's assume that a Pipe object called
narrow_025_pipe has already been defined in cOS Core that permits this data flow.
It is assumed that all clients on the local network that access the Internet must be authenticated.
Command-Line Interface
First, the appcontrol command is used to create a filter for BitTorrent. This should also include the
uTP protocol:
Device:/> appcontrol -filter -application=bittorrent,utp -save_list
Assume that this filter list is the third filter list created and is therefore assigned the list number 3.
All filters can be displayed with the command:
Device:/> appcontrol -show_lists
Next, create an ApplicationRuleSet called bt_app_list:
Device:/> add Policy ApplicationRuleSet bt_app_list
DefaultAction=Allow
Then, change the CLI context to be bt_app_list:
Device:/> cc Policy ApplicationRuleSet bt_app_list
Device:/bt_app_list>
Now, add the ApplicationRule object:
Device:/bt_app_list> add ApplicationRule
Action=Allow
AppFilter=3
UserAuthGroups=rogue_user
197
Chapter 3: Fundamentals
ForwardChain=narrow_025_pipe
ReturnChain=narrow_025_pipe
Then, return to the default context:
Device:/bt_app_list> cc
Device:/>
Last, associate this ApplicationRuleSet with the IPPolicy:
Device:/> set IPPolicy lan_to_wan_policy
AppControl=Yes
AC_RuleList=bt_app_list
InControl
Follow the same steps used for the Web Interface below.
Web Interface
First, define the Application Rule Set:
1.
Go to: Policies > Firewalling > Application Control > Add > Application Rule Set
2.
Specify a suitable name for the list, in this case bt_app_list
3.
Set the Default Action to Allow
4.
Click OK
Next, define a Application Rule as a child.
1.
Go to: Policies > Firewalling > Application Control > bt_app_list > Add > Application
Rule
2.
Select Allow for the Action
3.
Enable Application Control and add the signatures bittorrentandutp (both are required for
BitTorrent).
4.
Select Authentication Settings and enter the user name rogue_user
5.
Select Traffic Shaping Settings and move the pipe narrow_025_pipe into the Selected list
for both the Forward chain and Return chain
6.
Click OK
Last, associate the Application Rule Set with the IP Policy:
1.
Go to: Policies > Firewalling > Main IP Rules > lan_to_wan_policy
2.
Specify a suitable name for the list, in this case bt_app_list
3.
Select Application Control
4.
In the dialog:
198
Chapter 3: Fundamentals
5.
•
Set Enable Application Control to Yes
•
Set the Application Rule Set to bt_app_list
•
Click OK to close the dialog
Click OK
Note: BitTorrent should include uTP
As seen in the above example, when application control is configured to target
BitTorrent, the two signatures bittorrent and utp should be selected.
Browsing the Application Control Database
In the CLI, the command appcontrol can be used to examine the application control database of
application definitions. Without any parameters, this command shows the database size. For
example:
Device:/> appcontrol
Application library contents:
842 application definitions.
34 families.
4 tags.
If tab completion is used after the command, all the definition families are displayed. For
example:
Device:/> appcontrol <tab>
antivirus/
application_service/
audio_video/
authentication/
compression/
database/
encrypted/
erp/
file_server/
file_transfer/
forum/
game/
instant_messaging/
mail/
messenger/
microsoft_office/
middleware/
music_player/
network_management/
network_service/
peer_to_peer/
printer/
qosmos/
routing/
security_service/
telephony/
terminal/
thin_client/
tunneling/
unclassified/
wap/
web/
webmail/
These families consist of the individual definitions. For example, to view the two definitions in
the compression family, use the command:
Device:/> appcontrol compression
compression - Compression:
ccp
comp
2 application(s)
To view a single definition, the individual name can be used without the family. For example, to
display the comp definition within the compression family:
Device:/> appcontrol comp
comp - Compression
199
Chapter 3: Fundamentals
COMP protocol is used for data compression over PPP.
Family:
Risk Level:
Tags:
Revision:
Enabled:
Compression
1 - Very low risk
0
Yes
The Tags and Risk Level add further information to each definition but are not part of the
definition híerarchy. The Risk Level indicates the degree of threat that this particular application
poses. The Tags provide more information about the data traffic related to the application, for
example High Bandwidth might be a typical tag.
It is possible to search the definition database by using any of the filter parameters:
•
•
•
•
•
name
family
name
risk
tag
The name parameter must always be the first in a search but the asterisk "*" character can be
used as a wildcard. For example:
Device:/> appcontrol -name=* -family=mail -risk=HIGH
As demonstrated earlier, the -save_list option is used to save a filter list so it can be used with IP
rules and IP policies.
Managing Filters
As shown in the application example above for controlling BitTorrent, the appcontrol CLI
command is also used to create saved filters which are then used with the CLI in ApplicationRule
objects. For example, the following will create a saved filter for BitTorrent:
Device:/> appcontrol -filter -application=bittorrent,utp -save_list
The -application parameter specifies the individual signatures by name. An alternative is to use
the -name parameter which allows wildcarding and searches the signatures names looking for
character pattern matches. For example, we could have specified:
Device:/> appcontrol -filter -name=bit* -save_list
All the signatures with names that begin with the prefix bit would have been selected. It would
not have been possible to select bittorrent and utp using the -name parameter.
All the saved filters can be displayed with the command:
Device:/> appcontrol -filter -show_lists
To delete all saved filters, use the command: All the saved filters can be deleted with the
command:
Device:/> appcontrol -delete_lists=all
Individual saved filters can be deleted by specifying the number of the filter after -delete_lists=.
Selecting All Signatures
200
Chapter 3: Fundamentals
If the administrators aim is to find out what applications users are accessing, application control
can be used to do this by triggering on all signatures and allowing instead of blocking the traffic.
The log events generated will indicate the applications that are being detected.
Selecting all signatures is done through a checkbox in the Web Interface or InControl and can be
done with the CLI by using wildcarding with an ApplicationRuleSet object. The CLI cannot be used
when using application control directly with IP rules.
Risk Guidelines
The following are guidelines for how the risk parameter for each application control signature
should be viewed by the administrator:
•
Risk Level 5
Very high risk. This traffic should be blocked unless special circumstances or requirements
exist. For example, PHP-, CGI-, HTTPS-proxies; known attack sites.
•
Risk Level 4
High risk. This traffic should be reviewed and a block or allow action taken. Site-to-site
tunnelling should be used where possible. For example, SSH, LDAP, RADIUS, Dropbox and
similar.
•
Risk Level 3
Medium risk. Signatures with this risk level can affect network security, bandwidth usage and
company integrity if care is not taken. For example, Facebook and other social networks,
Google Analytics and similar aggregators, P2P/filesharing
•
Risk Level 2
Moderate risk. Signatures with this risk level can affect network security and/or affect
bandwidth usage. For example, video streaming sites, Java/Flash game sites
•
Risk Level 1
Low-risk. Signatures that could be candidates for blocking. Typically not a threat. For
example, E-commerce sites, news portals.
Application Control Licensing
As mentioned at the beginning of this section, for application control to function, the current
cOS Core license must allow it and a Clavister sales office can provide details about obtaining an
appropriate license.
Application control is a subscription service, so the expiry date for the feature may be different to
the expiry date of the license itself. Should the application control subscription expire, the
following will happen if application control has been configured on any IP Policy objects:
•
A console message is generated at system startup or on reconfiguration to indicate
subscription expiry.
•
Application control will continue to function so that traffic continues to flow through cOS
Core but, whenever it triggers, the data type will be set to Unknown.
For example, if the administrator had configured BitTorrent traffic to be dropped, it will no
longer be dropped because it has been recognized and then reclassified as Unknown traffic.
•
Whenever application control triggers, the log message application_identified will be
201
Chapter 3: Fundamentals
generated as usual but the traffic type will be marked as Unknown. Similarly, the type
Unknown will also appear in the application_end log message.
•
In addition, the log message application_control_disabled will also be generated when
application control triggers.
The current status of application control licensing can be viewed with the Web Interface by
going to Status > Maintenance > License.
202
Chapter 3: Fundamentals
3.7. 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.
Schedule Objects
cOS Core addresses this requirement by providing Schedule objects (often referred to as simply
schedules) that can be selected and used with various types of security policies to accomplish
time-based control.
Multiple Time Ranges
A Schedule object also offers 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.
Schedule Parameters
Each schedule object consists of the following parameters:
Name
The name of the schedule. This is used in user interface display and as a
reference to the schedule from other objects.
Scheduled Times
These are the times during each week when the schedule is applied.
Times are specified as being to the nearest hour. A schedule is either
active or inactive during each hour of each day of a week.
Start Date
If this option is used, it is the date after which this schedule object
becomes active.
End Date
If this option is used, it is the date after which this schedule object is no
longer active.
Comment
Any descriptive text that should be associated with the object.
This functionality is not limited to IP Rules, but is valid for most types of policies, including Traffic
Shaping rules, Intrusion Detection and Prevention (IDP) rules and Virtual Routing rules. A
Schedule object is, in other words, a very powerful component that can allow detailed regulation
of when functions in cOS Core are enabled or disabled.
Important: Set the system date and time
As schedules depend on an accurate system date and time, it is very important that the
system date and time are set correctly. This is also important for some other features
such as certificate usage in VPN tunnels.
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
203
Chapter 3: Fundamentals
Section 3.9, “Date and Time”.
Example 3.27. Setting up a Time-Scheduled Security Policy
This example creates a schedule object for office hours on weekdays, and attaches the object to
an IP Rule that allows HTTP traffic.
Command-Line Interface
Device:/> add ScheduleProfile OfficeHours
Mon=8-17 Tue=8-17 Wed=8-17 Thu=8-17 Fri=8-17
Now create the IP rule that uses this schedule.
Device:/> add IPRule Action=NAT
Service=http
SourceInterface=lan
SourceNetwork=lan_net
DestinationInterface=any
DestinationNetwork=all-nets
Schedule=OfficeHours name=AllowHTTP
Configuration changes must be saved by then issuing an activate followed by a commit
command.
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Policies > 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: Policies > Add > IPRule
2.
Enter the following:
•
3.
Name: AllowHTTP
Select the following from the dropdown lists:
•
Action: NAT
•
Service: http
•
Schedule: OfficeHours
204
Chapter 3: Fundamentals
4.
•
SourceInterface: lan
•
SourceNetwork lan_net
•
DestinationInterface: any
•
DestinationNetwork: all-nets
Click OK
205
Chapter 3: Fundamentals
3.8. Certificates
3.8.1. Overview
The X.509 Standard
cOS Core 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. References in this document to certificates mean X.509
certificates.
When distributed to another party, a certificate performs two functions:
•
It distributes the certificate owner's public key.
•
It establishes the certificate owner's identity.
A certificate acts as 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 fake key with the name
and user ID of an intended recipient.
Certificates with VPN Tunnels
The main usage of certificates in cOS Core 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 and user ID.
•
Digital signatures that verify that the information enclosed in the certificate has been verified
by a 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.
Certificate Authorities
A certificate 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 CA 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.
206
Chapter 3: Fundamentals
Certificate Chains
A CA can also issue certificates to other CAs. This leads to a chain-like certificate hierarchy. The
highest certificate is called the Root Certificate and it is signed by the Root CA. Each certificate in
the chain is signed by the CA of the certificate directly above it in the chain. However, the root
certificate is signed by itself (it is "self-signed"). Certificates in the chain between the root
certificate and the end certificate are called Intermediate Certificates.
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.
In cOS Core, the maximum length of a certificate chain is 4. In VPN scenarios with roaming
clients, the client's certificate will be the bottom of a certificate chain.
Validity Time
A certificate is not valid forever. Each certificate contains values for two points in time between
which the certificate is valid. When this validity period expires, the certificate can no longer be
used and a new certificate must be issued.
Important: The system date and time must be correct
Make sure the cOS Core system date and time are set correctly when using certificates.
Problems with certificates, for example in VPN tunnel establishment, can be due to an
incorrect system date or time.
The cOS Core Certificate Cache
cOS Core maintains a Certificate Cache in local memory which provides processing speed
enhancement when certificates are being repeatedly accessed. This cache is only completely
cleared and initialized when cOS Core is restarted.
For this reason, it is important to restart cOS Core if any certificates are added, modified or
deleted. This can be done with the CLI command:
Device:/> shutdown
Certificate Revocation Lists
A Certificate Revocation List (CRL) contains a list of all certificates that have been canceled before
their expiration date. They are normally held on an external server which is accessed to
determine if the certificate is still valid. The ability to validate a user certificate in this way is a key
reason why certificate security simplifies the administration of large user communities.
CRLs are published on servers that all certificate users can access, using either the LDAP or HTTP
protocols. Revocation 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, perhaps because they have left the
company. Whatever the reason, server CRLs can be updated to change the validity of one or
207
Chapter 3: Fundamentals
many certificates.
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.
A CA usually 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, cOS Core trusts anyone whose certificate is signed by a given CA. Before
a certificate is accepted, the following steps are taken to verify the validity of the certificate:
•
Construct a certification path up to the trusted root CA.
•
Verify the signatures of all certificates in the certification path.
•
Fetch the CRL for each certificate to verify that none of the certificates have been revoked.
Identification Lists
In addition to verifying the signatures of certificates, cOS Core 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 cOS Core, 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 cOS Core, it can still
be reused with any number of other, different VPN tunnels.
Other Considerations
A number of other factors should be kept in mind when using certificates:
•
If Certificate Revocation Lists (CRLs) are used then the CRL distribution point is defined as an
FQDN (for example, caserver.somecompany.com) which must be resolved to an IP address
using a public DNS server. At least one DNS server that can resolve this FQDN should
therefore be defined in cOS Core.
•
Do not get the Host Certificate files and Root Certificate files mixed up. Although it is not
possible to use a Host Certificate in cOS Core as a Root Certificate, it is possible to accidentally
use a Host Certificate as a Root Certificate.
•
Certificates have two files associated with them and these have the filetypes .key file and .cer.
The filename of these files must be the same for cOS Core to be able to use them. For
example, if the certificate is called my_cert then the files my_cert.key and my_cert.cer.
3.8.2. Certificates in cOS Core
There are two types of certificates that can be uploaded: self-signed certificates and the remote
certificates belonging to a remote peer or CA server. Self-signed certificates can be generated by
using one of a number of freely available utilities for doing this.
208
Chapter 3: Fundamentals
Uploading Certificates
Certificates can be uploaded to cOS Core in one of two ways:
•
Upload using Secure Copy (SCP).
•
Upload through the Web Interface or InControl.
The following command lines show how a typical SCP utility might upload a certificate consisting
of the two files called cert-1.cer and cert-1.key to a security gateway which has the management
IP address 192.168.3.1:
> scp C:\cert-1.cer [email protected]:certificate/MyCert
> scp C:\cert-1.key [email protected]:certificate/MyCert
The certificate object name in cOS Core is MyCert for the certificate and this is how it is
referenced by other objects in the configuration.
All certificate uploads should be followed by the configuration being activated since it has been
changed with new objects.
Example 3.28. Uploading a Certificate with Web Interface or InControl
The certificate may either be self-signed or belonging to a remote peer or CA server.
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Objects > Key Ring > Add > Certificate
2.
Specify a suitable name for the certificate
3.
Now select one of the following:
4.
•
Upload self-signed X.509 Certificate
•
Upload a remote certificate
Click OK and follow the instructions
Using Uploaded Certificates
Once certificates are uploaded, they are stored in non-volatile cOS Core memory. To be used
they must be explicitly associated with a cOS Core object. For example, an IPsec tunnel object
that uses certificates must be assigned a Gateway and Root certificate.
Example 3.29. Associating Certificates with IPsec Tunnels
209
Chapter 3: Fundamentals
To associate an imported certificate with an IPsec tunnel.
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Network > Interfaces and VPN > IPsec
2.
Display the properties of the IPsec tunnel
3.
Select Authentication
4.
Select the X509 Certificate option
5.
Select the correct Gateway and Root certificates
6.
Click OK
3.8.3. CA Certificate Requests
To request certificates from a CA server or CA company, the best method is to send a CA
Certificate Request which is a file that contains a request for a certificate in a well known,
predefined format.
Manually Creating Windows CA Server Requests
The cOS Core Web Interface (WebUI) does not currently include the ability to generate certificate
requests that can be sent to a CA server for generation of the .cer and .key files required by cOS
Core.
It is possible, however, to manually create the required files for a Windows CA server using the
following stages.
•
Create a gateway certificate on the Windows CA server and export it as a file in the .pfx format.
•
Convert the .pfx file into the .pem format.
•
Take out the relevant parts of the .pem file to form the required .cer and .key files.
The detailed steps for the above stages are as follows:
1.
Create the gateway certificate on the Windows CA server and export it to a .pfx file on the
local cOS Core management workstation disk.
2.
Now convert the local .pfx file to a .pem file. This can be done with the OpenSSL utility using
the console command line:
> openssl pkcs12 -in gateway.pfx -out gateway.pem -nodes
In this command line example, the file exported from the CA server is assumed to be called
gateway.pfx and it is assumed to be in the same local directory as the OpenSSL executable.
The original gateway.pfx file contained 3 certificates: CA root certificate, a personal
210
Chapter 3: Fundamentals
certificate and a private key certificate. The gateway.pem file now contains these in format
which can be cut and pasted with a text editor.
Note
OpenSSL is being used here as a conversion utility and not in its normal role as a
communication utility.
3.
Create two blank text files with a text editor, such as Windows Notepad. Give the files the
same filename but use the extension .cer for one and .key for the other. For example,
gateway.cer and gateway.key might be the names.
4.
Start a text editor and open the downloaded .pem file and locate the line that begins:
-----BEGIN RSA PRIVATE KEY-----
5.
Mark and copy into the system clipboard that line and everything under it, up to and
including the line:
-----END RSA PRIVATE KEY-----
6.
Now paste the copied text into the .key file and save it.
7.
Back in the .pem file, locate the line that begins:
-----BEGIN CERTIFICATE-----
and copy into the system clipboard that line and everything under it, up to and including:
-----END CERTIFICATE-----
8.
Now paste this copied text into the .cer file and save it.
The saved .key and .cer files are now ready for upload into cOS Core.
211
Chapter 3: Fundamentals
3.9. Date and Time
3.9.1. Overview
Correctly setting the date and time is important for cOS Core to operate properly. Time
scheduled policies, auto-update of the IDP and Anti-Virus databases, and other product features
such as digital certificates 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
occurred. Not only does this assume a working clock, but also that the clock is correctly
synchronized with other equipment in the network.
The Local System Clock
To maintain current date and time, cOS Core makes use of the local hardware real-time hardware
clock. On Clavister hardware models, this clock is also equipped with a battery backup to guard
against a temporary loss of power.
Time Synchronization Protocols
cOS Core supports the optional use of Time Synchronization Protocols in order to automatically
adjust the local system clock from the response to queries sent over the public Internet to special
external servers which are known as Time Servers.
3.9.2. Setting Date and Time
Current Date and Time
The administrator can set the date and time manually and this is recommended when a new cOS
Core installation is started for the first time.
Example 3.30. Setting the Current Date and Time
To adjust the current date and time, follow the steps outlined below:
Command-Line Interface
Device:/> 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,
2008 the command would be:
Device:/> time -set 2008-04-27 09:25:00
InControl
Follow the same steps used for the Web Interface below.
Web Interface
212
Chapter 3: Fundamentals
1.
Go to: System > Device > 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 reconfigure is not required
A new date and time will be applied by cOS Core as soon as it is set. There is no need to
reconfigure or restart the system.
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 cOS Core time zone setting reflects the time zone where the Clavister Security Gateway is
physically located.
Example 3.31. Setting the Time Zone
To modify the cOS Core time zone to be GMT plus 1 hour, follow the steps outlined below:
Command-Line Interface
Device:/> set DateTime Timezone=GMTplus1
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: System > Device > 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
213
Chapter 3: Fundamentals
principles regulating DST vary from country to country, and in some cases there can be variations
within the same country. For this reason, cOS Core 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.32. Enabling DST
To enable DST, follow the steps outlined below:
Command-Line Interface
Device:/> set DateTime DSTEnabled=Yes
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: System/Date and Time
2.
Check Enable daylight saving time
3.
Click OK
3.9.3. Time Servers
The hardware clock which cOS Core 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.
cOS Core 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 cOS Core will have its date and time aligned with
other network devices.
Time Synchronization Protocols
Time Synchronization Protocols are standardized methods for retrieving time information from
external Time Servers. cOS Core 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 cOS Core 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
214
Chapter 3: Fundamentals
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 accessible 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. cOS Core 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: DNS servers need to be configured in cOS Core
Make sure at least one external DNS server is correctly configured in cOS Core so that
Time Server URLs can be resolved (see Section 3.10, “DNS”). This is not needed if using IP
addresses for the servers.
Example 3.33. 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.
Command-Line Interface
Device:/> set DateTime TimeSynchronization=custom
TimeSyncServer1=dns:ntp1.sp.se
TimeSyncServer2=dns:ntp2.sp.se
TimeSyncInterval=86400
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: System > Device > Date and Time
2.
Check the Enable time synchronization
3.
Now enter:
4.
•
Time Server Type: SNTP
•
Primary Time Server: dns:ntp1.sp.se
•
Secondary Time Server: dns:ntp2.sp.se
Click OK
The time server URLs must have the prefix dns: to specify that they should be resolved with a
DNS server. cOS Core must therefore also have a DNS server defined so this resolution can be
215
Chapter 3: Fundamentals
performed.
Example 3.34. Manually Triggering a Time Synchronization
Time synchronization can be triggered from the CLI. The output below shows a typical response.
Command-Line Interface
Device:/> time -sync
Attempting to synchronize system time...
Server time: 2008-02-27 12:21:52 (UTC+00:00)
Local time: 2008-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 cOS Core 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 cOS Core 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.35. Modifying the Maximum Adjustment Value
Command-Line Interface
Device:/> set DateTime TimeSyncMaxAdjust=40000
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: System > Device > Date and Time
2.
For the setting Maximum time drift that a server is allowed to adjust, enter the
maximum time difference in seconds that an external server is allowed to adjust for. There
may be a valid reason why there is a significant difference such as an incorrect cOS Core
configuration.
3.
Click OK
Sometimes it might be necessary to override the maximum adjustment. For example, if time
synchronization has just been enabled and the initial time difference is greater than the
maximum adjust value. It is then possible to manually force a synchronization and disregard the
maximum adjustment parameter.
216
Chapter 3: Fundamentals
Example 3.36. Forcing Time Synchronization
This example demonstrates how to force time synchronization, overriding the maximum
adjustment setting.
Command-Line Interface
Device:/> 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.
3.9.4. Settings Summary for Date and Time
Below is a summary of the various settings for date and time:
Time Zone
Time zone offset in minutes.
Default: 0
DST Offset
Daylight saving time offset in minutes.
Default: 0
DST Start Date
What month and day DST starts, in the format MM-DD.
Default: none
DST End Date
What month and day DST ends, in the format MM-DD.
Default: none
Time Sync Server Type
Type of server for time synchronization, UDPTime or SNTP (Simple Network Time Protocol).
Default: SNTP
217
Chapter 3: Fundamentals
Primary Time Server
DNS hostname or IP Address of Timeserver 1.
Default: None
Secondary Time Server
DNS hostname or IP Address of Timeserver 2.
Default: None
tertiary Time Server
DNS hostname or IP Address of Timeserver 3.
Default: None
Interval between synchronization
Seconds between each resynchronization.
Default: 86400
Max time drift
Maximum time drift in seconds that a server is allowed to adjust.
Default: 600
Group interval
Interval according to which server responses will be grouped.
Default: 10
218
Chapter 3: Fundamentals
3.10. DNS
Overview
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 cOS Core configuration where IP addresses are unknown or
where it makes more sense to make use of DNS resolution instead of using static IP addresses.
DNS with cOS Core
To accomplish DNS resolution, cOS Core has a built-in DNS client that can be configured to make
use of up to three DNS servers. The are called the Primary Server, the Secondary Server and the
Tertiary Server. For DNS to function, at least the primary server must be configured. It is
recommended to have both a primary and secondary defined so that there is a backup should
the primary be unavailable.
Features Requiring DNS Resolution
Having at least one DNS server defined is vital for functioning of the following modules in cOS
Core:
•
Automatic time synchronization.
•
Access to an external certificate authority server for CA signed certificates.
•
UTM features that require access to external servers such as anti-virus and IDP.
Example 3.37. Configuring DNS Servers
In this example, the DNS client is configured to use one primary and one secondary DNS server,
having IPv4 addresses 10.0.0.1 and 10.0.0.2 respectively.
Command-Line Interface
Device:/> set DNS DNSServer1=10.0.0.1 DNSServer2=10.0.0.2
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: System > Device > DNS
219
Chapter 3: Fundamentals
2.
3.
Enter the following:
•
Primary Server: 10.0.0.1
•
Secondary Server: 10.0.0.2
Click OK
DNS Lookup and IP Rules
In the case of DNS server request being generated by cOS Core itself, no IP rules need to be
defined for the connection to succeed. This is because connections initiated by cOS Core are
considered to be trusted. For example, this would be the case if cOS Core is accessing a CA server
to establish the validity of a certificate and first needs to resolve the certificate's FQDN to an IP
address.
Dynamic DNS and HTTP Poster
A DNS feature offered by cOS Core is the ability to explicitly inform DNS servers when the
external IP address of the Clavister Security Gateway has changed. This is sometimes referred to
as Dynamic DNS and is useful where the Clavister Security Gateway has an external address that
can change.
Dynamic DNS can also be useful in VPN scenarios where both ends of the tunnel have dynamic IP
addresses. If only one side of the tunnel has a dynamic address then the cOS Core VPN keep alive
feature solves this problem.
Under System > Misc. Clients in the Web Interface, several dynamic DNS services are defined.
The HTTP Poster client object is a generic dynamic DNS client with the following characteristics:
•
Multiple HTTP Poster objects can be defined, each with a different URL and different optional
settings.
•
By default, an HTTP Poster object sends an HTTP GET request to the defined URL. Some servers
require an HTTP POST request and to achieve this the option HTTP Post the Values should be
enabled. This is usually needed when authentication parameters are being sent in the URL.
•
By default, HTTP Poster does not automatically send the server request after cOS Core
reconfiguration. This behaviour can be changed by enabling the option Repost on each
reconfiguration.
There is one exception to the default behaviour and that is after a reconfigure which is the
result of getting a new local IP address on the interface that connects to the DNS server.
In this case, cOS Core always waits a predefined period of 20 seconds before reposting after
the reconfiguration.
•
The default Repost Delay is 1200 seconds (20 minutes). This can be altered.
The predefined DynDNS client has an predefined refetch time of 30 days which cannot be
changed.
The difference between HTTP Poster and the predefined named DNS servers is that HTTP Poster
can be used to send any URL. The named services are a convenience that make it easy to
correctly format the URL needed for that particular service. For example, the http:// URL for the
dyndns.org service might be:
220
Chapter 3: Fundamentals
myuid:[email protected]/nic/update?hostname=mydns.dyndns.org
This could be sent by using HTTP Poster. Alternatively, the URL could be automatically formatted
for the administrator by cOS Core through using the DynDNS option and entering only the
information required for dyndns.org.
The CLI console command httpposter can be used to troubleshoot problems by seeing what cOS
Core is sending and what the servers are returning:
Device:/> httpposter
Note: A high rate of server queries can cause problems
Dynamic DNS services are often sensitive to repeated logon attempts over short periods
of time and may blacklist source IP addresses that are sending excessive requests. It is
therefore not advisable to query these servers too often, otherwise they may cease to
respond.
A repost for an individual server can be forced with the command:
Device:/> httpposter -repost=<index>
Where <index> is the position of the object in the list of posters. For example, to force a report of
the second in the list:
Device:/> httpposter -repost=2
HTTP Poster Has Other Uses
HTTP Poster may be used for other purposes than dynamic DNS. Any requirement for cOS Core to
send an HTTP GET or POST message to a particular URL could be met using this feature.
221
Chapter 3: Fundamentals
3.11. Internet Access Setup
Overview
One of the first things an administrator often wants to do after starting cOS Core for the first time
is to set up access to the public Internet. This section is a quick start guide to doing this and
refers to many other sections in Chapter 3, Fundamentals as well as Chapter 4, Routing which
follows.
Getting Started Guides
This section is designed to be a broad overview of setting up Internet access for all cOS Core
platforms. Clavister provides specific Getting Started guides for different Clavister hardware
models as well as a generic guide for third-party hardware (the cOS Core Software Series) and a
another guide for setup under VMware (the Virtual Security Gateway Series).
These getting started guides contain a comprehensive section on Internet setup which is specific
to each environment and the administrator is advised to refer to them for more detailed
information. The guides also explain how to set up Internet PPPoE and PPTP access.
The Setup Wizard
When cOS Core is accessed for the first time through the Web Interface using a web browser, the
administrator is not taken directly to the interface. Instead, a Setup Wizard runs which takes the
administrator through a number of dialogs to set up the basic cOS Core configuration. A portion
of the wizard deals with the set up of Internet access.
By dismissing the wizard, the administrator can go straight to the Web Interface and perform
setup manually, step by step. The sections below assume that setup is being performed
manually but they are also useful in understanding the setup steps that the wizard automates.
IP Address Options
Initially, access to the Internet will not be possible via a Clavister Security Gateway. To achieve
this, access must first be arranged with an Internet Service Provider (ISP). The ISP will probably
offer two options for access:
•
Using Static IP Addresses
Access can be setup using static IP addresses. The ISP provides the required addresses (for
example, in an email) and these are manually input into the cOS Core configuration.
•
Using DHCP
cOS Core can act as a DHCP client and use the DHCP protocol to automatically retrieve all the
IP addresses required across the connection with the ISP. No addresses need to be entered
manually.
3.11.1. Static Address Setup
For the static IP address option, the ISP should provide:
•
A public IPv4 address for the Clavister Security Gateway. This is assigned to the interface that
connects to the ISP.
222
Chapter 3: Fundamentals
•
The IP address of the ISP's "gateway" router.
•
A network address for the network between the ISP and the Clavister Security Gateway. This
can be used for addressing any hosts that lie on this network aside from the ISP's gateway.
Note: cOS Core ignores the broadcast address
The broadcast IP address need not be specified. It is automatically calculated by cOS
Core but is not responded to.
Creating IP Objects
Once the ISP has provided the necessary information, several IP objects in the cOS Core Address
Book need to be defined. The address book provides a way to associate a text name with an IP
address, IP range or IP network. Instead of re-typing IP addresses, these names can then be
selected throughout the Web Interface and InControl as well as being used with CLI commands.
Before defining any new addresses, the address book already contains a number of useful
addresses by default. One of the most useful is the all-nets address, which corresponds to the
IPv4 address 0.0.0.0/0 (all hosts and networks).
To create the IP objects necessary for Internet access, go to Objects > Address Book in the Web
Interface or InControl and then select Add > IP address.
The following IP objects should be added or modified:
•
Create a new IP object called gw-world with the IPv4 address of the ISP gateway.
•
One interface on the hardware must be dedicated as a connection to the ISP. We will assume
here that the interface is wan. This interface will have the IP address object wan_ip as its IP
address and belong to the network wan_net. Modify the object wan_ip so it is assigned the
public IPv4 address of the Clavister Security Gateway.
•
The object wan_net should be allocated the network address provided by the ISP. This is the
network between the Clavister Security Gateway and the ISP and both the wan and the ISP's
gateway will belong to it.
Interface Naming
The physical interface wan is assumed in this manual to be the default name of the interface to
which the ISP is connected. Different hardware models can have different default names and
these names my be changed by the administrator. The above should therefore be adapted for
the particular hardware in use.
cOS Core uses certain naming conventions for particular objects, such as gw-world for the ISP
gateway. These need not be followed by the administrator but if they are followed, it makes
examination of a configuration by support personnel easier.
3.11.2. DHCP Setup
The IP addresses defined in the previous section can alternatively be retrieved automatically
from the ISP using the DHCP protocol. This is done by enabling DHCP on the Ethernet interface.
The address book will now be automatically populated with all relevant IP addresses as they are
received from the ISP via DHCP.
223
Chapter 3: Fundamentals
See Chapter 5, DHCP Services for more information about this topic.
Example 3.38. Enabling DHCP
Assume that the wan is connected to the gateway of the ISP. The requirement is to enable DHCP
on this interface.
Command-Line Interface
Device:/> set Interface Ethernet wan DHCPEnabled=Yes
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Network > Interfaces and VPN > Ethernet
2.
Select the wan interface
3.
Select the option Enable DHCP Client
4.
Click OK
3.11.3. The Minimum Requirements for Traffic Flow
An important cOS Core principle that is repeated throughout this manual and which will be
stated again here, is that there are a minimum of two cOS Core configuration components
required for data traffic to flow through a Clavister Security Gateway:
•
A Matching Route
When traffic arrives at one cOS Core interface, it has a destination IP address. A cOS Core
routing table contain routes which specify which destination IP address or network can be
found on which interface. cOS Core uses this information to then forward the data out
through the right interface.
•
A Matching IP Rule or IP Policy
Before any traffic can flow out through the interface decided by a route, there must be an IP
Rule or IP Policy object defined that allows this traffic to flow.
IP rules and IP policies make up the security policies of the security gateway and can block or
allow traffic based on its protocol type as well as on the combination of source/destination
and interface/network. No rules or policies exist by default and all traffic is therefore dropped
until one is defined which allows it.
As explained in Section 3.6, “IP Rules and IP Policies”, an IP policy is a simplified and more
convenient method of defining IP rules.
The creation of the appropriate route and IP rules or IP policies for Internet access is discussed in
the sections that follow.
224
Chapter 3: Fundamentals
3.11.4. Creating a Route
Initially, no route will exist in the main routing table that allows traffic to reach the Internet so
this must be defined. The routes parameters will be as follows:
Interface
Network
Gateway
wan
all-nets
gw-world
Notice that the destination network for this route is all-nets. When cOS Core needs to determine
which interface the received traffic should be forwarded out from, it looks in a routing table for
the "narrowest" destination network match. This all-nets route is therefore a catch-all route that
will be used when no other, more specific, matching route exists. There should therefore only be
one all-nets route.
The all-nets route is, in fact, created automatically by cOS Core when the gateway IPv4 address is
specified for an Ethernet interface.
To create the route manually in the Web Interface or InControl go to Routes > New Route.
The route to access wan_net via the wan interface will be automatically created when the
wan_net object is edited and the gateway defined.
See Chapter 4, Routing for more information about routes.
Example 3.39. Adding an all-nets Route
This example shows how an all-nets route is added manually to the main routing table. The IP
address object isp_gw_ip is the IP of the ISP's gateway.
Command-Line Interface
Change the context to be the routing table:
Device:/> cc RoutingTable main
Add the route:
Device:/main> add Route
Interface=wan
Network=all-nets
Gateway=isp_gw_ip
Return to the default CLI context:
Device:/main> cc
Device:/>
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Network > Routing > Routing Tables > main > Add > Route
2.
Now enter:
225
Chapter 3: Fundamentals
3.
•
Interface: wan
•
Network: all-nets
•
Gateway: isp_gw_ip
Click OK
3.11.5. Creating IP Rules or IP Policies
Before traffic can flow to the ISP, appropriate IP Rule objects must be created to allow the traffic
to pass. An alternative to using IP rules is to use IP Policy objects which can simplify this process if
other options such as application control are being added.
At minimum, DNS and HTTP traffic should be allowed to flow so that web surfing can take place.
It may also be necessary to use NAT to share the single external IP address assigned to the
Clavister Security Gateway so that the internal network topology of private IPv4 addresses is
hidden.
If, for example, web surfing is going to be done from clients on the internal network lan_net
attached to the lan interface to the public Internet connected to the wan interface, then the IP
rules for DNS and HTTP would be:
Action
Src Interface
Src Network
Dest Interface
Dest Network
Service
NAT
lan
lan_net
wan
all-nets
dns-all
NAT
lan
lan_net
wan
all-nets
http-all
The service http-all includes both the HTTP and HTTPS protocols but not DNS so a second rule of
policy is needed. The single service all could have been used in a single rule but this is not
recommended as this means connections could be opened on any port number which can
compromise security. The best approach is to define the filter for traffic as narrowly as possible
which has been done here.
Example 3.40. Creating IP Policy Objects for Internet Access
This example creates an IP policy called surf_http that allows clients on the lan_net network to
access the public Internet. It is assumed that traffic is being NATed to the Internet using the
public IP address of the wan interface.
A second policy is also created called surf_dns which allows DNS queries.
Command-Line Interface
Create policy for the http-all service:
Device:/> add IPPolicy
SourceInterface=lan
SourceNetwork=lan_net
DestinationInterface=wan
DestinationNetwork=all-nets
Service=http-all
SourceAction=NAT
Name=surf_http
Repeat for the dns-all service:
226
Chapter 3: Fundamentals
Device:/> add IPPolicy
SourceInterface=lan
SourceNetwork=lan_net
DestinationInterface=wan
DestinationNetwork=all-nets
Service=dns-all
SourceAction=NAT
Name=surf_dns
The Action in the above CLI definitions has not been specified. The default value is Allow.
InControl
Follow the same steps used for the Web Interface below.
Web Interface
Create policy for the http-all service:
1.
Go to: Policies > Add > IPPolicy
2.
Now enter:
3.
4.
•
Name: surf_http
•
Action: Allow
•
Source Interface: lan
•
Source Network: lan_net
•
Destination Interface: all
•
Destination Network: all-nets
•
Service: http-all
Select Address Translation and in the dialog:
•
Under Source Address Translation enable NAT
•
Close the dialog
Click OK
Repeat for the dns-all service:
1.
Go to: Policies > Add > IPPolicy
2.
Now enter:
•
Name: surf_dns
•
Action: Allow
•
Source Interface: lan
•
Source Network: lan_net
•
Destination Interface: all
227
Chapter 3: Fundamentals
3.
4.
•
Destination Network: all-nets
•
Service: dns-all
Select Address Translation and in the dialog:
•
Under Source Address Translation enable NAT
•
Close the dialog
Click OK
See Section 3.6, “IP Rules and IP Policies” and Section 3.6.7, “IP Policies” for more information about
rules and policies.
3.11.6. Defining DNS Servers
cOS Core needs external DNS servers to be defined in order to resolve certain FQDNs. This is
particularly important for certificate handling. Up to three DNS servers can be manually specified
to cOS Core and at least one should be configured for DNS lookup to function.
Example 3.41. Configuring DNS Servers
Assume that the cOS Core address book already contains the IPv4 addresses dns_server_1 and
dns_server_2 for the primary and secondary DNS servers.
Command-Line Interface
Device:/> set DNS DNSServer1=dns_server_1 DNSServer2=dns_server_2
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: System > Device > DNS
2.
Enter the following:
3.
•
Primary Server: dns_server_1
•
Secondary Server: dns_server_2
Click OK
Automatic DNS Configuration through DHCP
If connection to an ISP is done with DHCP then the ISP's DHCP server should automatically
configured at least one DNS server in cOS Core at the same time all other IP addresses are
228
Chapter 3: Fundamentals
configured during initial connection to the ISP.
When DHCP configures the DHCP servers in cOS Core, names are automatically assigned to these
servers so they can be referenced later in user interfaces. The names used are of the form
<if-name>_dns1, <if-name>_dns2 and so on, where <if-name> is the interface name on which
the DHCP addresses are received.
When cOS Core itself acts as a DHCP server, the DNS addresses it hands out are, by default, the
same as those received through DHCP unless different DNS servers are explicitly specified.
Default DNS Server Address Names with DHCP
When cOS Core receives DNS servers through DHCP, these are automatically added to the
address book with a default name that follows the pattern <interface-name>_DNS<num>. For
example, the second DNS server address allocated though the wan interface would appear in the
address book as wan_DNS2.
When viewed in the Web Interface or InControl these DNS addresses always have the value
0.0.0.0. To see the actual value after it has been assigned with DHCP, use the CLI command dhcp
-show. For example, to see the status of the DNS servers on the wan interface, use the command:
Device:/> dhcp -show wan
See Section 3.10, “DNS” for more information about this topic.
229
Chapter 3: Fundamentals
230
Chapter 4: Routing
This chapter describes how to configure IP routing in cOS Core.
• Overview, page 231
• Static Routing, page 232
• Policy-based Routing, page 251
• Route Load Balancing, page 259
• Virtual Routing, page 267
• OSPF, page 275
• Multicast Routing, page 305
• Transparent Mode, page 319
4.1. Overview
IP routing is one of the most fundamental functions of cOS Core. Any IP packet flowing through a
Clavister Security Gateway will be subjected to at least one routing decision at some point in
time, and properly setting up routing is crucial for the system to function as expected.
cOS Core offers support for the following types of routing mechanisms:
•
Static routing
•
Dynamic routing
•
Virtual routing
Additionally, cOS Core supports route monitoring to achieve route and link redundancy with
fail-over capability.
231
Chapter 4: Routing
4.2. Static Routing
The most basic form of routing is known as Static Routing. The term "static" is used because most
entries in a routing table are part of the cOS Core system's static configuration. They usually
remain unchanged during long periods of system operation.
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. However, for larger networks, or whenever the network topology is complex,
the work of manually maintaining static routing tables can be time-consuming and also
problematic. Dynamic routing should therefore be used in such cases.
For more information about the dynamic routing capabilities of cOS Core, please see Section 4.6,
“OSPF”. Note, however, that even if dynamic routing is chosen for a network, understanding the
principles of static routing and how it is implemented in cOS Core is still required.
4.2.1. The 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 network devices. These
devices are most often referred to as routers since they are performing the task of routing
packets to their destination.
In each router, one or more routing tables contain a list of routes and these are consulted to find
out where to send a packet so it can reach its destination. The components of a single route are
discussed next.
The Components of a Route
When a route is defined it consists of the following parameters:
•
Interface
The interface to forward the packet on in order to reach the destination network. In other
words, the interface to which the destination IP range is connected, either directly or through
a router.
The interface might be a physical interface of the security gateway or it might be VPN tunnel
(tunnels are treated like physical interfaces by cOS Core).
•
Network
This is the destination network IP address range which this route will reach. The route chosen
from a routing table is the one that has a destination IP range which includes the IP address
being sought. If there is more than one such matching route, the route chosen is the one
which has the smallest IP address range.
The destination network all-nets is usually always used in the route for public Internet access
via an ISP.
•
Gateway
The IP address of the gateway which is the next router in the path to the destination network.
This is optional. If the destination network is connected directly to the interface, this is not
needed.
When a router lies between the Clavister Security Gateway and the destination network, a
gateway IP must be specified. For example, if the route is for public Internet access via an ISP
then the public IPv4 address of the ISP's gateway router would be specified.
232
Chapter 4: Routing
•
Local IP address
This parameter usually does not need to be specified. If it is specified, cOS Core responds to
ARP queries sent to this address. A special section below explains this parameter in more
depth.
Local IP Address and Gateway are mutually exclusive and either one or the other should be
specified.
•
Metric
This is a metric value assigned to the route and is used as a weight when performing
comparisons between alternate routes. If two routes are equivalent but have different metric
values then the route with the lowest metric value is taken.
The metric value is also used by Route Failover and Route Load Balancing.
For more information, see Section 4.4, “Route Load Balancing” and Section 4.2.3, “Route
Failover”.
A Typical Routing Scenario
The diagram below illustrates a typical Clavister Security Gateway usage scenario.
Figure 4.1. A Typical Routing Scenario
In the above diagram, the LAN interface is connected to the network 192.168.0.0/24 and the
DMZ interface is connected to the network 10.4.0.0/16. The WAN interface is connected to the
network 195.66.77.0/24 and the address of the ISP gateway to the public Internet is 195.66.77.4.
The associated routing table for this would be as follows:
233
Chapter 4: Routing
Route #
Interface
Destination
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
Gateway
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 the 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. This route usually specifies the
interface which is connected to the public internet.
The Narrowest Routing Table Match is Selected
When a routing table is evaluated, the ordering of the routes is not important. Instead, all routes
in the relevant routing table are evaluated and the most specific route is used. In other words, if
two routes have destination networks that overlap, the narrower network definition will be taken
before the wider one. This behavior is in contrast to IP rules where the first matching rule is used.
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 narrower, more
specific match so the evaluation will end there and the packet will be routed according to that
entry.
Although routing table ordering is not important, it is still recommended for readability to try
and place narrower routes first and the default all-nets route last.
The Local IP Address Parameter
The correct usage of the Local IP Address parameter can be difficult to understand so additional
explanation can be helpful.
Normally, a physical interface such as lan is connected to a single network and the interface and
network are on the same network. We can say that the network is bound to a physical interface
and clients on the connected network can automatically find the Clavister Security Gateway
234
Chapter 4: Routing
through ARP queries. ARP works because the clients and the cOS Core interface are part of the
same network.
A second network might then be added to the same physical interface via a switch, but with a
new network range that does not include the physical interface's IP address. This network is said
to be not bound to the physical interface. Clients on this second network won't then be able to
communicate with the Clavister Security Gateway because ARP won't function between the
clients and the interface.
To solve this problem, a new route is added to cOS Core with the following parameters:
•
Interface: The interface on which the second network is found.
•
Network: The IP address range of the second network.
•
Local IP Address: An address within the second network's IP range.
When the Default Gateway of the second network's clients is now set to the same value as the
Local IP Address of the above route, the clients will be able to communicate successfully with the
interface. The IP address chosen in the second network is not significant, as long as it is the same
value for the Default Gateway of the clients and the Local IP Address.
The effect of adding the route with the Local IP Address is that the security gateway will act as a
gateway with the Local IP Address and respond to, as well as send out, ARP queries as though the
interface had that IP address.
The diagram below illustrates a scenario where this feature could be used. The network
10.1.1.0/24 is bound to a physical interface that has an IP address within the network of 10.1.1.1. If
we now attach a second network 10.2.2.0/24 to the interface via the switch, it is unbound since
the interface's IP address does not belong to it.
Figure 4.2. Using Local IP Address with an Unbound Network
By adding a cOS Core route for this second network with the Local IP Address specified as 10.2.2.1,
the interface will then respond to ARP requests from the 10.2.2.0/24 network. The clients in this
235
Chapter 4: Routing
second network must also have their Default Gateway set to 10.2.2.1 in order to reach the
Clavister Security Gateway.
This feature is normally used when an additional network is to be added to an interface but it is
not desirable to change the existing IP addresses of the network. From a security standpoint,
doing this can present significant risks since different networks will typically be joined together
through a switch which imposes no controls on traffic passing between those networks. Caution
should therefore be exercised before using this feature.
All Traffic Must have Two Associated Routes
Something that is not intuitive when trying to understand routing in cOS Core is the fact that all
traffic must have two routes associated with it. Not only must a route be defined for the
destination network of a connection but also for the source network.
The route that defines the source network simply says that the source network is found on a
particular interface. When a new connection is opened, cOS Core performs a check known as a
reverse route lookup which looks for this route. The source network route is not used to perform
routing but instead as a check that the source network should be found on the interface where it
arrived. If this check fails, cOS Core generates a Default Access Rule error log message.
Even traffic destined for Core (cOS Core itself ), such as ICMP ping requests must follow this rule of
having two routes associated with it. In this case, the interface of one of the routes is specified as
Core.
4.2.2. Static Routing
This section describes how routing is implemented in cOS Core, and how to configure static
routing.
cOS Core supports multiple routing tables. A default table called main is predefined and is
always present in cOS Core. However, additional and completely separate routing tables can be
defined by the administrator to provide alternate routing.
Extra user-defined routing tables can be used in two ways:
•
Virtual Routing associates interfaces with a particular routing table. This enables a single
cOS Core installation to act as multiple virtual systems. Communication between these
systems is achieved with Loopback Interfaces (see Section 4.5, “Virtual Routing” and also
Section 3.4.6, “Loopback Interfaces”).
•
Policy Based Routing Rules can be defined which decide which of the routing tables will
deal with certain types of traffic (see Section 4.3, “Policy-based Routing”).
The Route Lookup Mechanism
The cOS Core 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 cOS Core, packets are forwarded with state-awareness, so the route
lookup process is tightly integrated into the cOS Core 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 cOS
Core.
236
Chapter 4: Routing
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 any of the various policy rules get
evaluated (for example, IP rules). Consequently, the destination interface is known at the time
cOS Core decides if the connection should be allowed or dropped. This design allows for a more
fine-grained control in security policies.
cOS Core Route Notation
cOS Core 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
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
10.255.255.255 255.255.255.255
10.4.2.143
10.4.2.143
50
85.11.194.33 255.255.255.255 192.168.0.1 192.168.0.10
20
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
192.168.0.255 255.255.255.255 192.168.0.10 192.168.0.10
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
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
===================================================================
Persistent Routes:
None
The corresponding routing table in cOS Core will be similar to the following:
Flags Network
----- -----------------192.168.0.0/24
10.0.0.0/8
0.0.0.0/0
Iface
Gateway
Local IP
-------- -------------- --------lan
wan
wan
192.168.0.1
Metric
-----20
1
20
cOS Core Route Definition Advantages
The cOS Core method of defining routes makes the reading and understanding of routing
information easier.
A further advantage with the cOS Core approach is that the administrator can directly specify a
gateway for a particular route and the following is true:
•
A separate route does not need to be defined that includes the gateway IP address.
237
Chapter 4: Routing
•
It does not matter even if there is a separate route which includes the gateway IP address and
that routes traffic to a different interface.
Composite Subnets can be Specified
Another advantage with the cOS Core approach to route definition is that it allows the
administrator to specify routes for destinations that are not aligned with traditional subnet
masks.
For example, it is perfectly legal to define one route for the destination IP address range
192.168.0.5 to 192.168.0.17 and another route for IP addresses 192.168.0.18 to 192.168.0.254. This
is a feature that makes cOS Core highly suitable for routing in highly complex network
topologies.
Displaying Routing Tables
It is important to note that routing tables that are initially configured by the administrator can
have routes added, deleted and changed automatically during live operation and these changes
will appear when the routing table contents are displayed.
These routing table changes can take place for different reasons. For example, if dynamic routing
with OSPF has been enabled then routing tables will become populated with new routes learned
from communicating with other OSPF routers in an OSPF network. Other events such as route
fail-over can also cause routing table contents to change over time.
Example 4.1. Displaying the main Routing Table
This example illustrates how to display the contents of the default main routing table.
Command-Line Interface
To see the routing table contents:
Device:/> cc RoutingTable main
Device:/main> show
Route
#
1
2
3
Interface
--------wan
lan
wan
Network
-------all-nets
lan_net
wan_net
Gateway
------------213.124.165.1
<empty>
<empty>
Local IP
-------<empty>
<empty>
<empty>
To return the default CLI context:
Device:/main> cc
Device:/>
To see the active routing table enter:
Device:/> routes
Flags Network
----- -----------------192.168.0.0/24
213.124.165.0/24
0.0.0.0/0
Iface
Gateway
Local IP
------- --------------- -------lan
wan
wan
213.124.165.1
238
Metric
-----0
0
0
Chapter 4: Routing
InControl
Follow the same steps used for the Web Interface below.
Web Interface
To see the configured routing table:
1.
Go to: Network > Routing > Routing Tables
2.
Select the main routing table
The main window will list the configured routes
To see the active routing table in the Web Interface, select the Routes item in the Status
dropdown menu in the menu bar - the main window will list the active routing table
Tip: The cc command may be needed to change context
In the CLI example above, it was necessary to first select the name of a specific routing
table with the cc command (meaning change category or change context) before
manipulating individual routes.
Default Static Routes are Added Automatically for Each Interface
When the Clavister Security Gateway is started for the first time, cOS Core will automatically add
a route in the main routing table for each physical interface. These routes are assigned a default
IP address object in the address book and these IP objects must have their addresses changed to
the appropriate range for traffic to flow.
Note: The metric for default routes is 100
The metric assigned to the default routes automatically created for the physical
interfaces is always 100.
These automatically added routes cannot be removed manually by deleting them one at a time
from a routing table. Instead, the properties of the interface must be selected and the advanced
option Automatically add a route for this interface using the given network must be
disabled. This will remove any route that was added automatically at startup. This option has no
other purpose but to delete the automatically added routes.
The all-nets Route
The most important route that should be defined is the route to all-nets which usually
corresponds to an ISP that provides public Internet access. If using the cOS Core setup wizard,
this route is also added automatically.
However, the option also exists for any physical interface to indicate that it should be used for
connection to the Internet. In the Web Interface or InControl this is an advanced setting in the
Ethernet interface properties called:
Automatically add a default route for this interface using the given default gateway.
239
Chapter 4: Routing
When this option is selected, the appropriate all-nets route is automatically added to the main
routing table for the interface.
Example 4.2. Adding a Route to the main Table
This example shows how an all-nets route is added to the routing table called main. This route
will be for the ISP connected to the wan interface and the ISP is accessed via a router with the IP
address isp_gw_ip which will be the gateway for the route.
Command-Line Interface
Change the context to be the routing table:
Device:/> cc RoutingTable main
Add the route:
Device:/main> add Route
Interface=wan
Network=all-nets
Gateway=isp_gw_ip
Return to the default CLI context:
Device:/main> cc
Device:/>
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Network > Routing > Routing Tables > main > Add > Route
2.
Now enter:
3.
•
Interface: wan
•
Network: all-nets
•
Gateway: isp_gw_ip
Click OK
Routes can Contain IPv4 or IPv6 Addresses
A single route can contain either an IPv4 or IPv6 address but not both. Routes that use IPv4 and
IPv6 addresses can be mixed in the same routing table. This topic is described further in
Section 3.2, “IPv6 Support”.
Routes to the Core Interface
cOS Core automatically populates the active routing table with Core Routes. These routes are
240
Chapter 4: Routing
present for cOS Core to understand how to route traffic that is destined for the itself.
There is one route added for each Ethernet interface in the system. For example, if there two
interfaces named lan and wan with the IPv4 addresses 192.168.0.10 and 193.55.66.77, this will
result in the following routes existing:
Route #
Interface
Destination
1
core
192.168.0.10
2
core
193.55.66.77
Gateway
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 cOS Core itself.
There is also a core route added for all multicast addresses:
Route #
Interface
Destination
1
core
224.0.0.0/4
Gateway
To include the core routes when the active routing table is displayed, it is necessary to explicitly
specify that all routes are to be displayed. This is shown in the example below.
Example 4.3. Displaying the Core Routes
This example illustrates how to display the core routes in the active routing table.
Command-Line Interface
Device:/> routes -all
Flags Network
----- -----------------127.0.0.1
192.168.0.1
213.124.165.181
127.0.3.1
127.0.4.1
192.168.0.0/24
213.124.165.0/24
224.0.0.0/4
0.0.0.0/0
Iface
Gateway
Local IP Metric
---------- ------------- -------- -----core
(Shared IP)
0
core
(Iface IP)
0
core
(Iface IP)
0
core
(Iface IP)
0
core
(Iface IP)
0
lan
0
wan
0
core
(Iface IP)
0
wan
213.124.165.1
0
InControl
This operation cannot be performed with InControl.
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
241
Chapter 4: Routing
Tip: Understanding output from the routes command
For detailed information about the output of the CLI routes command, refer to the
separate CLI Reference Guide.
4.2.3. Route Failover
Overview
Clavister Security Gateways are often deployed in mission-critical locations where availability and
connectivity is crucial. For example, an enterprise relying heavily on access to the Internet could
have operations severely disrupted if a single connection to the external Internet via a single
Internet Service Provider (ISP) fails.
It is therefore not unusual to have backup Internet connectivity using a secondary ISP. The
connections to the two service providers often use different routes to avoid a single point of
failure.
To allow for a situation with multiple ISPs, cOS Core provides a Route Failover capability so that
should one route fail, traffic can automatically failover to another, alternate route. cOS Core
implements route failover through the use of Route Monitoring in which cOS Core monitors the
availability of routes and then switches traffic to an alternate route should the primary, preferred
route fail.
Figure 4.3. A Route Failover Scenario for ISP Access
Setting Up Route Failover
To set up route failover, Route Monitoring must be enabled and this is an option that is enabled
on a route by route basis. To enable route failover 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 this since it will usually have no route to failover to. When route monitoring is
enabled for a route, one of the following monitoring methods must be chosen:
Interface Link Status
cOS Core will monitor the link status of the interface specified in
the route. As long as the interface is up, the route is diagnosed
242
Chapter 4: Routing
as healthy. This method is appropriate for monitoring that the
interface is physically attached and that the cabling is working
as expected. As any changes to the link status are instantly
noticed, this method provides the fastest response to failure.
Gateway Monitoring
If a specific gateway has been specified as the next hop for a
route, accessibility to that gateway can be monitored by
sending periodic ARP requests. As long as the gateway
responds to these requests, the route is considered to be
functioning correctly.
Host Monitoring
The first two options check the accessibility of components local
to the Clavister Security Gateway. An alternative is to monitor
the accessibility of one or more nominated remote hosts. These
hosts might have known high availability and polling them can
indicate if traffic from the local Clavister Security Gateway is
reaching them. Host monitoring also provides a way to measure
the network delays in reaching remote hosts and to initiate
failover to an alternate route if delays exceed
administrator-specified thresholds.
Automatically Added Routes Need Redefining
It is important to note that the route monitoring cannot be enabled on automatically added
routes. For example, the routes that cOS Core creates at initial startup for physical interfaces are
automatically added routes. The reason why monitoring cannot be enabled for these routes is
because automatically created routes have a special status in an cOS Core configuration and are
treated differently.
If route monitoring is required on an automatically created route, the route should first be
deleted and then recreated manually as a new route. Monitoring can then be enabled on the
new route.
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, cOS Core 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, cOS Core will mark the route as
243
Chapter 4: Routing
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 is not 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 cOS Core, 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, cOS Core will continue to check the status of that route. Should
the route become available again, it will be re-enabled and existing connections will
automatically be transferred back to it.
Route Interface Grouping
When using route monitoring, it is important to check if a failover to another route will cause the
routing interface to be changed. If this could happen, it is necessary to take some precautionary
steps to ensure that policies and existing connections will be maintained.
To illustrate the problem, consider the following configuration:
Firstly, 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
NAT
lan
lan_net
wan
all-nets
http
The routing table consequently contains the following default route:
Interface
Destination
Gateway
Metric
Monitoring
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 if the wan route
244
Chapter 4: Routing
should 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 established, 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.4.7, “Interface Groups”.
Gratuitous ARP Generation
By default cOS Core 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 behavior can be
controlled by the advanced setting Gratuitous ARP on Fail.
4.2.4. Host Monitoring for Route Failover
Overview
To provide a more flexible and configurable way to monitor the integrity of routes, cOS Core
provides the additional capability to perform Host Monitoring. This feature means that one or
more external host systems can be routinely polled to check that a particular route is available. It
is similar in concept to the monitoring used for the Server Load Balancing feature in cOS Core (see
Section 10.4.5, “SLB Server Monitoring”) but there are important differences.
The advantages of Host Monitoring are twofold:
•
In a complex network topology it is more reliable to check accessibility to external hosts. Just
monitoring a link to a local switch may not indicate a problem in another part of the internal
network.
•
Host monitoring can be used to help in setting the acceptable Quality of Service level of
Internet response times. Internet access may be functioning but it may be desirable to
instigate route failover if response latency times become unacceptable using the existing
route.
Enabling Host Monitoring
As part of Route Properties Host Monitoring can be enabled and a single route can have multiple
hosts associated with it for monitoring. Multiple hosts can provide a higher certainty that any
network problem resides in the local network rather than because one remote host itself is
down.
In association with Host Monitoring there are two numerical parameters for a route:
Grace Period
This is the period of time after startup or after
reconfiguration of the Clavister Security Gateway which
cOS Core will wait before starting Route Monitoring. This
waiting period allows time for all network links to initialize
once the security gateway comes online.
245
Chapter 4: Routing
Minimum Number of Hosts
Available
This is the minimum number of hosts that must be
considered to be accessible before the route is deemed to
have failed. The criteria for host accessibility are described
below.
Specifying Hosts
For each host specified for host monitoring there are a number of property parameters that
should be set:
•
Method
The method by which the host is to be polled. This can be one of:
•
•
ICMP - ICMP "Ping" polling. An IP address must be specified for this.
•
TCP - A TCP connection is established to and then disconnected from the host. An IP
address must be specified for this.
•
HTTP - A normal HTTP server request using a URL. A URL must be specified for this as well
as a text string which is the beginning (or complete) text of a valid response. If no text is
specified, any response from the server will be valid.
IP Address
The IP address of the host when using the ICMP or TCP option.
•
Port Number
The port number for polling when using the TCP option.
•
Interval
The interval in milliseconds between polling attempts. The default setting is 10,000 and the
minimum value allowed is 100 ms.
•
Sample
The number of polling attempts used as a sample size for calculating the Percentage Loss and
the Average Latency. This value cannot be less than 1.
•
Maximum Failed Poll Attempts
The maximum permissible number of polling attempts that fail. If this number is exceeded
then the host is considered unreachable.
•
Max Average Latency
The maximum number of milliseconds allowable between a poll request and the response. If
this threshold is exceeded then the host is considered unreachable. Average Latency is
calculated by averaging the response times from the host. If a polling attempt receives no
response then it is not included in the averaging calculation.
The Reachability Required option
An important option that can be enabled for a host is the Reachability Required option. When
this is selected, the host must be determined as accessible in order for that route to be
considered to be functioning. Even if other hosts are accessible, this option says that the
246
Chapter 4: Routing
accessibility of a host with this option set is mandatory.
Where multiple hosts are specified for host monitoring, more than one of them could have
Reachability Required enabled. If cOS Core determines that any host with this option enabled is
not reachable, Route Failover is initiated.
HTTP Parameters
If the HTTP polling method is selected then two further parameters can be entered:
•
Request URL
The URL which is to be requested.
•
Expected Response
The text that is expected back from querying the URL.
Testing for a specific response text provides the possibility of testing if an application is
offline. If, for example, a web page response from a server can indicate if a specific database is
operational with text such as "Database OK", then the absence of that response can indicate
that the server is operational but the application is offline.
A Known Issue When No External Route is Specified
With connections to an Internet ISP, an external network route should always be specified. This
external route specifies on which interface the network which exists between the Clavister
Security Gateway and the ISP can be found. If only an all-nets route is specified to the ISP's
gateway, route failover may, depending on the connected equipment, not function as expected.
This issue rarely occurs but the reason why it occurs is that ARP queries arriving on a disabled
route will be ignored.
4.2.5. Advanced Settings for Route Failover
The following cOS Core advanced settings are available for route failover:
Iface poll interval
The time in milliseconds between polling for interface failure.
Default: 500
ARP poll interval
The time in milliseconds between ARP-lookup of hosts. This may be overridden in individual
routes.
Default: 1000
Ping poll interval
The time in milliseconds between sending a Ping to hosts.
Default: 1000
247
Chapter 4: Routing
Grace time
The length of time in seconds between startup or reconfigure and monitoring start.
Default: 30
consecutive fails
The number of consecutive failures that occurs before a route is marked as being unavailable.
Default: 5
Consecutive success
The number of consecutive successes that must occur before a route is marked as being
available.
Default: 5
Gratuitous ARP on fail
Send a gratuitous ARP on HA failover to alert hosts of the changes in interface Ethernet and IP
addresses.
Default: Enabled
4.2.6. Proxy ARP
Overview
As discussed previously in Section 3.5, “ARP”, the ARP protocol facilitates a mapping between an
IP address and the MAC address of a host on an Ethernet network.
However, situations may exist where a network running Ethernet is separated into two parts with
a routing device such as a Clavister Security Gateway in between. In such a case, cOS Core itself
can respond to ARP requests directed to the network on the other side of the Clavister Security
Gateway using the feature known as Proxy ARP.
The splitting of an Ethernet network into distinct parts so that traffic between them can be
controlled is a common usage of the proxy ARP feature. cOS Core rule sets can then be used to
impose security policies on the traffic passing between the different network parts.
A Typical Scenario
As an example of a typical proxy ARP scenario, consider a network split into two sub-networks
with a Clavister Security Gateway between the two.
Host A on one sub-network might send an ARP request to find out the MAC address for the IP
address of host B on the other sub-network. With the proxy ARP feature configured, cOS Core
responds to this ARP request instead of host B. cOS Core sends its own MAC address in reply,
pretending to be the target host. After receiving the reply, Host A then sends data directly to cOS
Core which forwards the data to host B. In the process cOS Core checks the traffic against the
configured rule sets.
248
Chapter 4: Routing
Setting Up Proxy ARP
Setting up proxy ARP is done by specifying the option for a route in a routing table. Suppose
there is a network that is divided into two parts called net_1 and net_2.
The network net_1 is connected to the interface if1 and the network net_2 is connected to the
interface if2. In cOS Core there will be a route configured that says net_1 can be found on if1. This
might be called route_1.
For route_1 it is possible to specify the option that this network should be proxy ARPed on
interface if2. Now any ARP request issued by a net_2 host connected to if2 looking for an IP
address in net_1 will get a positive response from cOS Core. In other words, cOS Core will
pretend that the net_1 address is found on if2 and will forward data traffic to net_1.
In the same way, net_2 could be published on the interface if1 so that there is a mirroring of
routes and ARP proxy publishing.
Route #
Network
Interface
Proxy ARP Published
1
net_1
if1
if2
2
net_2
if2
if1
In this way there is complete separation of the sub-networks but the hosts are unaware of this.
The routes are a pair which are a mirror image of each other but there is no requirement that
proxy ARP is used in a pairing like this.
Keep in mind that if the host has an ARP request for an IP address outside of the local network
then this will be sent to the gateway configured for that host. The entire example is illustrated
below.
Figure 4.4. A Proxy ARP Example
Transparent Mode as an Alternative
Transparent Mode is an alternative and preferred way of splitting Ethernet networks. Setup is
simpler than using proxy ARP since only the appropriate switch routes need to be defined. Using
switch routes is fully explained in Section 4.8, “Transparent Mode”.
Proxy ARP depends on static routing where the location of networks on interfaces are known
and usually fixed. Transparent mode is more suited to networks whose interface location can
change.
249
Chapter 4: Routing
Proxy ARP and High Availability Clusters
In HA clusters, switch routes cannot be used and transparent mode is therefore not an option.
However, proxy ARP does function with HA and is consequently the only way to implement
transparent mode functionality with a cluster.
Note: Not all interfaces can make use of Proxy ARP
It is only possible to have Proxy ARP functioning for Ethernet and VLAN interfaces. Proxy
ARP is not relevant for other types of cOS Core interfaces since ARP is not involved.
Automatically Added Routes
Proxy ARP cannot be enabled for automatically added routes. For example, the routes that cOS
Core creates at initial startup for physical interfaces are automatically added routes. The reason
why Proxy ARP cannot be enabled for these routes is because automatically created routes have
a special status in the cOS Core configuration and are treated differently.
If Proxy ARP is required on an automatically created route, the route should first be deleted and
then manually recreated as a new route. Proxy ARP can then be enabled on the new route.
250
Chapter 4: Routing
4.3. Policy-based Routing
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
use different routing tables according to specified criteria.
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 allows the following to be possible:
•
Source-based Routing
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.
•
Service-based Routing
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.
•
User-based Routing
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 and subscribe to different
providers.
PBR Components
Policy-based routing implementation in cOS Core is implemented using two components:
•
Additional Routing Tables
One or more user-defined alternate Routing Tables are created in addition to the standard
default main routing table.
•
Routing Rules
One or more Routing Rules are created to determine which routing table to use for which
traffic.
Without routing rules, the main routing table is the default. However, an alternate routing
table can also be explicitly assigned as the default table for a given interface without the use
of rules.
251
Chapter 4: Routing
Routing Tables
cOS Core, as standard, has one default routing table called main. In addition to the main table, it
is possible to define one or more, additional routing tables for policy-based routing. (these will
sometimes be referred to as alternate routing tables).
Alternate routing tables contain the same information for describing routes as main, except that
there is an extra property defined for each of them which is called ordering. The ordering property
decides how route lookup is done using alternate tables in conjunction with the main table. This
is described further below.
Note: The number of tables is limited by the license
The total number of routing tables that can be created is limited only by the particular
license that is used with a cOS Core installation. At minimum, there is a limit of 5
alternate tables in addition to the main table.
Example 4.4. Creating a Routing Table
In this example, a new routing table called MyPBRTable is created with the Ordering property set
to First.
Command-Line Interface
To see the configured routing table:
Device:/> add RoutingTable MyPBRTable Ordering=First
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Network > Routing > Routing Tables > Add > RoutingTable
2.
Now enter:
3.
•
Name: MyPBRTable
•
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 (in other words the all-nets route), 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.
If Remove Interface IP Routes is enabled, the default interface routes are removed, that is
252
Chapter 4: Routing
to say routes to the core interface (which are routes to cOS Core itself ).
4.
Click OK
Example 4.5. Adding Routes
After defining the routing table MyPBRTable, routes can be added to the table. Assume that the
route to a network my_network is to be defined for the lan interface.
Command-Line Interface
Change the context to be the routing table:
Device:/> cc RoutingTable MyPBRTable
Add the route
Device:/main> add Route Interface=lan Network=my_network
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Network > Routing > Routing Tables > MyPBRTable > Add > Route
2.
Now enter:
3.
•
Interface: lan
•
Network: my_network
•
Gateway: The gateway router is there is one
•
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 gateway's interface IP address will be used.
•
Metric: Specifies the metric for this route. (Mostly used in route fail-over scenarios)
Click OK
Routing Rules
A rule in the routing rule set can decide which routing table is selected. A routing rule has a
number of filtering properties that are similar to those used in an IP rule. A rule can trigger on a
type of service (HTTP for example) in combination with the specified Source/Destination
Interface and Source/Destination Network.
When looking up routing rules, it is the first matching rule found that is triggered.
253
Chapter 4: Routing
Example 4.6. Creating a Routing Rule
In this example, a routing rule called my_routing_rule is created. This will select the routing table
MyPBRTable for any http traffic destined for the network my_network.
Command-Line Interface
Device:/> add RoutingRule Service=http
SourceInterface=any
SourceNetwork=all-nets
DestinationInterface=any
DestinationNetwork=my_network
ForwardRoutingTable=MyPBRTable
ReturnRoutingTable=MyPBRTable
Name=my_routing_rule
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Network > Routing > Routing Tables > Add > RoutingTable
2.
Now enter:
•
Name: my_routing_rule
•
Service: http
•
SourceInterface: any
•
SourceNetwork: all-nets
•
DestinationInterface: any
•
DestinationNetwork: my_network
•
ForwardRoutingTable: MyPBRTable
•
ReturnRoutingTable: MyPBRTable
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 cOS Core itself ).
4.
Click OK
Routing Rules can use IPv4 or IPv6 Addresses
Routing rules support either IPv4 or IPv6 addresses as the source and destination network for a
rule's filtering properties.
However both the source and destination network must be either IPv4 or IPv6. It is not
permissible to combine IPv4 and IPv6 addresses in a single rule. For further discussion of this
topic, see Section 3.2, “IPv6 Support”.
254
Chapter 4: Routing
The Forward and Return Routing Table can be Different
In most cases, the routing table for forward and return traffic will be the same. In some cases it
can be advantageous to have different values.
Take the example of a security gateway with two hypothetical interfaces wan1 and wan2
connected to two ISPs plus a protected network If1_net on the If1 interface. There are two
routing tables, the main routing table and an isp2 routing table which look like the following:
The main routing table
Index #
Interface
Network
1
If1
If1_net
Gateway
2
wan1
all-nets
isp1_ip
Index #
Interface
Destination
Gateway
1
wan2
all-nets
isp2_ip
The isp2 routing table
If traffic coming through wan2 is to have access to If1_net then a routing rule needs to
constructed as follows:
Source
Interface
Source
Network
Destination
Interface
Destination
Network
Forward
Routing Table
Return
Routing Table
wan2
all-nets
any
If1_net
main
isp2
This rule allows the forward traffic through the wan2 table to find the route for If1_net in the
main routing table. The return traffic will use the isp2 table so it can reach the initiator of the
connection.
This example should also have some address translation rules since If1_net will probably be a
private IP network. For simplicity, that has been omitted.
Routing Table/Interface Association
If a particular routing table is to be always used for traffic from a given source interface,
regardless of the service, it is possible to associate the source interface explicitly with a particular
table using the Group membership property of the interface. This is sometimes referred to as
Routing Table Membership.
The difference with this method of explicit association is that the administrator cannot specify
the service, such as HTTP, for which the lookup will apply. Routing rules allow a more
fine-grained approach to routing table selection by being able to also select a specific service
and interface/network filter.
The Routing Table Selection Process
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 routing rules are first 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 that a match for the destination network is found or at least a default all-nets
route exists which can catch anything not explicitly matched.
255
Chapter 4: Routing
2.
A search is now made for a routing rule that matches the packet's source/destination
interface/network as well as service. If a matching rule is found then this determines the
routing table to use.
3.
If no matching routing rule is found, a check is made to see if the source interface has an
alternate routing table explicitly associated with it through its Group property. In other
words, to see if the interface has Routing Table Membership of a particular routing table. If
there is no membership then the main table will be used.
4.
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.
5.
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.
6.
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.
7.
If allowed by the IP rule set, the new connection is opened in the cOS Core state table and
the packet forwarded through this connection.
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 behavior 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), 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 behavior 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 that is the
only one used for the lookup.
One application of this option is to give the administrator a way to dedicate a single routing
table to one set of interfaces. The Only option should be used when creating virtual systems
since it can dedicate a routing table to a set of interfaces.
256
Chapter 4: Routing
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: Ensure all-nets appears in the main table
A common mistake when setting up policy-based routing is the absence of a 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 of a default all-nets route
will mean that the connection will be dropped. The alternative of having interfaces
associated explicitly with alternate routing tables through the Group option will also
not function if the default all-nets route is missing.
Example 4.7. Policy-based Routing with Multiple ISPs
This example illustrates a multiple ISP scenario which is a common use of policy-based routing.
The following is assumed:
•
Each ISP will provide an IPv4 network from its network range. A 2 ISP scenario is assumed in
this case, with the network 10.10.10.0/24 belonging to ISP A and 20.20.20.0/24 belonging to
ISP B. The ISP provided gateways are 10.10.10.1 and 20.20.20.1 respectively.
•
All addresses in this scenario are public addresses for the sake of simplicity.
•
This is a "drop-in" design, where there are no explicit routing subnets between the ISP
gateways and the Clavister Security Gateway.
In a provider-independent network, clients will likely have a single IP address, belonging to one
of the ISPs. In a single-organization scenario, publicly accessible servers will be configured with
two separate IP addresses: one from each ISP. However, this difference does not matter for the
policy routing setup itself.
Note that, for a single organization, Internet connectivity through multiple ISPs is normally best
done with the BGP protocol, which means not worrying about different IP spans or about policy
routing. Unfortunately, this is not always possible, and this is where Policy Based Routing
becomes a necessity.
We will set up the main routing table to use ISP A and add a named routing table called r2 that
uses the default gateway of ISP B.
Interface
Network
Gateway
ProxyARP
lan1
10.10.10.0/24
wan1
lan1
20.20.20.0/24
wan2
wan1
10.10.10.1/32
lan1
wan2
20.20.20.1/32
wan1
all-nets
lan1
10.10.10.1
Contents of the named Policy-based Routing table r2:
Interface
Network
Gateway
wan2
all-nets
20.20.20.1
The table r2 has its Ordering parameter set to Default, which means that it will only be consulted
if the main routing table lookup matches the default route (all-nets).
257
Chapter 4: Routing
Contents of the Policy-based Routing Policy:
Source
Interface
Source
Range
Destination
Interface
Destination
Range
Selected/
Service
Forward
VR table
Return
VR table
lan1
10.10.10.0/24
wan1
all-nets
all_services
r2
r2
wan2
all-nets
lan1
20.20.20.0/24
all_services
r2
r2
To configure this example scenario:
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Add the routes in the list to the main routing table, as shown above.
2.
Create a routing table called r2 and make sure the ordering is set to Default.
3.
Add the routes found in the list above for the routing table r2.
4.
Add the PBR routing rules according to the list with the following:
•
Go to: Network > Routing > Policy-based Routing Rules > Add > Routing Rule
•
Enter the information from the list
•
Repeat to add the next rule
Note
Routing rules in the above example are added for both inbound and outbound
connections.
258
Chapter 4: Routing
4.4. Route Load Balancing
Overview
cOS Core provides the option to perform Route Load Balancing (RLB). This is the ability to
distribute traffic over multiple alternate routes using one of a number of distribution algorithms.
The purpose of this feature is to provide the following:
•
Balancing of traffic between interfaces in a policy driven fashion.
•
To balance simultaneous utilization of multiple Internet links so networks are not dependent
on a single ISP.
•
To allow balancing of traffic across multiple VPN tunnels which might be setup over different
physical interfaces.
Enabling RLB
RLB is enabled on a routing table basis and this is done by creating an RLB Instance object. This
object specifies two parameters: a routing table and an RLB algorithm. A table may have only
one Instance object associated with it.
One of the algorithms from the following list can be specified in an RLB Instance object:
•
Round Robin
Matching routes are used equally often by successively going to the next matching route.
•
Destination
This is an algorithm that is similar to Round Robin but provides destination IP "stickiness" so
that the same destination IP address gets the same route.
•
Spillover
This uses the next route when specified interface traffic limits are exceeded continuously for
a given time.
Disabling RLB
Deleting a routing table's Instance object has the effect of switching off RLB for that table.
RLB Operation
When RLB is enabled for a routing table through an RLB Instance object, the sequence of
processing steps is as follows:
1.
Route lookup is done in the routing table and a list of all matching routes is assembled. The
routes in the list must cover the exact same IP address range (further explanation of this
requirement can be found below).
2.
If the route lookup finds only one matching route then that route is used and balancing
does not take place.
259
Chapter 4: Routing
3.
If more than one matching route is found then RLB is used to choose which one to use. This
is done according to which algorithm is selected in the table's RLB Instance object:
•
Round Robin
Successive routes are chosen from the matching routes in a "round robin" fashion
provided that the metric of the routes is the same. This results in route lookups being
spread evenly across matching routes with same metric. If the matching routes have
unequal metrics then routes with lower metrics are selected more often and in
proportion to the relative values of all metrics (this is explained further below).
Figure 4.5. The RLB Round Robin Algorithm
•
Destination
This is similar to Round Robin but provides "stickiness" so that unique destination IP
addresses always get the same route from a lookup. The importance of this is that it
means that a particular destination application can see all traffic coming from the same
source IP address.
•
Spillover
Spillover is not similar to the previous algorithms. With spillover, the first matching
route's interface is repeatedly used until the Spillover Limits of that route's interface are
continuously exceeded for the Hold Timer number of seconds.
Once this happens, the next matching route is then chosen. The Spillover Limits for an
interface are set in the RLB Algorithm Settings along with the Hold Timer number of
seconds (the default is 30 seconds) for the interface.
When the traffic passing through the original route's interface falls below the Spillover
Limits continuously for the Hold Timer number of seconds, route lookups will then revert
back to the original route and its associated interface.
260
Chapter 4: Routing
Figure 4.6. The RLB Spillover Algorithm
Spillover Limits are set separately for ingoing and outgoing traffic with only one of these
typically being specified. If both are specified then only one of them needs to be
exceeded continuously for Hold Timer seconds for the next matching route to be chosen.
The units of the limits, such as Mbps, can be selected to simplify specification of the
values.
Using Route Metrics with Round Robin
An individual route has a metric associated with it, with the default metric value being zero.
With the Round Robin and the associated Destination algorithms, the metric value can be set
differently on matching routes to create a bias towards the routes with lower metrics. Routes
with lower metrics will be chosen more frequently than those with higher metrics and the
proportion of usage will be based on the relative differences between the metrics of matching
routes.
In a scenario with two ISPs, if the requirement is that the bulk of traffic passes through one of the
ISPs then this can be achieved by enabling RLB and setting a low metric on the route to the
favoured ISP. A relatively higher metric is then set on the route to the other ISP.
Using Route Metrics with Spillover
When using the Spillover algorithm, a number of points should be noted regarding metrics and
the way alternative routes are chosen:
•
Route metrics should always be set.
With spillover, cOS Core always chooses the route in the matching routes list that has the
lowest metric. The algorithm is not intended to be used with routes having the same metric
so the administrator should set different metrics for all the routes to which spillover applies.
Metrics determine a clear ordering for which route should be chosen next after the interface
traffic limits for the chosen route have been exceeded.
•
There can be many alternative routes.
Several alternative routes can be set up, each with their own interface limits and each with a
261
Chapter 4: Routing
different metric. The route with the lowest metric is chosen first and when that route's
interface limits are exceeded, the route with the next highest metric is then chosen.
When that new route's interface limits are also exceeded then the route with the next highest
metric is taken and so on. As soon as any route with a lower metric falls below its interface
limit for its Hold Timer number of seconds, then it reverts to being the chosen route.
•
If there is no alternative route, the route does not change.
If the spillover limit is reached but all alternative routes have also reached their limit then the
route will not change.
The Requirement for Matching IP Ranges
As explained above, when RLB is assembling a list of matching routes from a routing table, the
routes it selects must have the same range. Balancing between routes will not take place if their
ranges are not exactly the same.
For instance, if one matching route has an IP address range of 10.4.16.0/24 and there is a second
matching route with an address range 10.4.16.0/16 (which is a range that includes 10.4.16.0/24)
then RLB will not take place between these routes. The ranges are not exactly the same so RLB
will treat the routes as being different.
It should also be remembered that route lookup will select the route that has the narrowest
range that matches the destination IP address used in the lookup. In the above example,
10.4.16.0/24 may be chosen over 10.4.16.0/16 because the range is narrower with 10.4.16.0/24 for
an IP address they both contain.
RLB Resets
There are two occasions when all RLB algorithms will reset to their initial state:
•
After cOS Core reconfiguration.
•
After a high availability failover.
In both these cases, the chosen route will revert to the one selected when the algorithms began
operation.
RLB Limitations
It should be noted that the selection of different alternate routes occurs only when the route
lookup is done and it is based on the algorithm being used with the routing table used for the
lookup and the algorithm's state.
RLB cannot know how much data traffic will be related to each lookup. The purpose of RLB is to
be able to spread route lookups across alternatives on the assumption that each lookup will
relate to a connection carrying some assumed amount of traffic.
An RLB Scenario
Below is an illustration which shows a typical scenario where RLB might be used. Here, there is a
group of clients on a network connected via the LAN interface of the Clavister Security Gateway
and these will access the internet.
262
Chapter 4: Routing
Internet access is available from either one of two ISPs, whose gateways GW1 GW2 are connected
to the security gateway interfaces WAN1 and WAN2. RLB will be used to balance the
connections between the two ISPs.
Figure 4.7. A Route Load Balancing Scenario
We first need to define two routes to these two ISPs in the main routing table as shown below:
Route No.
Interface
Destination
Gateway
Metric
1
WAN1
all-nets
GW1
100
2
WAN2
all-nets
GW2
100
We will not use the spillover algorithm in this example so the routing metric for both routes
should be the same, in this case a value of 100 is selected.
By using the Destination RLB algorithm we can ensure that clients communicate with a particular
server using the same route and therefore the same source IP address. If NAT was being used for
the client communication, the IP address seen by the server would be WAN1 or WAN2.
In order to flow, any traffic requires both a route and an allowing IP rule. The following rules will
allow traffic to flow to either ISP and will NAT the traffic using the external IP addresses of
interfaces WAN1 and WAN2.
Rule No.
Action
Src Interface
Src Network
Dest Interace
Dest Network
Service
1
NAT
lan
lan_net
WAN1
all-nets
all_services
1
NAT
lan
lan_net
WAN2
all-nets
all_services
The service All is used in the above IP rules but this should be further refined to a service or
service group that covers all the traffic that will be allowed to flow.
263
Chapter 4: Routing
Example 4.8. Setting Up RLB
In this example, the details of the RLB scenario described above will be implemented. The
assumption is made that the various IP address book objects needed have already been defined.
The IP objects WAN1 and WAN2 represent the interfaces that connect to the two ISPs and the IP
objects GW1 and GW2 represent the IP addresses of the gateway routers at the two ISPs.
Step 1. Set up the routes in the main routing table
CLI
First, change the category context to be the main routing table:
Device:/> cc RoutingTable main
Add the route to the first ISP:
Device:/main> add Route
Interface=WAN1
Network=all-nets
Gateway=GW1
Metric=100
Add the route to the second ISP:
Device:/main> add Route
Interface=WAN2
Network=all-nets
Gateway=GW2
Metric=100
Return to the original context:
Device:/main> cc
Device:/>
Web Interface
1.
Go to: Network > Routing > Routing Tables
2.
Select the main routing table
3.
Select Add > Route
4.
The dialog for a new route will appear. For the first route, enter:
•
Interface: WAN1
•
Network: all-nets
•
Gateway: GW1
•
Local IP address: Leave as None
•
Metric: 100
264
Chapter 4: Routing
•
Click OK
5.
Select Add > Route again to add the second route
6.
The dialog for a new route will appear. For the second route, enter:
•
Interface: WAN2
•
Network: all-nets
•
Gateway: GW2
•
Local IP address: Leave as None
•
Metric: 100
•
Click OK
Step 2. Create an RLB Instance object
A Route Load Balancing Instance object is now created which uses the Destination algorithm will
be selected to achieve stickiness so the server always sees the same source IP address (WAN1 or
WAN2) from a single client.
Command-Line Interface
Device:/> add RouteBalancingInstance main Algorithm=Destination
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Network > Routing > Instances > Add > Route Balancing Instance
2.
The route balancing instance dialog will appear. Now select:
•
Routing Table: main
•
Algorithm: Destination
•
Click OK
Step 3. Create IP rules to allow traffic to flow
Finally, IP rules needed to be added to an IP rule set to allow traffic to flow. The detailed steps for
this are not included here but the created rules would follow the pattern described above.
RLB with VPN
When using RLB with VPN, a number of issues need to be overcome.
If we were to try and use RLB to balance traffic between two IPsec tunnels, the problem that
arises is that the Remote Endpoint for any two IPsec tunnels in cOS Core must be different. The
solutions to this issue are as follows:
265
Chapter 4: Routing
•
Use two ISPs, with one tunnel connecting through one ISP and the other tunnel connecting
through the other ISP. RLB can then be applied as normal with the two tunnels.
In order to get the second tunnel to function in this case, it is necessary to add a single host
route in the main routing table that points to the secondary ISPs interface and with the
secondary ISPs gateway.
This solution has the advantage of providing redundancy should one ISP link fail.
•
Use VPN with one tunnel that is IPsec based and another tunnel that is uses a different
protocol.
If both tunnels must be, for example, IPsec connects, it is possible to wrap IPsec in a GRE
tunnel (in other words, the IPsec tunnel is carried by a GRE tunnel). GRE is a simple tunneling
protocol without encryption and therefore involves a minimum of extra overhead. See
Section 3.4.5, “GRE Tunnels” for more about this topic.
266
Chapter 4: Routing
4.5. Virtual Routing
4.5.1. Overview
Virtual Routing is a cOS Core feature that allows the creation of multiple, logically separated
virtual systems within cOS Core, each with its own routing table. These systems can behave as
physically separated Clavister Security Gateways and almost everything that can be done with
separate gateways can be done with them, including dynamic routing with OSPF. Virtual systems
are sometimes also referred to as Virtual Routers.
The cOS Core components involved in creating virtual routing are:
•
Separate routing tables for each virtual system.
•
Per-interface policy-based routing table membership to make interface IP addresses
reachable only via a particular routing table. This association can be made explicitly by
linking an interface with a specific routing table.
•
Pairs of loopback interfaces can be used for communication between virtual systems if
required.
There are two ways of associating a specific routing table with a specific interface:
•
Using Routing Rules
Routing Rules can be defined so that all traffic on a particular interface are subject to a
particular routing table.
•
Specifying a Routing Table for an Interface
It is possible to associate an interface directly with a specific routing table. This is known as
the interface's routing table membership. This option is part an interface's virtual routing
options.
This is the preferred way of implementing a virtual router. The interface might be physical or
it could be a virtual LAN (VLAN).
To ensure that a routing table does not use any other tables in the route lookup process, the
Ordering parameter of the table should be set to Only.
4.5.2. A Simple Scenario
Consider a single Clavister Security Gateway connected to two external ISPs, ISP1 and ISP2.
267
Chapter 4: Routing
ISP1 provides Internet connection to Department A and connects to the Clavister Security
Gateway via the physical interface if1.
ISP2 provides Internet connection to Department B and connects via the physical interface if2. For
administration purposes it is decided that the Clavister Security Gateway is to be divided into 2
virtual systems, one for each ISP.
This is done by creating two dedicated routing tables, PBR1 to deal with ISP1 and Department A
traffic and another, PBR2, to deal with ISP2 and Department B traffic.
Interface if1 is a member of the first routing table but not the second (in other words that routing
table has been explicitly associated with the interface). Interface if2 is a member of the second
table but not the first. It is this interface membership which determines which routing table is
used and which keeps the two sets of traffic totally separated.
Tip: The main routing table could be used
In this example, the main routing table could have been used. However, it is often better
to create new, dedicated routing tables for this purpose.
Reusing Internal IP Addresses
An advantage of using separate routing tables on different interfaces is that internal IP address
ranges can be re-used on different virtual systems. For example, Department A and Department B
could both use the internal network 192.168.0.0/24.
Since route lookup is done in completely separate routing tables, there are no conflicts.
VPN Tunnels are Interfaces
VPN tunnels are also considered to be interfaces in cOS Core and can therefore also be
268
Chapter 4: Routing
associated with their own routing tables just as physical interfaces can.
This means that tunnels can be logically totally separate from each other within cOS Core.
Using Loopback Interfaces
In this simple example, loopback interfaces were not used since there is no requirement for
communication between the virtual systems. For example, Department A does not need to
communicate with Department B. If communication between them is needed then an
appropriate loopback interface pair would have to be defined to allow this.
After we define a loopback interface, all traffic sent to that interface automatically appears as
being received on another interface.
4.5.3. Advantages Over Routing Rules
Using Routing Rules can solve many of the problems that virtual routing can but complex
configurations can become unwieldy for such rules. Consider a single Clavister Security Gateway
being used as a firewall for two organizations, both using the same IP span.
In this case, two separate routing tables could be used, one for each organization as shown
below.
We first would define two routing tables for this scenario, pbrtable1 and pbrtable2.
Routing Table pbrtable1
Route #
Interface
Network
Gateway
1
ext
all-nets
defaultgw
2
int1
192.168.0.0/24
Routing Table pbrtable2
269
Chapter 4: Routing
Route #
Interface
Network
Gateway
1
ext
all-nets
defaultgw
2
int2
192.168.0.0/24
Getting traffic from each network to and from the Internet is straightforward. Assuming only
outbound traffic, it takes two Routing Rules. Assuming that each organization has a public IPv4
address which maps to servers on the respective networks, outbound as well as inbound traffic is
handled with four rules:
Route #
Name
Source If
Source Net
Dest Net
Fwd Table
Ret Table
1
org1-in
ext
all-nets
pubip-org1
pbrtable1
pbrtable1
2
org1-out
int1
all-nets
all-nets
pbrtable1
pbrtable1
3
org2-in
ext
all-nets
pubip-org2
pbrtable2
pbrtable2
4
org2-out
int2
all-nets
all-nets
pbrtable2
pbrtable2
This works if the two organizations do not attempt to communicate with each other. If this
happens the following two routing rules are also needed, before the other four.
Route #
Name
Source if
Source Net
Dest Net
Fwd Table
Ret Table
1
org1-org2
int1
all-nets
pubip-org2
pbrtable1
pbrtable2
2
org2-org1
int2
all-nets
pubip-org1
pbrtable2
pbrtable1
With two organizations, two routing rules are enough for them to communicate. However, with
three organizations, six are needed; with four, twelve are needed; with five, twenty are needed.
The numbers continue: 30, 42, 56... and the administration task becomes unmanageable.
Virtual Routing can eliminate the all-to-all mappings described in the previous section. Using
interface routing table membership instead of routing rules reduces the complexity by creating 3
virtual systems as shown above.
Each organization gets a virtual system of its own and both of these connect to "main", using
pairs of loopback interfaces. First, we examine the routing tables:
270
Chapter 4: Routing
Routing Table main
Route #
Interface
Network
Gateway
1
main-ext
all-nets
defaultgw
2
main-vs1
pubip-vs1
3
main-vs2
pubip-vs2
Route #
Interface
Network
1
vs1-main
all-nets
2
vs1-int
192.168.0.0/24
Route #
Interface
Network
1
vs2-main
all-nets
2
vs2-int
192.168.0.0/24
Interface #
Name
IP Address
Routing Table
1
main-ext
ip_main-ext
main
2
vs1-int
192.168.0.1
vs1
3
vs2-int
192.168.0.254
vs2
Routing Table vs1
Gateway
Roouting Table vs2
Gateway
Ethernet Interfaces
Loopback Interfaces
#
Name
IP Address
Loop to
Routing Table
1
main-vs1
ip_main-ext
vs1-main
main
2
vs1-main
pubip-vs1
main-vs1
vs1
3
main-vs2
ip_main-ext
vs2-main
main
4
vs2-main
pubip-vs2
main-vs2
vs2
For each connection between a pair of virtual systems, a pair of loopback interfaces is required,
one for each system. In this example, when traffic is sent through main-vs1, it arrives on vs1-main.
When traffic is sent through vs1-main, it is received on main-vs1. This is exactly the same as with
two Clavister Security Gateways and two interfaces, one on each, with a connection between
them.
The Routing Table Membership setting means that if a connection arrives on an interface, it will be
routed according to the routing table that the interface is a member of.
Also note how the IPv4 addresses of the internal interfaces of the virtual systems differ. If
271
Chapter 4: Routing
per-interface routing table membership were not used, "core" routes for both IP addresses would
be added in both routing tables, leading to 192.168.0.1 being unusable in vs2 (even though it
should not be) and 192.168.0.254 being unusable in vs1. With per-interface routing table
membership, interface IP addresses belonging to one virtual system will not interfere with other
virtual systems and loopback interfaces are not needed.
The IPv4 addresses of the main-vs1 and main-vs2 interfaces are the same as the IP address of the
external interface. They could also have been set to something nonsensical, such as 127.0.0.1.
Regular routing would still have worked since loopback interfaces are raw IP interfaces (the ARP
protocol is not used over them). However, their IP addresses will be visible to users doing a
traceroute from the inside, and also the issue exists of traffic originating from the Clavister
Security Gateway itself to the internal networks, such as pings or logging. Such traffic is most
often routed according to the main routing table, and will be sourced from the IP address of the
nearest interface in the main routing table.
4.5.4. IP Rules with Virtual Routing
The IP rule sets for different virtual systems can be split into separate rule sets using the cOS Core
feature of creating multiple IP rule sets (see Section 3.6.4, “Multiple IP Rule Sets” for more detail on
this feature).
IP Rules for different virtual systems need not be split up. The rules can reside together in a single
IP rule set. The benefit of doing this is being able to define "shared" or "global" rules that span
over several virtual systems. For example, for aggressive "worm" attacks, it may be desirable to
drop all communication on ports known to be used by the worm until counter-measures can be
put into place. One single Drop rule placed at the top of the rule set can take care of this for all
the virtual systems. Using the example of the previous section, this is how the IP rule set might
look:
Interface Groups
#
Name
Interfaces
1
main-vsifs
main-vs1, main-vs2
2
main-ifs
main-ext, main-vsifs
3
vs1-ifs
vs1-main, vs1-int
4
vs2-ifs
vs2-main, vs2-int
IP Rules
#
Name
Action
Source If
Source Net
Dest If
Dest Net
Service
main-ifs
all-nets
Any
all-nets
all_services
IP Rules for the "main" virtual system
1
main-allowall
Allow
IP Rules for the "vs1" virtual system
2
vs1-http-in
SAT
vs1-ifs
all-nets
pubip-vs1
all-nets
http SetDest
192.168.0.5
3
vs1-http-in
Allow
vs1-main
all-nets
Any
pubip-vs1
http
4
vs1-out
NAT
vs1-int
all-nets
Any
all-nets
all_services
IP Rules for the "vs2" virtual system
5
vs2-smtp-in
SAT
vs2-main
all-nets
Any
pubip-vs2
all_services
6
vs2-smtp-in
Allow
vs2-main
all-nets
Any
pubip-vs2
smtp
7
vs2-http-out
NAT
vs2-int
192.168.0.4
vs2-main
all-nets
http
272
Chapter 4: Routing
Note that SAT rules do not need to take into account that there are more organizations
connected to the same physical unit. There is no direct connection between them; everything
arrives through the same interface, connected to the main routing table. If this was done without
virtual routing, the Allow rules would have to be preceded by NAT rules for traffic from other
organizations. Care would also have to be taken that such rules were in accordance with the
security policy of each organization. Such problems are eliminated with virtual routing.
The source interface filters are very specific. Any is not used as the source interface anywhere,
since such a rule would trigger regardless. Consider for instance what would happen if the
vs1-http-in rules were to use Any as source interface. They would trigger as soon as packets
destined to pubip-vs1 were received on main-ext. The destination address would be rewritten to
192.168.0.5, and passed on using the main routing table. The main routing table would not know
what to do with 192.168.0.5 and pass it back out to the default gateway outside the Clavister
Security Gateway.
If the same naming scheme as shown in this example is used, making sure the source interfaces
are correct can be done quickly. All the rules concerning the main system have source interfaces
beginning with "main-". All those concerning vs1 have source interfaces beginning with "vs1-",
and so on.
The destination interface filters, however, do not need to be as specific as the source interface
filters. The possible destinations are limited by the routing tables used. If the vs1 table only
includes routes through vs1- interfaces, Any filters can only mean "through other interfaces in the
same virtual system". It may however be sound practice to write tighter destination interface
filters in case an error occurs elsewhere in the configuration. In this example, rule 1 might use
main-ifs, rule 4 might use vs1-main. The SAT and corresponding Allow rules however are already
fairly tight in that they only concern one single destination IP address.
4.5.5. Multiple IP rule sets
An alternative approach to having all the IP rules for different virtual systems in one rule set is to
make use of Multiple IP rule sets.
Although all scanning of IP rules begins in the main rule set, it is possible to define a rule in main
whose action is Goto so that scanning continues in a separate, named rule set. These extra rule
sets can be defined as needed and one rule set can be created for each virtual system and its
corresponding routing table.
More details on this subject can be found in Section 3.6.4, “Multiple IP Rule Sets”.
4.5.6. Trouble Shooting
•
Make sure that the source interface filters are correct
•
Double check interface PBR table membership. For all types of interfaces and tunnels
•
Use "ping -p <pbrtable>" to source pings from different virtual systems
•
Use "ping -r <recvif> -s <srcip>" to test the rule set, simulating that the ping was received on
a given interface from a given IP address
•
Use "arpsnoop -v <ifacenames>" to get verbose information about ARP resolution
•
Use "route <pbrtable> -all" to view all route entries in a given table, including "core" routes
•
Use "route -lookup <ipaddr> <pbrtable>" to make sure that a given IP address is routed the
way expected in a given virtual system. (Hint: "-lookup" may be shortened to "-l".)
•
Use "conn -v" to view verbose information about open connections. Both ends of a
273
Chapter 4: Routing
connection will be shown; before and after address translation. Also, the routing tables used
in the forward and return direction will be shown.
•
Enable logging and read the logs. In each virtual system, a separate rule decision is made,
and a separate connection is established
274
Chapter 4: Routing
4.6. OSPF
The feature called Dynamic Routing is implemented in cOS Core using the Open Shortest Path First
(OSPF) architecture.
This section begins by looking generally at what dynamic routing is and how it can be
implemented. It then goes on to look at how OSPF can provide dynamic routing followed by a
description of how a simple OSPF network can be set up.
4.6.1. Dynamic Routing
Before looking at OSPF in detail this section will discuss generally the concept of Dynamic routing
and what type of dynamic routing OSPF provides. It introduces important concepts in dynamic
routing and in OSPF.
Differences to Static Routing
Dynamic routing is different to static routing in that a routing network device, such as a Clavister
Security Gateway, can adapt to changes of network topology automatically.
Dynamic routing involves first learning about all the directly connected networks and then
getting further routing information from other connected routers specifying which networks
they are connected to. All this routing information is then processed and the most suitable
routes for both locally connected and remotely connected destinations are added into local
routing tables.
Dynamic routing responds to routing updates dynamically but has some disadvantages in that it
can be more susceptible to certain problems such as routing loops. One of two types of
algorithms are generally used to implement the dynamic routing mechanism:
•
A Distance Vector (DV) algorithm.
•
A Link State (LS) algorithm.
How a router decides the optimal or "best" route and shares updated information with other
routers depends on the type of algorithm used. The two algorithm types will be discussed next.
Distance Vector Algorithms
A Distance vector algorithm is a decentralized routing algorithm that computes the best path in a
distributed way.
Each router in a network computes the "costs" of its own attached links, and shares routing
information only with its neighboring routers. Each router determines the least-cost path to a
destination by iterative computation and also using information exchanged with its neighbors.
Routing Information Protocol (RIP) is a well-known DV algorithm for router information exchange
and operates by sending regular update messages and reflecting routing changes in routing
tables. Path determination is based on the "length" of the path which is the number of
intermediate routers (also known as "hops") to the destination.
After updating its own routing table, the router immediately begins transmitting its entire
routing table to neighboring routers to inform them of changes.
Link State Algorithms
275
Chapter 4: Routing
In contrast to DV algorithms, Link State (LS) algorithms enable routers to keep routing tables that
reflect the topology of the entire network.
Each router broadcasts its attached links and link costs to all other routers in the network. When
a router receives these broadcasts it runs the LS algorithm and calculates its own set of least-cost
paths. Any change of the link state will be sent everywhere in the network, so that all routers
keep the same routing table information and have a consistent view of the network.
Advantages of Link State Algorithms
Due to the fact that the global link state information is maintained everywhere in a network, LS
algorithms, like that used in OSPF, offer a high degree of configuration control and scalability.
Changes result in broadcasts of just the updated information to other routers which means faster
convergence and less possibility of routing loops. OSPF can also function within a hierarchy,
whereas RIP has no knowledge of sub-network addressing.
The OSPF Solution
Open Shortest Path First (OSPF) is a widely used protocol based on an LS algorithm. Dynamic
routing is implemented in cOS Core using OSPF.
An OSPF enabled router first identifies the routers and sub-networks that are directly connected
to it and then broadcasts the information to all the other routers. Each router uses the
information it receives to add the OSPF learned routes to its routing table.
With this larger picture, each OSPF router can identify the networks and routers that lead to a
given destination IP and therefore the best route. Routers using OSPF then only broadcast
updates to inform others of any route changes instead of broadcasting the entire routing table.
OSPF depends on various metrics for path determination, including hops, bandwidth, load and
delay. OSPF can also provide a high level of control over the routing process since its parameters
can be finely tuned.
A Simple OSPF Scenario
The simple network topology illustrated below provides an excellent example of what OSPF can
achieve. Here we have two Clavister Security Gateways A and B connected together and
configured to be in the same OSPF area (the concept of area will be explained later).
Figure 4.8. A Simple OSPF Scenario
OSPF allows security gateway A to know that to reach network Y, traffic needs to be sent to
security gateway B. Instead of having to manually insert this routing information into the routing
tables of A, OSPF allows B's routing table information to be automatically shared with A.
In the same way, OSPF allows security gateway B to automatically become aware that network X
is attached to security gateway A.
276
Chapter 4: Routing
Under OSPF, this exchange of routing information is completely automatic.
OSPF Provides Route Redundancy
If we now take the above scenario and add a third Clavister Security Gateway called C then we
have a situation where all three security gateways are aware, through OSPF, of what networks
are attached to the other gateways. This is illustrated below.
Figure 4.9. OSPF Providing Route Redundancy
In addition, we now have route redundancy between any two of the security gateways. For
example, if the direct link between A and C fails then OSPF allows both security gateways to
know immediately that there is an alternate route between them via gateway B.
For instance, traffic from network X which is destined for network Z will be routed automatically
through security gateway B.
From the administrator's point of view, only the routes for directly connected networks need to
be configured on each security gateway. OSPF automatically provides the required routing
information to find networks connected to other security gateways, even if traffic needs to
transit several other gateways to reach its destination.
Tip: Ring topologies always provide alternate routes
When designing the topology of a network that implements OSPF, arranging Clavister
Security Gateways in a circular ring means that any security gateway always has two
possible routes to any other. Should any one inter-gateway connection fail, an
alternative path always exists.
A Look at Routing Metrics
In discussing dynamic routing and OSPF further, an understanding of Routing Metrics can be
useful and a brief explanation is given here.
Routing metrics are the criteria that a routing algorithm will use to compute the "best" route to a
destination. A routing protocol relies on one or several metrics to evaluate links across a network
277
Chapter 4: Routing
and to determine the optimal path. The principal metrics used include:
Path length
The sum of the costs associated with each link. A commonly used value for
this metric is called "hop count" which is the number of routing devices a
packet must pass through when it travels from source to destination.
Item Bandwidth
The traffic capacity of a path, rated by "Mbps".
Load
The usage of a router. The usage can be evaluated by CPU utilization and
throughput.
Delay
The time it takes to move a packet from the source to the destination. The
time depends on various factors, including bandwidth, load, and the
length of the path.
4.6.2. OSPF Concepts
Overview
Open Shortest Path First (OSPF) is a routing protocol developed for IP networks by the Internet
Engineering Task Force (IETF). The cOS Core OSPF implementation is based upon RFC 2328, with
compatibility to RFC 1583.
OSPF functions by routing IP packets based only on the destination IP address found in the IP
packet header. IP packets are routed "as is", in other words they are not encapsulated in any
further protocol headers as they transit the Autonomous System (AS).
The Autonomous System
The term Autonomous System refers to a single network or group of networks with a single,
clearly defined routing policy controlled by a common administrator. It forms the top level of a
tree structure which describes the various OSPF components.
In cOS Core, an AS corresponds to an OSPF Router object. This must be defined first when setting
up OSPF. In most scenarios only one OSPF router is required to be defined and it must be defined
separately on each Clavister Security Gateway involved in the OSPF network. This cOS Core
object is described further in Section 4.6.3.1, “OSPF Router Process”.
OSPF is a dynamic routing protocol as it quickly detects topological changes in the AS (such as
router interface failures) and calculates new loop-free routes to destinations.
Link-state Routing
OSPF is a form of link-state routing (LS) that sends Link-state Advertisements (LSAs) to all other
routers within the same area. Each router maintains a database, known as a Link-state Database,
which maps the topology of the autonomous system (AS). Using this database, each router
constructs a tree of shortest paths to other routers with itself as the root. This shortest-path tree
yields the best route to each destination in the AS.
Authentication.
All OSPF protocol exchanges can, if required, be authenticated. This means that only routers with
the correct authentication can join an AS. Different authentication schemes can be used and
with cOS Core the scheme can be either a passphrase or an MD5 digest.
278
Chapter 4: Routing
It is possible to configure separate authentication methods for each AS.
OSPF Areas
An OSPF Area consists of networks and hosts within an AS that have been grouped together.
Routers that are only within an area are called internal routers. All interfaces on internal routers
are directly connected to networks within the area.
The topology of an area is hidden from the rest of the AS. This information hiding reduces the
amount of routing traffic exchanged. Also, routing within the area is determined only by the
area's own topology, lending the area protection from bad routing data. An area is a
generalization of an IP sub netted network.
In cOS Core, areas are defined by OSPF Area objects and are added to the AS which is itself
defined by an OSPF Router object. There can be more than one area within an AS so multiple
OSPF Area objects could be added to a single OSPF Router. In most cases, one is enough and it
should be defined separately on each Clavister Security Gateway which will be part of the OSPF
network.
This cOS Core object is described further in Section 4.6.3.2, “OSPF Area”.
OSPF Area Components
A summary of OSPF components related to an area is given below:
ABRs
Area Border Routers are routers that have interfaces connected to more
than one area. These maintain a separate topological database for each
area to which they have an interface.
ASBRs
Routers that exchange routing information with routers in other
Autonomous Systems are called Autonomous System Boundary Routers.
They advertise externally learned routes throughout the Autonomous
System.
Backbone Areas
All OSPF networks need to have at least the Backbone Area which is the
OSPF area with an ID of 0. This is the area that other related areas should
be connected to. The backbone ensures routing information is distributed
between connected areas. When an area is not directly connected to the
backbone it needs a virtual link to it.
OSPF networks should be designed by beginning with the backbone.
Stub Areas
Stub areas are areas through which or into which AS external
advertisements are not flooded. When an area is configured as a stub area,
the router will automatically advertise a default route so that routers in
the stub area can reach destinations outside the area.
Transit Areas
Transit areas are used to pass traffic from an area that is not directly
connected to the backbone area.
The Designated Router
Each OSPF broadcast network has a single Designated Router (DR) and a single Backup Designated
Router. The routers use OSPF Hello messages to elect the DR and BDR for the network based on
the priorities advertised by all the routers. If there is already a DR on the network, the router will
accept that one, regardless of its own router priority.
279
Chapter 4: Routing
With cOS Core, the DR and the BDR are automatically assigned.
Neighbors
Routers that are in the same area become neighbors in that area. Neighbors are elected by the
use of Hello messages. These are sent out periodically on each interface using IP multicast.
Routers become neighbors as soon as they see themselves listed in a neighbor's Hello message.
In this way, a two way communication is guaranteed.
The following Neighbor States are defined:
Down
This is the initial state of the neighbor relationship.
Init
When a Hello message is received from a neighbor, but does NOT include the
Router ID of the security gateway in it, the neighbor will be placed in the Init state.
As soon as the neighbor in question receives a Hello message it will know the
sending router's Router ID and will send a Hello message with that included. The
state of the neighbors will change to the 2-way state.
2-Way
In this state the communication between the router and the neighbor is
bi-directional.
On Point-to-Point and Point-to-Multipoint OSPF interfaces, the state will be changed
to Full. On Broadcast interfaces, only the DR/BDR will advance to the Full state with
their neighbors, all the remaining neighbors will remain in the 2-Way state.
ExStart
Preparing to build adjacency.
Exchange
Routers are exchanging Data Descriptors.
Loading
Routers are exchanging LSAs.
Full
This is the normal state of an adjacency between a router and the DR/BDR.
Aggregates
OSPF Aggregation is used to combine groups of routes with common addresses into a single
entry in the routing table. This is commonly used to minimize the routing table.
To set this feature up in cOS Core, see Section 4.6.3.5, “OSPF Aggregates”.
Virtual Links
Virtual links are used for the following scenarios:
A. Linking an area that does not have a direct connection to the backbone area.
B. Linking backbone areas when the backbone is partitioned.
The two uses are discussed next.
A. Linking areas without direct connection to the backbone
The backbone area always needs to be the center of all other areas. In some rare cases where it is
impossible to have an area physically connected to the backbone, a Virtual Link is used. Virtual
links can provide an area with a logical path to the backbone area.
280
Chapter 4: Routing
This virtual link is established between two Area Border Routers (ABRs) that are on one common
area, with one of the ABRs connected to the backbone area. In the example below two routers
are connected to the same area (Area 1) but just one of them, fw1, is connected physically to the
backbone area.
Figure 4.10. Virtual Links Connecting Areas
In the above example, a Virtual Link is configured between fw1 and fw2 on Area 1 as it is used as
the transit area. In this configuration only the Router ID has to be configured. The diagram shows
that fw2 needs to have a Virtual Link to fw1 with Router ID 192.168.1.1 and vice versa. These
virtual links need to be configured in Area 1.
B. Linking a Partitioned Backbone
OSPF allows for linking a partitioned backbone using a virtual link. The virtual link should be
configured between two separate ABRs that touch the backbone from each side and have a
common area in between.
281
Chapter 4: Routing
Figure 4.11. Virtual Links with Partitioned Backbone
The virtual link is configured between fw1 and fw2 on Area 1 as it is used as the transit area. In the
configuration, only the Router ID has to be configured, as in the example above show fw2 need to
have a virtual link to fw1 with the Router ID 192.168.1.1 and vice versa. These virtual links need to
be configured in Area 1.
To set this feature up in cOS Core, see Section 4.6.3.6, “OSPF VLinks”.
OSPF High Availability Support
There are some limitations in High Availability support for OSPF that should be noted:
Both the active and the inactive part of an HA cluster will run separate OSPF processes, although
the inactive part will make sure that it is not the preferred choice for routing. The HA master and
slave will not form adjacency with each other and are not allowed to become DR/BDR on
broadcast networks. This is done by forcing the router priority to 0.
For OSPF HA support to work correctly, the Clavister Security Gateway needs to have a broadcast
interface with at least ONE neighbor for ALL areas that the security gateway is attached to. In
essence, the inactive part of the cluster needs a neighbor to get the link state database from.
It should also be noted that is not possible to put an HA cluster on the same broadcast network
without any other neighbors (they will not form adjacency with each other because of the router
priority 0). However, it may be possible, depending on the scenario, to setup a point to point link
between them instead. Special care must also be taken when setting up a virtual link to an
security gateway in an HA cluster. The endpoint setting up a link to the HA security gateway
must setup 3 separate links: one to the shared, one to the master and one to the slave router id
of the security gateway.
Using OSPF with cOS Core
When using OSPF with cOS Core, the scenario will be that we have two or more Clavister Security
Gateways connected together in some way. OSPF allows any of these security gateway to be able
to correctly route traffic to a destination network connected to another security gateway without
282
Chapter 4: Routing
having a route in its routing tables for the destination.
The key aspect of an OSPF setup is that connected Clavister Security Gateways share the
information in their routing tables so that traffic entering an interface on one of the security
gateways can be automatically routed so that it exits the interface on another gateway which is
attached to the correct destination network.
Another important aspect is that the security gateways monitor the connections between each
other and route traffic by an alternate connection if one is available. A network topology can
therefore be designed to be fault tolerant. If a connection between two security gateways fails
then any alternate route that also reaches the destination will be used.
4.6.3. OSPF Components
This section looks at the cOS Core objects that need to be configured for OSPF routing. Defining
these objects creates the OSPF network. The objects should be defined on each Clavister Security
Gateway that is part of the OSPF network and should describe the same network.
An illustration of the relationship between cOS Core OSPF objects is shown below.
Figure 4.12. cOS Core OSPF Objects
4.6.3.1. OSPF Router Process
This object defines the autonomous system (AS) which is the top level of the OSPF network. A
similar Router Process object should be defined on each Clavister Security Gateway which is part
of the OSPF network.
General Parameters
Name
Specifies a symbolic name for the OSPF AS.
Router ID
Specifies the IP address that is used to identify the router in a
AS. If no Router ID is configured, the security gateway
computes the Router ID based on the highest IP address of any
283
Chapter 4: Routing
interface participating in the OSPF AS.
Private Router ID
This is used in an HA cluster and is the ID for this security
gateway and not the cluster.
Note
When running OSPF on a HA Cluster there is a need
for a private master and private slave Router ID as
well as the shared Router ID.
Reference Bandwidth
Set the reference bandwidth that is used when calculating the
default interface cost for routes.
If bandwidth is used instead of specifying a metric on an OSPF
Interface, the cost is calculated using the following formula:
cost = reference bandwidth / bandwidth
RFC 1583 Compatibility
Enable this if the Clavister Security Gateway will be used in a
environment that consists of routers that only support RFC
1583.
Debug
The debug options provides a troubleshooting tool by enabling the generation of additional
OSPF log events. These are described more fully in Section 4.6.7, “OSPF Troubleshooting”.
Authentication
The primary purpose of OSPF authentication is to make sure that the correct OSPF router
processes are talking to each and it is therefore mostly used when there are multiple OSPF AS'.
OSPF supports the following authentication options:
No (null) authentication
No authentication is used for OSPF protocol exchanges.
Passphrase
A simple password is used to authenticate all the OSPF
protocol exchanges.
MD5 Digest
MD5 authentication consists of a key ID and 128-bit key.
When MD5 digest is used the specified key is used to
produce the 128-bit MD5 digest.
This does NOT mean that the OSPF packets are encrypted.
If the OSPF traffic needs to be encrypted then they must be
sent using a VPN. For example, using IPsec. Sending OSPF
packets through an IPsec tunnel is discussed further in
Section 4.6.5, “Setting Up OSPF”.
Note: Authentication must be the same on all routers
If a passphrase or MD5 authentication is configured for OSPF, the passphrase or
authentication key must be the same on all OSPF Routers in that Autonomous System.
284
Chapter 4: Routing
In other words, the OSPF authentication method must be replicated on all Clavister
Security Gateways.
Advanced
Time Settings
SPF Hold Time
Specifies the minimum time, in seconds, between two SPF calculations.
The default time is 10 seconds. A value of 0 means that there is no
delay. Note however that SPF can potentially be a CPU demanding
process, so in a big network it might not be a good idea to run it to
often.
SPF Delay Time
Specifies the delay time, in seconds, between when OSPF receives a
topology change and when it starts a SPF calculation. The default time
is 5 seconds. A value of 0 means that there is no delay. Note however
that SPF can potentially be a CPU demanding process, so in a big
network it might not be a good idea to run it to often.
LSA Group Pacing
This specifies the time in seconds at which interval the OSPF LSAs are
collected into a group and refreshed. It is more optimal to group many
LSAs and process them at the same time, instead of running them one
and one.
Routes Hold Time
This specifies the time in seconds that the routing table will be kept
unchanged after a reconfiguration of OSPF entries or a HA failover.
Memory Settings
Memory Max Usage
Maximum amount in Kilobytes of RAM that the OSPF AS process are
allowed to use, if no value is specified the default is 1% of installed
RAM. Specifying 0 indicates that the OSPF AS process is allowed to use
all available ram in the security gateway.
4.6.3.2. OSPF Area
The Autonomous System (AS) is divided into smaller parts called an Area, this section explains
how to configure areas. An area collects together OSPF interfaces, neighbors, aggregates and
virtual links.
An OSPF Area is a child of the OSPF Router Process and there can be many area objects defined
under a single router process. In most simple networking scenarios, a single area is sufficient. Like
the router process object, a similar area object should be defined on all the Clavister Security
Gateways which will be part of the OSPF network.
General Parameters
Name
Specifies the name of the OSPF Area.
ID
Specifies the area id. If 0.0.0.0 is specified then this is the
backbone area.
285
Chapter 4: Routing
There can only be one backbone area and it forms the central
portion of an AS. Routing information that is exchanged
between different area always transits the backbone area.
Is stub area
Enable this option if the area is a stub area.
Become Default Router
It is possible to configure if the security gateway should become
the default router for the stub area, and with what metric.
Import Filter
The import filter is used to filter what can be imported in the OSPF AS from either external
sources (like the main routing table or a policy based routing table) or inside the OSPF area.
External
Specifies the network addresses allowed to be imported into this OSPF area from
external routing sources.
Interarea
Specifies the network addresses allowed to be imported from other routers inside
the OSPF area.
4.6.3.3. OSPF Interface
This section describes how to configure an OSPF Interface object. OSPF interface objects are
children of OSPF areas. Unlike areas, they are not similar on each Clavister Security Gateway in
the OSPF network. The purpose of an OSPF interface object is to describe a specific interface
which will be part of an OSPF network.
Note: Different interface types can be used with OSPF interfaces
Note that an OSPF Interface does not always correspond to a physical interface
although this is the most common usage. Other types of interfaces, such as a VLAN,
could instead be associated with an OSPF Interface.
General Parameters
Interface
Specifies which interface on the security gateway will be used for this
OSPF interface.
Network
Specifies the IPv4 network address for this OSPF interface. If is not
specified it defaults to the network assigned to the underlying cOS Core
interface.
This network is automatically exported to the OSPF AS and does not
require a Dynamic Routing Rule.
Interface Type
This can be one of the following:
•
Auto - Tries to automatically detect interface type. This can be used for
physical interfaces.
•
Broadcast - The Broadcast interface type is an interface that has native
Layer 2 broadcast/multicast capabilities. The typical example of a
broadcast/multicast network is an ordinary physical Ethernet interface.
When broadcast is used, OSPF will send OSPF Hello packets to the IP
286
Chapter 4: Routing
multicast address 224.0.0.5. Those packets will be heard by all other
the OSPF routers on the network. For this reason, no configuration of
OSPF Neighbor objects is required for the discovery of neighboring
routers.
•
Point-to-Point - Point-to-Point is used for direct links which involve
only two routers (in other words, two security gateways). A typical
example of this is a VPN tunnel which is used to transfer OSPF traffic
between two security gateways. The neighbor address of such a link is
configured by defining an OSPF Neighbour object.
Using VPN tunnels is discussed further in Section 4.6.5, “Setting Up
OSPF”.
•
Point-to-Multipoint - The Point-to-Multipoint interface type is a
collection of Point-to-Point networks, where there is more then one
router in a link that does not have OSI Layer 2 broadcast/multicast
capabilities.
Metric
Specifies the metric for this OSPF interface. This represents the "cost" of
sending packets over this interface. This cost is inversely proportional to
the bandwidth of the interface.
Bandwidth
If the metric is not specified, the bandwidth is specified instead. If the
bandwidth is known then this can be specified directly instead of the
metric.
Authentication
All OSPF protocol exchanges can be authenticated using a simple password or MD5
cryptographic hashes.
If Use Default for Router Process is enabled then the values configured in the router process
properties are used. If this is not enabled then the following options are available:
•
No authentication.
•
Passphrase.
•
MD5 Digest.
Advanced
Passive
Unless an interface is being used by the OSPF router process to
connect to another OSPF router, this option should be enabled. In
the Web Interface or InControl the option is called No OSPF
routers connected to this interface.
When enabled, no OSPF traffic will be generated on the interface.
Hello Interval
Specifies the number of seconds between Hello packets sent on
the interface.
Router Dead Interval
If not Hello packets are received from a neighbor within this
interval then that neighbor router will be considered to be out of
operation.
RXMT Interval
Specifies the number of seconds between retransmissions of
LSAs to neighbors on this interface.
287
Chapter 4: Routing
InfTrans Delay
Specifies the estimated transmit delay for the interface. This value
represents the maximum time it takes to forward a LSA packet
trough the router.
Wait Interval
Specifies the number of seconds between the interface brought
up and the election of the DR and BDR. This value should be
higher than the hello interval.
Router Priority
Specifies the router priority, a higher number increases this
routers chance of becoming a DR or a BDR. If 0 is specified then
this router will not be eligible in the DR/BDR election.
Note
An HA cluster will always have 0 as router priority, and
can never be used as a DR or BDR.
Sometimes there is a need to include networks into the OSPF router process, without running
OSPF on the interface connected to that network. This is done by enabling the Passive option: No
OSPF routers connected to this interface ("Passive").
This is an alternative to using a Dynamic Routing Policy to import static routes into the OSPF
router process.
If the Ignore received OSPF MTU restrictions is enabled, OSPF MTU mismatches will be
allowed.
4.6.3.4. OSPF Neighbors
In some scenarios the neighboring OSPF router to a security gateway needs to be explicitly
defined. For example, when the connection is not between physical interfaces.
The most common situation for using this is when a VPN tunnel is used to connect two
neighbors and we need to tell cOS Core that the OSPF connection needs to be made through the
tunnel. This type of VPN usage with IPsec tunnels is described further in Section 4.6.5, “Setting Up
OSPF”.
cOS Core OSPF Neighbor objects are created within an OSPF Area and each object has the
following property parameters:
Interface
Specifies which OSPF interface the neighbor is located on.
IP Address
The IP Address of the neighbor. This is the IP Address of the neighbors OSPF
interface connecting to this router. For VPN tunnels this will be the IP address of
the tunnel's remote end.
Metric
Specifies the metric to this neighbor.
4.6.3.5. OSPF Aggregates
OSPF Aggregation is used to combine groups of routes with common addresses into a single
entry in the routing table. If advertised this will decreases the size of the routing table in the
security gateway, if not advertised this will hide the networks.
cOS Core OSPF Aggregate objects are created within an OSPF Area and each object has the
following parameters:
288
Chapter 4: Routing
Network
The network consisting of the smaller routers.
Advertise
If the aggregation should be advertised or not.
In most, simple OSPF scenarios, OSPF Aggregate objects will not be needed.
4.6.3.6. OSPF VLinks
All areas in an OSPF AS must be physically connected to the backbone area (the area with ID 0).
In some cases this is not possible and in that case a Virtual Link (VLink) can be used to connect to
the backbone through a non-backbone area.
cOS Core OSPF VLink objects are created within an OSPF Area and each object has the following
parameters:
General Parameters
Name
Symbolic name of the virtual link.
Neighbor Router ID
The Router ID of the router on the other side of the virtual link.
Authentication
Use Default For AS
Use the values configured in the AS properties page.
Note: Linking partitioned backbones
If the backbone area is partitioned, a virtual link is used to connect the different parts.
In most, simple OSPF scenarios, OSPF VLink objects will not be needed.
4.6.4. Dynamic Routing Rules
This section examines Dynamic Routing Rules. These rules determine which routes can be
exported to an OSPF AS from the local routing tables and which can be imported into the local
routing tables from the AS.
4.6.4.1. Overview
The Final OSPF Setup Step is Creating Dynamic Routing Rules
After the OSPF structure is created, the final step is always to create a Dynamic Routing Rule on
each Clavister Security Gateway which allows the routing information that the OSPF AS delivers
from remote security gateways to be added to the local routing tables.
Dynamic routing rules are discussed here in the context of OSPF, but can also be used in other
contexts.
The Reasons for Dynamic Routing Rules
In a dynamic routing environment, it is important for routers to be able to regulate to what
extent they will participate in the routing exchange. It is not feasible to accept or trust all
289
Chapter 4: Routing
received routing information, and it might be crucial to avoid parts of the routing database
getting published to other routers.
For this reason, Dynamic Routing Rules are used to regulate the flow of routing information.
These rules filter either statically configured or OSPF learned routes according to parameters like
the origin of the routes, destination, metric and so on. The matched routes can be controlled by
actions to be either exported to OSPF processes or to be added to one or more routing tables.
Usage with OSPF
Dynamic Routing Rules are used with OSPF to achieve the following:
•
Allowing the import of routes from the OSPF AS into local routing tables.
•
Allowing the export of routes from a local routing tables to the OSPF AS.
•
Allowing the export of routes from one OSPF AS to another OSPF AS.
Note
The last usage of joining asynchronous systems together is rarely encountered except in
very large networks.
OSPF Requires at Least an Import Rule
By default, cOS Core will not import or export any routes. For OSPF to function, it is therefore
mandatory to define at least one dynamic routing rule which will be an Import rule.
This Import rule specifies the local OSPF Router Process object. This enables the external routes
made available in the OSPF AS to be imported into the local routing tables.
Specifying a Filter
Dynamic routing rules allow a filter to be specified which narrows the routes that are imported
based on the network reached. In most cases, the Or is within option should be specified as
all-nets so that no filter is applied.
When to Use Export Rules
Although an Import rule is needed to import routes from the OSPF AS, the opposite is not true.
The export of routes to networks that are part of OSPF Interface objects are automatic.
A dynamic routing export rule must be created to explicitly export the route to the OSPF AS.
Dynamic Routing Rule Objects
The diagram below shows the relationship between the cOS Core dynamic routing rule objects.
290
Chapter 4: Routing
Figure 4.13. Dynamic Routing Rule Objects
4.6.4.2. Dynamic Routing Rule
This object defines a dynamic routing rule.
General Parameters
Name
Specifies a symbolic name for the rule.
From OSPF AS
Specifies the from which OSPF AS (in other words, an OSPF
Router Process) the route should be imported from into either a
routing table or another AS.
From Routing Table
Specifies from which routing table a route should be imported
into the OSPF AS or copied into another routing table.
Destination Interface
Specifies if the rule has to have a match to a certain destination
interface.
Destination Network
Exactly Matches
Specifies if the network needs to exactly match a specific network.
Or is within
Specifies if the network needs to be within a specific network.
More Parameters
Next Hop
Specifies what the next hop (in other words, router) needs to be for this
rule to be triggered.
Metric
Specifies an interval that the metric of the routers needs to be in
between.
Router ID
Specifies if the rule should filter on Router ID.
OSPF Route Type
Specifies if the rule should filter on the OSPF Router Type.
291
Chapter 4: Routing
OSPF Tag
Specifies an interval that the tag of the routers needs to be in between.
4.6.4.3. OSPF Action
This object defines an OSPF action.
General Parameters
Export to Process
Specifies into which OSPF AS the route change should be imported.
Forward
If needed, specifies the IP to route via.
Tag
Specifies a tag for this route. This tag can be used in other routers for
filtering.
Route Type
Specifies what the kind of external route type. Specify 1 if OSPF
should regard external routes as type 1 OSPF routes. Type 2 is the most
significant cost of a route.
OffsetMetric
Increases the metric of an imported route by this value.
Limit Metric To
Limits the metrics for these routes to a minimum and maximum value.
If a route has a higher or lower value than specified then it will be set
to the specified value.
4.6.4.4. Routing Action
A Routing Action is used to manipulate and export routing changes to one or more local routing
tables.
Destination
Specifies into which routing table the route changes to the
OSPF AS should be imported.
Offset Metric
Increases the metric by this value.
Offset Metric Type 2
Increases the Type 2 router's metric by this value.
Limit Metric To
Limits the metrics for these routes to a minimum and
maximum value. If a route has a higher value than specified
then it will be set to the specified value.
Static Route Override
Allows the override of the static routes.
Default Route Override
Allows the override of the default route.
4.6.5. Setting Up OSPF
Setting up OSPF can seem complicated because of the large number of configuration
possibilities that OSPF offers. However, in many cases a simple OSPF solution using a minimum
of cOS Core objects is needed and setup can be straightforward.
Let us examine again the simple scenario described earlier with just two Clavister Security
Gateways.
292
Chapter 4: Routing
Figure 4.14. Setting Up OSPF
In this example we connect together the two Clavister Security Gateways with OSPF so they can
share the routes in their routing tables. Both will be inside a single OSPF area which will be part
of a single OSPF autonomous system (AS). If unfamiliar with these OSPF concepts, please refer to
earlier sections for further explanation.
Beginning with just one of these security gateways, the cOS Core setup steps are as follows:
1. Create an OSPF Router object
Create a cOS Core OSPF Router Process object. This will represent an OSPF Autonomous Area (AS)
which is the highest level in the OSPF hierarchy. Give the object an appropriate name. The
Router ID can be left blank since this will be assigned automatically by cOS Core.
2. Add an OSPF Area to the OSPF Router
Within the OSPF Router Process created in the previous step, add a new OSPF Area object. Assign
an appropriate name and use the value 0.0.0.0 for the Area ID.
An AS can have multiple areas but in many cases only one is needed. The ID 0.0.0.0 identifies this
area as the backbone area which forms the central portion of the AS.
3. Add OSPF Interfaces to the OSPF Area
Within the OSPF Area created in the previous step, add a new OSPF Interface for each physical
interface that will be part of the area.
The OSPF Interface object needs the following parameters specified in its properties:
•
Interface - the physical interface which will be part of the OSPF area.
•
Network - the network on the interface that will be part of the area.
This does not need to be specified and if it is not, the network assigned to the physical
interface is used. For example if lan is the interface then lan_net will be the default network.
•
Interface Type - this would normally be Auto so that the correct type is automatically
selected.
•
The Passive option No OSPF routers connected to this interface must be enabled if the
physical interface does not connect directly to another OSPF Router (in other words, with
another Clavister Security Gateway that acts as an OSPF router). For example, the interface
may only be connected to a network of clients, in which case the option would be enabled.
The option must be disabled if the physical interface is connected to another security
gateway which is set up as an OSPF Router. In this example, the physical interface connected
to the other security gateway would have this option disabled.
4. Add a Dynamic Routing Rule
293
Chapter 4: Routing
Finally, a Dynamic Routing Rule needs to be defined to deploy the OSPF network. This involves
two steps:
i.
A Dynamic Routing Policy Rule object is added. This rule should be an Import rule that
enables the option From OSPF Process so that the previously defined OSPF Router Process
object is selected. What we are doing is saying that we want to import all routes from the
OSPF AS.
In addition, the optional Or is within filter parameter for the destination network must be
set to be all-nets. We could use a narrower filter for the destination network but in this case
we want all networks.
ii.
Within the Dynamic Routing Policy Rule just added, we now add a Routing Action object. Here
we add the routing table into the Selected list which will receive the routing information
from OSPF.
In the typical case this will be the routing table called main.
There is no need to have a Dynamic Routing Policy Rule which exports the local routing table into
the AS since this is done automatically for OSPF Interface objects.
The exception to this is if a route involves an ISP gateway (in other words, a router hop). In this
case the route MUST be explicitly exported. The most frequent case when this is necessary is for
the all-nets route to the external public Internet where the gateway is the ISP's router. Doing this
is discussed in the next step.
5. Add a Dynamic Routing Rule for all-nets
Optionally, a Dynamic Routing Rule needs to be defined if any routes except the OSPF Interface
routes are to be exported. This involves the following steps
i.
A Dynamic Routing Policy Rule object is added. This rule should be an Export rule that enables
the option From Routing Table with the main routing table moved to the Selected list.
In addition, the optional Or is within filter parameter for the destination network must be
set to be all-nets. This means all routes will be exported.
ii.
Within the Dynamic Routing Policy Rule just added, we now add an OSPF Action object. Here
set the Export to process option to be the OSPF Router Process which represents the OSPF
AS.
6. Repeat these steps on the other security gateway
Now repeat steps 1 to 5 for the other Clavister Security Gateway that will be part of the OSPF AS
and area. The OSPF Router and OSPF Area objects will be identical on each. The OSPF Interface
objects will be different depending on which interfaces and networks will be included in the
OSPF system.
If more than two security gateways will be part of the same OSPF area then all of them should be
configured similarly.
OSPF Routing Information Exchange Begins Automatically
As the new configurations are created in the above steps and then deployed, OSPF will
automatically start and begin exchanging routing information. Since OSPF is a dynamic and
distributed system, it does not matter in which order the configurations of the individual security
gateways are deployed.
When the physical link is plugged in between two interfaces on two different security gateways
294
Chapter 4: Routing
and those interfaces are configured with OSPF Router Process objects, OSPF will begin
exchanging routing information.
Confirming OSPF Deployment
It is now possible to check that OSPF is operating and that routing information is exchanged.
This can be done by examining the routing tables. Routes that have been imported into the
routing tables though OSPF are indicated with the letter "O" to the left of the route description.
For example, the routes command might give following output:
Device:/> routes
Flags Network
----- --------------192.168.1.0/24
172.16.0.0/16
O
192.168.2.0/24
Iface
Gateway
Local IP
----------- --------------- ---------lan
wan
wan
172.16.2.1
Metric
-----0
0
1
Here, the route for 192.168.2.0/24 has been imported via OSPF and that network can be found on
the WAN interface with the gateway of 172.16.2.1. The gateway in this case is of course the
Clavister Security Gateway to which the traffic should be sent. That security gateway may or may
not be attached to the destination network but OSPF has determined that that is the optimum
route to reach it.
The CLI command ospf can also be used to indicate OSPF status. The options for this command
are fully described in the CLI Reference Guide.
Sending OSPF Traffic Through a VPN Tunnel
In some cases, the link between two Clavister Security Gateways which are configured with OSPF
Router Process objects may be insecure. For example, over the public Internet.
In this case, we can secure the link by setting up a VPN tunnel between the two security
gateways and telling OSPF to use this tunnel for exchange of OSPF information. Next, we will
look at how to set this up and assume that IPsec will be the chosen method for implementing the
tunnel.
Figure 4.15. OSPF Over IPsec
To create this setup we need to perform the normal OSPF steps described above but with the
following additional steps:
1. Set up an IPsec tunnel
First set up an IPsec tunnel in the normal way between the two security gateways A and B. The
IPsec setup options are explained in Section 9.2, “VPN Quick Start”.
This IPsec tunnel is now treated like any other interface when configuring OSPF in cOS Core.
295
Chapter 4: Routing
2. Choose a random internal IP network
For each security gateway, we need to choose a random IP network using internal, private IPv4
addresses. For example, for security gateway A we could use the network 192.168.55.0/24.
This network is used just as a convenience with OSPF setup and will never be associated with a
real physical network.
3. Define an OSPF Interface for the tunnel
Define an cOS Core OSPF Interface object which has the IPsec tunnel for the Interface parameter.
Specify the Type parameter to be point-to-point and the Network parameter to be the network
chosen in the previous step, 192.168.55.0/24.
This OSPF Interface tells cOS Core that any OPSF related connections to addresses within the
network 192.168.55.0/24 should be routed into the IPsec tunnel.
4. Define an OSPF Neighbor
Next, we must explicitly tell OSPF how to find the neighbouring OSPF router. Do this by defining
a cOS Core OSPF Neighbor object. This consists of a pairing of the IPsec tunnel (which is treated
like an interface) and the IP address of the router at the other end of the tunnel.
For the IPv4 address of the router, we simply use any single IP address from the network
192.168.55.0/24. For example, 192.168.55.1.
When cOS Core sets up OSPF, it will look at this OSPF Neighbor object and will try to send OSPF
messages to the IPv4 address 192.168.55.1. The OSPF Interface object defined in the previous step
tells cOS Core that OSPF related traffic to this IP address should be routed into the IPsec tunnel.
5. Set the Local IP of the tunnel endpoint
To finish the setup for security gateway A there needs to be two changes made to the IPsec
tunnel setup on security gateway B. These are:
i.
In the IPsec tunnel properties, the Local Network for the tunnel needs to be set to all-nets.
This setting acts as a filter for what traffic is allowed into the tunnel and all-nets will allow all
traffic into the tunnel.
ii.
In the routing section of the IPsec properties, the Specify address manually option needs
to be enabled and the IPv4 address in this example of 192.168.55.1 needs to be entered (in
the CLI, OriginatorType is set to manual and the OriginatorIP is 192.168.55.1). This sets the
tunnel endpoint IP to be 192.168.55.1 so that all OSPF traffic will be sent to security gateway
A with this source IP.
The result of doing this is to "core route" OSPF traffic coming from security gateway A. In other
words the traffic is destined for cOS Core.
6. Repeat the steps for the other security gateway
What we have done so far is allow OSPF traffic to flow from A to B. The steps above need to be
repeated as a mirror image for security gateway B using the same IPsec tunnel but using a
different random internal IP network for OSPF setup.
Tip: Non-OSPF traffic can also use the tunnel
A VPN tunnel can carry both OSPF traffic as well as other types of traffic. There is no
requirement to dedicate a tunnel to OSPF traffic.
296
Chapter 4: Routing
4.6.6. An OSPF Example
This section goes through the detailed setup steps for the simple OSPF scenario illustrated
below.
Figure 4.16. An OSPF Example
Here, two identical Clavister Security Gateways called A and B are joined together directly via
their If3 interfaces. Each has a network of hosts attached to its If1 interface. On one side, If1_net
is the IPv4 network 10.4.0.0/16 and on the other side it is the IPv4 network 192.168.0.0/24.
The goal is to configure OSPF on both security gateways so routing information is automatically
exchanged and traffic can be correctly routed between the 10.4.0.0/16 network and the
192.168.0.0/24 network. The IP rules that are needed to allow such traffic to flow are not included
in this example.
Example 4.9. Creating an OSPF Router Process
First the Autonomous System (AS) must be defined on both security gateways.
On security gateway A, create an OSPF Router Process object. Assume the object name will be
as_0.
Command-Line Interface
Device:/> add OSPFProcess as_0
InControl
297
Chapter 4: Routing
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Network > Routing > OSPF > Add > OSPF Router Process
2.
Enter the process name, in this case as_0
3.
Click OK
Now, repeat this for security gateway B, using the same OSPF Router Process object name of as_0.
Example 4.10. Add an OSPF Area
Now add an OSPF Area object to the OSPF Router Process object as_0 on security gateway A. This
area will be the OSPF backbone area and will therefore have the ID 0.0.0.0. Assume the name for
the area object will be area_0.
Command-Line Interface
First, change the CLI context to be the OSPFProcess object created above:
Device:/> cc OSPFProcess as_0
Now, add the area:
Device:/as_0> add OSPFArea area_0 AreaID=0.0.0.0
This new OSPFArea object can be displayed with the command:
Device:/as_0> show
OSPFArea/
!
Name
---area_1
Area ID
------0.0.0.0
Comments
-------<empty>
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Network > Routing > OSPF
2.
Select the routing process as_0
3.
Select Add > OSPF Area
4.
For the area properties:
•
Enter the area name, in this case area_0
•
Specify the Area ID as 0.0.0.0
298
Chapter 4: Routing
5.
Click OK
Now, repeat this for security gateway B, using the same OSPF Area object name of area_0.
Example 4.11. Add OSPF Interface Objects
For security gateway A, add OSPF Interface objects for each physical interface that is to be part of
the OSPF area called area_0.
Command-Line Interface
Assume the context is still the OSPFProcess called as_0 from the last example. Now, change the
context to be the OSPFArea that was created previously:
Device:/as_0> cc area_0
Next, add the OSPFInterface object:
Device:/as_0/area_0> add OSPFInterface If1 Passive=Yes
Enabling the Passive option means that this interface is not connected to another OSPF router.
Finally, return to the default CLI context:
Device:/as_0/area_0> cc
Device:/>
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Network > Routing > OSPF > as_0 > area_0 > OSPF Interfaces
2.
Select Add > OSPF Interface
3.
Select the Interface. In this case, If1
4.
Select the Advanced tab
5.
Select No OSPF routers connected to this interface
6.
Click OK
Just selecting the Interface means that the Network defaults to the network bound to that
interface. In this case If1_net.
This should be repeated for all interfaces that will be part of the OSPF area. In this case, the
interface If3 must also be added as an OSPFInterface but the Passive property should be left at its
default value of enabled since this interface is connected to another router.
security gateway B, should then be set up in the same way.
299
Chapter 4: Routing
Example 4.12. Import Routes from an OSPF AS into the Main Routing Table
In this example, the routes received using OSPF will be added into the main routing table. To do
this, a Dynamic Routing Policy Rule first needs to be created. In this example, the rule is called
ImportOSPFRoutes.
The rule must specify from what OSPF AS the routes should be imported. In this example, the
OSPF AS configured above, with the name as_0, is used.
Depending on the routing topology, it may be preferable to just import certain routes using the
Destination Interface/Destination Network filters, but in this scenario all routes that are within the
all-nets network object are allowed.
The steps are first performed for security gateway A.
Command-Line Interface
Device:/> add DynamicRoutingRule
OSPFProcess=as_0
Name=ImportOSPFRoutes
DestinationNetworkIn=all-nets
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Network > Routing > Routing Rules > Add > Dynamic Routing Policy Rule
2.
Specify a suitable name for the rule. For example, ImportOSPFRoutes.
3.
Select the option From OSPF Process
4.
Move as_0 from Available to Selected
5.
Choose all-nets in the ...Or is within filter option for Destination Interface
6.
Click OK
Now, create a Dynamic Routing Action that will import routes into the routing table. The
destination routing table that the routes should be added to is main.
Command-Line Interface
First, change the CLI context to be the DynamicRoutingRule just added for import:
Device:/> cc DynamicRoutingRule ImportOSPFRoutes
Next, add a DynamicRoutingRuleAddRoute object:
Device:/1(ImportOSPFRoutes)> add DynamicRoutingRuleAddRoute
Destination=main
InControl
Follow the same steps used for the Web Interface below.
300
Chapter 4: Routing
Web Interface
1.
Go to: Network > Routing > Routing Rules
2.
Click on the newly created ImportOSPFRoutes
3.
Go to: Routing Action > Add > DynamicRoutingRuleAddRoute
4.
Move the routing table main from Available to Selected
5.
Click OK
The same procedure should be repeated for security gateway B.
Example 4.13. Exporting the Routes into an OSPF AS
In this example, routes from the main routing table will be exported into an OSPF AS named
as_0. This must be done explicitly because routes are not exported automatically.
The exception to this are the routes for the OSPF interface networks which are exported
automatically (in this example If1_net and If3_net).
The steps are first performed for security gateway A.
First, add a new Dynamic Routing Policy Rule.
Command-Line Interface
Device:/> add DynamicRoutingRule
OSPFProcess=as_0
Name=ExportDefRoute
DestinationNetworkIn=all-nets
DestinationInterface=If3
From=RTable
RoutingTable=main
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Network > Routing > Routing Rules > Add > Dynamic Routing Policy Rule
2.
Specify a name for the rule. In this case, ExportAllNets
3.
Select the option From Routing Table
4.
Move the routing table main to the Selected list
5.
Choose all-nets in the ...Or is within filter for Destination Interface
6.
Click OK
Next, create an OSPF Action that will export the filtered route to the specified OSPF AS:
301
Chapter 4: Routing
Command-Line Interface
First, change the CLI context to be the DynamicRoutingRule just added for export:
Device:/> cc DynamicRoutingRule ExportDefRoute
Next, add a DynamicRoutingRuleExportOSPF object:
Device:/2(ExportDefRoute)> add DynamicRoutingRuleExportOSPF
ExportToProcess=as_0
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Network > Routing > Routing Rules
2.
Click on the newly created ExportAllNets
3.
Go to: OSPF Actions > Add > DynamicRoutingRuleExportOSPF
4.
For Export to process choose as_0
5.
Click OK
The same procedure should be repeated for security gateway B.
4.6.7. OSPF Troubleshooting
There are two special ways of troubleshooting OSPF issues:
•
Additional OSPF Log Event Messages.
•
The OSPF CLI command.
These are discussed next.
Additional OSPF Log Event Messages
By default, a range of basic log event messages are generated by OSPF operation within cOS
Core. For example, if the OSPFProcess object running under cOS Core is called my_ospf_proc,
normal log generation would be enabled with the CLI command:
Device:/> set OSPFProcess my_ospf_proc LogEnabled=Yes
This is the default setting so the command is only for illustration.
The following properties can be enabled to provide additional OSPF log messages for
troubleshooting and/or monitoring purposes:
•
DebugPacket - Log general packet parsing events.
•
DebugHello - Log Hello packets.
302
Chapter 4: Routing
•
DebugDDesc - Log database description packets.
•
DebugExchange - Log exchange packets.
•
DebugLSA - Log LSA events.
•
DebugSPF - Log SPF calculation events.
•
DebugRoute - Log routing table manipulation events.
Each of these properties can be assigned one of the following values:
•
Off - Nothing is logged.
•
Low - Logs all actions.
•
Medium - Logs all actions but with more detail.
•
High - Logs everything with maximum detail.
Note: The high setting generates large amounts of data
When using the High setting, the security gateway will log a large amount of
information, even when just connected to a small AS. Changing the advanced setting
Log Send Per Sec Limit may be required.
Example 4.14. Enabling OSPF Debug Log Events
In this example, the DebugHello and DebugRoute log events will be enabled for the OSPFProcess
called my_ospf_proc.
Command-Line Interface
Device:/> set OSPFProcess my_ospf_proc DebugHello=Low DebugRoute=High
InControl
Follow the same steps used for the Web Interface below.
Web Interface
1.
Go to: Network > Routing > OSPF > my_ospf_proc
2.
Select the Debug option
3.
Now enter:
4.
•
Hello Packets: Low
•
Routing Table Manipulation: High
Click OK
303
Chapter 4: Routing
The OSPF CLI command
The CLI command ospf provides various options for examining the behaviour of OSPF in
real-time on a particular.
In order to see general OSPF activity on a CLI console, the -snoop option can be used:
Device:/> ospf -snoop=on
Usually, there is only one OSPFProcess defined for a security gateway and there is therefore no
need to specify this explicitly in the command. The snooping processes is turned off with:
Device:/> ospf -snoop=off
A snapshot of the state of any of the different OSPF components can be displayed. For example,
if an OSPFInterface object has the name ospf_If1, details about this can be shown with the
command:
Device:/> ospf -interface ospf_If1
A similar snapshot can be displayed for areas, neighbors, routes and LSAs.
OSPF interface operation can also be selectively halted and restarted. For example, to stop the
OSPFInterface called ospf_If1, the CLI command would be:
Device:/> ospf -ifacedown ospf_If1
To restart the same interface:
Device:/> ospf -ifacedown ospf_If1
An entire functioning OSPFRouteProcess can also be halted. For example, assuming that there is
only one OSPFRouteProcess object defined in the configuration, the CLI command to halt it is:
Device:/> ospf -execute=stop
To start the stopped OSPFRouteProcess:
Device:/> ospf -execute=start
To stop and then start in a single command:
Device:/> ospf -execute=restart
The ospf command options are fully described in the separate cOS Core CLI Reference Guide.
304
Chapter 4: Routing
4.7. Multicast Routing
4.7.1. Overview
The Multicast Problem
Certain types of Internet interactions, such as conferencing and video broadcasts, require a
single client or host to send the same packet to multiple receivers. This could be achieved
through the sender duplicating the packet with different receiving IP addresses or by a broadcast
of the packet across the Internet. These solutions waste large amounts of sender resources or
network bandwidth and are therefore not satisfactory. An appropriate solution should also be
able to scale to large numbers of receivers.
The Multicast Routing Solution
Multicast Routing solves the problem by the network routers themselves, replicating and
forwarding packets via the optimum route to all members of a group.
The IETF standards that allow multicast routing are the following:
•
Class D of the IPv4 address space which is reserved for multicast traffic. Each multicast IP
address represent an arbitrary group of recipients.
•
The Internet Group Membership Protocol (IGMP) allows a receiver to tell the network that it is a
member of a particular multicast group.
•
Protocol Independent Multicast (PIM) is a group of routing protocols for deciding the optimal
path for multicast packets.
Underlying Principles
Multicast routing functions on the principle that an interested receiver joins a group for a
multicast by using the IGMP protocol. PIM routers can then duplicate and forward packets to all
members of such a multicast group, thus creating a distribution tree for packet flow. Rather than
acquiring new network information, PIM uses the routing information from existing protocols,
such as OSPF, to decide the optimal path.
Reverse Path Forwarding
A key mechanism in the multicast routing process is Reverse Path Forwarding. For unicast traffic, a
router is concerned only with a packet's destination. With multicast, the router is also concerned
with a packets source since it forwards the packet on paths which are known to be downstream,
away from the packet's source. This approach is adopted to avoid loops in the distribution tree.
Routing to the Correct Interface
By default, multicast packets are routed by cOS Core to the core interface (in other words, to cOS
Core itself ). SAT Multiplex rules are set up in the IP rule set in order to perform forwarding to the
correct interfaces. This is demonstrated in the examples described later.
Note: Interface multicast handling must be On or Auto
305
Chapter 4: Routing
For multicast to function with an Ethernet interface on any Clavister Security Gateway,
that interface must have multicast handling set to On or Auto. For further details on this
see Section 3.4.2, “Ethernet Interfaces”.
4.7.2. Multicast Forwarding with SAT Multiplex Rules
The SAT Multiplex rule is used to achieve duplication and forwarding of packets through more
than one interface. This feature implements multicast forwarding in cOS Core, where a multicast
packet is sent through several interfaces.
Note that since this rule overrides the normal routing tables, packets that should be duplicated
by the multiplex rule needs to be routed to the core interface.
By default, the multicast IP range 224.0.0.0/4 is always routed to core and does not have to be
manually added to the routing tables. Each specified output interface can individually be
configured with static address translation of the destination address. The Interface field in the
Interface/Net Tuple dialog may be left empty if the IPAddress field is set. In this case, the
output interface will be determined by a route lookup on the specified IP address.
The multiplex rule can operate in one of two modes:
•
Using IGMP
The traffic flow specified by the multiplex rule must have been requested by hosts using
IGMP before any multicast packets are forwarded through the specified interfaces. This is the
default behavior of cOS Core.
•
Not using IGMP
The traffic flow will be forwarded according to the specified interfaces directly without any
inference from IGMP.
Note: An Allow or NAT rule is also needed
Since the Multiplex rule is a SAT rule, an Allow or NAT rule also has to be specified as
well as the Multiplex rule.
4.7.2.1. Multicast Forwarding - No Address Translation
This scenario describes how to configure multicast forwarding together with IGMP. The multicast
sender is 192.168.10.1 and generates the multicast streams 239.192.10.0/24:1234. These multicast
streams should be forwarded from interface wan through the interfaces if1, if2 and if3. The
streams should only be forwarded if some host has requested the streams using the IGMP
protocol.
The example below only covers the multicast forwarding part of the configuration. The IGMP
configuration can be found later in Section 4.7.3.1, “IGMP Rules Configuration - No Address
Translation”.
306
Chapter 4: Routing
Figure 4.17. Multicast Forwarding - No Address Translation
Note: SAT Multiplex rules must have a matching Allow rule
Remember to add an Allow rule that matches the SAT Multiplex rule.
The matching rule could also be a NAT rule for source address translation (see below)
but cannot be a FwdFast or SAT rule.
Example 4.15. Forwarding of Multicast Traffic using the SAT Multiplex Rule
In this example, we will create a multiplex rule in order to forward the multicast groups
239.192.10.0/24:1234 to the interfaces if1, if2 and if3. All groups have the same sender
192.168.10.1 which is located somewhere behind the wan interface.
The multicast groups should only be forwarded to the out interfaces if clients behind those
interfaces have requested the groups using IGMP. The following steps need to be performed to
configure the actual forwarding of the multicast traffic. IGMP has to be configured separately.
InControl
Follow the same steps used for the Web Interface below.
Web Interface
A. Create a custom service for multicast called multicast_service:
307
Chapter 4: Routing
1.
Go to: Objects > Services > Add > TCP/UDP
2.
Now enter:
•
Name: multicast_service
•
Type: UDP
•
Destination: 1234
B. Create an IP rule:
1.
Go to: Policies > Add > IP Rule
2.
Under General enter.
3.
•
Name: a name for the rule, for example Multicast_Multiplex
•
Action: Multiplex SAT
•
Service: multicast_service
Under Address Filter enter:
•
Source Interface: wan
•
Source Network: 192.168.10.1
•
Destination Interface: core
•
Destination Network: 239.192.10.0/24
4.
Click the Multiplex SAT tab and add the output interfaces if1, if2 and if3 one at a time. For
each interface, leave the IPAddress field blank since no destination address translation is
wanted.
5.
Enable the option:
Multicast traffic must have been requested using IGMP before it is forwarded
6.
Click OK
Creating Multiplex Rules with the CLI
Creating multiplex rules through the CLI requires some additional explanation.
The CLI command to create the multiplex rule is then:
Device:/> add IPRule
SourceNetwork=<srcnet>
SourceInterface=<srcif>
DestinationInterface=<srcif>
DestinationNetwork=<destnet>
Action=MultiplexSAT
Service=<service>
MultiplexArgument={outif1;ip1},{outif2;ip2},{outif3;ip3}...
The two values {outif;ip} represent a combination of output interface and, if address translation of
a group is needed, an IP address.
308
Chapter 4: Routing
If, for example, multiplexing of the multicast group 239.192.100.50 is required to the output
interfaces if2 and if3, then the command to create the rule would be:
Device:/> add IPRule
SourceNetwork=<srcnet>
SourceInterface=<if1>
DestinationInterface=core
DestinationNetwork=239.192.100.50
Action=MultiplexSAT
Service=<service>
MultiplexArgument={if2;},{if3;}
The destination interface is core since 239.192.100.50 is a multicast group. No address translation
of 239.192.100.50 was added but if it is required for, say, if2 then the final argument would be:
MultiplexArgument={if2;<new_ip_address>},{if3;}
4.7.2.2. Multicast Forwarding - Address Translation Scenario
Figure 4.18. Multicast Forwarding - Address Translation
This scenario is based on the previous scenario but this time the multicast group is translated.
When the multicast streams 239.192.10.0/24 are forwarded through the if2 interface, the
multicast groups should be translated into 237.192.10.0/24.
No address translation should be made when forwarding through interface if1. The configuration
of the corresponding IGMP rules can be found below in Section 4.7.3.2, “IGMP Rules Configuration
- Address Translation”.
Tip
As previously noted, remember to add an Allow rule matching the SAT Multiplex rule.
Example 4.16. Multicast Forwarding - Address Translation
309
Chapter 4: Routing
The following SAT Multiplex rule needs to be configured to match the scenario described above:
InControl
Follow the same steps used for the Web Interface below.
Web Interface
A. Create a custom service for multicast called multicast_service:
1.
Go to: Objects > Services > Add > TCP/UDP
2.
Now enter:
•
Name: multicast_service
•
Type: UDP
•
Destination: 1234
B. Create an IP rule:
1.
Go to: Policies > Add > IP Rule
2.
Under General enter.
3.
•
Name: a name for the rule, for example Multicast_Multiplex
•
Action: Multiplex SAT
•
Service: multicast_service
Under Address Filter enter:
•
Source Interface: wan
•
Source Network: 192.168.10.1
•
Destination Interface: core
•
Destination Network: 239.192.10.0/24
4.
Click the Multiplex SAT tab
5.
Add interface if1 but leave the IPAddress empty
6.
Add interface if2 but this time, enter 237.192.10.0 as the IPAddress
7.
Enable the option:
Multicast traffic must have been requested using IGMP before it is forwarded
8.
Click OK
Note: Replace Allow with NAT for source IP translation
If address translation of the source address is required, the Allow rule following the SAT
Multiplex rule should be replaced with a NAT rule.
310
Chapter 4: Routing
4.7.3. IGMP Configuration
IGMP signalling between hosts and routers can be divided into two categories:
•
IGMP Reports
Reports are sent from hosts towards the router when a host wants to subscribe to new
multicast groups or change current multicast subscriptions.
•
IGMP Queries
Queries are IGMP messages sent from the router towards the hosts in order to make sure that
it will not close any stream that some host still wants to receive.
Normally, both types of rule have to be specified for IGMP to function but there are two
exceptions:
1.
If the multicast source is located on a network directly connected to the router, no query
rule is needed.
2.
If a neighboring router is statically configured to deliver a multicast stream to the Clavister
Security Gateway, an IGMP query would also not have to be specified.
cOS Core supports two IGMP modes of operation:
•
Snoop Mode
•
Proxy Mode
The operation of these two modes are shown in the following illustrations:
Figure 4.19. Multicast Snoop Mode
311
Chapter 4: Routing
Figure 4.20. Multicast Proxy Mode
In Snoop Mode, the Clavister Security Gateway will act transparently between the hosts and
another IGMP router. It will not send any IGMP Queries. It will only forward queries and reports
between the other router and the hosts.
In Proxy Mode, the security gateway will act as an IGMP router towards the clients and actively
send queries. Towards the upstream router, the security gateway will be acting as a normal host,
subscribing to multicast groups on behalf of its clients.
4.7.3.1. IGMP Rules Configuration - No Address Translation
This example describes the IGMP rules needed for configuring IGMP according to the No Address
Translation scenario described above. The router is required to act as a host towards the
upstream router and therefore IGMP must be configured to run in proxy mode.
Example 4.17. IGMP - No Address Translation
The following example requires a configured interface group IfGrpClients including interfaces if1,
if2 and if3. The IP address of the upstream IGMP router is known as UpstreamRouterIP.
Two rules are needed. The first one is a report rule that allows the clients behind interfaces if1, if2
and if3 to subscribe for the multicast groups 239.192.10.0/24. The second rule, is a query rule that
allows the upstream router to query us for the multicast groups that the clients have requested.
The following steps need to be executed to create the two rules.
InControl
Follow the same steps used for the Web Interface below.
Web Interface
A. Create the first IGMP Rule:
312
Chapter 4: Routing
1.
Go to: Network > Routing > IGMP Rules > Add > IGMP Rule
2.
Under General enter:
3.
4.
•
Name: A suitable name for the rule, for example Reports
•
Type: Report
•
Action: Proxy
•
Output: wan (this is the relay interface)
Under Address Filter enter:
•
Source Interface: lfGrpClients
•
Source Network: if1net, if2net, if3net
•
Destination Interface: core
•
Destination Network: auto
•
Multicast Source: 192.168.10.1
•
Multicast Destination: 239.192.10.0/24
Click OK
B. Create the second IGMP Rule:
1.
Again, go to: Network > Routing > IGMP Rules > Add > IGMP Rule
2.
Under General enter:
3.
4.
•
Name: A suitable name for the rule, for example Queries
•
Type: Query
•
Action: Proxy
•
Output: IfGrpClients (this is the relay interface)
Under Address Filter enter:
•
Source Interface: wan
•
Source Network: UpstreamRouterIp
•
Destination Interface: core
•
Destination Network: auto
•
Multicast Source: 192.168.10.1
•
Multicast Group: 239.192.10.0/24
Click OK
313
Chapter 4: Routing
4.7.3.2. IGMP Rules Configuration - Address Translation
The following examples illustrates the IGMP rules needed to configure IGMP according to the
Address Translation scenario described above in Section 4.7.2.2, “Multicast Forwarding - Address
Translation Scenario”. We need two IGMP report rules, one for each client interface. The interface
if1 uses no address translation and if2 translates the multicast group to 237.192.10.0/24. We also
need two query rules, one for the translated address and interface, and one for the original
address towards if1.
Two examples are provided, one for each pair of report and query rule. The upstream multicast
router uses IP UpstreamRouterIP.
Example 4.18. if1 Configuration
The following steps needs to be executed to create the report and query rule pair for if1 which
uses no address translation.
InControl
Follow the same steps used for the Web Interface below.
Web Interface
A. Create the first IGMP Rule:
1.
Go to: Network > Routing > IGMP Rules > Add > IGMP Rule
2.
Under General enter:
3.
4.
•
Name: A suitable name for the rule, for example Reports_if1
•
Type: Report
•
Action: Proxy
•
Output: wan (this is the relay interface)
Under Address Filter enter:
•
Source Interface: if1
•
Source Network: if1net
•
Destination Interface: core
•
Destination Network: auto
•
Multicast Source: 192.168.10.1
•
Multicast Group: 239.192.10.0/24
Click OK
B. Create the second IGMP Rule:
1.
Again, go to: Network > Routing > IGMP Rules > Add > IGMP Rule
314
Chapter 4: Routing
2.
3.
4.
Under General enter:
•
Name: A suitable name for the rule, for example Queries_if1
•
Type: Query
•
Action: Proxy
•
Output: if1 (this is the relay interface)
Under Address Filter enter:
•
Source Interface: wan
•
Source Network: UpstreamRouterIp
•
Destination Interface: core
•
Destination Network: auto
•
Multicast Source: 192.168.10.1
•
Multicast Group: 239.192.10.0/24
Click OK
Example 4.19. if2 Configuration - Group Translation
The following steps needs to be executed to create the report and query rule pair for if2 which
translates the multicast group. Note that the group translated therefore the IGMP reports include
the translated IP addresses and the queries will contain the original IP addresses
InControl
Follow the same steps used for the Web Interface below.
Web Interface
A. Create the first IGMP Rule:
1.
Go to: Network > Routing > IGMP Rules > Add > IGMP Rule
2.
Under General enter:
3.
•
Name: A suitable name for the rule, for example Reports_if2
•
Type: Report
•
Action: Proxy
•
Output: wan (this is the relay interface)
Under Address Filter enter:
•
Source Interface: if2
•
Source Network: if2net
315
Chapter 4: Routing
4.
•
Destination Interface: core
•
Destination Network: auto
•
Multicast Source: 192.168.10.1
•
Multicast Group: 239.192.10.0/24
Click OK
B. Create the second IGMP Rule:
1.
Again, go to: Network > Routing > IGMP Rules > Add > IGMP Rule
2.
Under General enter:
3.
4.
•
Name: A suitable name for the rule, for example Queries_if2
•
Type: Query
•
Action: Proxy
•
Output: if2 (this is the relay interface)
Under Address Filter enter:
•
Source Interface: wan
•
Source Network: UpstreamRouterIp
•
Destination Interface: core
•
Destination Network: auto
•
Multicast Source: 192.168.10.1
•
Multicast Group: 239.192.10.0/24
Click OK
Advanced IGMP Settings
There are a number of IGMP advanced settings which are global and apply to all
interfaces which do not have IGMP settings explicitly specified for them.
4.7.4. Advanced IGMP Settings
The following advanced settings for IGMP can be found in the Web Interface by going to:
Network > Routing > Advanced Multicast Settings
Auto Add Multicast Core Route
This setting will automatically add core routes in all routing tables for the multicast IP address
range 224.0.0.0/4. If the setting is disabled, multicast packets might be forwarded according to
316
Chapter 4: Routing
the default route.
Default: Enabled
IGMP Before Rules
For IGMP traffic, by-pass the normal IP rule set and consult the IGMP rule set.
Default: Enabled
IGMP React To Own Queries
The security gateway should always respond with IGMP Membership Reports, even to queries
originating from itself. Global setting on interfaces without an overriding IGMP Setting.
Default: Disabled
IGMP Lowest Compatible Version
IGMP messages with a version lower than this will be logged and ignored. Global setting on
interfaces without an overriding IGMP Setting.
Default: IGMPv1
IGMP Router Version
The IGMP protocol version that will be globally used on interfaces without a configured IGMP
Setting. Multiple querying IGMP routers on the same network must use the same IGMP version.
Global setting on interfaces without an overriding IGMP Setting.
Default: IGMPv3
IGMP Last Member Query Interval
The maximum time in milliseconds until a host has to send an answer to a group or
group-and-source specific query. Global setting on interfaces without an overriding IGMP
Setting.
Default: 5,000
IGMP Max Total Requests
The maximum global number of IGMP messages to process each second.
Default: 1000
IGMP Max Interface Requests
The maximum number of requests per interface and second. Global setting on interfaces without
an overriding IGMP Setting.
Default: 100
IGMP Query Interval
317
Chapter 4: Routing
The interval in milliseconds between General Queries sent by the device to refresh its IGMP state.
Global setting on interfaces without an overriding IGMP Setting.
Default: 125,000
IGMP Query Response Interval
The maximum time in milliseconds until a host has to send a reply to a query. Global setting on
interfaces without an overriding IGMP Setting.
Default: 10,000
IGMP Robustness Variable
IGMP is robust to (IGMP Robustness Variable - 1) packet losses. Global setting on interfaces
without an overriding IGMP Setting.
Default: 2
IGMP Startup Query Count
The security gateway will send IGMP Startup Query Count general queries with an interval of
IGMPStartupQueryInterval at startup. Global setting on interfaces without an overriding IGMP
Setting.
Default: 2
IGMP Startup Query Interval
The interval of General Queries in milliseconds used during the startup phase. Global setting on
interfaces without an overriding IGMP Setting.
Default: 30,000
IGMP Unsolicitated Report Interval
The time in milliseconds between repetitions of an initial membership report. Global setting on
interfaces without an overriding IGMP Setting.
Default: 1,000
318
Chapter 4: Routing
4.8. Transparent Mode
4.8.1. Overview
Transparent Mode Usage
The cOS Core Transparent Mode feature allows a Clavister Security Gateway to be placed at a
point in a network without any reconfiguration of the network and without hosts being aware of
its presence. All cOS Core features can then be used to monitor and manage traffic flowing
through that point. cOS Core can allow or deny access to different types of services (for example
HTTP) and in specified directions. As long as users are accessing the services permitted, they will
not be aware of the Clavister Security Gateway's presence.
Network security and control can therefore be significantly enhanced with deployment of a
Clavister Security Gateway operating in transparent mode but while disturbance to existing users
and hosts is minimized.
Switch Routes
Transparent mode is enabled by specifying a Switch Route instead of a standard Route in routing
tables. The switch route usually specifies that the network all-nets is found on a specific interface.
cOS Core then uses ARP message exchanges over the connected Ethernet network to identify
and keep track of which host IP addresses are located on that interface (this is explained further
below). There should not be a normal non-switch route for that same interface.
In certain, less usual circumstances, switch routes can have a network range specified instead of
all-nets. This is usually when a network is split between two interfaces but the administrator does
not know exactly which users are on which interface.
Usage Scenarios
Two examples of transparent mode usage are:
•
Implementing Security Between Users
In a corporate environment, there may be a need to protect the computing resources of
different departments from one another. The finance department might require access to
only a restricted set of services (HTTP for example) on the sales department's servers whilst
the sales department might require access to a similarly restricted set of applications on the
finance department's hosts. By deploying a single Clavister Security Gateway between the
two department's physical networks, transparent but controlled access can be achieved.
•
Controlling Internet Access
An organization allows traffic between the external Internet and a range of public IPv4
addresses on an internal network. Transparent mode can control what kind of service is
permitted to these IP addresses and in what direction. For instance the only services
permitted in such a situation may be HTTP access out to the Internet. This usage is dealt with
in greater depth below in Section 4.8.2, “Enabling Internet Access”.
Comparison with Routing Mode
The Clavister Security Gateway can be regarded as operating in either of two modes:
319
Chapter 4: Routing
•
Routing Mode using non-switch routes.
•
Transparent Mode using switch routes.
With non-switch routes, the Clavister Security Gateway acts as a router and routing operates at
layer 3 of the OSI model. If the security gateway is placed into a network for the first time, or if
network topology changes, the routing configuration must therefore be checked and adjusted
to ensure that the routing table is consistent with the new layout. Reconfiguration of IP settings
may be required for pre-existing routers and protected servers. This works well when
comprehensive control over routing is desired.
With switch routes, the Clavister Security Gateway operates in transparent mode and resembles
a OSI Layer 2 Switch in that it screens IP packets and forwards them transparently to the correct
interface without modifying any of the source or destination information at the IP or Ethernet
levels. This is achieved by cOS Core keeping track of the MAC addresses of the connected hosts
and cOS Core allows physical Ethernet networks on either side of the Clavister Security Gateway
to act as though they were a single logical IP network. (See Appendix D, The OSI Framework for an
overview of the OSI layer model.)
Two benefits of transparent mode over conventional routing are:
•
A user can move from one interface to another in a "plug-n-play" fashion, without changing
their IP address (assuming their IP address is fixed). The user can still obtain the same services
as before (for example HTTP, FTP) without any need to change routes.
•
The same network address range can exist on several interfaces.
Note: Transparent and Routing Mode can be combined
Transparent mode and routing mode can operate together on a single Clavister Security
Gateway. Switch Routes can be defined alongside standard non-switch routes although
the two types cannot be combined for the same interface. An interface operates in one
mode or the other.
It is also possible to create a hybrid case by applying address translation on otherwise
transparent traffic.
How Transparent Mode Functions
In transparent mode, cOS Core allows ARP transactions to pass through the Clavister Security
Gateway, and determines from this ARP traffic the relationship between IP addresses, physical
addresses and interfaces. cOS Core remembers this address information in order to relay IP
packets to the correct receiver. During the ARP transactions, neither of the endpoints will be
aware of the Clavister Security Gateway.
When beginning communication, a host will locate the target host's physical address by
broadcasting an ARP request. This request is intercepted by cOS Core and it sets up an internal
ARP Transaction State entry and broadcasts the ARP request to all the other switch-route
interfaces except the interface the ARP request was received on. If cOS Core receives an ARP
reply from the destination within a configurable timeout period, it will relay the reply back to the
sender of the request, using the information previously stored in the ARP Transaction State entry.
During the ARP transaction, cOS Core learns the source address information for both ends from
the request and reply. cOS Core maintains two tables to store this information: the Content
Addressable Memory (CAM) and Layer 3 Cache. The CAM table tracks the MAC addresses
available on a given interface and the Layer 3 cache maps an IP address to MAC address and
320
Chapter 4: Routing
interface. As the Layer 3 Cache is only used for IP traffic, Layer 3 Cache entries are stored as single
host entries in the routing table.
For each IP packet that passes through the Clavister Security Gateway, a route lookup for the
destination is done. If the route of the packet matches a Switch Route or a Layer 3 Cache entry in
the routing table, cOS Core knows that it should handle this packet in a transparent manner. If a
destination interface and MAC address is available in the route, cOS Core has the necessary
information to forward the packet to the destination. If the route was a Switch Route, no specific
information about the destination is available and the security gateway will have to discover
where the destination is located in the network.
Discovery is done by cOS Core sending out ARP as well as ICMP (ping) requests, acting as the
initiating sender of the original IP packet for the destination on the interfaces specified in the
Switch Route. If an ARP reply is received, cOS Core will update the CAM table and Layer 3 Cache
and forward the packet to the destination.
If the CAM table or the Layer 3 Cache is full, the tables are partially flushed automatically. Using
the discovery mechanism of sending ARP and ICMP requests, cOS Core will rediscover
destinations that may have been flushed.
Enabling Transparent Mode
To enable cOS Core transparent mode, the following steps are required:
1.
The interfaces that are to be transparent should be first collected together into a single
Interface Group object. Interfaces in the group should be marked as Security transport
equivalent if hosts are to move freely between them.
2.
A Switch Route is now created in the appropriate routing table and the interface group
associated with it. Any existing non-switch routes for interfaces in the group should be
removed from the routing table.
For the Network parameter in the switch route, specify all-nets or alternatively, specify a
network or range of IP addresses that will be transparent between the interfaces (this latter
option is discussed further below).
3.
Create the appropriate IP rules in the IP rule set to allow the desired traffic to flow between
the interfaces operating in transparent mode.
If no restriction at all is to be initially placed on traffic flowing in transparent mode, the
following single IP rule could be added but more restrictive IP rules are recommended.
Action
Src Interface
Src Network
Dest Interface
Dest Network
Service
Allow
any
all-nets
any
all-nets
all_services
Restricting the Network Parameter
As cOS Core listens to ARP traffic, it continuously adds single host routes to the routing table as it
discovers on which interface IP addresses are located. As the name suggests, single host routes
give a route for a single IP address. The number of these routes can therefore become large as
connections are made to more and more hosts.
A key advantage of specifying a network or a range of IP addresses instead of all-nets for the
Network parameter is that the number of routes automatically generated by cOS Core will be
significantly smaller. A single host route will only be added if the IP address falls within the
network or address specified. Reducing the number of routes added will reduce the processing
overhead of route lookups.
321
Chapter 4: Routing
Specifying a network or address range is, of course, only possible if the administrator has some
knowledge of the network topology and often this may not be the case.
Multiple Switch Routes are Connected Together
The setup steps listed above describe placing all the interfaces into a single interface group
object which is associated with a single switch route.
An alternative to one switch route is to not use an interface group but instead use an individual
switch route for each interface. The end result is the same. All the switch routes defined in a
single routing table will be connected together by cOS Core and no matter how interfaces are
associated with the switch routes, transparency will exist between them.
For example, if the interfaces if1 to if6 appear in a switch routes in routing table A, the resulting
interconnections will be as illustrated below.
Connecting together switch routes in this way only applies, however, if all interfaces are
associated with the same routing table. The situation where they are not, is described next.
Creating Separate Transparent Mode Networks
If we now have two routing tables A and B so that interfaces if1, if2 and if3 appear in a switch
route in table A and interfaces if4, if5, if6 appear in a swit">