Wind River Firewall and NAT for VxWorks 6 User's Guide,...

Wind RiverFirewall and NAT

for VxWorks 6

USER'S GUIDE

®

6.6

®

Wind River Firewall and NAT for VxWorks 6 User's Guide, 6.6

Copyright © 2007 Wind River Systems, Inc.

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means without the prior written permission of Wind River Systems, Inc.

Wind River, Tornado, and VxWorks are registered trademarks of Wind River Systems, Inc. The Wind River logo is a trademark of Wind River Systems, Inc. Any third-party trademarks referenced are the property of their respective owners. For further information regarding Wind River trademarks, please see:

http://www.windriver.com/company/terms/trademark.html

This product may include software licensed to Wind River by third parties. Relevant notices (if any) are provided in your product installation at the following location: installDir/product_name/3rd_party_licensor_notice.pdf.

Wind River may refer to third-party documentation by listing publications or providing links to third-party Web sites for informational purposes. Wind River accepts no responsibility for the information provided in such third-party documentation.

Corporate HeadquartersWind River Systems, Inc.500 Wind River WayAlameda, CA 94501-1153U.S.A.

toll free (U.S.): (800) 545-WINDtelephone: (510) 748-4100facsimile: (510) 749-2010

For additional contact information, please visit the Wind River URL:

http://www.windriver.com

For information on how to contact Customer Support, please visit the following URL:

http://www.windriver.com/support


6 Nov 07 Part #: DOC-16133-ND-00

http://www.windriver.com/company/terms/trademark.html

http://www.windriver.com

http://www.windriver.com/support

iii

Contents

PART I: WIND RIVER FIREWALL

1 Overview of Wind River Firewall ......................................................... 3

1.1 Introduction ............................................................................................................. 3

About the Addresses Used in Examples ............................................... 3

1.2 Product Overview ................................................................................................... 4

General Purpose Features ....................................................................... 4IP Filter Features ....................................................................................... 5MAC Filter Features ................................................................................. 5Filter Actions ............................................................................................. 6Extensions .................................................................................................. 6HTTP Filtering .......................................................................................... 6Sample Firewall Rules ............................................................................. 6Management Features ............................................................................. 7Configuration Interfaces ......................................................................... 7Network Address Translation ................................................................ 7

1.3 Additional Documentation .................................................................................. 7

Wind River Documentation .................................................................... 8Online Resources ...................................................................................... 8Books .......................................................................................................... 9RFCs ........................................................................................................... 9

Wind River Firewall and NAT for VxWorks 6User's Guide, 6.6

iv

2 Configuring and Building Wind River Firewall ................................. 11

2.1 Introduction ............................................................................................................. 11

2.2 Configuring and Building Wind River Firewall .............................................. 12

2.3 Configuring VxWorks with Wind River Firewall ........................................... 12

2.3.1 Components and Parameters ................................................................. 12

Required Components ............................................................................. 12

2.3.2 Wind River Firewall and Symmetric Multiprocessing ....................... 13

2.3.3 Configuring Wind River Firewall to Run on a Gateway .................... 13

Checking for VxBus Support .................................................................. 14Adding a Network Interface—Legacy END Drivers .......................... 14Configuring an Additional Interface ..................................................... 15

2.3.4 Excluding Firewall Components ........................................................... 17

2.3.5 Adding a Hook for Firewall Rules ......................................................... 17

2.4 Building the VxWorks Image ............................................................................... 18

2.5 Booting the Target and Testing Wind River Firewall ..................................... 18

3 Firewall Tutorial .................................................................................... 19

3.1 Introduction ............................................................................................................. 19

3.2 Network Configuration ......................................................................................... 20

3.3 Creating a Simple Firewall ................................................................................... 21

3.3.1 Security Policy .......................................................................................... 22

3.3.2 Writing Rules ............................................................................................ 22

Complete Code—Simple Firewall ......................................................... 23

3.3.3 Testing the Firewall .................................................................................. 24

3.4 Creating a Home/SOHO Gateway Firewall ...................................................... 25

3.4.1 Security Policy .......................................................................................... 26

3.4.2 Writing Rules ............................................................................................ 26

Contents

v

Complete Code—Home/SOHO Gateway Firewall ............................ 28

3.4.3 Testing the Firewall ................................................................................. 29

4 Firewall Fundamentals ........................................................................ 31

4.1 Introduction ............................................................................................................. 32

4.2 Firewall Operation ................................................................................................. 32

4.3 Elements of a Firewall Rule ................................................................................. 34

4.3.1 Action to Be Taken ................................................................................... 34

4.3.2 Address Scope .......................................................................................... 34

4.3.3 Interface ..................................................................................................... 34

4.4 Methods for Writing Rules ................................................................................... 35

4.4.1 Using a Rule File ....................................................................................... 35

4.4.2 Using the API ............................................................................................ 36

4.4.3 Using a Shell Command .......................................................................... 36

4.5 Rules and Rule Groups ......................................................................................... 36

4.5.1 How Packets Are Matched against Rules ............................................. 37

4.6 Rate Limiting ........................................................................................................... 38

4.7 Logging ..................................................................................................................... 39

4.7.1 Log Formats .............................................................................................. 40

IP Filter Logs ............................................................................................. 40MAC Filter Logs ....................................................................................... 40

4.7.2 Logging Traffic ......................................................................................... 41

Viewing the Firewall Log ........................................................................ 41Clearing the Firewall Log ........................................................................ 42Adjusting Log Capacity .......................................................................... 42

4.8 Enabling and Disabling the Firewall ................................................................. 42


vi

4.9 Adding and Removing Firewall Rules ............................................................... 42

4.9.1 Adding Rules ............................................................................................ 43

Adding Rules from a File ........................................................................ 43Specifying the Rule Position ................................................................... 44Inserting a Rule within a Group ............................................................ 44

4.9.2 Removing Rules ........................................................................................ 45

4.9.3 Checking Rule Syntax .............................................................................. 45

4.10 Saving and Restoring Firewall Rules ................................................................. 45

4.11 Viewing and Clearing Firewall Information .................................................... 46

4.11.1 Viewing and Clearing Firewall Statistics .............................................. 46

4.11.2 Viewing and Clearing Firewall Tables .................................................. 48

Rule Table .................................................................................................. 48State Table ................................................................................................. 49Log Table ................................................................................................... 49Custom Routines Table ........................................................................... 49Group Rule Table ..................................................................................... 50

5 Creating an IP Filter ............................................................................. 51

5.1 Introduction ............................................................................................................. 51

5.2 Methods for Filtering ............................................................................................. 52

5.2.1 Filtering by Address ................................................................................ 52

IP Filter Address Scope ........................................................................... 52

5.2.2 Filtering by Type of Service or Traffic Class ........................................ 53

5.2.3 Filtering by Time to Live ......................................................................... 53

5.2.4 Filtering by Protocol ................................................................................ 53

Filtering by ICMP Type and Code ......................................................... 54Filtering by Port for UDP and TCP Protocols ...................................... 54Filtering by TCP Flags ............................................................................. 54Filtering by IP Options and Fragments ................................................. 55

Contents

vii

5.3 Stateful Inspection ................................................................................................. 56

5.3.1 Configuring Stateful Inspection ............................................................. 56

5.4 Responding to Blocked Packets .......................................................................... 57

Sending a Reset Segment (TCP Only) ................................................... 57Sending a Destination Unreachable Message (ICMP Only) .............. 57

6 Creating a MAC Filter ........................................................................... 59

6.1 Introduction ............................................................................................................. 59

6.2 Methods for Filtering ............................................................................................. 60

6.2.1 Filtering by Address ................................................................................ 60

6.2.2 Filtering by Interface ................................................................................ 60

6.2.3 Filtering by Frame Type .......................................................................... 61

7 Defining Custom Routines .................................................................. 63

7.1 Introduction ............................................................................................................. 63

7.2 Elements of a Custom Routine ............................................................................ 64

7.3 Viewing Custom Routines ................................................................................... 65

8 Filtering HTTP Content ........................................................................ 67

8.1 Introduction ............................................................................................................. 67

8.2 Enabling HTTP Content Filtering ....................................................................... 68

8.3 Filtering Content by URL ..................................................................................... 69

8.3.1 Understanding the URL Filter Mechanism .......................................... 69

8.3.2 Implementing a URL Filter ..................................................................... 70

8.4 Filtering Proxy Traffic ........................................................................................... 70

8.4.1 Understanding the Proxy Filter ............................................................. 70

8.4.2 Implementing Proxy Filtering ................................................................ 71


viii

8.5 Filtering Java Applets ............................................................................................ 71

8.5.1 Understanding the Java Applet Filter ................................................... 71

8.5.2 Implementing a Java Applet Filter ........................................................ 71

8.6 Filtering ActiveX Controls .................................................................................... 71

8.6.1 Understanding the ActiveX Filter .......................................................... 71

8.6.2 Implementing an ActiveX Filter ............................................................. 72

8.7 Filtering Cookies .................................................................................................... 72

8.7.1 Understanding the Cookie Filter ............................................................ 72

8.7.2 Implementing a Cookie Filter ................................................................. 72

8.8 Program Example .................................................................................................... 73

PART II: WIND RIVER NAT

9 Overview of Wind River NAT ............................................................... 77

9.1 Introduction ............................................................................................................. 77

About the Addresses Used in Examples ............................................... 78

9.2 Product Overview ................................................................................................... 78

Basic NAT .................................................................................................. 79NAPT ......................................................................................................... 79Bidirectional NAT .................................................................................... 79NAT-PT ...................................................................................................... 80NAPT-PT ................................................................................................... 80DMZ Host .................................................................................................. 80NAT-T ........................................................................................................ 80Application-Level Gateways .................................................................. 81Configuration Interfaces .......................................................................... 82

9.3 Additional Documentation ................................................................................... 82

Wind River Documentation .................................................................... 82Books .......................................................................................................... 83RFCs ........................................................................................................... 83

Contents

ix

10 Configuring and Building Wind River NAT ........................................ 85

10.1 Introduction ............................................................................................................. 85

10.2 Configuring and Building Wind River NAT .................................................... 85

10.3 Configuring VxWorks with Wind River NAT ................................................. 86

10.3.1 Components and Parameters ................................................................. 86

Required Components ............................................................................. 86

10.3.2 Wind River NAT and Symmetric Multiprocessing ............................. 87

10.3.3 Configuring Wind River NAT to Run on a Gateway ......................... 87

Checking for VxBus Support .................................................................. 87Adding a Network Interface—Legacy END Drivers .......................... 88Configuring an Additional Interface ..................................................... 88

10.3.4 Excluding NAT Components ................................................................. 90

10.3.5 Adding a Hook for NAT Rules .............................................................. 91

10.4 Building the VxWorks Image .............................................................................. 91

10.5 Booting the Target and Testing Wind River NAT ........................................... 92

11 NAT Tutorial .......................................................................................... 93

11.1 Introduction ............................................................................................................. 93

11.2 Network Configuration ......................................................................................... 94

11.3 Implementing NAT ................................................................................................ 95

11.3.1 NAT Rules ................................................................................................. 96

11.3.2 Writing Rules ............................................................................................ 96

Complete NAT Code ............................................................................... 97

11.3.3 Testing the NAT Implementation .......................................................... 98


x

12 NAT Fundamentals .............................................................................. 101

12.1 Introduction ............................................................................................................. 102

12.2 NAT Operation ....................................................................................................... 102

12.2.1 Outbound Packets .................................................................................... 102

NAT and NAPT Operation ..................................................................... 103NAT-PT and NAPT-PT Operation ........................................................ 103Handling of Fragments ........................................................................... 104

12.2.2 Inbound Packets ....................................................................................... 104

DMZ Host .................................................................................................. 105

12.3 Elements of a NAT Rule ........................................................................................ 105

12.4 Methods for Writing Rules ................................................................................... 106

12.4.1 Using a Rule File ....................................................................................... 106

12.4.2 Using the API ............................................................................................ 107

12.4.3 Using a Shell Command .......................................................................... 107

12.5 Configuring Basic NAT ......................................................................................... 107

12.5.1 Basic NAT Limitations ............................................................................. 107

12.5.2 Mapping between Address Blocks ........................................................ 108

12.6 Configuring NAPT ................................................................................................. 108

12.7 Configuring Bidirectional NAT .......................................................................... 109

12.8 Configuring NAT-PT ............................................................................................. 110

12.9 Configuring NAPT-PT .......................................................................................... 111

12.10 Sample Rule Set—Simple NAT Router ............................................................. 111

12.11 Configuring a DMZ Host ...................................................................................... 111

12.12 Enabling and Disabling NAT .............................................................................. 112

Contents

xi

12.13 Adding and Removing NAT Rules ..................................................................... 112

Adding Rules ............................................................................................ 113Specifying the Rule Position ................................................................... 113Removing Rules ........................................................................................ 114Clearing Active Mappings ...................................................................... 114Checking Rule Syntax .............................................................................. 114

12.14 Saving and Restoring NAT Rules ....................................................................... 115

12.15 Viewing NAT Information ................................................................................... 115

12.15.1 Viewing Rules and Active Mappings ................................................... 115

12.15.2 Viewing and Clearing NAT Statistics ................................................... 116

13 Application-Level Gateways ............................................................... 117

13.1 Introduction ............................................................................................................. 118

13.1.1 API for Integrating a Custom ALG with Wind River NAT ............... 118

13.2 Configuring ALG Support ................................................................................... 118

13.3 ICMP ALG Operation ........................................................................................... 121

13.4 DNS ALG Operation ............................................................................................. 121

13.5 FTP ALG Operation ............................................................................................... 122

13.6 H.323 ALG Operation ............................................................................................ 123

H.225 .......................................................................................................... 123H.245 .......................................................................................................... 124

13.7 IPsec Passthrough ALG Operation ..................................................................... 125

13.8 PTTP Passthrough ALG Operation .................................................................... 125

13.9 Port Triggering ........................................................................................................ 126

13.10 Writing a Custom ALG .......................................................................................... 127

13.10.1 Adding Your ALG .................................................................................... 127

13.10.2 Adding the NAT Rule ............................................................................. 128


xii

13.10.3 Writing the ALG Routine ........................................................................ 128

Routines Available for ALGs .................................................................. 131

13.11 Sample Rule Sets with ALG Support ................................................................. 132

NAT Router with ALG Support ............................................................. 132NAT Router with ALG Support and DMZ Host ................................. 132NAT-PT Router with ALG Support ...................................................... 133

PART III: APPENDICES

A Wind River Firewall Keywords ........................................................... 137

A.1 Introduction ............................................................................................................. 137

A.2 Syntax ........................................................................................................................ 137

A.2.1 IP Filter Rule Syntax ................................................................................ 137

IP Filter Address Scope ........................................................................... 138

A.2.2 MAC Filter Rule Syntax ........................................................................... 138

MAC Filter Address Scope ..................................................................... 138

A.3 Keywords ................................................................................................................. 138

! .................................................................................................................... 138# ................................................................................................................... 138all ................................................................................................................ 139any .............................................................................................................. 139block ........................................................................................................... 139burst ............................................................................................................ 139first .............................................................................................................. 140flags ............................................................................................................ 140frag .............................................................................................................. 141from ............................................................................................................ 141group .......................................................................................................... 142head ............................................................................................................ 142icmp-type ................................................................................................... 142in ................................................................................................................. 143ipopts .......................................................................................................... 143keep state ................................................................................................... 143limit ............................................................................................................ 144

Contents

xiii

log ............................................................................................................... 144mac-type .................................................................................................... 145me ............................................................................................................... 145on ................................................................................................................ 145out ............................................................................................................... 146no ................................................................................................................ 146pass ............................................................................................................. 146port ............................................................................................................. 147proto ........................................................................................................... 148quick ........................................................................................................... 148return-icmp ............................................................................................... 148return-icmp-as-dest .................................................................................. 150return-rst .................................................................................................... 151to ................................................................................................................. 151tos ............................................................................................................... 151ttl ................................................................................................................. 152with ............................................................................................................. 152

B Wind River Firewall Libraries .............................................................. 153

C Wind River Firewall Routines .............................................................. 155

D Wind River Firewall Shell Command ................................................. 171

ipf ................................................................................................................ 171

E Wind River NAT Keywords ................................................................. 175

E.1 Introduction ............................................................................................................. 175

E.2 Syntax ....................................................................................................................... 175

E.2.1 NAT Rule Syntax ...................................................................................... 175

E.2.2 NAT Redirect Rule Syntax ...................................................................... 176

E.3 Keywords ................................................................................................................. 176

-> ................................................................................................................. 176# ................................................................................................................... 176icmpidmap ................................................................................................ 176map ............................................................................................................. 177map-block .................................................................................................. 177


xiv

nonapt ........................................................................................................ 178port ............................................................................................................. 178portmap ..................................................................................................... 178proxy .......................................................................................................... 179pt ................................................................................................................. 180pt-block ...................................................................................................... 180rdr ............................................................................................................... 181to ................................................................................................................. 182

F Wind River NAT Libraries .................................................................... 183

G Wind River NAT Routines .................................................................... 185

H Wind River NAT Shell Command ....................................................... 195

nat ............................................................................................................... 195

Index .............................................................................................................. 197

1

PART I

Wind River Firewall

1 Overview of Wind River Firewall ....................... 3

2 Configuring and Building Wind River Firewall 11

3 Firewall Tutorial .................................................. 19

4 Firewall Fundamentals ....................................... 31

5 Creating an IP Filter ........................................... 51

6 Creating a MAC Filter ......................................... 59

7 Defining Custom Routines ................................ 63

8 Filtering HTTP Content ...................................... 67


2

3

1Overview of

Wind River Firewall

1.1 Introduction 3

1.2 Product Overview 4

1.3 Additional Documentation 7

1.1 Introduction

Wind River Firewall is based on a rule syntax compatible with IP Filter, the firewall filter package delivered with the NetBSD, FreeBSD, and OpenBSD operating systems. You can develop firewall rules using a simple keyword syntax and add those rules to the firewall with the Wind River Firewall application programming interface (API) or the ipf shell command.

About the Addresses Used in Examples

According to RFC 1918, the Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IPv4 address space for private internets:

■ 10.0.0.0 - 10.255.255.255 (10/8 prefix)

■ 172.16.0.0 - 172.31.255.255 (172.16/12 prefix)

■ 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)


4

These address spaces are also useful in networking examples, which need to function but also need to avoid public Internet addresses.

In this book, the 10/8 prefix, the largest of the three private address spaces, represents the public Internet. To represent a private address space, this book uses the 192.168/16 prefix.

1.2 Product Overview

Wind River Firewall provides the following features:

■ IP filtering with stateful inspection for IPv4 or IPv6 packets

■ MAC (media access control) filtering

■ logging at the network (L3) and data link (L2) layers

■ HTTP content filtering for URLs (both specific and by keyword), proxy traffic, Java applets, ActiveX controls, and cookies

■ nonvolatile (NV) storage of firewall rules

IP filtering, MAC filtering, and logging are independent of each other. For example, you can install the IP filter, the MAC filter, or both. NV storage is implemented for both the IP and MAC filters.

General Purpose Features

Wind River Firewall has the following features:

■ input filter■ output filter■ stateful inspection ■ rate limiting■ filter on network interface■ rule grouping

Stateful Packet Inspection

IP packet filtering alone cannot determine which packets are unsolicited and which packets are expected responses to legitimate requests. Stateful inspection

1 Overview of Wind River Firewall1.2 Product Overview

5

1determines which packets belong to legitimate connections. You can limit the number of concurrent stateful connections that Wind River Firewall allows to be open.

Rate Limiting

Rate limiting lets you restrict the rate at which IP packets transit the firewall or their absolute quantity. You can also combine rate limiting with address filtering, limiting packets sent from a particular source address or going to a particular destination address. This feature helps defend against denial of service (DoS) flood attacks.

IP Filter Features

You can also write rules to filter IP packets based on the following conditions:

■ IPv4 addresses■ IPv6 addresses■ IP header length■ protocol type■ fragments■ port numbers■ TCP flags■ ICMP type and code■ type of service or traffic class■ IPv6 extension header■ time to live■ IP header length (IPv4 only)

MAC Filter Features

You can also write rules to filter MAC packets based on the following conditions:

■ network interface■ address■ frame type■ packet rate


6

Filter Actions

You can apply the following actions to filtered packets:

■ Reject the packet silently.■ Accept the packet silently.■ Log the packet. (See Logging, p.6, for further information.)■ Reject the packet and send back an ICMP message.■ Reject the packet and send back a TCP RESET packet.

■ Perform the action specified by your custom extension handler, including rejecting packets from specific hosts and URLs.

Logging

Logging allows a packet that matches a filtering rule to be logged. Logged information is stored in memory and can be retrieved for display on the console.

Extensions

You can provide an extension handler and an HTTP handler.

HTTP Filtering

You can perform HTTP content filtering to perform the following actions:

■ Block access to Web sites based on specific URLs or URLs containing specific keywords.

■ Block access to proxy servers that may circumvent the firewall’s content filtering.

■ Block Java applets, ActiveX controls, and cookies.

Sample Firewall Rules

Sample firewall rules for a typical Home/SOHO (small office/home office) gateway are provided. For more information, see 3.4 Creating a Home/SOHO Gateway Firewall, p.25.

1 Overview of Wind River Firewall1.3 Additional Documentation

7

1Management Features

Wind River Firewall provides the following management features:

■ logging to memory■ nonvolatile (NV) storage to file system

NV Storage

The firewall can save and restore filter rules. NV storage is supported in the file system only.

Configuration Interfaces

Wind River Firewall provides the following configuration interfaces:

■ APIs■ shell command

API Library and Shell Command

The public API library contains utilities for IP filtering, MAC filtering, and logging. These routines are useful for testing and debugging. The ipf shell command provides access to the same functionality.

Network Address Translation

This functionality is described in Part IIWind River NAT, p.75.

1.3 Additional Documentation

The Wind River Firewall part of this manual focuses on configuring and using Wind River Firewall. Although the manual includes some general information about firewalls, it does not provide an exhaustive general discussion of firewall technology.

NOTE: Wind River Firewall does not support the use of virtual stacks.


8

The following sections describe additional documentation about the technologies described in this book.

Wind River Documentation

The following Wind River documents present information associated with Wind River Firewall:

■ Wind River VxWorks Platforms Getting Started—describes how to install and build components of the Wind River VxWorks Platforms product.

■ Wind River VxWorks Platforms Release Notes—describes reported and resolved software defects and new features for the Wind River VxWorks Platforms product.

■ VxWorks Kernel Programmer’s Guide

■ VxWorks Application Programmer’s Guide

■ VxWorks Command-Line Tools User’s Guide

■ Wind River Workbench User’s Guide

Online Resources

■ Conoboy, B. and Fichtner, E. IP Filter Based Firewalls HOWTO, December, 2002. Accessible from:

http://www.obfuscation.org/ipf/ipf-howto.pdf

■ Curtin, M. and Ranum, M.J. Internet Firewalls: Frequently Asked Questions, Revision 10, December, 2000.Accessible from:

http://www.interhack.net/pubs/fwfaq

■ Packet Filtering for Firewall Systems, Carnegie Mellon University, 1999.Accessible from:

http://www.cert.org/tech_tips/packet_filtering.html

■ The Firewall Newsgroup, comp.security.firewalls. Accessible from:

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&group=comp.security.firewalls

http://www.obfuscation.org/ipf/ipf-howto.pdf

http://www.interhack.net/pubs/fwfaq

http://www.cert.org/tech_tips/packet_filtering.html



1 Overview of Wind River Firewall1.3 Additional Documentation

9

1Books

■ Stevens, W.R. TCP/IP Illustrated, Volume 1: The Protocols. ISBN-10: 0-201-63346-9. Reading, Massachusetts: Addison-Wesley, 1994.

■ Cheswick, W.R. and Bellovin, S.M. Firewalls and Internet Security: Repelling the Wily Hacker. ISBN 0-201-63357-4. Reading, Massachusetts: Addison-Wesley, 1994.

■ Zwicky, E.D., Cooper, S. and Chapman, D.B. Building Internet Firewalls, Second Edition. ISBN 1-56592-871-7. Sebastopol, California: O’Reilly and Associates, 2000.

RFCs

■ RFC 1918, Address Allocation for Private Internets. February 1996, Moskowitz, B., Karrenberg, D., de Groot, G. J., Lear, E. See:

http://www.ietf.org/rfc/rfc1918.txt

■ RFC 2196, Site Security Handbook. September 1997, Fraser, B. See:





10

11

2Configuring and Building

Wind River Firewall

2.1 Introduction 11

2.2 Configuring and Building Wind River Firewall 12

2.3 Configuring VxWorks with Wind River Firewall 12

2.4 Building the VxWorks Image 18

2.5 Booting the Target and Testing Wind River Firewall 18

2.1 Introduction

This chapter describes how to configure Wind River Firewall and include it in a VxWorks image, which can run on a target device to provide secure communications. You must perform these tasks before you define rules for a firewall.


12

2.2 Configuring and Building Wind River Firewall

Wind River Firewall is provided in source code and must be built before it can be used with a kernel application. It must be built as a static library for use in kernel mode.

Wind River Firewall is built as part of the top-level build for your Wind River Platform product. For information about this build, see the Wind River Platforms Getting Started. Wind River recommends that you use the output of this build. Once you have created the appropriate library, you can integrate it with your firewall application. See 2.3.5 Adding a Hook for Firewall Rules, p.17.

2.3 Configuring VxWorks with Wind River Firewall

2.3.1 Components and Parameters

Required Components

The components required for Wind River Firewall are the following:

IPF_IPV4_RULE_FILESpecifies the name of the default IPv4 IP filter rule file. The firewall will load the rules from this file if it exists at boot. Default is fw4.cfg.

IPF_IPV6_RULE_FILESpecifies the name of the default IPv6 IP filter rule file. The firewall will load the rules from this file if it exists at boot. Default is fw6.cfg.

IPF_FWMAC_RULE_FILESpecifies the name of the default MAC filter rule file. The firewall will load the rules from this file if it exists at boot. Default is fwmac.cfg.

IPF_ICMP_TIMEOUTSpecifies the timeout until an ICMP stateful mapping times out. Default is 60 seconds.

IPF_MAX_STATEFUL_MAPPINGSSpecifies the maximum number of stateful mappings the firewall is able to handle. Default is 1,000.

2 Configuring and Building Wind River Firewall2.3 Configuring VxWorks with Wind River Firewall

13

2

IPF_OTHER_TIMEOUTSpecifies the timeout until other stateful mappings time out. Default is 60 seconds.

IPF_TCP_TIMEOUTSpecifies the timeout until a TCP stateful mapping times out. Default is 432,000 seconds (5 days).

IPF_UDP_TIMEOUTSpecifies the timeout until a UDP stateful mapping times out. Default is 60 seconds.

2.3.2 Wind River Firewall and Symmetric Multiprocessing

If you build Wind River Firewall for use on a target configured with symmetric multiprocessing (SMP), the SMP capability of firewall is automatically enabled. The firewall hooks will run in parallel on multiple cores, resulting in improved performance.

For information on configuring VxWorks with SMP, see Wind River VxWorks Platforms Getting Started.

2.3.3 Configuring Wind River Firewall to Run on a Gateway

If you are building a router (gateway) that includes Wind River Firewall, you will need at least two network interfaces. The following sections describe how to add and configure those interfaces.

Which procedure you follow depends on whether your BSP supports VxBus. If it does, the system will automatically detect any additional drivers, and you only need to configure them. In such a case, perform only the procedure described in Configuring an Additional Interface, p.15.

! CAUTION: The firewall components are included by default. Excluding these components in Workbench also excludes other components required by the network stack. For instructions on safely excluding firewall, see 2.3.4 Excluding Firewall Components, p.17.


14

Checking for VxBus Support

You can tell whether your BSP supports VxBus by examining the following file:

target/config/bspName/config.h

If this file contains the line #define INCLUDE_VXBUS, it supports VxBus, and you do not need to perform a separate procedure to add a network interface.

If this file does not contain the line #define INCLUDE_VXBUS, you must edit the file to add the necessary interfaces. See Adding a Network Interface—Legacy END Drivers, p.14, for further information.

Adding a Network Interface—Legacy END Drivers

Perform this procedure only if your BSP does not support VxBus.

Before configuring , check whether your BSP supports a second interface. If not, you can add that support. To learn whether your BSP already supports a second interface and how to enable it, read the BSP reference page in the Workbench online help.

To add a network interface, you must edit target/config/bspName/configNet.h.

Each BSP requires specific edits to add support for an interface. The following example shows how to add support for an additional fei interface for the pcPentium BSP.

Example 2-1 Adding a Network Interface to a BSP (FEI Driver)

1. Locate the following lines:

#ifdef INCLUDE_FEI_END{ 0, FEI82557_LOAD_FUNC, FEI82557_LOAD_STRING, FEI82557_BUFF_LOAN,NULL, FALSE},

#endif /* INCLUDE_FEI_END */

2. Add the following line just before the #endif line:

{ 1, FEI82557_LOAD_FUNC, FEI82557_LOAD_STRING, FEI82557_BUFF_LOAN,NULL, FALSE},

3. If more than two interfaces are necessary, repeat step 2, incrementing the interface number for each additional interface.

4. Ensure that installDir/vxworks-6.x/target/config/bspName/config.h includes the following define:

#define INCLUDE_FEI_END


15

2

If you are using a different BSP or interface, read the BSP reference page in Workbench online help.

Configuring an Additional Interface

Once you have added a network interface, you must configure it with an IP address or network mask. You can configure the interface at build time or at run time.

Configuring an Additional Interface at Build Time

To configure an interface at build time, include an INCLUDE_IPNET_IFCONFIG_N component (one for each interface). Each of these components contains an IFCONFIG_N parameter.

For each IFCONFIG_N, edit the following fields:

ifnameSpecifies the name of the Ethernet interface, for example, ifname fei0. If the interface name is missing after ifname (the default setting), the END device name will be used.

devnameSpecifies the driver to which this interface should attach itself, for example, fei0. The default setting driver instructs VxWorks to retrieve the device name from the device boot parameters.

inetSpecifies the interface IPv4 address and subnet, for example, inet 10.1.2.100/24. Instead of IPv4 address, the following syntaxes can also be used:

inet driver (default)Specifies that the address and mask should be read from the BSP.

inet dhcpSpecifies that the address and mask should be received from a DHCP server. The gateway might also be received from that server (depending on the DHCP server configuration).

inet rarpSpecifies that the address and mask should be received from an RARP server.


16

gatewaySpecifies the default gateway used for IPv4, for example, gateway 10.1.2.1. Only one default gateway can be specified. gateway driver can be used to take the gateway from the boot parameters.

inet6Specifies the interface IPv6 address and subnet, for example, inet6 3ffe:1:2:3::4/64. The tentative keyword can be inserted before the address if the stack should perform duplicate address detection on the address before assigning it to the interface, for example, tentative 3ffe:1:2:3::4/64.

gateway6Specifies the default gateway used for IPv6. Only one default gateway can be specified.

Configuring an Additional Interface by Editing config.h

You can also configure an additional interface by editing the config.h file for your BSP—that is, target/config/bspName/config.h. In this case, specify the values for IFCONFIG_N directly in the file, using a #define statement. For example:

#define IFCONFIG_1 "ifname", "devname driver","inet driver","gateway driver", \ "inet6 3ffe:1:2:3::10/64"

Configuring an Additional Interface at Run Time

If you are not ready to configure the interface at build time, you can configure it at run time. This procedure consists of two steps:

1. Attaching a protocol.

2. Configuring the address and subnet mask.

To perform these steps, run an ipAttach shell command on the target, followed by an ifconfig. For example:

[vxWorks *] # ipAttach 1,"fei"[vxWorks *] # ifconfig "fei1 10.0.0.2 netmask 255.255.255.0 up"

The parameters for the ifconfig command are specified in Configuring an Additional Interface at Build Time, p.15.


17

2

2.3.4 Excluding Firewall Components

Wind River Firewall uses components that are also required by the network stack. Excluding firewall in Workbench can disable the network stack. To exclude firewall safely, you must modify a configuration file and rebuild your Platform.

To exclude the firewall, follow this procedure:

1. Locate the following file:

installDir/vxworks-6.x/config/platform/config.mk

2. Locate the following command within this file:

export COMPONENT_FIREWALL = true

3. Change the value for this component from true to false.

4. Save config.mk and close the file.

5. Rebuild your Platform.

2.3.5 Adding a Hook for Firewall Rules

If you plan to add firewall rules at startup by calling ipfirewall_add_rule( ), add a hook for those rules. To create this hook, add a USER_APPL_INIT macro in the BSP. For example:

#define INCLUDE_USER_APPL #define USER_APPL_INIT \{ \IMPORT void usrFwAddRules();\usrFwAddRules();\}

usrFwAddRules( ) is a sample routine only, which is not distributed with your Wind River Platform. You must create it (or a routine with a similar name) yourself.

NOTE: Some BSPs include sample definitions of INCLUDE_USER_APPL and USER_APPL_INIT. If so, remove those examples. Define INCLUDE_USER_APPL and USER_APPL_INIT only once.


18

2.4 Building the VxWorks Image

For information about building VxWorks with Wind River Firewall, including build options, image types, and so on, see the Wind River Workbench User’s Guide.

When you have finished building the image, verify that the firewall was included in the build. See 2.5 Booting the Target and Testing Wind River Firewall, p.18, for detailed instructions.

2.5 Booting the Target and Testing Wind River Firewall

1. Boot the target with your VxWorks image.

2. Verify that the firewall was included in the build by issuing the following shell command:

[vxWorks *] # ipf -V

The current version appears on the target shell.

NOTE: If you see an error message indicating undefined references to ipfirewall routines, you must rebuild your Platform. For instructions, see the getting started guide for your Platform.

NOTE: To run this command, you must switch to the command interpreter shell before running the ipf command. Type cmd at the command prompt. Then run the ipf command.

19

3Firewall Tutorial

3.1 Introduction 19

3.2 Network Configuration 20

3.3 Creating a Simple Firewall 21

3.4 Creating a Home/SOHO Gateway Firewall 25

3.1 Introduction

This chapter contains tutorials that will guide you through the creation of two projects:

■ Creating and building a simple firewall.

■ Creating and building a typical firewall for a home/SOHO gateway protecting a private network.

Both tutorials provide information on writing firewall rules and testing the firewall. Both tutorials also provide information on using Wind River Workbench to develop and deploy your firewall.


20

3.2 Network Configuration

The firewalls created in these tutorials are both designed to run on a simple network consisting of the following nodes:

■ a public host■ two private hosts ■ a gateway with two interfaces■ switches (optional)

Table 3-1 provides configuration information for each node.

If desired, this network can also be connected to a corporate LAN and, through that LAN, to the Internet. Figure 3-1 illustrates this configuration.

Table 3-1 Tutorial Network—Nodes and Software Requirements

Node IP Address Required Software

A (public host) 10.31.100.21 ■ Web server■ Web browser■ Ping command

B (private host) 192.168.74.2 ■ Web server■ Web browser■ Ping command■ Telnet client command

C (private host) 192.168.74.3 ■ Web server■ Web browser■ Ping command■ Telnet client command

(optional)

D (gateway) ■ 10.31.151.155 on fei0 (public interface)

■ 192.168.74.1 on fei1 (private interface)

NOTE: Host A must be configured with a route to the 192.168.74.0/24 network via 10.31.151.155.Hosts B and C must be configured with a route to the 10.31.0.0/16 network via 192.168.74.1.

3 Firewall Tutorial3.3 Creating a Simple Firewall

21

3

3.3 Creating a Simple Firewall

This tutorial explains how to create a simple firewall using basic IP filtering rules. Detailed information on the IP filter is provided in 5. Creating an IP Filter.

Figure 3-1 Tutorial Network Configuration

Switch

Switch

Corporate LAN

Internet

A (public host)

B (private host) C (private host)

D (gateway)

192.168.74.1 (fei1)10.31.151.155 (fei0)

NOTE: The steps in the following sections assume you have installed and built your Platform. For installation and build instructions, see the getting started guide for your Platform.


22

3.3.1 Security Policy

The security policy implemented in this tutorial is designed to do the following:

1. Block all packets from the public network going to the private network unless private hosts have requested the incoming traffic.

2. Pass and log incoming ICMP echo requests to host C.

3. Pass outbound TCP/UDP packets from any private network host and keep state. Inbound packets arriving in response to such requests are allowed to pass the firewall.

4. Pass outbound ICMP packets from any private network host and keep state. Inbound packets arriving in response to such requests are allowed to pass the firewall.

This security policy uses stateful packet inspection. Stateful inspection allows outgoing connections to be established, but does not allow uninitiated connections from the public network. For more information on stateful packet inspection, see 5.3 Stateful Inspection, p.56.

3.3.2 Writing Rules

This section describes how to develop the rules to fulfill the security policy described in 3.3.1 Security Policy, p.22. All rules should be added to the usrAppInit.c file in your Workbench firewall project.

Step 1: Create a Default Rule

Create a rule that blocks all incoming packets unless other rules explicitly allow the packets to pass. To create a rule, call the ipfirewall_add_rule( ) routine, using the appropriate keywords as parameters. For our simple firewall, the routine is as follows:

ipfirewall_add_rule( AF_INET, "block in on fei0 all" );

NOTE: This tutorial assumes that you have already connected the required hardware, created a Wind River Firewall project, and added a hook for firewall rules. If you have not already performed these tasks, do so now. For further information, see 3.2 Network Configuration, p.20, and 2.3.3 Configuring Wind River Firewall to Run on a Gateway, p.13.

3 Firewall Tutorial3.3 Creating a Simple Firewall

23

3

Step 2: Create a Rule to Accept Incoming ICMP Echo Requests

Create a rule that accepts incoming ICMP echo requests to private host C and logs these packets. Use the following routine:

ipfirewall_add_rule( AF_INET, "pass in log quick on fei0 proto icmp from any to 192.168.74.3 icmp-type 8" )

Note the use of the quick keyword in these routines. This keyword instructs the firewall to abort processing on the first match and immediately take the action specified in the rule. See Controlling Rule Processing, p.37, for further information.

Step 3: Create a Rule to Keep State on Outbound TCP/UDP Packets

Create a rule that passes outbound TCP/UDP packets from any private network host and records their state. With this rule, the firewall automatically passes inbound packets arriving in response to such requests. Use the following routine:

ipfirewall_add_rule( AF_INET, "pass out quick on fei0 proto tcp/udp from 192.168.74.0/24 to any keep state" )

Step 4: Create a Rule to Keep State on Outbound ICMP Packets

Create a rule that passes outbound ICMP packets from any private network host and records their state. With this rule, the firewall automatically passes inbound packets arriving in response to such requests. This rule is nearly identical to the previous one. Use the following routine:

ipfirewall_add_rule( AF_INET, "pass out quick on fei0 proto icmp from 192.168.74.0/24 to any keep state" )

Complete Code—Simple Firewall

When complete, the firewall code should look something like this:

include <vxWorks.h>#if defined(PRJ_BUILD)#include "prjParams.h"#endif /* defined PRJ_BUILD */

#ifndef AF_INET#define AF_INET 2#endif

#ifndef INCLUDE_USER_APPL#define INCLUDE_USER_APPL#endif


24

#define USER_APPL_INIT_FIREWALL { \IMPORT int ipfirewall_add_rule(int family, const char *rule); \/* Default rule to block all traffic */ \ipfirewall_add_rule( AF_INET, "block in on fei0 all" );/* Pass in and log ICMP packets */ \ipfirewall_add_rule( AF_INET, "pass in log quick on fei0 proto icmp from any to 192.168.74.3 icmp-type 8" )/* Pass outbound TCP\UDP packets and keep state */ \ipfirewall_add_rule( AF_INET, "pass out quick on fei0 proto tcp/udp from 192.168.74.0/24 to any keep state" )/* Pass outbound ICMP packets and keep state */ \ipfirewall_add_rule( AF_INET, "pass out quick on fei0 proto icmp from 192.168.74.0/24 to any keep state" )

}/****************************************************************************** usrAppInit - initialize the users application*/

void usrAppInit (void) {#ifdef USER_APPL_INIT

USER_APPL_INIT; /* for backwards compatibility */#endif

3.3.3 Testing the Firewall

Test the firewall to verify that it is working and accepting and rejecting traffic as expected.

1. Perform the following tests:

■ Web browsing from B to A ■ Web browsing from C to A■ ping from B to A■ ping from C to A■ ping from A to C

These tests should all pass.

2. Next, perform these tests:

■ Web browsing from A to B■ Web browsing from A to C■ ping from A to B

These tests should all fail.

3 Firewall Tutorial3.4 Creating a Home/SOHO Gateway Firewall

25

3

3. Check the firewall log by issuing the following shell command:

[vxWorks *] # ipf -Pl

Verify that the ping from A to C was logged.

4. Check firewall statistics by issuing the following shell command:

[vxWorks *] # ipf -S

Counters for states added, states expired, states expired, logged input packets, blocked input, passed input should all be greater than 0. The firewall statistics will look something like this:

FIREWALL STATISTICS:input packets: blocked 23 passed 21 nomatch 0output packets: blocked 0 passed 32 nomatch 0invalid packets: 0logged input packets: blocked 0 passed 16logged output packets: blocked 0 passed 0log failures: 0states added: 17states expired: 17state hits: 0state failures: 0input mac frames: blocked 0 passed 0 nomatch 0output mac frames: blocked 0 passed 0 nomatch 0invalid mac frames: 0logged input mac frames: blocked 0 passed 0logged output mac frames: blocked 0 passed 0mac log failures: 0

3.4 Creating a Home/SOHO Gateway Firewall

In the preceding tutorial, we learned how to create a basic firewall. This tutorial presents a more complex example that can serve as the basis for a firewall running on a home/SOHO gateway. The network configuration is the same one used in the preceding tutorial. For more information, see 3.2 Network Configuration, p.20. No services are available on any internal host.



26

3.4.1 Security Policy

The security policy for the home/SOHO gateway is to:

1. Block all incoming traffic from the Internet unless a private host has connected to a server on the Internet.

2. Block all incoming traffic from private networks.

3. Block incoming traffic from special networks, such as those used for internal communication, automated system configuration, and similar purposes.

4. Block multicast traffic.

5. Block and log spoofing and smurf relay attacks.

6. Pass outbound TCP/UDP packets from any private network host and keep state. Inbound packets arriving in response to such requests are allowed to pass the firewall.

7. Pass outbound ICMP packets from any private network host and keep state. Inbound packets arriving in response to such requests are allowed to pass the firewall.

3.4.2 Writing Rules

This section describes how to develop the rules to fulfill the security policy described in 3.4.1 Security Policy, p.26. All rules should be added to the usrAppInit.c file in your Workbench firewall project.

Step 1: Create a Default Rule

Create a rule that blocks all incoming packets unless other rules explicitly allow the packets to pass. As in the previous tutorial, call ipfirewall_add_rule( ), using the appropriate keywords as parameters. For the SOHO gateway firewall, the routine is as follows:

ipfirewall_add_rule(AF_INET, "block in on fei0 all"); \


27

3

Step 2: Block All Private Networks

Create rules to block traffic from private networks. Use the following routines:

ipfirewall_add_rule(AF_INET, "block in quick on fei1 from 192.168.0.0/16 to any"); \ipfirewall_add_rule(AF_INET, "block in quick on fei1 from 172.16.0.0/12 to any"); \ipfirewall_add_rule(AF_INET, "block in quick on fei1 from 10.0.0.0/8 to any"); \

Note the use of the quick keyword in these routines. This keyword instructs the firewall to abort processing on the first match and immediately take the action specified in the rule. See Controlling Rule Processing, p.37, for further information.

Step 3: Block All Special Networks

Create rules to block traffic from special networks. Use the following routines:

ipfirewall_add_rule(AF_INET, "block in quick on fei0 from 127.0.0.0/8 to any"); \ipfirewall_add_rule(AF_INET, "block in quick on fei0 from 0.0.0.0/8 to any"); \ipfirewall_add_rule(AF_INET, "block in quick on fei0 from 169.254.0.0/16 to any"); \ipfirewall_add_rule(AF_INET, "block in quick on fei0 from 192.0.2.0/24 to any"); \ipfirewall_add_rule(AF_INET, "block in quick on fei0 from 204.152.64.0/23 to any"); \

Step 4: Block Multicast Traffic

Create a rule to block all multicast traffic. Use the following routine:

ipfirewall_add_rule(AF_INET, "block in quick on fei0 from 224.0.0.0/3 to any"); \

Step 5: Block and Log Spoofing Attacks

Create a rule to block and log spoofing attacks. Use the following routine:

ipfirewall_add_rule(AF_INET, "block in log quick on fei0 from 192.168.74.0/24 to any"); \

Step 6: Block and Log Smurfing Attacks

Create a rule to block and log possible smurf attacks. Use the following routines:

ipfirewall_add_rule(AF_INET, "block in log quick on fei0 from any to 192.168.74.0/32"); \ipfirewall_add_rule(AF_INET, "block in log quick on fei0 from any to 192.168.74.255/32"); \


28

Step 7: Create a Rule to Keep State on Outbound TCP/UDP Packets

Create a rule that passes outbound TCP/UDP packets from any private network host and records their state. With this rule, the firewall automatically passes inbound packets arriving in response to such requests. Use the following routine:

ipfirewall_add_rule(AF_INET, "pass out quick on fei0 proto tcp/udp from 192.168.74.0/24 to any keep state"); \

Step 8: Create a Rule to Keep State on Outbound ICMP Packets

Create a rule that passes outbound ICMP packets from any private network host and records their state. With this rule, the firewall automatically passes inbound packets arriving in response to such requests. This rule is nearly identical to the previous one. Use the following routine:

ipfirewall_add_rule(AF_INET, "pass out quick on fei0 proto icmp from 192.168.74.0/24 to any keep state"); \

Complete Code—Home/SOHO Gateway Firewall

When complete, the firewall code should look something like this:

#include <vxWorks.h>#if defined(PRJ_BUILD)#include "prjParams.h"#endif /* defined PRJ_BUILD */

#ifndef AF_INET#define AF_INET 2#endif


#define USER_APPL_INIT_FIREWALL { \IMPORT int ipfirewall_add_rule(int family, const char *rule); \/* Default rule to block all traffic */ \ipfirewall_add_rule(AF_INET, "block in on fei0 all"); \/* Block private networks */ \ipfirewall_add_rule(AF_INET, "block in quick on fei0 from 192.168.0.0/16

to any"); \ipfirewall_add_rule(AF_INET, "block in quick on fei0 from 172.16.0.0/12

to any"); \ipfirewall_add_rule(AF_INET, "block in quick on fei0 from 10.0.0.0/8 to

any"); \/* Block special networks */ \ipfirewall_add_rule(AF_INET, "block in quick on fei0 from 127.0.0.0/8 to

any"); \ipfirewall_add_rule(AF_INET, "block in quick on fei0 from 0.0.0.0/8 to

any"); \


29

3




/* Block multicast */ \ipfirewall_add_rule(AF_INET, "block in quick on fei0 from 224.0.0.0/3 to

any"); \/* Block and log possible spoofing attacks */ \ipfirewall_add_rule(AF_INET, "block in log quick on fei0 from

192.168.74.0/24 to any"); \/* Block and log possible smurf attacks */ \ipfirewall_add_rule(AF_INET, "block in log quick on fei0 from any to

192.168.74.0/32"); \ipfirewall_add_rule(AF_INET, "block in log quick on fei0 from any to

192.168.74.255/32"); \/* Enable stateful firewall on outgoing traffic */ \ipfirewall_add_rule(AF_INET, "pass out quick on fei0 proto tcp/udp from

192.168.74.0/24 to any keep state"); \ipfirewall_add_rule(AF_INET, "pass out quick on fei0 proto icmp from

192.168.74.0/24 to any keep state"); \}** usrAppInit - initialize the users application*/

void usrAppInit (void) {#ifdef USER_APPL_INIT

USER_APPL_INIT; /* for backwards compatibility */#endif

3.4.3 Testing the Firewall

Test the firewall to verify that it is working and accepting and rejecting traffic as expected. The home/SOHO gateway firewall should pass and fail the same tests as the simple tutorial.


■ Web browsing from B to A ■ Web browsing from C to A■ ping from B to A■ ping from C to A■ ping from A to C

These tests should all pass.


30

2. Next, perform these tests:

■ Web browsing from A to B■ Web browsing from A to C■ ping from A to B

These tests should all fail.

3. Check the firewall log by issuing the following shell command:


Verify that the ping from A to C was logged.

4. Check firewall statistics by issuing the following shell command:


Counters for states added, states expired, logged input packets, blocked input, passed input should all be greater than 0. The firewall statistics will look something like this:


The exact statistics you see may vary according to the test parameters actually used.

These tests verify the proper functioning of the stateful firewall rules described in steps 7 and 8. These tests do not verify functioning of the rules that block special networks and spoofing/smurf attacks. Testing these additional rules would require more computers and the ability to send packets with a faked source IP address. These test procedures, however, are outside the scope of this manual.


31

4Firewall Fundamentals

4.1 Introduction 32

4.2 Firewall Operation 32

4.3 Elements of a Firewall Rule 34

4.4 Methods for Writing Rules 35

4.5 Rules and Rule Groups 36

4.6 Rate Limiting 38

4.7 Logging 39

4.8 Enabling and Disabling the Firewall 42

4.9 Adding and Removing Firewall Rules 42

4.10 Saving and Restoring Firewall Rules 45

4.11 Viewing and Clearing Firewall Information 46


32

4.1 Introduction

This chapter describes basic firewall concepts, including the elements of a firewall rule, the processing of rules and rule groups, different methods for writing rules, and rate limiting.

See also the following chapters:

■ 5. Creating an IP Filter for a description of IP-specific filtering methods

■ 6. Creating a MAC Filter for a description of MAC-specific filtering methods

■ 8. Filtering HTTP Content for a description of methods for filtering HTTP traffic

4.2 Firewall Operation

A firewall is a collection of rules for inspecting and filtering data packets and frames as they enter, transit, and exit the TCP/IP stack. Wind River Firewall provides two filters:

■ an IP filter, which operates in the network layer

■ a MAC filter, which operates in the data link layer

At the network layer, the firewall checks every incoming IP packet against the rules in the IP filter. If there is a matching rule, the firewall either blocks the packet or passes it to the transport layer, based on the action specified in the rule. The firewall also checks every outgoing packet against the rules in the IP filter. If there is a matching rule, the firewall either blocks the packet or passes it to the data link layer, based on the action specified in the rule.

At the data link layer, the firewall checks every incoming Ethernet frame against the rules in the MAC filter. If there is a matching rule, the firewall silently blocks the frame or passes it to the network layer, based on the action specified in the rule. The firewall also checks every outgoing frame against the rules in the MAC filter and either drops the frame or passes it to the physical layer for output.

Figure 4-1 illustrates the flow of data through the network and data link layers of the TCP/IP stack.

4 Firewall Fundamentals4.2 Firewall Operation

33

4

Figure 4-1 Wind River Firewall Schematic

Data link layer

Network layer IP filter

MAC filter

Transport layer

Application layer

Physical layer

NOTE: Filtering rules implement your security policy. Before you start writing filtering rules, develop your security policy carefully and in detail.


34

4.3 Elements of a Firewall Rule

Each firewall rule consists of at least the following elements:

■ an action to be taken (either block or pass)

■ the direction, or filter location (either in or out)

■ an address scope, such as all, me, or any

Additional optional parameters can also be specified.

4.3.1 Action to Be Taken

At a minimum, each rule must specify whether a packet is to be blocked or passed, using the keyword block or pass. For example:

pass out all

instructs the firewall to allow all packets to exit the system.

Additional actions are also possible. For example:

block in log all

instructs the firewall to block all incoming packets and log them for later examination. Logging is available for both IP and MAC filters. For more information, see 4.7 Logging, p.39.

For IP filter rules, you can also instruct the firewall to notify the peer when a packet is dropped. For further information, see 5.4 Responding to Blocked Packets, p.57.

4.3.2 Address Scope

For further information on defining the address scope of a rule, see IP Filter Address Scope, p.52, and 6.2.1 Filtering by Address, p.60.

4.3.3 Interface

Use the on keyword to narrow the scope of a rule to packets being sent or received on a particular interface. For example:

block in on ppp0 allpass out on fei0 all

4 Firewall Fundamentals4.4 Methods for Writing Rules

35

4

You can also use the plus sign (+) to specify more than one interface. For example:

pass out on fei+ all

This rule instructs the firewall to pass all packets on any interface containing the characters fei—fei0, fei1, fei2, etc.

4.4 Methods for Writing Rules

You can develop firewall rules using a simple keyword syntax and add these rules to the firewall with a rule file, the Wind River Firewall API, or the ipf shell command.

4.4.1 Using a Rule File

You can write firewall rules using the keyword syntax shown in the preceding examples in this chapter. Save your firewall rules in a text file and store them wherever you like on the system. You can use any file name or extension, but it is common to use a .cfg extension. The file must reside on the target and be stored on local media.

It is a good practice to maintain separate rule files for IPv4, IPv6, and MAC rules. Certain rules, such as block in all, have the same syntax for each filter type. Segregating them in separate keyword files allows the firewall to apply the rules correctly.

Empty lines and white space are permitted in a rule file. The pound sign (#) precedes a comment. You can terminate a line with a comment.

The following example shows a comment line, an empty line, a line with a rule terminated by a comment, and a line with a rule. The entire file consists of four lines.

NOTE: Other methods of filtering are also available. For further information on IP filter rules, see 5. Creating an IP Filter. For further information on MAC filter rules, see 6. Creating a MAC Filter.


36

# example rule file

block in on fei0 all # default action is to block all incoming packetspass out quick on fei0 proto tcp/udp from any to any keep state

For further information on a particular keyword, see its reference entry in A. Wind River Firewall Keywords.

4.4.2 Using the API

You can also use the Wind River Firewall API to create firewall rules. All rules should be added to the usrAppInit.c file in your Workbench firewall project. See the reference entry for each routine for a description of the syntax and available parameters.

4.4.3 Using a Shell Command

You can also use the ipf shell command to create firewall rules. See D. Wind River Firewall Shell Command for a description of all available parameters.

4.5 Rules and Rule Groups

Arranging rules in groups can improve performance for complex rule sets. Grouping allows you to arrange rules in a treelike structure instead of a linear list. The advantage to rule grouping is that if a packet fails to match the head rule in a group, the firewall skips the remaining subrules and immediately begins matching against the next group. This feature is available for both IP and MAC filters.

When you add rules to a firewall without specifying a rule group, the new rules are added to the default group. To create a group, use the head keyword, followed by a group number. The number 0 is reserved for the default group, so use a number greater than 1. Each group must have a head rule, followed by any number of subrules.

To assign a subrule to a group, use the group keyword, followed by the group number. For example:

block in quick on fei0 all head 1block in quick on fei0 from 10.0.0.0/8 to any group 1

4 Firewall Fundamentals4.5 Rules and Rule Groups

37

4

block in quick on fei0 from 11.0.0.0/8 to any group 1pass in on fei0 all group 1

block in quick on fei1 all head 2block in quick on fei1 from 10.0.0.0/8 to any group 2block in quick on fei1 from 11.0.0.0/8 to any group 2pass in on fei1 all group 2

pass in all

Rules are usually grouped by interface, but other criteria can also be used.

4.5.1 How Packets Are Matched against Rules

By default, a firewall inspects each packet against every rule, then takes action on the basis of the last match. In the following rule set, the firewall acts only on the basis of the final rule, allowing all packets to pass.

block in allpass in all

In effect, the final rule in a rule set—pass all or block all—becomes the default action for the firewall.

In a large rule set, however, checking every rule and subrule can lead to long processing times and unintended results. For this reason, it may be necessary to control rule processing.

Controlling Rule Processing

To control rule processing, include the quick keyword in a rule or subrule. This keyword instructs the firewall to abort processing on the first match and immediately take the action specified in the rule.

For example, in the following rule set, the firewall aborts processing with the first rule and blocks all incoming packets.

block in quick allpass in all

Rule Processing in Grouped Rule Sets

In grouped rule sets, the quick keyword has a slightly different effect. If a packet fails to match a head rule, the firewall skips all subrules within that group and proceed to the next head rule. The firewall only checks subrules when a packet meets the criteria specified by the head rule.

Consider the previous example. If a packet arrives on fei1 from 12.1.1.1, the firewall attempts to match it against the first head rule:

block in quick on fei0 all head 1


38

Because there is no match, the firewall skips the subrules in group 1 and proceeds directly to group 2.

The firewall then attempts to match the packet against the second head rule:

block in quick on fei1 all head 2

Because the packet meets the interface criterion specified in the rule, the firewall then attempts to match the packet against the subrules in group 2.

The packet fails to match the source address criteria (10.0.0.0/8 and 11.0.0.0/8), so it matches against the final rule (pass in on fei1 all group 2) and passes the firewall.

4.6 Rate Limiting

Rate limiting filters packets based on a specified intercept rate for a specified type of packet. You can instruct the firewall to pass or block packets of the specified type under the following conditions:

■ When their rate of transmittal is greater than or less than the specified rate.

■ When the number of packets transmitted or received exceeds a specified quantity during a specified period of time.

Rate limiting is available for both IP and MAC filter rules.

Rate limiting works like a token bucket filter. The burst parameter specifies the size of the bucket—that is, how many tokens the bucket can hold. The limit parameter specifies the maximum average rate at which new tokens are allowed to enter the bucket.

For example, if a rule specifies a maximum rate of 500 packets in 120-second period, any packets exceeding that rate match the condition. If the action is to reject such packets, you can use this rule to block attempts to flood the stack with packets.

You can also rate-limit packets arriving from or being transmitted to a specified host. If you do not specify a host, the firewall limits the rate of all intercepted packets of the specified type, regardless of their source or destination address.

4 Firewall Fundamentals4.7 Logging

39

4

To limit traffic by rate, use the limit keyword with a numeric quantifier with a unit specifier to specify the unit of time. Valid units are s (second), m (minute), h (hour), or d (day).

To limit traffic by quantity—that is, to specify a maximum or minimum number of packets of a particular type—use the burst keyword. Use a numeric quantifier of at least 1.

For example, the following rule limits incoming TCP packets with SYN flags to a rate of 5 per second or bursts of ten SYN segments:

pass in limit 5/s burst 10 proto tcp all flags S

The following rule accepts 100 frames per day from MAC address 00:08:74:01:00:01:

pass in limit 100/d burst 1 from 00:08:74:01:00:01 to any

The following example logs one outgoing packet per hour:

pass out log limit 1/h burst 1 all

Note also that, as with other keywords, the exclamation point (!) can be used to invert a specified parameter. The following example blocks incoming ICMP packets unless they arrive at a rate exceeding 10 packets per second.

block in limit ! 10/s burst 10 proto icmp all

4.7 Logging

Logging is available for both IP packets and MAC frames. Logged information is stored in memory and can be retrieved for display on the system console.


40

4.7.1 Log Formats

IP Filter Logs

When logging is specified, Wind River Firewall keeps the following information for IP packets:

■ date and time the packet arrived or departed

■ interface on which the packet arrived or departed

■ rule group and rule index within the group

■ action taken: passed (p) or blocked (b)

■ source IP address

■ source port for TCP/UDP packets

■ destination IP address

■ destination port for TCP/UDP packets

■ protocol

■ IP header length

■ total length

■ ICMP type and code for ICMP packets

■ TCP flags for TCP packets

■ a notice if the packet is a fragment

The following is an example of an IP filter log:

2006/11/08 16:46:49.167074 vlan5 @0:1 p 10.50.1.1 -> 10.50.2.3 PR icmp len 20 84 icmp 8/0

MAC Filter Logs

When logging is specified, Wind River Firewall keeps the following information for MAC frames:

■ date and time the packet arrived or departed

■ interface on which the packet arrived or departed

■ rule group and rule index within the group

4 Firewall Fundamentals4.7 Logging

41

4

■ action taken: passed (p) or blocked (b)

■ source MAC address

■ destination MAC address

■ MAC type

■ frame length

■ first 64 bytes of frame data

The following is an example of a MAC filter log:

2006/11/08 19:22:56.733333 vlan5 @0:1 p 00:a0:1e:11:11:00 -> 00:01:01:01:01:00 TYPE 8100 len 880005080045000054f26900003f0171d80a3201010a3202030800fa2083450003202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f

4.7.2 Logging Traffic

To log firewall traffic, simply include the log keyword in the rule. For example:

block in log quick all

To reduce the number of packets stored in the log, use the first keyword with log. For example:

block in log first quick on fei0 from 10.0.0.0/8 to any

This rule instructs the firewall to log only the first packet arriving on fei0 from the address space 10.0.0.0/8. Use this parameter to avoid filling up the log too fast, because the log can hold only a limited number of packets (100 by default).

Viewing the Firewall Log

To view the firewall log, type the following shell command:




42

Clearing the Firewall Log

To clear (flush) the firewall log, type the following shell command:

[vxWorks *] # ipf -Fl

Adjusting Log Capacity

To adjust the default log capacity, edit the following macros in ipfirewall_h.h:

Maximum number of MAC filter log rules:

#define IPFIREWALL_MAX_MAC_LOG_ENTRIES 100

Maximum number of IP filter log rules:

#define IPFIREWALL_MAX_IP_LOG_ENTRIES 100

The default value for each macro is 100.

4.8 Enabling and Disabling the Firewall

To enable the firewall, type the following shell command:

[vxWorks *] # ipf -E

To disable the firewall, type the following shell command:

[vxWorks *] # ipf -D

4.9 Adding and Removing Firewall Rules

There are three ways to add rules to a firewall:

■ By storing the rules in a file that is automatically loaded on startup (see 4.10 Saving and Restoring Firewall Rules, p.45).

■ By adding individual rules or an entire rule set with a shell command.

4 Firewall Fundamentals4.9 Adding and Removing Firewall Rules

43

4

■ By adding individual rules or an entire rule set with the Wind River Firewall API.

Once added, rules are stored in an internal table in system memory. By default, the firewall appends all rules to this rule set without checking for duplicates or conflicts. If you load rules on startup with a rule file, then add additional rules by shell command or API, the firewall automatically appends them to the existing rule set.

4.9.1 Adding Rules

To add a rule to the firewall, type the following shell command:

[vxWorks *] # ipf rule

where rule is the firewall rule you wish to add. The default operation is to append the specified rule to the IP filter. For example:

[vxWorks *] # ipf block in quick from 192.168.1.14 to any

makes block in quick from 192.168.1.14 to any the last rule in an existing IP filter.

To add a rule that applies only to IPv6 packets, type:

[vxWorks *] # ipf -6 rule

To add a rule to the MAC filter, type:

[vxWorks *] # ipf -m rule

Adding Rules from a File

You can also store firewall rules in a text file with a name such as myrules.cfg. To load all rules in this file at once, specify the file name and path of the rules file. For example:

[vxWorks *] # ipf -f myrules.cfg

If you do not specify a path, Wind River Firewall tries to open the file in the current working directory. If the file is in a different directory, you can specify the absolute path to it. For example:

[vxWorks *] # ipf -f /usr/local/ipfirewall/config/myrules.cfg



44

Specifying the Rule Position

By default, new rules are appended to the existing rule list. However, you can insert a rule into a list at a specified location by using the ipf shell command with the index parameter (@). This feature is available for both IP and MAC filters.

The index parameter must be the first parameter in the shell command. In a set of ungrouped rules, the index begins with 1 by default. Any index you specify must be 1 or greater. Thus:

[vxWorks *] # ipf @2 block in quick from 192.168.1.15 to 10.0.0.4

inserts the rule block in quick from 192.168.1.15 to 10.0.0.4 as the second rule in an existing rule set. If the initial rule set is as follows:

block in quick from 192.168.1.14 to anyblock in quick from 10.0.0.4 to any

the resulting rule set would be as follows:

block in quick from 192.168.1.14 to anyblock in quick from 192.168.1.15 to 10.0.0.4block in quick from 10.0.0.4 to any

Inserting a Rule within a Group

When rule grouping is used, a new rule is inserted by default as the last rule in the specified group. If the index parameter is used in conjunction with grouping, it refers to the position of a rule within its group. Within the group, the head rule is index zero, the first rule index 1, and so on. Thus, the shell command:

[vxWorks *] # ipf @2 block in quick on fei1 from 11.0.0.0/8 to any group 9

inserts the new rule into the second position in group 9. The resulting rule set would be as follows:

block in quick on fei0 all head 8block in quick on fei0 from 10.0.0.0/8 to any group 8block in on quick fei0 from 11.0.0.0/8 to any group 8pass in on fei0 all group 8

block in quick on fei1 all head 9block in quick on fei1 from 10.0.0.0/8 to any group 9block in on quick fei1 from 11.0.0.0/8 to any group 9pass in on fei1 all group 9

pass in all

4 Firewall Fundamentals4.10 Saving and Restoring Firewall Rules

45

4

4.9.2 Removing Rules

To remove a rule from the firewall, type:

[vxWorks *] # ipf -r rule

To remove all rules from the firewall at once, type:

[vxWorks *] # ipf -Fr

4.9.3 Checking Rule Syntax

To check the rule syntax, type:

[vxWorks *] # ipf -n rule

The -n option parses the rule syntax and reports any errors without adding the rule to the firewall. When the rule syntax is correct, there is no output. When the rule syntax is incorrect, Wind River Firewall reports the error. For example:

[vxWorks *] # ipf -n pas in all

returns the error message:

Unknown action: pas.

4.10 Saving and Restoring Firewall Rules

Wind River Firewall supports nonvolatile (NV) storage to the file system. To implement NV storage, simply save your rule set in a text file. You can use any file name or extension, but it is common to use a .cfg extension. The file must reside on the target and be stored on local media.

It is a good practice to maintain separate rule files for IPv4, IPv6, and MAC rules. Certain rules, such as block in all, have the same syntax for each filter type. Segregating them in separate keyword files allows the firewall to apply the rules correctly.

This capability allows the system to save firewall rules and restore them on system reset.

NV storage is defined by the following Workbench components (or system variables):


46

IPF_IPV4_RULE_FILESpecifies the name of the default IPv4 IP filter rule file. The firewall loads the rules from this file if it exists at boot time. The default is IPCOM_FILE_ROOT"fw4.cfg".

IPF_IPV6_RULE_FILESpecifies the name of the default IPv6 IP filter rule file. The firewall loads the rules from this file if it exists at boot time. The default is IPCOM_FILE_ROOT"fw6.cfg".

IPF_FWMAC_RULE_FILESpecifies the name of the default MAC filter rule file. The firewall loads the rules from this file if it exists at boot time. The default is IPCOM_FILE_ROOT"fwmac.cfg".

On restart, the system loads the rules in the files defined by these components.

4.11 Viewing and Clearing Firewall Information

Wind River Firewall maintains information on firewall rules and operations in the form of logs, tables, and statistics. You can retrieve this information by typing the appropriate shell command.

See 4.7.2 Logging Traffic, p.41, for information on accessing and clearing firewall logs.

4.11.1 Viewing and Clearing Firewall Statistics

Wind River Firewall keeps the following statistics:

■ input packets (blocked, passed, and nonmatching)

■ output packets (blocked, passed, and nonmatching)

■ invalid packets

■ logged input packets (blocked and passed)

■ logged output packets (blocked and passed)

■ log failures

4 Firewall Fundamentals4.11 Viewing and Clearing Firewall Information

47

4

■ states added

■ states expired

■ state hits

■ state failures

■ input MAC frames (blocked, passed, and nonmatching)

■ output MAC frames (blocked, passed, and nonmatching)

■ invalid MAC frames

■ logged input MAC frames (blocked and passed)

■ logged output MAC frames (blocked and passed 0)

■ MAC log failures

To display these statistics, type the following shell command:


The following is an example of statistics kept by the firewall:


To clear the statistics, type the following:

[vxWorks *] # ipf -Z



48

4.11.2 Viewing and Clearing Firewall Tables

Wind River Firewall keeps the following tables:

■ rules■ state entries■ log■ user (custom routines)

To view all tables, type the following shell command:

[vxWorks *] # ipf -Pa

To clear all tables, type the following:

[vxWorks *] # ipf -Fa

See the following sections for information on viewing or clearing individual tables.

Rule Table

To view the rule table, type the following:

[vxWorks *] # ipf -Pr

The following is an example of a firewall rule table:

IP FILTER RULE TABLE:AF_INET: @1 pass out quick on vlan5 all group 0:1 AF_INET: @2 block out on vlan5 all group 0:2

To view all rules for a specific group, type the following:

[vxWorks *] # ipf -PgN

where N is the number of the group whose rules you want to view.

To clear the rule table, type the following:

[vxWorks *] # ipf -Fr

To clear all rules for a specific group, type the following:

[vxWorks *] # ipf -FgN

where N is the number of the group whose rules you want to clear.

4 Firewall Fundamentals4.11 Viewing and Clearing Firewall Information

49

4

State Table

To view the state table, type the following:

[vxWorks *] # ipf -Ps

The following is an example of a state table:

IP FILTER STATE TABLE:10.50.1.1:40000 -> 10.50.2.3:30000 proto udp expire in 56 s10.50.1.1:40000 -> 10.50.2.3:30000 proto tcp expire in 58 s10.50.1.1:21217 -> 10.50.2.3:21217 proto icmp expire in 3 s

To clear the state table, type the following:

[vxWorks *] # ipf -Fs

Log Table

To view the log table, type the following:


The following is an example of a log table:

IP FILTER LOG:2006/11/08 16:46:49.167074 vlan5 @0:1 p 10.50.1.1 -> 10.50.2.3 PR icmp len 20 84 icmp 8/02006/11/08 16:46:50.168399 vlan5 @0:1 p 10.50.1.1 -> 10.50.2.3 PR icmp len 20 84 icmp 8/02006/11/08 16:46:51.172488 vlan5 @0:1 p 10.50.1.1 -> 10.50.2.3 PR icmp len 20 84 icmp 8/02006/11/08 16:46:52.176583 vlan5 @0:1 p 10.50.1.1 -> 10.50.2.3 PR icmp len 20 84 icmp 8/02006/11/08 16:46:53.180652 vlan5 @0:1 p 10.50.1.1 -> 10.50.2.3 PR icmp len 20 84 icmp 8/0

To clear the log table, type

[vxWorks *] # ipf -Fl

Custom Routines Table

See 7.3 Viewing Custom Routines, p.65, for information on viewing custom routines.


50

Group Rule Table

To view the rule table for a particular group, type:

[vxWorks *] # ipf -PgN

where N is the number of the group whose rule table you want to view. For example:

[vxWorks *] # ipf -Pg2

The following is an example of the table generated by the previous command:

IP FILTER RULE TABLE:AF_INET: @1 pass in proto icmp all head 1:0AF_INET: @2 pass in proto igmp all group 1:1AF_INET: @3 pass in proto 3 all group 1:2

To clear the rule table for a particular group, type:

[vxWorks *] # ipf -FgN

where N is the number of the group whose rule table you want to clear. For example:

[vxWorks *] # ipf -Fg2

51

5Creating an IP Filter

5.1 Introduction 51

5.2 Methods for Filtering 52

5.3 Stateful Inspection 56

5.4 Responding to Blocked Packets 57

5.1 Introduction

The IP filter operates in the network layer of the TCP/IP stack. It filters IPv4 or IPv6 packets based on the rules you specify. You can write rules to filter incoming or outgoing packets, using any combination of source addresses, destination addresses, or fields in a packet header.

This chapter describes filtering methods specific to the IP filter (see 5.2 Methods for Filtering, p.52). See also the following chapters:

■ 4. Firewall Fundamentals for information on filtering methods available for both IP and MAC filters

■ 8. Filtering HTTP Content for information on HTTP filters


52

5.2 Methods for Filtering

You can filter IP packets by a variety of means, including the following:

■ address■ type of service or traffic class■ time to live■ protocol■ ICMP type and code■ port specification for UDP and TCP protocols■ TCP flags■ IP options and fragments

5.2.1 Filtering by Address

You can instruct the firewall to pass or block individual addresses or a range of addresses.

IP Filter Address Scope

The address scope parameter specifies an individual address or range of addresses for either the source or destination of the data packet. The keyword all specifies all traffic, regardless of source or destination address. The keyword me specifies any address configured on the system. The keyword from precedes a source address. The keyword to precedes a destination address. When used with from, the keyword any specifies any source address. When used with to, any specifies any destination address. Examples include:

block in allpass out from me to any

Specific addresses are shown as follows:

block in from 192.168.1.14 to any

A range of addresses is shown as follows:

block in from 10.0.0.0/8 to any

Preceding an address or range of addresses with an exclamation point (!) inverts the specification. For example:

pass in from ! 192.168.1.14 to me

5 Creating an IP Filter5.2 Methods for Filtering

53

5

permits packets from any address except 192.168.1.14 to pass the firewall and reach the system.

IPv6 Addresses

IPv6 addresses are specified as follows:

pass out from 3ffe:b80:2:6cbf to anypass out from 3ffe:b80:a19::/48 to any

5.2.2 Filtering by Type of Service or Traffic Class

You can filter packets based on a value in the type of service (tos) field in the packet header. Examples include:

block in tos 0x0c allblock in tos ab all

A tos mask can be used to specify that certain bits must match while others can differ. The tos mask is combined with the tos field in the incoming packet header (using an AND operator), and the resulting value is compared with the tos value in the rule. Examples include:

block in tos 0x80/0xe0 allblock in tos F0/FC all

The tos value and tos mask must be specified in hexadecimal. A leading 0x or 0X is optional.

5.2.3 Filtering by Time to Live

You can filter packets based on a value in the time to live (ttl) field in the packet header. For example:

block in ttl 0 all

5.2.4 Filtering by Protocol

You can filter packets based on their Internet protocol, using either the protocol name or a numeric value. A special case protocol is tcp/udp, which means either TCP or UDP. Examples include:

block in proto icmp allpass out proto udp allpass in proto 89 all


54

Filtering by ICMP Type and Code

If the protocol is ICMP, you can specify the icmp-type and code, using a numeric value. Examples include:

block in proto icmp all icmp-type 8block out proto icmp all icmp-type 0 code 0

Filtering by Port for UDP and TCP Protocols

For UDP and TCP protocols, you can specify the source port, destination port, or both. The port can be an individual port or an interval. For example:

block in quick proto tcp from any to any port = 80

If the port keyword precedes the to keyword, the specification refers to a source port. If the port keyword follows the to keyword, the specification refers to a destination port. Consider the following three examples.

The first rule blocks all TCP traffic bound for destination port 80:

block in quick proto tcp from any to any port = 80

The second rule passes outbound UDP traffic from any source port below 1024:

pass out log proto udp from any port < 1024 to any

The third rule passes outbound TCP traffic from any source port below 1024 to destination port 80:

pass out log proto tcp from any port < 1024 to any port = 80

A variety of mathematical operators are available for use with the port keyword. See port, p.147, further information.

Filtering by TCP Flags

If the protocol is TCP, you can specify certain TCP flags in the rule, which will be matched against the TCP flags in the packet header. Valid settings include:

■ U (URG)■ A (ACK)■ P (PSH)■ R (RST)■ S (SYN)■ F (FIN)■ 0 (no flags must be active)

5 Creating an IP Filter5.2 Methods for Filtering

55

5

If you specify a particular flag, that flag must be set in the packet header for the rule to match. Flags that are not explicitly specified must not be set. For example:

block in quick proto tcp all flags S

requires the S flag to be set in the packet header while all other flags are cleared. Conversely, the following line requires that no flags are set:

block in quick proto tcp all flags 0

You can also specify a flag mask, which requires a match on certain flags while allowing flexibility on others. A slash (/) separates the flag type specification from the flag mask specification. All flags specified before the slash must be set in the TCP header for the rule to match. All flags not specified before the slash must not be set in the TCP header for the rule to match.

Flags specified after the slash must strictly conform to the specification set before the slash. Flags not specified after the slash are allowed to vary from the specification set before the slash.

For example:

block in quick proto tcp all flags S/SA

means that the header must conform to the specification for the S and A flags—set for S and cleared for A. Other flags can be either set or cleared, and the rule will still match.

The practical effect is that the default mask UAPRSF (meaning that all flag bits must be set) is in effect even if you do not explicitly specify it in the rule. Thus, the two rules below are equal:

block in proto tcp all flags Sblock in proto tcp all flags S/UAPRSF

The default mask is UAPRSF. That means that if no flag mask is specified, all flags must match their type specification.

Filtering by IP Options and Fragments

You can use the with keyword to filter packets including IP options and fragments. The ipopts keyword is only relevant for IPv4 rules, while the frag keyword is relevant for both IPv4 and IPv6 rules. To exclude packets with fragments or IP options from a specification, use with no. Examples include:

block in quick all with fragpass in log quick all with ipoptspass in all with no frag


56

5.3 Stateful Inspection

Stateful inspection analyzes the transport layer headers in data packets to track the state of network connections. Using this header information, stateful inspection identifies whether each packet is a new connection request or a packet belonging to a previously established connection. You can write filtering rules to pass or block packets based on the state information. Stateful inspection keeps the state for TCP packets, UDP packets, ICMP echo packets, and ICMPv6 echo packets.

Wind River Firewall stateful inspection requires a rule with a keep state keyword to create a state tracking entry for outgoing packets. When an outgoing packet matches the rule, the firewall temporarily opens a port for packets arriving in response to such a request.

The firewall then matches incoming packets against active state entries before checking other rules. If there is a matching state entry, the firewall bypasses other rules and accepts the packet. If the state entry has timed out, the packet is blocked by any matching rule in the rule set.

The state tracking entry contains the following information:

■ source and destination IP addresses

■ source and destination ports for UDP and TCP

■ ICMP ID and sequence number for ICMP or ICMPv6 echo

Use the keep state keyword to create a state tracking entry. The following example allows DNS responses to pass the firewall in response to an outgoing connection request transmitted on port 53:

pass out proto udp from any to any port = 53 keep stateblock in quick proto udp allpass in all

5.3.1 Configuring Stateful Inspection

Use the firewall component IPF_MAX_STATEFUL_MAPPINGS to specify the maximum number of stateful mappings the firewall can handle. The default is 1,000.

5 Creating an IP Filter5.4 Responding to Blocked Packets

57

5

Use one of the following firewall components to specify stateful mapping timeout values for individual protocols:

■ IPF_ICMP_TIMEOUT■ IPF_UDP_TIMEOUT■ IPF_TCP_TIMEOUT■ IPF_OTHER_TIMEOUT

For further information on these components, see 2.3.1 Components and Parameters, p.12.

5.4 Responding to Blocked Packets

Normally, packets are silently dropped at the firewall when blocked. Since this behavior is sometimes undesirable, there are three keywords available for instructing the firewall to send a response back to the peer. These keywords are only available for IP filter rules and not MAC filter rules.

Sending a Reset Segment (TCP Only)

The return-rst keyword can be used to send a reset segment back to the peer if a packet is blocked. This option is only available for the TCP protocol and is useful if certain services are blocked by the firewall. If this option is used, the peer will receive a connection refused error instead of a connection timeout. For example:

block in return-rst proto tcp from any to any port = 80

Sending a Destination Unreachable Message (ICMP Only)

The return-icmp keyword can be used to send an ICMP destination unreachable message back to the peer. Any ICMP destination unreachable code can be used, but the default is unreachable-network. The unreachable-port code shall be used if the firewall blocks a packet destined for a UDP port. Some examples follow below.

Block incoming packets addressed to the 11.0.0.0/8 address space and send an ICMP network unreachable code to the peer:

block in return-icmp from any to 11.0.0.0/8


58

Block incoming UDP packets on port 53 and send an ICMP port unreachable code to the peer:

block in return-icmp(3) proto udp from any to any port = 53

The return-icmp-as-dest keyword is used like return-icmp, except that the ICMP message is sent with a source address copied from the destination address of the blocked packet. This has the advantage that the peer will see only the remote host address and not the firewall. For example:

block in return-icmp-as-dest(3) proto udp from any to any port = 53

All three keywords are also available for IPv6 rules. Note that an ICMPv6 message will be sent for the return-icmp and return-icmp-as-dest keywords. The default unreachable code is no-route for IPv6 rules.

59

6Creating a MAC Filter

6.1 Introduction 59

6.2 Methods for Filtering 60

6.1 Introduction

The MAC filter operates in the data link layer of the TCP/IP stack. It filters packets based on the rules you specify. You can write rules to filter incoming or outgoing packets, using any combination of source address, destination address, interface, frame type and packet length.

This chapter describes filtering methods specific to the MAC filter (see 6.2 Methods for Filtering, p.60). For filtering methods available for both MAC and IP filters, see 4. Firewall Fundamentals.


60

6.2 Methods for Filtering

You can filter MAC packets by the following methods:

■ address■ interface■ frame type

6.2.1 Filtering by Address

The address scope parameter for MAC filters is similar to that used for IP filters. This parameter can specify an individual address or range of addresses for either the source or destination of the data frame. The keyword all specifies all traffic, regardless of source or destination address. The keyword me specifies the MAC address assigned to the interface the frame is sent or received on. The keyword from precedes a source address. The keyword to precedes a destination address. When used with from, the keyword any specifies any source address. When used with to, any specifies any destination address. Examples include:

pass out from me to anyblock in from any to me

Specific addresses are shown as follows:

block in from 00:08:74:00:00:01 to any

A range of addresses is shown as follows:

block in from 00:08:74:01:00:00/FF:FF:FF:FF:00:00 to anyblock in from any to 00:AO:88:11:00:00/FF:FF:FF:FF:00:00

Preceding an address or range of addresses with an exclamation point (!) inverts the specification. For example:

pass in from ! 00:08:74:00:00:01 to me

permits packets from any address except 00:08:74:00:00:01 to pass the firewall and reach the system. Similarly,

block in from any to ! me

blocks packets from any source address to all destination addresses except the one assigned to the interface the packet is received on.

6.2.2 Filtering by Interface

Filtering by interface is discussed in 4.3.3 Interface, p.34.

6 Creating a MAC Filter6.2 Methods for Filtering

61

6

6.2.3 Filtering by Frame Type

The mac-type keyword can be used to filter frame types, based on the MAC type specified in the frame header. For example:

block in on fei0 all mac-type 0x86DDblock in from 00:08:74:01:00:01 to me mac-type 0x0806


62

63

7Defining Custom Routines

7.1 Introduction 63

7.2 Elements of a Custom Routine 64

7.3 Viewing Custom Routines 65

7.1 Introduction

This chapter describes the process of creating custom routines, which can be used to extend the capabilities of the firewall. Some useful applications of this capability include:

■ scanning the contents of application data

■ changing a field in the packet headers or data

■ creating a rule to match parameters not covered by the current syntax


64

7.2 Elements of a Custom Routine

A custom routine consists of three routine hooks: a check routine, a match routine, and a destroy routine. They have the following prototypes:

typedef int (* Ipfirewall_userdef_check) (void *cookie, void *info, unsigned int infolen);

typedef int (* Ipfirewall_userdef_match) (Ipcom_pkt *pkt, void *cookie, void *info);

typedef void (* Ipfirewall_userdef_destroy) (void *cookie, void *info, unsigned int infolen);

The check routine is optional and is called at the time the rule is added to the firewall. The purpose of the check routine is to verify the rule parameters and possibly convert the rule parameter string to a custom type to speed up the match routine’s processing time.

The match routine is mandatory and is called at rule matching. When all rule parameters match the packet and a custom routine is specified with the rule, the match routine is called.

The destroy routine is optional and is called at the time the rule is removed from the firewall. The purpose of the destroy routine is to free resources that were dynamically allocated by the check routine.

The pkt parameter is a pointer to the complete packet. The custom routine can access any field in the packet headers or packet payload.

The cookie parameter is assigned at registration of the custom routine and kept through calls to the check, match and destroy routines.

The info parameter is set to an ASCII string with the custom rule parameters. If no parameters are assigned to the rule, the info parameter will be an empty string.

The infolen parameter is set to the buffer length of the info parameter. It shows how much space is available for altering the info buffer.

The check and match routines can alter the contents of the info buffer. The only requirement is that the buffer size is not exceeded. The check routine typically converts the ASCII string received in the call to a custom structure, which is easier for the match routine to parse.

The check routine must return 0 or 1. Zero means that the check failed and that the rule shall not be added. One means that the rule was successfully verified and the rule will be added.

7 Defining Custom Routines7.3 Viewing Custom Routines

65

7

The match routine must return 0 or 1. Zero means that packet did not match the rule, while 1 means that it matched.

The routines ipfirewall_register_userdef( ) and ipfirewall_unregister_userdef( ) are available for registration and unregistration of the check and match routines. A custom routine is registered with an ASCII string identifier, a mandatory pointer to the match routine, an optional pointer to the check routine, an optional pointer to the destroy routine and an optional cookie. The identifier is used in the rule syntax to specify the custom routines. See rule syntax examples below:

pass in on fei1 all userdef scan_appdata

The rule above specifies that the check and match routines, which have been registered with the string scan_appdata, are called for incoming packets on interface fei1. Since no parameters are given to scan_appdata in the rule syntax, the call to the check routine is made with an empty string in the info parameter.

pass out on fei0 all userdef set_mprio 1

The rule above specifies that the check and match routines, which have been registered with the string set_mprio, will be called for outgoing packets on interface fei0. The call to the check routine will be made with the 1 in the info parameter.

Custom routines are available for both IP filter and MAC filter rules.

7.3 Viewing Custom Routines

To view custom, or user-defined, routines, type the following shell command:

[vxWorks *] # ipf -Pu

This command outputs the identifier and address of the match, check, and destroy functions defined in custom routines, as follows:

IPFIREWALL USER TABLE:id=userdef_example match=0x43cd50 check=0x43cda0 destroy=0x43cdd0id=http_filter match=0x43a740 check=0x43bbe0 destroy=0x43bcf0



66

67

8Filtering HTTP Content

8.1 Introduction 67

8.2 Enabling HTTP Content Filtering 68

8.3 Filtering Content by URL 69

8.4 Filtering Proxy Traffic 70

8.5 Filtering Java Applets 71

8.6 Filtering ActiveX Controls 71

8.7 Filtering Cookies 72

8.8 Program Example 73

8.1 Introduction

You can establish content filtering for HTTP traffic through Wind River Firewall, specifying filters for URLs, proxy traffic, cookies, Java applets and ActiveX controls. Establishing such filters is typically a three-step process

1. Define an HTTP filter and add it to the firewall.

2. Enable a particular content filter.

3. Add a rule that refers to the HTTP filter.


68

The first two steps require the use of the Wind River Firewall API. The third step can be performed using any of the methods available for adding firewall rules.

8.2 Enabling HTTP Content Filtering

Each HTTP filter is identified by an ASCII string that defines the name of the filter. Use ipfirewall_http_add_filter( ) to add HTTP filters to the firewall. This routine takes the name of the filter as the only input parameter. Once you’ve added at least one HTTP filter, you can specify a rule that refers to it. For example, if you add an HTTP filter with the name badurls, you can then add a firewall rule that lets all HTTP traffic go through the filter:

block out proto tcp from any to any port = 80 all userdef http_filter badurls

Before the HTTP filter actually enters operation, you must enable at least one of the available content filters described below. The HTTP filter checks these content filters in the following order:

1. URL filter

2. proxy filter

3. Java filter

4. ActiveX filter

5. cookie filter

If a packet matches any of the filters, the entire rule is considered a match, and the HTTP filter mechanism stops checking the other filters. Note however that the cookie filter is always checked even if a packet matches one of the previous content filters. This check occurs because the cookie filter actually changes the content of the packet.

8 Filtering HTTP Content8.3 Filtering Content by URL

69

8

8.3 Filtering Content by URL

8.3.1 Understanding the URL Filter Mechanism

Wind River Firewall lets you establish and maintain a database of specific URLs or keywords that appear in URLs. The URL filter matches the URL in the packet with the database of specific URLs and keywords.You can also list acceptable URLs that the firewall allows to pass.

You first create the database, then add URLs and keywords you want to filter. After creating the database, you enable URL filtering by registering it and specifying the filter's action.

The URL filter has two filtering features: path match and keyword match.

Path Matching

Path matching compares the provided path (host name and file path) to the initial portion of the absolute path for an HTTP packet. For example, if you add the path www.somewebsite.com to the URL list, the firewall treats all of the following URLs as matches for the string:

■ www.somewebsite.com■ www.somewebsite.com/bad■ www.somewebsite.com/bad/a.html

For path matching, supply at least the host name part.

Keyword Matching

Keyword matching means matching any word in the URL. For example, if you add the keyword bad to the URL list, the firewall considers the last two of the previous three URLs as a match.


70

8.3.2 Implementing a URL Filter

Use ipfirewall_http_insert_url_filter( ) to add URLs and keywords to the HTTP filter. This routine takes three arguments:

■ the name of the HTTP filter on which you want to enable a URL filter

■ the URL or keyword to be added to the list

■ a Boolean used to specify whether a URL or a keyword is added. FALSE specifies a URL filter, TRUE a keyword filter.

8.4 Filtering Proxy Traffic

8.4.1 Understanding the Proxy Filter

Proxy Web servers sit between your Web browser and the actual Web server. The use of proxy servers may allow users to circumvent the firewall's content filtering. A proxy filter matches HTTP packets sent to proxy Web servers.

The proxy filter matches HTTP packets sent to a HTTP proxy server on the same destination port to which you attach the proxy content filter.

According to the HTTP version 1.1 specification (see RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1, section 5.1.2), HTTP clients only generate an absolute uniform resource identifier (URI) in requests to proxies.

The URI in the HTTP request line has the following format:

http://www.nnn.nnn/aaa

A direct HTTP request line generally has only the path information (/aaa), without including host information. The Wind River Firewall proxy filter uses this characteristic to differentiate direct HTTP traffic from proxy traffic.

8 Filtering HTTP Content8.5 Filtering Java Applets

71

8

8.4.2 Implementing Proxy Filtering

Use ipfirewall_http_insert_url_filter( ) to enable a proxy filter. This routine has one input argument—the name of the HTTP filter on which you want to enable the proxy content filter.

8.5 Filtering Java Applets

8.5.1 Understanding the Java Applet Filter

A Web client triggers a Java applet by reacting to either the HTML APPLET tag (for HTML version 1.0) or the OBJECT tag (for HTML version 1.1) in an incoming HTML page. Both tags specify the name of the Java applet class object or .jar file.

To match Java applets and ActiveX controls, Wind River Firewall matches the GET requests for files with .class and .jar extensions.

8.5.2 Implementing a Java Applet Filter

Use ipfirewall_http_insert_java_filter( ) to enable a Java filter. This routine has one input argument—the name of the HTTP filter on which you want to enable the Java content filter.

8.6 Filtering ActiveX Controls

8.6.1 Understanding the ActiveX Filter

A Web client runs an ActiveX control by reacting to the embedded file specified by an OBJECT tag in an incoming HTML page.


72

To match ActiveX controls, Wind River Firewall matches the GET requests for files with .cab and .ocx extensions.

8.6.2 Implementing an ActiveX Filter

Use ipfirewall_http_insert_activex_filter( ) to enable an ActiveX filter. This routine has one input argument—the name of the HTTP filter on which you want to enable the ActiveX content filter.

8.7 Filtering Cookies

8.7.1 Understanding the Cookie Filter

When a Web client contacts a Web server, the first response from the server has a SET cookie field in the packet header. Subsequent packets from the Web client back to the Web server may contain cookie information in the header in the following form:

"Cookie: cookie_data"

The Web client may also have cookie information set by JavaScript code running on the Web client. The Wind River Firewall cookie filter blocks cookie information from being returned to a Web server by overwriting the cookie data with the same length of junk data in the message that the Web client sends back to the Web server, after adjusting the TCP checksum.

8.7.2 Implementing a Cookie Filter

Use ipfirewall_http_insert_cookie_filter( ) to enable a cookie filter. This routine has one input argument—the name of the HTTP filter on which you want to enable the cookie content filter.

8 Filtering HTTP Content8.8 Program Example

73

8

8.8 Program Example

The code to add a HTTP filter and enable individual content filters would look similar to the example below.

ipfirewall_http_add_filter("http_test");ipfirewall_http_insert_url_filter("http_test", "www.somewebsite.com", IP_FALSE);

ipfirewall_http_add_filter("http_key");ipfirewall_http_insert_url_filter("http_key", "bad", IP_TRUE);

ipfirewall_http_add_filter("http_proxy");ipfirewall_http_insert_proxy_filter("http_proxy");

ipfirewall_http_add_filter("http_java");ipfirewall_http_insert_java_filter("http_java");

ipfirewall_http_add_filter("http_activex");ipfirewall_http_insert_activex_filter("http_activex");

ipfirewall_http_add_filter("http_cookie");ipfirewall_http_insert_cookie_filter("http_cookie");

The preceding example is part of the firewall code and will be included if the compile time macro IPFIREWALL_USE_HTTP_FILTER_TEST is defined.


74

75

PART II

Wind River NAT

9 Overview of Wind River NAT ............................. 77

10 Configuring and Building Wind River NAT ...... 85

11 NAT Tutorial ........................................................ 93

12 NAT Fundamentals ............................................. 101

13 Application-Level Gateways .............................. 117


76

77

9Overview of Wind River NAT

9.1 Introduction 77

9.2 Product Overview 78

9.3 Additional Documentation 82

9.1 Introduction

Wind River Network Address Translation (NAT) is an implementation of Traditional NAT. Its key feature is to translate private network addresses, which may be invalid outside the private network, into addresses recognizable to a public network such as the Internet.

The chief advantage of this feature is that addresses on the private network are hidden from the public Internet, providing a measure of security. A second advantage, realized with certain varieties of NAT, is that scarce IP addresses are conserved, reducing network administration costs.

NAT is typically used on routers and gateways that forward packets between private and public networks, such as home or small office Internet gateways.

You can develop NAT rules using a simple keyword syntax and load these rules with a rule file, the Wind River NAT API, or the nat shell command.


78

About the Addresses Used in Examples

According to RFC 1918, the Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IPv4 address space for private internets:

■ 10.0.0.0 - 10.255.255.255 (10/8 prefix)

■ 172.16.0.0 - 172.31.255.255 (172.16/12 prefix)

■ 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

These address spaces are also useful in networking examples, which need to function but also need to avoid public Internet addresses.

In this book, the 10/8 prefix, the largest of the three private address spaces, represents the public Internet. To represent a private address space, this book uses the 192.168/16 prefix.

9.2 Product Overview

Wind River NAT supports the following features:

■ Basic NAT

■ Network Address Port Translation (NAPT)

■ Bidirectional NAT

■ Network Address Translation-Protocol Translation (NAT-PT)

■ NAPT-PT

■ demilitarized zone (DMZ) host

■ application-level gateways (ALGs)

■ port triggering

Wind River NAT supports these NAT modes to provide a comprehensive framework for address translation and communication between private and public networks. Together, these modes optimize security and connectivity while conserving public IP addresses.

The following sections provide additional information on the Wind River implementation of each NAT mode.

9 Overview of Wind River NAT9.2 Product Overview

79

9

Basic NAT

In Basic NAT, a router or gateway connects a private network to a public network, using one public IP address for each connection to an external host. As outgoing packets from hosts on the private network pass the router, NAT replaces the source addresses in those packets with the router’s public IP address. This translation, or mapping, conceals private network addresses from hosts on the public network.

NAT records the mapping of private host source addresses to public host destination addresses. When a reply arrives from a public host, NAT uses this mapping to route the reply to the correct host on the private network.

In Basic NAT mode, Wind River NAT permits private hosts to initiate connections with hosts on the public Internet. These connections, which are outbound from the private network to the public, are considered unidirectional at initiation. Once initiated, such connections become bidirectional.

NAPT

NAPT extends the capabilities of Basic NAT by translating the port field in outgoing packet headers in addition to the source address field. This feature allows the gateway to handle multiple simultaneous connections from multiple hosts on the private network to the same server on the public side.

A device running NAPT can connect an entire department or small office to the Internet using only a single global IP address. This feature saves network administration costs by reducing the number of public IP addresses that must be purchased or leased from a service provider.

Bidirectional NAT

In Bidirectional NAT, hosts on a public network can initiate connections to hosts on the private network. Wind River NAT supports static translation entries to permit such connections.

NAT maps private network addresses to globally unique public addresses as connections are established in either direction. Public network hosts access private network hosts using DNS for address resolution, so a DNS ALG is required to enable Bidirectional NAT if the name server is located on the private side of the NAT gateway.


80

NAT-PT

In NAT-PT, the router is equipped with a dual TCP/IP stack so that it can translate IPv6 addresses to IPv4 addresses. This facility establishes a transparent communication path between IPv6 networks and IPv4 networks, allowing IPv6 hosts on the private network to communicate with IPv4 hosts on the public network. Address bindings are dynamic. NAT-PT operation is unidirectional from the private network to the public at initiation. Public network hosts can only respond to connections initiated from private network hosts. They cannot initiate their own connections.

NAPT-PT

NAPT-PT combines the capabilities of protocol translation with port translation to enable transparent communication between IPv6 and IPv4 hosts, using a single IPv4 address. NAT-PT translates the TCP/UDP ports of the IPv6 hosts into the TCP/UDP ports of the registered IPv4 host.

The advantage of combining protocol translation with port translation is that it makes more efficient use of the address pool available for mapping connections between IPv6 hosts and IPv4 hosts. NAPT-PT allows an IPv4 host to conduct simultaneous TCP and UDP sessions using a single IPv4 address—up to 63 k for each protocol—rather than requiring a unique IPv4 address for each session.

DMZ Host

DMZ host functionality lets you specify a host (on the private network) to which the router forwards all packets not handled by NAT. The private network host that receives the forwarded packets is known as the DMZ host. This host, although resident on a private network, is still externally accessible to connections initiated on the external network. For more information, see 12.11 Configuring a DMZ Host, p.111.

NAT-T

Wind River NAT supports the following two variants of NAT-Traversal:

■ RFC 3947, Negotiation of NAT-Traversal in the IKE

9 Overview of Wind River NAT9.2 Product Overview

81

9

■ RFC 3519, Mobile IP Traversal of Network Address Translation (NAT) Devices

These features are part of the IKE and Mobile IP components. For further information on their implementation, see the Wind River IKE for VxWorks Programmer’s Guide or the Wind River Network Stack for VxWorks Programmer’s Guide, Volume 1: Transport and Network Protocols.

Application-Level Gateways

All NAT modes include IP address translation. NAPT also includes the translation of TCP/UDP port entries. However, some applications use IP addresses and port numbers inside their data payloads. To extend the capabilities of NAT and enable it to operate with such applications, ALGs can modify such information within data payloads. Because different applications employ different protocols or data formats, ALGs must be customized for each application.

Wind River NAT includes the ALG software for the following protocols and applications:

■ DNS■ FTP■ H.323■ ICMP■ IPsec Passthrough ■ PPTP Passthrough■ port triggering

ICMP is built into Wind River NAT. You can also create additional ALGs. For more information, see 13. Application-Level Gateways.

Port Triggering

Port triggering lets you dynamically open inbound ports to external connections based on outbound traffic. For information on port triggering, see 13.9 Port Triggering, p.126.

API for Integrating a Custom ALG with Wind River NAT

Wind River NAT includes a set of API routines you can use to integrate a custom ALG with Wind River NAT. Using this API, your ALG can create NATmappings to let incoming traffic through, modify application-specific payloads, and do whatever is needed to get the application running across disparate address realms.


82

RFC 3022 Checksum Adjustment

Each time Wind River NAT makes an address and port translation, it adjusts the checksums in the IP header and in the TCP/UDP headers. To minimize overhead, the checksum adjustment is made according to the checksum adjustment algorithm suggested in RFC 3022, 4.2 Checksum Adjustment, rather than calculating the checksums from scratch.

Configuration Interfaces

Wind River NAT provides the following configuration interfaces:

■ APIs■ shell command

API Library and Shell Command

The public API library contains utilities for the translation of addresses, ports, and protocols. These routines are useful for testing and debugging. The nat shell command provides access to the same functionality.

9.3 Additional Documentation

The Wind River NAT part of this manual focuses on configuring and using Wind River NAT. Although the manual includes some general information about NAT, it is beyond the scope of this manual to provide an exhaustive general discussion of NAT technology.

The following sections describe additional documentation about the technologies described in this book.

Wind River Documentation

The following Wind River documents present information associated with Wind River Firewall:

■ Wind River VxWorks Platforms Getting Started—describes how to install and build components of the Wind River VxWorks Platforms product.

9 Overview of Wind River NAT9.3 Additional Documentation

83

9

■ Wind River VxWorks Platforms Release Notes—describes reported and resolved software defects and new features for the Wind River VxWorks Platforms product.

■ VxWorks Kernel Programmer’s Guide ■ VxWorks Application Programmer’s Guide■ VxWorks Command-Line Tools User’s Guide■ Wind River Workbench User’s Guide

Books

■ Kumar, V., Korpi, M., and Sengodan, S. IP Telephony with H.323: Architectures for Unified Networks and Integrated Services. New York: John Wiley & Sons, Inc., 2001.

RFCs

Supported RFCs

■ RFC 2663, IP Network Address Translator (NAT) Terminology and Considerations. August 1999, Srisuresh, P. and Holdrege, M. See:


■ RFC 2766, Network Address Translation—Protocol Translation (NAT-PT). February 2000, Tsirtsis, G. and Srisuresh, P. See:


■ RFC 3022, Traditional IP Network Address Translator (Traditional NAT). January 2001, Srisuresh, P. and Egevang, K. See:


Related RFCs

■ RFC 1034, Domain Names - Concepts and Facilities. November 1987, Mockapetris, P. See:


■ RFC 1035, Domain Names - Implementation and Specification. November 1987, Mockapetris, P. See:






84

■ RFC 1701, Generic Routing Encapsulation (GRE). October 1994, Hanks, S., Farinacci, D., and Traina, P. See:


■ RFC 1886, DNS Extensions to support IP version 6. December 1995, Thomson, S., Huitema, C. See:


■ RFC 1918, Address Allocation for Private Internets. February 1996, Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and Lear. E. See:


■ RFC 2406, IP Encapsulating Security Payload (ESP). November 1998, Kens, S., and Atkinson, R. See:


■ RFC 2408, Internet Security Association and Key Management Protocol (ISAKMP). November 1998, Maughan, D., Schertler, M., Schneider, M., and Turner, J. See:


■ RFC 2428, FTP Extensions for IPv6 and NATs. September 1998, Allman, N., Ostermann, S., and Metz, C. See:

ftp://ftp.isi.edu/in-notes/rfc2428.txt

■ RFC 2874, DNS Extensions to Support IPv6 Address Aggregation and Renumbering. July 2000, Crawford, M., Huitema, C. See:



85

10Configuring and Building

Wind River NAT

10.1 Introduction 85

10.2 Configuring and Building Wind River NAT 85

10.3 Configuring VxWorks with Wind River NAT 86

10.4 Building the VxWorks Image 91

10.5 Booting the Target and Testing Wind River NAT 92

10.1 Introduction

This chapter describes how to configure Wind River NAT and include it in a VxWorks image, which can run on a target device to provide secure communications. You must perform these tasks before you set up NAT.

10.2 Configuring and Building Wind River NAT

Wind River NAT is provided in source code as an integral part of the network stack. The stack must be built before it (or any of its components) can be used with a kernel application. It must be built as a static library for use in kernel mode.


86

Wind River NAT is built as part of the top-level build for your Wind River Platform product. For information about this build, see the Wind River Platforms Getting Started. Wind River recommends that you use the output of this build.

Once you have built the network stack and its NAT component, you can integrate it with your NAT application. See 10.3.5 Adding a Hook for NAT Rules, p.91.

10.3 Configuring VxWorks with Wind River NAT

10.3.1 Components and Parameters

Required Components

The components required for Wind River NAT are the following:

IPNAT_AUTOPORT_END_INTERVALEnd of the interval used for automatically generated NAT ports. Default: 29,999.

IPNAT_AUTOPORT_START_INTERVALStart of the interval used for automatically generated NAT ports. Default: 29,000.

IPNAT_ICMP_MAPPING_TIMEOUTSpecifies the timeout in seconds until an ICMP mapping expires. Default: 5.

IPNAT_MAX_MAPPINGThe maximum number of active NAT mappings. Default: 1,000.

IPNAT_TCP_MAPPING_TIMEOUTSpecifies the timeout in seconds until a TCP mapping expires. Default: 432,000 seconds (5 days).

IPNAT_UDP_MAPPING_TIMEOUTSpecifies the timeout in seconds until a UDP mapping expires. Default: 60.

IPNAT_OTHER_MAPPING_TIMEOUTSpecifies the timeout in seconds until other mappings from protocols other than ICMP, UDP and TCP expire. Default: 60.

10 Configuring and Building Wind River NAT10.3 Configuring VxWorks with Wind River NAT

87

10

10.3.2 Wind River NAT and Symmetric Multiprocessing

If you build Wind River NAT for use on a target configured with symmetric multiprocessing (SMP), the SMP capability of NAT is automatically enabled. The NAT hooks will run in parallel on multiple cores, resulting in improved performance.

For information on configuring VxWorks with SMP, see Wind River VxWorks Platforms Getting Started.

10.3.3 Configuring Wind River NAT to Run on a Gateway

If you are building a router (gateway) that includes Wind River NAT, you will need at least two network interfaces. The following sections describe how to add and configure the necessary interfaces.

Which procedure you follow depends on whether your BSP supports VxBus. If it does, the system will automatically detect any additional drivers, and you only need to configure them. In such a case, perform only the procedure described in Configuring an Additional Interface, p.88.

Checking for VxBus Support

You can tell whether your BSP supports VxBus by examining the following file:

target/config/bspName/config.h

If this file contains the line #define INCLUDE_VXBUS, it supports VxBus, and you do not need to perform a separate procedure to add a network interface.

If this file does not contain the line #define INCLUDE_VXBUS, you must edit the file to add the necessary interfaces. See Adding a Network Interface—Legacy END Drivers, p.88, for further information.

! CAUTION: The NAT components are included by default. Excluding these components in Workbench also excludes other components required by the network stack. For instructions on safely excluding firewall, see 10.3.4 Excluding NAT Components, p.90.


88

Adding a Network Interface—Legacy END Drivers

Perform this procedure only if your BSP does not support VxBus.

Before configuring , check whether your BSP supports a second interface. If not, you can add that support. To learn whether your BSP already supports a second interface and how to enable it, read the BSP reference page in the Workbench online help.

To add a network interface, you must edit target/config/bspName/configNet.h.

Each BSP requires specific edits to add support for an interface. The following example shows how to add support for an additional fei interface for the pcPentium BSP.

Example 10-1 Adding a Network Interface to a BSP (FEI Driver)

1. Locate the following lines:

#ifdef INCLUDE_FEI_END{ 0, FEI82557_LOAD_FUNC, FEI82557_LOAD_STRING, FEI82557_BUFF_LOAN,NULL, FALSE},

#endif /* INCLUDE_FEI_END */

2. Add the following line just before the #endif line:

{ 1, FEI82557_LOAD_FUNC, FEI82557_LOAD_STRING, FEI82557_BUFF_LOAN,NULL, FALSE},

3. If more than two interfaces are necessary, repeat step 2, incrementing the interface number for each additional interface.

4. Ensure that installDir/vxworks-6.x/target/config/bspName/config.h includes the following define:

#define INCLUDE_FEI_END

If you are using a different BSP or interface, read the BSP reference page in Workbench online help.

Configuring an Additional Interface

Once you have added a network interface, you must configure it with an IP address or network mask. You can configure the interface at build time or at run time.

10 Configuring and Building Wind River NAT10.3 Configuring VxWorks with Wind River NAT

89

10

Configuring an Additional Interface at Build Time

To configure an interface at build time, include an INCLUDE_IPNET_IFCONFIG_N component (one for each interface). Each of these components contains an IFCONFIG_N parameter.

For each IFCONFIG_N, edit the following fields:

ifnameSpecifies the name of the Ethernet interface, for example, ifname fei0. If the interface name is missing after ifname (the default setting), the END device name will be used.

devnameSpecifies the driver to which this interface should attach itself, for example, fei0. The default setting driver instructs VxWorks to retrieve the device name from the device boot parameters.

inetSpecifies the interface IPv4 address and subnet, for example, inet 10.1.2.100/24. Instead of IPv4 address, the following syntaxes can also be used:

inet driver (default)Specifies that the address and mask should be read from the BSP.

inet dhcpSpecifies that the address and mask should be received from a DHCP server. The gateway might also be received from that server (depending on the DHCP server configuration).

inet rarpSpecifies that the address and mask should be received from an RARP server.

gatewaySpecifies the default gateway used for IPv4, for example, gateway 10.1.2.1. Only one default gateway can be specified. gateway driver can be used to take the gateway from the boot parameters.

inet6Specifies the interface IPv6 address and subnet, for example, inet6 3ffe:1:2:3::4/64. The tentative keyword can be inserted before the address if the stack should perform duplicate address detection on the address before assigning it to the interface, for example, tentative 3ffe:1:2:3::4/64.


90

gateway6Specifies the default gateway used for IPv6. Only one default gateway can be specified.

Configuring an Additional Interface by Editing config.h

You can also configure an additional interface by editing the config.h file for your BSP—that is, target/config/bspName/config.h. In this case, specify the values for IFCONFIG_N directly in the file, using a #define statement. For example:

#define IFCONFIG_1 "ifname", "devname driver","inet driver","gateway driver", \ "inet6 3ffe:1:2:3::10/64"

Configuring an Additional Interface at Run Time

If you are not ready to configure the interface at build time, you can configure it at run time. This procedure consists of two steps:

1. Attaching a protocol.

2. Configuring the address and subnet mask.

To perform these steps, run an ipAttach shell command on the target, followed by an ifconfig. For example:

[vxWorks *] # ipAttach 1,"fei"[vxWorks *] # ifconfig "fei1 10.0.0.2 netmask 255.255.255.0 up"

The parameters for the ifconfig command are specified in Configuring an Additional Interface at Build Time, p.89.

10.3.4 Excluding NAT Components

NAT is a component of the TCP/IP stack. To exclude it, you must modify a configuration file and rebuild your Platform. Excluding NAT in Workbench also excludes other critical components that are required by the network stack.

To exclude NAT, follow this procedure:

1. Locate the following file:

installDir/components/ip_net2-6.5/ipnet2/config/ipnet_config.h

2. Locate the following command: #define IPNET_USE_NAT

3. Comment out this line.

4. Rebuild your Platform.

10 Configuring and Building Wind River NAT10.4 Building the VxWorks Image

91

10

10.3.5 Adding a Hook for NAT Rules

If you plan to add NAT rules at startup by calling ipnet_nat_add_rule( ), add a hook for those rules. To create this hook, add a USER_APPL_INIT macro in the BSP. For example:

#define INCLUDE_USER_APPL #define USER_APPL_INIT \{ \IMPORT void usrNATAddRules();\usrNATAddRules();\}

usrNATAddRules( ) is a sample routine only, which is not distributed with your Wind River Platform. You must create it (or a routine with a similar name) yourself.

10.4 Building the VxWorks Image

For information about building VxWorks with Wind River Firewall, including build options, image types, and so on, see the Wind River Workbench User’s Guide.

When you have finished building the image, verify that NAT was included in the build. See 10.5 Booting the Target and Testing Wind River NAT, p.92, for detailed instructions.

NOTE: Some BSPs include sample definitions of INCLUDE_USER_APPL and USER_APPL_INIT. If so, remove those examples. Define INCLUDE_USER_APPL and USER_APPL_INIT only once.

NOTE: If you see an error message indicating undefined references to ipfirewall routines, you must rebuild your Platform. For instructions, see the getting started guide for your Platform.


92

10.5 Booting the Target and Testing Wind River NAT

1. Boot the target with your VxWorks image.

2. Verify that NAT was included in the build by issuing the following shell command:

[vxWorks *] # nat -V

The current version appears on the target shell.

NOTE: To run this command, you must switch to the command interpreter shell before running the nat command. Type cmd at the command prompt. Then run the nat command.

93

11NAT Tutorial


11.2 Network Configuration 94

11.3 Implementing NAT 95

11.1 Introduction

This chapter contains a tutorial that will guide you in implementing NAT. The tutorial provides information on writing NAT rules and testing the NAT system. It also provides information on using Wind River Workbench to develop and deploy NAT.


94

11.2 Network Configuration

The NAT system created in this tutorial is designed to run on a simple network consisting of the following nodes:

■ a public host■ two private hosts■ a gateway with two interfaces■ a switch (optional)

Table 11-1 provides configuration information for each node.

Table 11-1 Tutorial Network—Nodes and Software Requirements

Node IP Address Required Software

A (public host) 10.31.100.21 ■ FTP server■ Web server■ Web browser■ Ping command

B (private host) 192.168.0.2 ■ FTP client■ Web server■ Web browser■ Ping command■ Telnet client command

C (private host) 192.168.0.3 ■ FTP client■ Web server■ Web browser■ Ping command■ Telnet client command

(optional)

D (gateway) ■ 10.31.151.155 on fei0 (public interface)

■ 192.168.0.1 on fei1 (private interface)

NOTE: Hosts B and C must be configured with a route to the 10.31.0.0/16 network via 192.168.0.1.Host A must not be configured with a route to the 192.168.0.0/24 network.

11 NAT Tutorial11.3 Implementing NAT

95

11

If desired, this network can also be connected to a corporate LAN and, through that LAN, to the Internet. Figure 11-1 illustrates this configuration.

11.3 Implementing NAT

This tutorial explains how to create a simple gateway using NAT rules.

Figure 11-1 Tutorial Network Configuration

Switch

Switch

Corporate LAN

Internet

A (public host)

B (private host) C (private host)

D (gateway)

192.168.0.1 (fei1)10.31.151.155 (fei0)


96

11.3.1 NAT Rules

The rule set in this tutorial implements the following policy:

■ an FTP ALG called when a TCP packet crosses port 21

■ NAPT for TCP and UDP packets, using a source port in the 18000:18999 interval for translation

■ NAPT for ICMP packets, using a source port in the 19000:19999 interval for translation

■ Basic NAPT for other protocols

Note the order in which these features are implemented. The first rule enables the FTP ALG to ensure that this rule is parsed before the packet matches an address or port specification in a NAT, NAT-PT, or NAPT rule. (See 12.2 NAT Operation, p.102 for further information.)

No services are available on any internal host.

11.3.2 Writing Rules

This section describes how to develop the rules to fulfill the security policy described in 11.3.1 NAT Rules, p.96. All rules should be added to the usrAppInit.c file in your Workbench NAT project.

Step 1: Implement the FTP ALG

Create a rule that implements the FTP ALG. To create this rule, call the ipnet_nat_add_rule( ) routine, using the appropriate keywords as parameters. Use the following routine:

ipnet_nat_add_rule("map fei0 0/0 -> 0/32 proxy port 21 ftp/tcp"); \

NOTE: The steps in the following sections assume you have installed and built your Platform. For installation and build instructions, see the getting started guide for your Platform.This tutorial assumes that you have already connected the required hardware, created a Wind River NAT project, and added a hook for NAT rules. If you have not already performed these tasks, do so now. For further information, see 11.2 Network Configuration, p.94, and 10.3.3 Configuring Wind River NAT to Run on a Gateway, p.87.


97

11

Step 2: Implement NAPT for TCP and UDP Packets

Create a rule that implements NAPT for TCP and UDP packets. Use the following routine:

ipnet_nat_add_rule("map fei0 0/0 -> 0/32 portmap tcp/udp 18000:18999"); \

Step 3: Implement NAPT for ICMP Packets

Create a rule that implements NAPT for ICMP packets. Use the following routine:

ipnet_nat_add_rule("map fei0 0/0 -> 0/32 icmpidmap icmp 19000:19999"); \

Step 4: Implement Basic NAPT for Other Protocols

Create a rule that implements Basic NAPT for other protocols. Use the following routine:

ipnet_nat_add_rule("map fei0 0/0 -> 0/32"); \}

Complete NAT Code

When complete, the NAT code should look something like this:

/*DESCRIPTIONInitialize user application code.*/

#include <vxWorks.h>#if defined(PRJ_BUILD)#include "prjParams.h"#endif /* defined PRJ_BUILD */


/* Example NAT ruleset for a Home/SOHO gateway. The internal network is on 'fei1' and the external on 'fei0'. The ruleset enables NAPT for TCP, UDP and ICMP request/reply and basic NAT for other protocols. The first rule enables the FTP ALG. No services are available on any internal host. */

#define USER_APPL_INIT { \IMPORT int ipnet_nat_add_rule(const char *rule); \/* Enable the FTP ALG */ \ipnet_nat_add_rule("map fei0 0/0 -> 0/32 proxy port 21 ftp/tcp"); \

NOTE: To include the ALG in the VxWorks image, enable the macro #define IPNET_USE_NAT_FTP_ALG.


98

/* Enable NAPT for TCP and UDP */ \ipnet_nat_add_rule("map fei0 0/0 -> 0/32 portmap tcp/udp 18000:18999"); \/* Enable NAPT for ICMP */ \ipnet_nat_add_rule("map fei0 0/0 -> 0/32 icmpidmap icmp 19000:19999"); \/* Enable basic NAPT for other protocols */ \ipnet_nat_add_rule("map fei0 0/0 -> 0/32"); \}

/******************************************************************************** usrAppInit - initialize the users application*/

void usrAppInit (void){

#ifdef USER_APPL_INITUSER_APPL_INIT; /* for backwards compatibility */

#endif}

11.3.3 Testing the NAT Implementation

Test the NAT gateway to verify that it is working by following this procedure.

1. Begin by disabling NAT. To do so, issue the following command from a target shell:

[vxWorks *] # nat -D


■ ping from B to A■ ping from C to A

With NAT disabled and no direct route connecting host A to the private 192.168.0/0 network, these tests should fail.

3. Enable NAT by issuing the following command from a target shell:

[vxWorks *] # nat -E



99

11


■ ping from B to A■ ping from C to A

With NAT enabled, these pings should succeed.

5. Perform also these additional tests:

■ Web browsing from B to A ■ Web browsing from C to A■ FTP from B to A (with FTP in active mode)■ FTP from C to A (with FTP in active mode)

These tests should all succeed.

6. Check NAT statistics by issuing the following shell command:

[vxWorks *] # nat -s

Translated packets in and out, added mappings, and expired mappings should be all greater than 0. The NAT statistics will look something like this:

translated: in 87 out 45nomatch: in 0 out 0invalid: in 0 out 0dropped: in 0 out 0added mappings: 14expired mappings: 14failed mappings: 0


100

101

12NAT Fundamentals


12.2 NAT Operation 102

12.3 Elements of a NAT Rule 105

12.4 Methods for Writing Rules 106

12.5 Configuring Basic NAT 107

12.6 Configuring NAPT 108

12.7 Configuring Bidirectional NAT 109

12.8 Configuring NAT-PT 110

12.9 Configuring NAPT-PT 111

12.10 Sample Rule Set—Simple NAT Router 111

12.11 Configuring a DMZ Host 111

12.12 Enabling and Disabling NAT 112

12.13 Adding and Removing NAT Rules 112

12.14 Saving and Restoring NAT Rules 115

12.15 Viewing NAT Information 115


102

12.1 Introduction

This chapter describes core NAT concepts, including the elements of a NAT rule, the processing of rules, and different methods for writing rules. It also describes how to configure NAT to operate in different modes and how to configure a DMZ host.

12.2 NAT Operation

Wind River NAT is designed for use on routers and gateways that forward packets between private networks and a public network, such as the Internet. NAT relies on the normal forwarding mechanism in the TCP/IP stack. Packets received from the private network are forwarded by the stack and then intercepted by NAT for translation before being handed over to the driver. Similarly, packets received from the Internet are intercepted by NAT for translation and then forwarded to the private network.

You can save NAT rules in a text file, which you can store anywhere on the system. NAT parses the rules from the top down and stops parsing when it finds a matching rule. Therefore it is important that rules are added in the right order to ensure complete processing of all packets.

For optimal results, arrange rules in the following order:

1. ALG rules

2. NAPT rules

3. Basic NAT or NAT-PT rules

4. Bidirectional NAT rules

12.2.1 Outbound Packets

NAT processes outbound packets by translating their source addresses, protocols, and ports, as applicable, and recording the translations for subsequent use in the processing of inbound packets. The following sections provide additional detail on the various NAT modes.

12 NAT Fundamentals12.2 NAT Operation

103

12

NAT and NAPT Operation

NAT compares outbound packets from the private network with the Basic NAT and NAPT rules in its rule set. If a packet matches a rule, NAT translates the source address as specified in the rule. If the rule also specifies port translation, NAT translates the port as well.

When the packet is translated, NAT records, or maps, the combination of source and destination addresses, protocol, and ports for future use. If the protocol is UDP, TCP, or ICMP echo request, NAT also maps the source and destination port or the echo request identifier. Subsequent outbound packets are checked first against such mappings, then against the NAT and NAPT rules. Mappings are also used for the subsequent translation and routing of inbound packets received in response to outbound packets.

NAT-PT and NAPT-PT Operation

NAT-PT intercepts IPv6 packets outbound from the private network and compares them with the NAT-PT rules in its rule set. If a packet matches a rule, its address is translated to IPv4 format and forwarded through the router to the Internet. NAT-PT records the combination of addresses for future use and marks the mapping as NAT-PT-originated. This mapping is used for the subsequent translation and routing of inbound packets received in response to outbound packets.

NAT-PT Configuration Note

To connect to IPv4 hosts on the Internet, IPv6 hosts on a private network must be configured to route their packets to the PREFIX::/96 network. Alternately, this configuration can be applied to the NAT-PT router.

The PREFIX network is an arbitrarily chosen bogus network. If a user on the IPv6 network wishes to ping the host 192.42.198.5, the following command would be required:

[vxWorks *] # ping PREFIX::192.42.198.5

For further information on NAT-PT, see RFC 2766.


104

Handling of Fragments

Fragmented outbound packets can cause problems for NAT gateways. (Incoming packets from the outside of the NAT do not cause any problems because the router reassembles packets before applying NAT rules.)

Fragmented packets coming from the private network can cause problems if the the fragments arrive out of order. If the second fragment arrives before the first, it cannot be matched against NAPT rules and may be translated incorrectly. However, most TCP/IP stacks will send the fragments in order and there are typically no routers on the private network that can cause the fragments to be lost or reordered. When the first fragment transmitted is the first to arrive, a mapping is added, which can then be used by the second fragment. All fragments are thereby translated correctly.

Fragments may also cause problems for ALGs, because the ALG routine does not have access to the complete packet at the same time. When the routine cannot access the complete packet, problems may occur in checksum recalculation. For this reason, ALGs cannot change the application data for fragmented packets. Also, if the second fragment arrives before the first, the ALG will never be called.

Wind River NAT-PT implementation has some additional limitations for fragments:

■ Fragmented TCP packets and ICMP echo requests are not translated.

■ UDP packets are translated with a zero checksum, which is allowed for IPv4 UDP.

12.2.2 Inbound Packets

Inbound packets from the Internet receive slightly different processing. NAT compares the packet against its active NAT and NAPT mappings to determine if the packet should be forwarded to a host on the private network or to the NAT router itself. If NAT finds a relevant mapping, it translates the packet’s destination address and port to the address and port of the specified private host. If the packet does not match any active mappings, NAT compares it with the Bidirectional NAT rules in its rule set. If NAT finds a matching bidirectional rule, it maps the combination of public source and private destination addresses—and ports, if applicable—for future use, then performs the appropriate translations and forwards the packet to the specified private network host.

12 NAT Fundamentals12.3 Elements of a NAT Rule

105

12

DMZ Host

A DMZ host is a computer on the private network to which to the router forwards all packets not handled by NAT. This host, although resident on a private network, is still externally accessible to connections initiated on the external network.

Preserving Access to Services on a Gateway Running a DMZ Host

If the NAT rule set designates a DMZ host, all normal service requests are forwarded to that host. As a result, all services normally available on the gateway (such as an FTP server, Web server, or Telnet) are effectively disabled for the gateway. If you need to preserve the availability of these services on the gateway, you must add Bidirectional NAT rules that redirect the services to the gateway. It is important that these rules are added before the DMZ host rule. Otherwise the DMZ host rule will override the redirection rules. See 12.11 Configuring a DMZ Host, p.111, for further information and sample rules.

ICMP Requests to a Gateway Running a DMZ Host

Incoming echo requests (pings) to the NAT router are normally sent up to the router’s host stack. However, if NAT has been configured with a DMZ host rule, the ping will be sent through the router to the DMZ host. You can override this behavior by placing a Bidirectional NAT rule before the DMZ host rule that redirects the echo request to a specific host on the private network or to the NAT router itself. See 12.11 Configuring a DMZ Host, p.111, for further information and sample rules.

12.3 Elements of a NAT Rule

Each NAT rule consists of the following elements:

■ an action to be taken, such as map, rdr (redirect), or pt (protocol translation)

■ a network interface specification

■ a pair of addresses for translation

■ a hyphen and greater than sign (->) or the keyword to to join the translated addresses

■ a port specification


106

The first four parameters are required. The last is optional.

Note that the keyword to can be used instead of ->. This practice is useful with shells like bash and others that use the > character for other purposes. If you are using the VxWorks target shell to load a rule, use the to keyword. The hyphen and greater than sign (->) does not work with this shell.

12.4 Methods for Writing Rules

You can develop NAT rules using a simple keyword syntax and load these rules with a rule file, the Wind River NAT API, or the nat shell command.

See 12.13 Adding and Removing NAT Rules, p.112, for further information on adding rules to the active rule set.

12.4.1 Using a Rule File

You can write NAT rules using the keyword syntax shown in the preceding examples in this chapter. Save your NAT rules in a text file and store them wherever you like on the system. You can use any file name or extension, but it is common to use a .cfg extension. The file must reside on the target and be stored on local media.

Empty lines and white space are permitted in a keyword file. The pound sign (#) precedes a comment. You can terminate a line with a comment.

The following example shows a comment line, an empty line, a line with a rule terminated by a comment, and a line with a rule. The entire file consists of four lines.

# example NAT rule file

map fei0 0/0 -> 0/32 # use basic NAT for other protocolsrdr fei0 195.42.198.1 port 0 -> 10.0.0.1 port 0 ip

For further information on a particular keyword, see its reference entry in E. Wind River NAT Keywords.

12 NAT Fundamentals12.5 Configuring Basic NAT

107

12

12.4.2 Using the API

You can also create NAT rules using the Wind River NAT API. All rules should be added to the usrAppInit.c file in your Workbench NAT project. See the reference entry for each routine for a description of the syntax and available parameters.

12.4.3 Using a Shell Command

You can also create NAT rules using the nat shell command. See H. Wind River NAT Shell Command for a description of all available parameters.

12.5 Configuring Basic NAT

Use map rules to configure Basic NAT. For example:

map fei0 192.168.1.0/24 -> 195.42.198.5map fei0 10.0.0.0/8 -> 0/32map fei0 0/0 -> 0/32

The first rule pertains to all packets going out on interface fei0 from any source address in the 192.168.1.0/24 address space. The rule instructs NAT to replace the source address in such packets with the address 195.42.198.5.

The second rule also pertains to all packets going out on interface fei0 from any source address in the 10.0.0.0/8 address space. The rule instructs NAT to replace the source address in such packets with the interface address fei0. The parameter 0/32 instructs NAT to use the address of the interface the packet is sent on as the new source address.

The third rule also pertains to all packets going out on interface fei0 from any source address. The rule instructs NAT to replace the source address in such packets with the interface address of fei0. The parameter 0/0 makes this rule applicable to packets from any source address.

12.5.1 Basic NAT Limitations

The drawback with Basic NAT is that if several hosts on the private network connect to the same host on the public network, there is a risk that responses from


108

the public host will be misrouted to incorrect hosts. This error can occur if private network hosts choose the same source port, which would prevent NAT from distinguishing between responses intended for different private network hosts.

There are two ways to avoid this error. The first is to use NAPT, as described in 12.6 Configuring NAPT, p.108. The second is to use a new source address for each new private host whose address is being translated. The second solution, however, requires the NAT gateway to have access to many public IP addresses that it can use as alias addresses on the same interface.

12.5.2 Mapping between Address Blocks

You can map between address blocks, using the map-block keyword to assign each private address a unique public address.

map-block fei0 192.168.1.0/24 -> 195.42.198.0/24

This rule instructs NAT to translate source address 192.168.1.1 to 195.42.198.1, 192.168.1.2 to 195.42.198.2, and so forth. Note that with map-block rules, the network masks must be in parallel form on both sides of the -> string for the rule to be accepted.

12.6 Configuring NAPT

Use portmap rules to configure NAPT. They begin with the same syntax as map rules but use the portmap keyword to specify additional parameters. For example:

map fei0 10.0.0.0/8 -> 0/32 portmap tcp/udp 9000:10000

The rule above pertains to all packets going out on interface fei0 with a source address matching the 10.0.0.0/8 address space. The rule instructs NAT to perform the following two actions on such packets:

■ Replace the source address with the interface address of fei0.

■ Replace the source port with a port between 9000 and 10000.

This rule is valid for all TCP/UDP packets. You can also write a similar rule for only TCP or UDP packets, using different port intervals for each protocol. For example:

12 NAT Fundamentals12.7 Configuring Bidirectional NAT

109

12

map fei0 0/0 -> 0/32 portmap tcp 9000:10000map fei0 0/0 -> 0/32 portmap udp 19000:20000

For ICMP echo requests/replies, the icmpidmap keyword instructs NAT to translate the port, based on the identifier field of the ICMP echo header. This keyword use similar syntax as portmap but must specify ICMP as the protocol. For example:

map fei0 10.0.0.0/8 -> 0/32 icmpidmap icmp 20000:21000

Note that NAPT can only be used with TCP, UCP and ICMP echo requests. If you want to translate other protocols, the rule set must also include a Basic NAT rule after the NAPT rules. For a program example, see 12.10 Sample Rule Set—Simple NAT Router, p.111.

12.7 Configuring Bidirectional NAT

Use redirect rules (with the rdr keyword) to configure Bidirectional NAT. For example:

rdr fei0 195.42.198.1 port 80 -> 10.0.0.1 port 8080 tcp

This rule instructs NAT to redirect all TCP packets arriving on interface fei0 with the destination address 195.42.198.1 and destination port 80 to a private host with address 10.0.0.1 at port 8080. To a host on the Internet, it looks like a Web server is running on the NAT gateway, but instead all traffic to the Web server is redirected to the private host on port 8080. A Bidirectional NAT rule can also specify udp for UDP packets or tcp/udp to cover both UDP and TCP. There must be one redirection rule for service redirected to a host on the private network.

If protocols other than TCP and UDP must be redirected, there must be redirection rules for each of those protocols. In such cases, the ports are set to zero. The following example shows how to set a rule that redirects GRE packets to a private network host:

rdr fei0 195.42.198.1 port 0 -> 10.0.0.1 port 0 gre

Instead of the protocol name, the protocol number can also be used:

rdr fei0 195.42.198.1 port 0 -> 10.0.0.1 port 0 47


110

12.8 Configuring NAT-PT

Configuring NAT-PT is much like configuring Traditional NAT. The keywords that correspond to the Traditional NAT's map and map-block are pt and pt-block. However, there are some important differences that apply to NAT-PT rules:

■ First, the rule must specify the incoming interface on the IPv6 side of NAT-PT, because that is where NAT-PT intercepts the IPv6 packets and converts them to IPv4 packets.

■ Second, the source address must be an IPv6 address or an IPv6 prefix of up to 128 bits.

■ Third, it is not possible for a NAT-PT rule to specify an outgoing interface address such as 0/32 as the new source address. The NAT-PT rule must explicitly specify a new source address.

The following examples demonstrate theNAT-PT configuration:

pt fei1 3fff::0/120 -> 195.42.198.5pt fei1 ::/0 -> 195.42.198.5pt-block fei1 3fff::0/120 -> 195.42.198.0/24

All three rules above configure Basic NAT-PT. The first rule instructs NAT to forward all IPv6 packets coming in on interface fei1 with a source address of 3fff::0 to 3fff::ff to the IPv4 network. The new source address for the IPv4 packet will be 195.42.198.5.

The second rule is the same as the first, except that the ::/0 parameter makes this rule valid for all incoming IPv6 packets, regardless of their source address.

The third rule works like a map-block rule. An incoming packet with address 3fff::1 will get the IPv4 address 195.42.198.1, 3fff::2 will get the address 195.42.198.2 and so forth.

Wind River NAT does not support Bidirectional NAT-PT.

12 NAT Fundamentals12.9 Configuring NAPT-PT

111

12

12.9 Configuring NAPT-PT

NAPT-PT is similar to NAT-PT. Use the pt keyword in conjunction with portmap and icmpidmap, as shown in the following examples:

pt fei1 ::/0 -> 195.42.198.5 portmap tcp/udp 9000:10000pt fei1 ::/0 -> 195.42.198.5 icmpidmap icmp 20000:21000

12.10 Sample Rule Set—Simple NAT Router

The following example implements a rule set that covers the general requirements for a NAT router.

map fei0 0/0 -> 0/32 portmap tcp/udp 18000:18999map fei0 0/0 -> 0/32 icmpidmap icmp 19000:19999map fei0 0/0 -> 0/32

The first rule enables NAPT for the TCP and UDP protocols. The second rule enables ICMP echo requests. The third sets a Basic NAT rule for other protocols.

12.11 Configuring a DMZ Host

To enable DMZ host support, use a Bidirectional NAT rule. The DMZ host rule must be the last of all rules in the list because it comes into operation only when no other rules matches.

The following example shows a DMZ host rule that forwards all incoming packets not handled by other NAT rules or mappings to the private host with IP address 10.0.0.1. The ports are set to zero in a DMZ host rule, and the protocol ip is used to specify that the rule is valid for all IP protocols.

rdr fei0 195.42.198.1 port 0 -> 10.0.0.1 port 0 ip

You may want to preserve some services on the NAT gateway even if there is a DMZ host rule. You can do so by placing a redirect rule before the DMZ host that


112

redirects a port to the NAT gateway itself. The following example shows how that is done:

rdr fei0 195.42.198.1 port 22 -> 195.42.198.1 port 22 tcprdr fei0 195.42.198.1 port 0 -> 10.0.0.1 port 0 ip

The first rule above preserves access to the NAT gateway's SSH server from the public Internet. The second rule redirects all other combinations of protocol and port to the DMZ host. Note that when redirection is made to the NAT gateway itself, it is not possible to redirect to a different port.

Sometimes it is desirable to let the NAT gateway respond to echo requests even if there is a DMZ host rule. This can be done by placing a redirection rule for the ICMP protocol before the DMZ host rule as shown below:

rdr fei0 195.42.198.1 port 22 -> 195.42.198.1 port 22 tcprdr fei0 195.42.198.1 port 0 -> 195.42.198.1 port 0 icmprdr fei0 195.42.198.1 port 0 -> 10.0.0.1 port 0 ip

12.12 Enabling and Disabling NAT

To enable NAT, type the following shell command:

[vxWorks *] # nat -E

To disable NAT, type the following shell command:

[vxWorks *] # nat -D

12.13 Adding and Removing NAT Rules

There are three ways to add rules to a NAT:


12 NAT Fundamentals12.13 Adding and Removing NAT Rules

113

12

■ by storing the rules in a file and loading the rule set with the nat shell command (see 12.14 Saving and Restoring NAT Rules, p.115)

■ by adding individual rules or an entire rule set with the nat shell command

■ by adding individual rules or an entire rule set with the Wind River NAT API

Once added, rules are stored in an internal table in system memory. By default, NAT appends all rules to this rule set without checking for duplicates or conflicts. If you add rules by shell command or API, NAT automatically appends them to any rule set that was automatically loaded on startup.

Adding Rules

To add a NAT rule, type the following shell command:

[vxWorks *] # nat rule

where rule is the NAT rule you wish to add. The default operation is to append the specified rule to rule set. For example:

[vxWorks *] # nat map fei0 192.168.1.0/24 to 195.42.198.5

makes map fei0 192.168.1.0/24 to 195.42.198.5 the last rule in an existing NAT rule set.

Adding Rules from a File

You can also store NAT rules in a text file with a name such as myrules.cfg. To load all rules in this file at once, specify the file name and path of the rules file. For example:

[vxWorks *] # nat -f myrules.cfg

If you do not specify a path, Wind River NAT tries to open the file in the current working directory. If the file is in a different directory, you can specify the absolute path to it. For example:

[vxWorks *] # nat -f /usr/local/ipnat/config/myrules.cfg

Specifying the Rule Position

By default, new rules are appended to the existing rule list. However, you can insert a rule into a list at a specified location by using the nat shell command with the index parameter (@). The index parameter must be the first parameter in the shell command. In a set of rules, the index begins with 1. Thus:


114

[vxWorks *] # nat map @2 fei0 0/0 to 0/32 icmpidmap icmp 19000:19999

inserts the rule map fei- 0/0 to 0/32 icmpidmap icmp 19000:19999 as the second rule in an existing rule set. If the initial rule set is as follows:

map fei0 0/0 -> 0/32 portmap tcp/udp 18000:18999map fei0 0/0 -> 0/32

the resulting rule set would be as follows:

map fei0 0/0 -> 0/32 portmap tcp/udp 18000:18999map fei0 0/0 -> 0/32 icmpidmap icmp 19000:19999map fei0 0/0 -> 0/32

Removing Rules

To remove a NAT rule, type:

[vxWorks *] # nat -r rule

To remove all NAT rules and active mappings at once, type:

[vxWorks *] # nat -Fr

Clearing Active Mappings

To clear active NAT mappings, type:

[vxWorks *] # nat -C

Checking Rule Syntax

To check the rule syntax, type:

[vxWorks *] # nat -n rule

The -n option parses the rule syntax and reports any errors without adding the rule. When the rule syntax is correct, there is no output. When the rule syntax is incorrect, Wind River NAT reports the error. For example:

[vxWorks *] # nat -f mapp fei0 192.168.1.0/24 to 195.42.198.5

returns the error message:

Unknown action: mapp.

12 NAT Fundamentals12.14 Saving and Restoring NAT Rules

115

12

12.14 Saving and Restoring NAT Rules

Wind River NAT supports nonvolatile (NV) storage to the file system. To implement NV storage, simply save your rule set in a text file. You can use any file name or extension, but it is common to use a .cfg extension. The file must reside on the target and be stored on local media.

You can load these rules by specifying a nat shell command as follows:

[vxWorks *] # nat -f myrules.cfg

12.15 Viewing NAT Information

12.15.1 Viewing Rules and Active Mappings

To view the current NAT rule set, type:

[vxWorks *] # nat -l

The following is an example of a NAT rule set:

NAT RULE TABLE:@1 map fei0 0/0 -> 0/32 proxy port ftp ftp/tcp@2 map fei0 0/0 -> 0/32 portmap tcp/udp 18000:18999@3 map fei0 0/0 -> 0/32 icmpidmap icmp 19000:19999@4 map fei0 0/0 -> 0/32

To view the currently active NAT mappings, type:

[vxWorks *] # nat -m

The following is an example of a NAT mappings table:

NAT MAPPINGS TABLE:10.50.1.1:49236 -> 10.50.2.3:21 proto tcp, (10.50.2.1:29000), state EST/EST, expire in 431999 s seq_start=0, curr_delta=0, prev_delta=010.50.1.2:49236 -> 10.50.2.3:21 proto tcp, (10.50.2.1:29001), state EST/EST, expire in 431999 s seq_start=0, curr_delta=0, prev_delta=0



116

To clear the active NAT mappings, type:

[vxWorks *] # nat -C

To clear the all rules and mappings, type:

[vxWorks *] # nat -F

12.15.2 Viewing and Clearing NAT Statistics

Wind River NAT keeps the following statistics:

■ number of translated packets ■ number of packets not matching any NAT rule ■ number of invalid packets received by NAT ■ number of packets dropped by NAT ■ number of mappings added by NAT ■ number of mappings that expired due to timeout ■ number of mappings that could not be added

To display these statistics, type the following shell command:

[vxWorks *] # nat -s

The following is an example of statistics kept by NAT:

NAT STATISTICS:translated: in 0 out 0nomatch: in 307 out 0invalid: in 0 out 0dropped: in 0 out 0added mappings: 0expired mappings: 0failed mappings: 0

To clear the statistics, type:

[vxWorks *] # nat -Z

117

13Application-Level Gateways


13.2 Configuring ALG Support 118

13.3 ICMP ALG Operation 121

13.4 DNS ALG Operation 121

13.5 FTP ALG Operation 122

13.6 H.323 ALG Operation 123

13.7 IPsec Passthrough ALG Operation 125

13.8 PTTP Passthrough ALG Operation 125

13.9 Port Triggering 126

13.10 Writing a Custom ALG 127

13.11 Sample Rule Sets with ALG Support 132


118

13.1 Introduction

All NAT modes include IP address translation. NAPT also includes the translation of TCP/UDP port entries. However, some applications use IP addresses and port numbers inside their data payloads. To extend the capabilities of NAT and enable it to operate with such applications, ALGs modify such information within data payloads. Because different applications employ different protocols or data formats, ALGs must be customized for each application.

Wind River NAT includes the ALG software for the following protocols and applications:

■ DNS■ FTP■ H.323■ ICMP■ IPsec Passthrough ■ PPTP Passthrough■ port triggering

ICMP is built into Wind River NAT. You can also create additional ALGs, using the proxy keyword and #define commands to enable the appropriate macros. See the following sections for additional information.

13.1.1 API for Integrating a Custom ALG with Wind River NAT

Wind River NAT includes a set of API routines you can use to integrate a custom ALG with Wind River NAT. Using this API, your ALG can create NAT mappings and modify application-specific payloads in order to enable the application to run across the gateway.

13.2 Configuring ALG Support

The keyword used to specify a NAT rule with an ALG is proxy. It is important that proxy rules are specified before other NAT rules to ensure that these rules are parsed before the packet matches an address or port specification in a NAT, NAT-PT, or NAPT rule.

13 Application-Level Gateways13.2 Configuring ALG Support

119

13

The following example shows a proxy rule for the FTP ALG.

map fei0 10.0.0.0/8 -> 0/32 proxy port 21 ftp/tcp

Proxy rules begin exactly like Basic NAT or NAPT rules with the addition of the following elements:

■ the proxy keyword

■ a specification of the trigger port that will cause ALG to be called— typically the well-known port for the service the ALG is meant to handle

■ a string identifying the ALG

■ the protocol that, in combination with the specified port, causes the ALG routine to be called.

The protocol specified in the rule must be the same as the protocol for which the ALG was registered. Proxy rules translate the packets address and port in accordance with NAPT rules, but the new source port is allocated from the automatic port interval, which is set in the IPNAT_AUTOPORT_START_INTERVAL and IPNAT_AUTOPORT_END_INTERVAL components. See 10.3.1 Components and Parameters, p.86, for more information on these NAT system variables.

The sample rule above pertains to all packets going out on interface fei0 with a source address matching the network 10.0.0.0/8. The rule instructs NAT to replace the source address in such packets with the interface address of fei0—but only when the destination port is equal to 21 and the protocol is TCP. The rule also instructs NAT to pass the packet to the ALG routine defined by the identifier ftp.

In some rare cases, it may be necessary for the proxy rule to disable NAPT, because sometimes the protocol does not allow the source port to be changed. For this purpose the nonapt keyword can be added after to the proxy rule. The IKE protocol may require that source port is not changed. The rule below shows an example of the nonapt keyword.

map eth0 0/0 -> 0/32 proxy port 500 ipsec/udp nonapt

You can also add ALG rules for protocols other than TCP or UDP. For example:

map fei0 10.0.0.0/8 -> 0/32 proxy port 0 ipsec/esp

This rule enables the IPsec proxy for all ESP encapsulating security payload (ESP) packets coming from the 10.0.0.0/8 network (RFC 2406). It instructs NAT to set the trigger port to 0 when the protocol is not TCP or UDP. ALG rules can be added for all protocols except ICMP and ICMPv6.

Some ALGs can handle Bidirectional NAT as well as Traditional NAT. To enable an ALG for Bidirectional NAT, simply add the keyword proxy, followed by the


120

identifier of the ALG at the end of the redirection rule. The FTP ALG is an example of an ALG that can handle both Traditional NAT and Bidirectional NAT. The following example shows how to configure Bidirectional NAT to an FTP server on the private network and enable the FTP ALG at the same time.

rdr fei0 195.42.198.1 port 21 -> 10.0.0.1 port 21 tcp proxy ftp

The proxy trigger port is the port to the left of the address join string (->), and the proxy protocol is TCP. You can also enable ALG support for redirection rules for protocols other than TCP or UDP, as shown is the following example:

rdr fei0 195.42.198.1 port 0 -> 10.0.0.1 port 0 gre proxy pptp

Some protocols need ALGs to enable NAT-PT. For example, it may be necessary to translate embedded IPv6 addresses to IPv4 addresses or vice versa. To configure NAT-PT with ALG support, add a NAT-PT rule that specifies the proxy keyword, the ALG identifier, and the protocol in the same manner as Traditional NAT proxy rules. The following example enables the DNS ALG for NAT-PT. DNS typically runs over UDP and uses port 53.

pt fei1 ::/0 -> 195.42.198.5 proxy port 53 dns/udp

Table 13-1 summarizes the ALGs provided by Wind River NAT.

Table 13-1 Wind River NAT ALGs

ALG ID ProtocolSupports Outbound (Traditional NAT)

Supports Inbound (Bidirectional NAT)

Supports NAT-PT

DNS "dns" udp No No Yes

FTP "ftp" tcp Yes Yes Yes

H.323 "h323" tcp Yes Yes No

IPsec Passthrough "ipsec" udp Yes No No

"ipsec" esp Yes No No

PPTP Passthrough "pptp" tcp Yes No No

"pptp" gre Yes No No

Port triggering "example_tcp" tcp Yes No No

"example_udp" udp Yes No No

13 Application-Level Gateways13.3 ICMP ALG Operation

121

13

13.3 ICMP ALG Operation

The ICMP ALG is built into the Wind River NAT software itself. There is no need to create a custom ALG.

13.4 DNS ALG Operation

The Domain Name System (DNS) is commonly used on the Internet to match a host name to an Internet address and vice versa. The DNS protocol is described in RFC 1034 and RFC 1035. Extensions to DNS required for IPv6 are described in RFC 1886 and RFC 2874.

Generally the DNS protocol is NAT-friendly, which means that no ALG is required for NAT operation in Basic mode or NAPT mode when the name server is placed on the outside of the NAT. However, when running in Bidirectional NAT mode with the name server located on the private side of NAT, a DNS ALG is required. This mode is not supported by the DNS ALG. Instead, it is recommended that the name server be located outside of the NAT in this configuration.

A second scenario where a DNS ALG is required is for NAT-PT when a private IPv6 network is behind a NAT-PT router and the name server is located on the public IPv4 network. Wind River NAT supports this configuration, which enables a local IPv6 network to communicate transparently with IPv4 servers on the Internet, using their host names.

When an IPv6 host on the inside of the NAT looks up the address of a corresponding host name, it queries for AAAA records. Normally the name server has no entry for AAAA records because it is likely to be an IPv4-only server. Therefore the DNS ALG translates the AAAA record in the query to an A record. When the answer comes back, it translates the A record back to an AAAA record.

NOTE: Port triggering entries are examples only. Configure actual entries in accordance with your application.


122

The ALG matches incoming responses to outgoing requests by tracking the transaction ID of the DNS messages.

The DNS ALG also supports reverse name lookups. When a DNS client queries for the name corresponding to a certain address, it uses PTR records. The DNS ALG translates the PTR record so that it contains the IPv4 part of the IPv6 address and changes the zone name, which can be either ip6.int or ip6.arpa to in-addr.arpa. When the answer comes back it restores the IPv6 address and zone so that it corresponds to the original requests.

The DNS ALG is included at compile time by enabling the following macro at compile time: #define IPNET_USE_NAT_DNS_ALG. It can be used only with NAT-PT.

13.5 FTP ALG Operation

File Transfer Protocol (FTP) is one of the most popular applications for remote file transfer. For an FTP application to work with NAT, it requires an ALG to monitor the control session payload to determine the ensuing data session parameters. The optional FTP ALG component in NAT fully supports the required functionalities specified in RFC 3022, 4.4 FTP support, as follows:

The FTP ALG would require a special table to correct the TCP sequence and acknowledge numbers with source port FTP or destination port FTP. The table entries should have source address, destination address, source port, destination port, delta for sequence numbers and a timestamp. New entries are created only when FTP PORT commands or PASV responses are seen. The sequence number delta may be increased or decreased for every FTP PORT command or PASV response. Sequence numbers are incremented on the outbound and acknowledge numbers are decremented on the inbound by this delta.

FTP payload translations are limited to private addresses and their assigned external addresses (encoded as individual octets in ASCII) for Basic NAT. For NAPT setup, however, the translations must be extended to include the TCP port octets (in ASCII) following the address octets.

The FTP ALG also supports the EPRT and EPSV command extensions, as specified in RFC 2428 and is capable of handling NAT-PT, as described in RFC 2766, section 6.2, Payload modifications for V6 originated FTP sessions, as follows:

13 Application-Level Gateways13.6 H.323 ALG Operation

123

13

If a V6 host originates the FTP session, however, the FTP-ALG has two approaches to pursue. In the first approach, the FTP-ALG will leave the command strings "EPRT" and "EPSV" unaltered and simply translate the <net-prt>, <net-addr> and <tcp-port> arguments from V6 to its NAT-PT (or NAPT-PT) assigned V4 information. <tcp-port> is translated only in the case of NAPT-PT. Same goes for EPSV response from V4 node. This is the approach we recommend to ensure forward support for RFC 2428. However, with this approach, the V4 hosts are mandated to have their FTP application upgraded to support EPRT and EPSV extensions to allow access to V4 and V6 hosts, alike.

The FTP ALG is included at compile time by enabling the following macro at compile time: #define IPNET_USE_NAT_FTP_ALG. It can be used with Traditional NAT, Bidirectional NAT and NAT-PT.

13.6 H.323 ALG Operation

H.323 is a standard published by the International Telecommunication Union—Telecommunication Standardization sector (ITU-T) specifying multimedia video conferencing on packet-switched networks such as LANs and the Internet. The standard comprises a set of protocols for voice, video, and data conferencing on packet-switched networks.

H.323 is complex, uses dynamic ports, and includes multiple UDP and TCP streams. However, the H.323 ALG component must handle only two associated protocols: H.225 and H.245.

H.225

This protocol defines the procedures and signaling between two endpoints for setting up and releasing a call to TCP port 1720. Note that port 1720 is the well-known call-signaling port for H.323.

NOTE: A discussion of H.323 architecture and its protocols is outside the scope of this manual. Information about the H.323 standard is largely available on the Internet. For an in-depth understanding of this standard, refer to the Kumar, Korpi, and Sengodan book noted in 9.3 Additional Documentation, p.82.


124

H.245

This protocol defines procedures and signaling between two endpoints in order to exchange capabilities and control media streams.

The H.225 payload contains address and port number fields for setting up calls and preparing for the H.245 connection. Similarly, the H.245 payload includes various address and port fields for creating media control and data streams. Since both of these protocols sit above the transport layer, a specialized ALG is required to translate the addresses and port numbers in the payloads. For this reason, the H.323 ALG actually comprises two ALGs: H.225 ALG and H.245 ALG. Both of these ALGs are registered to NAT. The H.225 ALG is registered at H.323 ALG initialization and is associated with port TCP port 1720. The H.245 ALG is registered during the H.225 session (that is, during call setup) because there is no well-known port associated with the H.245 protocol, which is an ephemeral port lasting only for the duration of the video conferencing session).

The H.323 ALG component does not actually parse both the H.225 and the H.245 payloads. The messages of both these protocols are encoded in ASN.1. Rather than employing the ASN.1 decoder within the ALG, the ALG does a byte-by-byte search for the IP address and TCP/UDP port number in the payload. (Fortunately, the port number always follows immediately after the address.) By interacting with NAT through the NAT API, the ALG correctly processes the packet according to its direction of flow, original address and port number, and translated address and port number. The ALG creates mappings for all of the negotiated control and data streams (mostly UDP streams, except for the T.120 stream with its well-known TCP port 1503).

The H.323 ALG component has been successfully tested with the Microsoft NetMeeting application. Because the ALG does not have the ASN.1 decoder to interpret the H.225 and H.245 messages, it is not guaranteed to always work with other applications using the H.323 protocol.

The H.323 ALG is included at compile time by enabling the following macro at compile time: #define IPNET_USE_NAT_H323_ALG. It can be used with Traditional NAT and Bidirectional NAT but not with NAT-PT.

13 Application-Level Gateways13.7 IPsec Passthrough ALG Operation

125

13

13.7 IPsec Passthrough ALG Operation

IPsec is a set of protocols developed by the IETF to support the secure exchange of packets at the IP layer. IPsec has been deployed widely to implement virtual private networks (VPNs).

IPsec supports two encryption modes: transport and tunnel. Transport mode encrypts only the data portion (payload) of each packet but leaves the header untouched. The more secure tunnel mode encrypts both the header and the payload. On the receiving side, an IPsec-compliant device decrypts each packet.

The IPsec/IKE Passthrough ALG allows IPsec VPN traffic to pass through a router using NAT. This passthrough service is limited to IPsec in ESP tunnel mode only (RFC 2406). The Passthrough ALG performs translation on both Internet Security Association and Key Management Protocol (ISAKMP, RFC 2408) and ESP packets. ISAKMP packets are tracked and translated by using the cookies present in those messages. ESP packets are tracked and translated by using the security parameter index present in those messages. This allows for multiple IPsec connections to pass through the NAT router.

The IPSEC ALG is included at compile time by enabling the following macro at compile time: #define IPNET_USE_NAT_IPSEC_ALG. It can be used only with Traditional NAT.

13.8 PTTP Passthrough ALG Operation

The Point-to-Point-Tunneling Protocol (PPTP) is a networking technology that supports multi-protocol VPNs, enabling remote users to access corporate networks securely across point-to-point protocol (PPP)-enabled systems—that is, to dial into a local Internet service provider to connect securely to their corporate network through the Internet.

PPTP enables a low-cost, private connection to a corporate network through the public Internet. This capability is particularly useful for people who work from home or people who travel and must access their corporate networks remotely to check e-mail or perform other activities.

The PPTP Passthrough ALG allows PPTP VPN traffic to pass through a router using NAT (NAPT mode only). It performs translation on both PPTP control and generic routing encapsulation packets (GRE,RFC 1701). Both type of packets are


126

tracked and translated by using the call IDs present in those messages. This functionality allows multiple PPTP connections to pass through the NAT router.

The PPTP ALG is included by enabling the following macro at compile time: #define IPNET_USE_NAT_PPTP_ALG. It can be used only with Traditional NAT.

13.9 Port Triggering

The port trigger ALG lets you dynamically open inbound ports to external connections, based on outbound traffic. The ALG does not do any actual parsing of the packet payload. Instead it adds a mapping to a host on the internal network when an outgoing connection is made to the port on which the ALG is registered. The inbound connection is sent to the same private host that caused the trigger to be hit. The Trigger ALG is configured by the cookie parameter in the call to the routine ipnet_nat_add_proxy( ). The cookie shall have the following type:

typedef struct Ipnet_nat_trigger_struct{ Ip_u8 protocol; Ip_u16 portlo; Ip_u16 porthi; Ip_u32 timeout; Ipnet_nat_proxy_func func; void *cookie;}Ipnet_nat_trigger;

The protocol parameter must be either IP_IPPROTO_UDP or IP_IPPROTO_TCP and specify the protocol for which the port shall be opened. The portlo and porthi parameters are the triggered ports and specify the port range that will be opened. If only one port will be opened, both shall have the same value. The timeout parameter specifies how long the port shall be opened for after the trigger port has been hit. The func and cookie parameters are optional and used to specify an ALG that shall be called when packets go through the triggered ports. Below is an example configuration structure that will open the SSH port (22) for 120 seconds after the trigger port has been hit.

Ipnet_nat_trigger example_trigger = {IP_IPPROTO_TCP, 22, 22, 120, IP_NULL, IP_NULL};

13 Application-Level Gateways13.10 Writing a Custom ALG

127

13

The timer will be refreshed each time there is traffic to either the trigger port or the triggered ports.

To include the trigger ALG, enable the following macro at compile time: #define IPNET_USE_NAT_TRIGGER_ALG. This ALG can be used only with Traditional NAT.

13.10 Writing a Custom ALG

The NAT module provides an interface for writing custom ALGs. The list of protocols used on the Internet is constantly evolving, which calls for a published API that can be used register new ALGs with the NAT. This section describes the methods and types available for this purpose.

13.10.1 Adding Your ALG

Before the ALG can be used by any NAT rules, it must be added to the NAT module. Use the API routine ipnet_nat_add_proxy( ). This routine registers the ALG with the NAT module so that it can accept rules that refer to the ALG.

The routine accepts four parameters, of which the first three are mandatory. The mandatory parameters are:

■ the name of the ALG

■ the protocol to which the ALG applies

■ the actual ALG routine that will be called when a NAT rule is hit by a packet

The same ALG can be registered for several protocols. ALGs can be added for all protocols but ICMP and ICMPv6.

The last parameter is optional and is used as a cookie that will be provided in the call to the ALG routine. The cookie can be used for configuring the ALG as exemplified in 13.9 Port Triggering, p.126.

To remove an ALG from the NAT module, verify that no NATrules refer to it. Then call ipnet_nat_remove_proxy( ). The following example illustrates the addition of a new ALG:

errval = ipnet_nat_add_proxy("my_alg", "tcp", my_custom_alg, IP_NULL);


128

13.10.2 Adding the NAT Rule

Once the ALG has been added to the NAT, it is possible to add a NAT rule that refers to it. The rule must specify the same name and protocol for which the ALG was registered or the addition of the rule will fail. It is also important that rules referring to an ALG are added before other NAT rules. Otherwise packets may match a different rule and the ALG will never come into operation. Below is an example of a NAT rule specifying an ALG. The ALG called my_alg is called when a private host makes an outgoing TCP connection to port 12345. All further traffic, incoming or outgoing, on this port also calls the ALG.

map fei0 0/0 -> 0/32 proxy port 12345 my_alg/tcp

13.10.3 Writing the ALG Routine

The ALG routine is the piece of code that performs the task the ALG is meant to accomplish. ALGs are typically used for:

■ scanning application data for IP addresses in order to replace them with the NAT-translated address and port

■ opening ports or protocols to incoming traffic

■ providing NAT functionality when a protocol without ports needs to be translated

The ALG routine must have the following type:

typedef int (* Ipnet_nat_proxy_func) (Ip_u8 *newhdr, Ip_u8 *appdata, int *applen, int growspace, Ipnet_nat_proxy_param *param, Ip_u8 **newdata);

The return value is an integer and must have one of the following values: 1, 0 or a negative value.

■ A value of 1 means the ALG has modified application data.

■ A value of 0 means application data is unchanged.

■ A negative value means that the packet will be dropped by the NAT module.


129

13

The ALG routine must have six arguments:

■ The parameter newhdr is a pointer to a memory location where the ALG optionally may create a new IP header. NAT normally creates a new header, so this step may not be required. However, certain protocols are not based on UDP or TCP and therefore do not have any ports that can be used by the NAT module to check incoming packets against mappings and direct them to the correct private network host. ALGs for these protocols attempt to use another protocol field for this purpose. Such ALGs include IPsec, which uses the SPI field and PPTP, which uses the call ID field.

■ The parameter appdata is a pointer to the protocol’s application data. This pointer indicates the location where the ALG typically scans for embedded IP addresses and ports.

■ The parameter applen is a pointer to the protocol’s application data length. If the ALG modifies the application data so that the length is changed, the new length must be reflected in the parameter.

■ The parameter growspace tells the ALG how much (in bytes) the application data can grow before a new buffer must be created.

■ The parameter param is a pointer to some useful proxy parameters. These parameters are further described below.

■ The parameter newdata is a pointer to a pointer to a new application data buffer in case the packet grows more than what is possible without creating a new buffer (as indicated by growspace). Use ipcom_malloc( ) to allocate a new application data buffer, which will be automatically freed by the NAT module when the packet has been sent.

The proxy parameters represented by param have the following type:

typedef struct Ipnet_nat_proxy_param_struct{ Ipnet_nat_proxy_tuple tuple; Ip_u32 nat_addr; Ip_u16 nat_port; void *mapping; Ip_bool inbound; Ip_bool incoming; Ip_bool natpt; Ip_u32 prefix[3]; void *cookie; Ip_u32 fragid; Ip_u16 fragoff; Ip_u8 fragmf;}Ipnet_nat_proxy_param;


130

■ The parameter tuple is a pointer to the proxy tuple structure. It includes information about the addresses, ports and protocol that created the NAT mapping that caused the call to the ALG. See below for a detailed description of the tuple structure.

■ The parameter nat_addr and nat_port are the new source address and source port the packet was given after it has been translated by NAT.

■ The parameter mapping is a pointer to the NAT mapping that caused the call to the ALG. It is provided in the proxy parameters because some of the functions available for ALGs require the parent mapping to be given as argument.

■ The parameter inbound is a Boolean value that tells the ALG if the mapping that caused the call to the ALG was created by an inbound packet (Bidirectional NAT) or an outbound packet.

■ The parameter incoming is a Boolean that tells the ALG if the packet that caused the call to the ALG was an incoming packet.

■ The parameter natpt is a Boolean that tells the ALG if the mapping that caused the call to the ALG was created by a NAT-PT rule.

■ The parameter prefix is set to the IPv6 prefix used by NAT-PT.

■ The parameter cookie is the cookie that was set when adding the ALG.

■ The parameter fragid, fragoff, and fragmf are used to indicate if the packet is a fragment or not. fragid is the fragment identifier, fragoff is the fragment offset, and fragmf is the more fragments bit (the bit that indicates whether more fragments exist).

Finally, the proxy tuple structure has the following format:

typedef struct Ipnet_nat_proxy_tuple_struct{ Ip_u16 private_port; Ip_u16 public_port; Ip_u32 private_addr; Ip_u32 public_addr; Ip_u8 protocol;}Ipnet_nat_proxy_tuple;


131

13

■ The parameter private_port is the port used by the host on the private side of the NAT. This value will be 0 for protocols other than UDP, TCP or ICMP echo.

■ The parameter public_port is the port used by the host on the public side of the NAT. This value will be 0 for protocols other than UDP, TCP or ICMP echo.

■ The parameter private_address is the address of the host on the private side of the NAT.

■ The parameter public_address is the address of the host on the public side of the NAT.

■ The parameter protocol is the IP protocol that created the mapping.

Routines Available for ALGs

The following routines are available for the ALG writer. See the reference entry for each routine for detailed information.

■ ipnet_nat_proxy_add_mapping( ) can be used to open a port or protocol through the NAT to a host on the private network for which there is no Bidirectional NAT rule.

■ ipnet_nat_proxy_set_mapping_timeout( ) can be used to set a timeout for the mapping that caused the call to the ALG.

■ ipnet_nat_proxy_get_time( ) can be used to get the elapsed time since boot.

■ ipnet_nat_proxy_timeout_schedule( ) can be used to schedule a routine to be called in the future.

■ ipnet_nat_proxy_timeout_reschedule( ) can be used to reschedule a previously scheduled routine.

■ ipnet_nat_proxy_timeout_cancel( ) can be used to cancel a previously scheduled routine.


132

13.11 Sample Rule Sets with ALG Support

NAT Router with ALG Support

map fei0 0/0 -> 0/32 proxy port 21 ftp/tcpmap fei0 0/0 -> 0/32 proxy port 1723 pptp/tcpmap fei0 0/0 -> 0/32 proxy port 1720 h323/tcpmap fei0 0/0 -> 0/32 proxy port 500 ipsec/udp nonaptmap fei0 0/0 -> 0/32 portmap tcp/udp 18000:18999map fei0 0/0 -> 0/32 icmpidmap icmp 19000:19999map fei0 0/0 -> 0/32

This configuration implements a rule set that adds ALG support for FTP, PPTP, H323 and IPsec. Note that in this rule set, there are no ALGs registered for the ESP and GRE protocols. The IPsec ALG adds a mapping for ESP automatically as a result of IKE traffic on port 500. Similarly, the PPTP ALG adds a mapping for GRE as a result of call setup traffic on TCP port 1723.

NAT Router with ALG Support and DMZ Host

map fei0 0/0 -> 0/32 proxy port 21 ftp/tcpmap fei0 0/0 -> 0/32 proxy port 1723 pptp/tcpmap fei0 0/0 -> 0/32 proxy port 1720 h323/tcpmap fei0 0/0 -> 0/32 proxy port 500 ipsec/udpmap fei0 0/0 -> 0/32 portmap tcp/udp 18000:18999map fei0 0/0 -> 0/32 icmpidmap icmp 19000:19999map fei0 0/0 -> 0/32rdr fei0 195.42.198.1 port 22 -> 195.42.198.1 port 22 tcprdr fei0 195.42.198.1 port 0 -> 195.42.198.1 port 0 icmprdr fei0 195.42.198.1 port 1720 -> 10.0.0.2 port 1720 tcp proxy h323rdr fei0 195.42.198.1 port 0 -> 10.0.0.1 port 0 ip

This configuration implements a rule set which adds ALG support for FTP, PPTP, H323, and IPSEC with DMZ host support. It assumes the public IP of the NAT gateway is 192.42.198.5 and the DMZ host is at private address 10.0.0.1. The SSH service at port 22 and echo requests are preserved at the NAT gateway itself. Additionally it redirects incoming H.323 calls to the private host 10.0.0.2 and enables the H.323 proxy for that bidirectional NAT rule.

13 Application-Level Gateways13.11 Sample Rule Sets with ALG Support

133

13

NAT-PT Router with ALG Support

pt fei1 ::/0 -> 195.42.198.5 proxy port 21 ftp/tcppt fei1 ::/0 -> 195.42.198.5 proxy port 53 dns/udppt fei1 ::/0 -> 195.42.198.5 portmap tcp/udp 18000:18999pt fei1 ::/0 -> 195.42.198.5 icmpidmap icmp 19000:19999pt fei1 ::/0 -> 195.42.198.5

This configuration implements a rule set for a NAT-PT router which adds ALG support for FTP and DNS.


134

135

PART II I

Appendices

A Wind River Firewall Keywords .......................... 137

D Wind River Firewall Shell Command ................ 171

E Wind River NAT Keywords ................................ 175

H Wind River NAT Shell Command ...................... 195


136

137

A Wind River Firewall Keywords

A.1 Introduction 137

A.2 Syntax 137

A.3 Keywords 138

A.1 Introduction

This appendix provides reference information for the Wind River Firewall keywords used to define firewall rules.

A.2 Syntax

A.2.1 IP Filter Rule Syntax

[@index] {pass | block} [return-rst | return-icmp[-as-dest](return_value) {in | out} [log [first]] [limit [!] limit_value/unit burst [burst_value] [quick] [on [!] interface[+]] [tos [tos_value][/mask]] [ttl ttl_value] [proto [proto_value]] address_scope [icmp-type icmp_value] [flags flags_value[/mask]] [with [no] {frag|ipopts}] [keep state] [head head_number] [group group_number] [userdef id [paramstring]]


138

IP Filter Address Scope

{all | from {[!] any|me|ip_address[/mask]} [port {op} {port_value}] to {[!] any|me|ip_address[/mask]} [port {op} {port_value}]}}

A.2.2 MAC Filter Rule Syntax

[@index] {pass | block {in | out} [log [first]] [limit [!] limit_value/unit burst {burst_value] [quick] [on [!] interface[+]] address_scope [mac-type mac_type_value] [head head_number] [group group_number] [userdef id [paramstring]]

MAC Filter Address Scope

{all | from {[!] any|me|mac_address[/mask]} to {[!] any|me|mac_address[/mask]}}

A.3 Keywords

!

Description

Inverts a parameter.

Syntax

keyword ! parameter

#

Description

Precedes a comment.

Syntax

# comment

A Wind River Firewall KeywordsA.3 Keywords

139

A

all

Description

Specifies all traffic—that is, packets originating from any source and addressed to any destination.

Syntax

{block | pass} {in | out} all

any

Description

Specifies packets arriving from any source (with from keyword) or addressed to any destination (with to keyword).

Syntax

{block | pass} {in | out} {to | from} any

block

Description

Blocks the specified packet.

Syntax

block {in | out} {to | from} address_scope

address_scope can be a unique IP address, an address space, or the keywords !, all, me or any.

burst

Description

Specifies an absolute number of packets to be blocked or passed under the criteria specified by the rule. Used in conjunction with limit.


140

Syntax

{block | pass} {in | out} limit limit_value/unit burst burst_value {to | from} address_scope

limit_value is the maximum number of packets to be accepted within the specified period of time (unit).

unit is second (s), minute (m), hour (h), or day (d).

burst_value is the absolute number of packets to be accepted under the criteria specified by the rule.


first

Description

Instructs the firewall to log only the first packet matching the rule. Use this parameter to avoid filling up the log too fast, because only a limited number of packets (1,000 by default) fits in the log.

Syntax

{block | pass} {in | out} log [first] address_scope


flags

Description

Instructs the firewall to match TCP flags in the packet header against the specified type.

Syntax

{block | pass} {in | out} proto tcp address_scope flags [flag_type[/flag_mask]]



141

A

flag_type and flag_mask can be:

■ U (Urgent■ A (Ack)■ P (Push)■ R (Reset)■ S (Syn)■ F (Fin)■ 0 (no flags active)

flag_type and flag_mask are separated by a slash (/). For a rule to match, the flag specified in flag_type must be set in the TCP packet header. If a flag is not explicitly specified in flag_type, it must not be set in the TCP packet header.

A flag_mask, however, introduces flexibility to the rule. Flags specified in the flag_mask must strictly conform to their flag_type setting. Flags not specified in the flag_mask are allowed to vary from their flag_type setting.

If no flag_mask is specified, all flags must match their flag_type specification—that is, the default mask is UAPRSF.

frag

Description

Used to filter IP fragments (for both IPv4 and IPv6 rules).

Syntax

{block | pass} {in | out} [all] with [no] frag {from | to} address_scope


from

Description

Precedes a source address or range of addresses.


142

Syntax

{block | pass} {in | out} from address_scope


group

Description

Identifies the group to which a rule belongs.

Syntax

{block | pass} {in | out} address_scope group group_number


group_number is the number of the rule group to which the rule belongs.

head

Description

Identifies the head rule of a group.

Syntax

{block | pass} {in | out} address_scope head head_number


head_number is the number of the group for which this rule is the head rule.

icmp-type

Description

In an IP filter rule, specifies the ICMP type.


143

A

Syntax

{block | pass} {in | out} {to | from} address_scope proto icmp [icmp-type type_value] [code code_value]


type_value is the ICMP type field in the IP packet header.

code_value is the ICMP code field for the specified ICMP type.

in

Description

Indicates an incoming packet.

Syntax

{block | pass} in address_scope


ipopts

Description

Used to filter IP options (for IPv4 rules only).

Syntax

{block | pass} {in | out} [all] with [no] ipopts {from | to} address_scope


keep state

Description

Enables stateful firewalling by temporarily opening a port for incoming traffic when an outgoing packet matches the specified rule.


144

Syntax

{block | pass} {in | out} {to | from} address_scope keep state


limit

Description

Specifies the number of packets to be accepted within a given time frame under the criteria specified by the rule. Used in conjunction with burst.

Syntax

{block | pass} {in | out} limit limit_value/unit burst burst_value {to | from} address_scope

limit_value is the maximum number of packets to be accepted within the specified period of time (unit).

unit is second (s), minute (m), hour (h), or day (d).

burst_value is the absolute number of packets to be accepted under the criteria specified by the rule.


log

Description

Instructs the firewall to log packets matching the rule.

Syntax

{block | pass} {in | out} log [first] address_scope

first instructs the firewall to log only the first packet matching the rule. Use this parameter to avoid filling up the log too fast, because only a limited number of packets (1,000 by default) fits in the log.



145

A

mac-type

Description

In a MAC filter rule, specifies the MAC frame type.

Syntax

{block | pass} {in | out} {to | from} address_scope mac-type mac_type_value

address_scope can be a unique MAC address, an address space, or the keywords !, all, me or any.

me

Description

In an IP filter rule, specifies any address configured on the system.

In a MAC filter rule, specifies the MAC address assigned to the interface the packet is sent or received on.

Syntax

{block | pass} {in | out} me

on

Description

Precedes an interface specification.

Syntax

{block | pass} {in | out} on interface[+] address_scope

interface is an interface name.

The plus sign (+) is used as a wildcard to specify any character or digit in an interface name.

address_scope can be a unique IP or MAC address, an address space, or the keywords !, all, me or any.


146

out

Description

Indicates an outgoing packet.

Syntax

{block | pass} out address_scope


no

Description

Inverts the IP fragments or IP options setting specified in a with frag or with ipopts rule.

Syntax

{block | pass} {in| out} {to | from} address_scope with no {frag | ipopts}


pass

Description

Accepts the specified packet.

Syntax

pass {in | out} {to | from} address_scope



147

A

port

Description

Specifies a port for a UDP or TCP packet.

Syntax

{block | pass} {in | out} proto proto_value {to | from} address_scope port op port_value

proto_value is tcp or udp.


op is a mathematical operator. Wind River Firewall recognizes the operators defined in Table A-1, which can be specified using mathematical signs or text:

For <> and ><, the syntax is actually as follows:

port port_value op port_value

For example, a specification such as port 10000 <> 20000 means that all port numbers less than 10000 or greater than 20000 match the rule.

port_value is an individual port or an interval.

Table A-1 Operators Valid with Port Keyword

Operator Text Designation Description

= eq equal

!= ne not equal

< lt less than

<= le less than or equal

> gt greater than

>= ge greater than or equal to

<> or outside range

>< ir inside range


148

proto

Description

Specifies an Internet protocol.

Syntax

{block | pass} {in | out} proto proto_value address_scope [port op port_value]

proto_value is tcp or udp.


op is a mathematical operator. For more information, see Table A-1.


quick

Description

Instructs the firewall to abort processing and immediately take the action specified in the rule.

Syntax

{block | pass} {in | out} quick address_scope


return-icmp

Description

Sends a destination unreachable error back to a peer if an ICMP packet specified by the rule is blocked by the firewall.

Syntax

block in return-icmp[(number)] [proto udp] {from | to} address_scope [port op port_value]


149

A

number indicates the ICMP destination unreachable code field to be set in the response message. It can be any value from 0-255. If no value is supplied, 0 is assumed. Table A-2 defines the supported options.

proto_value can be any protocol.

address_scope can be a unique IP address, an address space, or the keywords me or any.



Table A-2 Return-ICMP Codes

Code Description

IPv4 Codes

0 Network unreachable

1 Host unreachable

2 Protocol unreachable

3 Port unreachable

4 Fragmentation needed but no frag bit set

5 Source routing failed

9 Destination network administratively prohibited

10 Destination host administratively prohibited

IPv6 Codes

0 Destination unreachable: no route

2 Destination unreachable: beyond scope

3 Destination unreachable: addr

4 Destination unreachable: no port


150

return-icmp-as-dest

Description

Sends a destination unreachable error back to a peer if an ICMP packet specified by the rule is blocked by the firewall. When this keyword is used, the destination unreachable error contains a source address copied from the destination address of the blocked packet.

Syntax

block in return-icmp-as-dest[(number)] [proto udp] {from | to} address_scope [port op port_value]

number indicates the ICMP destination unreachable code field to be set in the response message. It can be any value from 0-255. If no value is supplied, 0 is assumed. Table A-3 defines the supported options.

Table A-3 Return-ICMP-as-Dest Codes

Code Description

IPv4 Codes

0 Network unreachable

1 Host unreachable

2 Protocol unreachable

3 Port unreachable

4 Fragmentation needed but no frag bit set

5 Source routing failed

9 Destination network administratively prohibited

10 Destination host administratively prohibited

IPv6 Codes

0 Destination unreachable: no route

2 Destination unreachable: beyond scope

3 Destination unreachable: addr

4 Destination unreachable: no port


151

A




return-rst

Description

Sends a reset segment (connection refused error) back to a peer if a TCP packet specified by the rule is blocked by the firewall.

Syntax

block in return-rst proto tcp address_scope [port op port_value]




to

Description

Precedes a destination address or range of addresses.

Syntax

{block | pass} {in | out} to address_scope


tos

Description

Specifies a value in the type of service (tos) field of an IPv4 packet header or the quality class field of an IPv6 packet header.


152

Syntax

{block | pass} {in| out} tos tos_value[/tos_mask] address_scope

tos_value is the type of service (TOS) value field in an IPv4 packet header or the quality class field in an IPv6 packet header. It must be specified in hexadecimal. The leading 0 or 0x is optional.

tos_mask is a full mask, which is bitwise combined with the tos field in the protocol header using a Boolean AND, then compared with the tos_value in the rule. It must be specified in hexadecimal. The leading 0 or 0x is optional.

ttl

Description

Specifies a value in the time to live (ttl) field of an IP packet header. This value specifies a timeout for received fragments.

Syntax

{block | pass} {in| out} ttl ttl_value address_scope

ttl_value ranges from 0-255.


with

Description

Enables a rule to match packets containing IP options and fragments. Use with ipopts for IPv4 rules and with frag for IPv4 or IPv6 rules. It is also possible to insert a no keyword to match packets not including fragments or IP options.

Syntax

{block | pass} {in| out} {to | from} address_scope with [no] {frag | ipopts}


153

BWind River Firewall Libraries

ipfirewall – Public API of Wind River Firewall 154


154

ipfirewall

NAME ipfirewall – Public API of Wind River Firewall

ROUTINES ipfirewall_enable( ) – enable firewallipfirewall_disable( ) – disable firewallipfirewall_add_rule( ) – add an IP filter ruleipfirewall_remove_rule( ) – remove an IP filter ruleipfirewall_flush_rules( ) – remove all IP filter rulesipfirewall_flush_group( ) – remove all rules in a groupipfirewall_flush_states( ) – remove all active statesipfirewall_flush_log( ) – remove all entries in the IP filter logipfirewall_mac_add_rule( ) – add a MAC filter ruleipfirewall_mac_remove_rule( ) – remove a MAC filter ruleipfirewall_mac_flush_rules( ) – remove all MAC filter rulesipfirewall_mac_flush_group( ) – remove all MAC filter rules in a groupipfirewall_mac_flush_log( ) – remove all entries in the MAC filter logipfirewall_flush_userdefs( ) – remove all user-defined routinesipfirewall_register_userdef( ) – register a user-defined functionipfirewall_unregister_userdef( ) – deregister a user-defined functionipfirewall_http_add_filter( ) – add an HTTP filteripfirewall_http_remove_filter( ) – remove an HTTP filteripfirewall_http_insert_url_filter( ) – add a URL or keyword to an HTTP filteripfirewall_http_insert_proxy_filter( ) – set proxy filter in an HTTP filteripfirewall_http_insert_cookie_filter( ) – set cookie filter in an HTTP filteripfirewall_http_insert_java_filter( ) – set Java filter in an HTTP filteripfirewall_http_insert_activex_filter( ) – set ActiveX filter in an HTTP filter

DESCRIPTION This library contains the APIs used for configuration of Wind River Firewall.

INCLUDE FILES none

155

CWind River Firewall Routines

ipfirewall_add_rule( ) – add an IP filter rule 156ipfirewall_disable( ) – disable firewall 156ipfirewall_enable( ) – enable firewall 157ipfirewall_flush_group( ) – remove all rules in a group 158ipfirewall_flush_log( ) – remove all entries in the IP filter log 158ipfirewall_flush_rules( ) – remove all IP filter rules 159ipfirewall_flush_states( ) – remove all active states 159ipfirewall_flush_userdefs( ) – remove all user-defined routines 160ipfirewall_http_add_filter( ) – add an HTTP filter 160ipfirewall_http_insert_activex_filter( ) – set ActiveX filter in an HTTP filter 161ipfirewall_http_insert_cookie_filter( ) – set cookie filter in an HTTP filter 161ipfirewall_http_insert_java_filter( ) – set Java filter in an HTTP filter 162ipfirewall_http_insert_proxy_filter( ) – set proxy filter in an HTTP filter 162ipfirewall_http_insert_url_filter( ) – add a URL or keyword to an HTTP filter 163ipfirewall_http_remove_filter( ) – remove an HTTP filter 163ipfirewall_mac_add_rule( ) – add a MAC filter rule 164ipfirewall_mac_flush_group( ) – remove all MAC filter rules in a group 164ipfirewall_mac_flush_log( ) – remove all entries in the MAC filter log 165ipfirewall_mac_flush_rules( ) – remove all MAC filter rules 165ipfirewall_mac_remove_rule( ) – remove a MAC filter rule 166ipfirewall_register_userdef( ) – register a user-defined function 167ipfirewall_remove_rule( ) – remove an IP filter rule 167ipfirewall_unregister_userdef( ) – deregister a user-defined function 168


156

ipfirewall_add_rule( )

NAME ipfirewall_add_rule( ) – add an IP filter rule

SYNOPSIS IP_PUBLIC Ip_err ipfirewall_add_rule ( Ip_s32 family, const char *rule );

DESCRIPTION The ipfirewall_add_rule( ) routine adds an IP filter rule to the current ruleset.

Parameters:

familyThe Internet address family that the IP filter rule applies to. Set to IP_AF_INET or IP_AF_INET6.

ruleThe rule to add.

RETURNS IPCOM_SUCCESS or one of the following errors:

IPCOM_ERR_FAILEDFailed to add the rule.

IPCOM_ERR_NO_MEMORYOut of memory.

ERRNO

SEE ALSO ipfirewall

ipfirewall_disable( )

NAME ipfirewall_disable( ) – disable firewall

SYNOPSIS IP_PUBLIC Ip_err ipfirewall_disable(void);

DESCRIPTION The ipfirewall_disable( ) routine disables the firewall. When disabled, packet matching against the current ruleset is skipped.

C Wind River Firewall Routines ipfirewall_enable( )

157

C


IPCOM_ERR_ALREADY_CLOSEDFirewall was already disabled.

IPCOM_ERR_FAILEDFailed to disable the firewall.


ERRNO

SEE ALSO ipfirewall

ipfirewall_enable( )

NAME ipfirewall_enable( ) – enable firewall

SYNOPSIS IP_PUBLIC Ip_err ipfirewall_enable(void);

DESCRIPTION The ipfirewall_enable( ) routine enables the firewall. When enabled, each incoming and outgoing packet is matched against the current ruleset.


IPCOM_ERR_ALREADY_OPENFirewall was already enabled.

IPCOM_ERR_FAILEDFailed to enable the firewall.


ERRNO

SEE ALSO ipfirewall


158

ipfirewall_flush_group( )

NAME ipfirewall_flush_group( ) – remove all rules in a group

SYNOPSIS IP_PUBLIC Ip_err ipfirewall_flush_group ( Ip_s32 group );

DESCRIPTION This routine removes all rules in the current group.

Parameter:

groupThe group to flush rules in.

RETURNS IPCOM_SUCCESS, or the following error:

IPCOM_ERR_FAILEDFailed to flush rules in the group.

ERRNO

SEE ALSO ipfirewall

ipfirewall_flush_log( )

NAME ipfirewall_flush_log( ) – remove all entries in the IP filter log

SYNOPSIS IP_PUBLIC Ip_err ipfirewall_flush_log(void);

DESCRIPTION The ipfirewall_flush_log( ) routine removes all entries in the IP filter log.

RETURNS IPCOM_SUCCESS or the following error:

IPCOM_ERR_FAILEDFailed to flush log.

ERRNO

SEE ALSO ipfirewall

C Wind River Firewall Routines ipfirewall_flush_rules( )

159

C

ipfirewall_flush_rules( )

NAME ipfirewall_flush_rules( ) – remove all IP filter rules

SYNOPSIS IP_PUBLIC Ip_err ipfirewall_flush_rules(void);

DESCRIPTION The ipfirewall_flush_rules( ) routine flushes all IP filter rules in the current ruleset.


IPCOM_ERR_FAILEDFailed to flush rules.

ERRNO

SEE ALSO ipfirewall

ipfirewall_flush_states( )

NAME ipfirewall_flush_states( ) – remove all active states

SYNOPSIS IP_PUBLIC Ip_err ipfirewall_flush_states(void);

DESCRIPTION The ipfirewall_flush_states( ) routine removes all active states added by stateful IP filter rules.


IPCOM_ERR_FAILEDFailed to flush states.

ERRNO

SEE ALSO ipfirewall


160

ipfirewall_flush_userdefs( )

NAME ipfirewall_flush_userdefs( ) – remove all user-defined routines

SYNOPSIS IP_PUBLIC Ip_err ipfirewall_flush_userdefs(void);

DESCRIPTION The ipfirewall_flush_userdefs( ) routine removes all registered user-defined routines.


IPCOM_ERR_FAILEDFailed to flush user-defined routines.

ERRNO

SEE ALSO ipfirewall

ipfirewall_http_add_filter( )

NAME ipfirewall_http_add_filter( ) – add an HTTP filter

SYNOPSIS IP_PUBLIC Ip_err ipfirewall_http_add_filter ( const char *id );

DESCRIPTION This routine adds an HTTP filter.

Parameter:

idThe ID of the HTTP filter to add.

RETURNS Either IPCOM_SUCCESS or an error code (see ipcom_err.h).

ERRNO

SEE ALSO ipfirewall

C Wind River Firewall Routines ipfirewall_http_insert_activex_filter( )

161

C

ipfirewall_http_insert_activex_filter( )

NAME ipfirewall_http_insert_activex_filter( ) – set ActiveX filter in an HTTP filter

SYNOPSIS IP_PUBLIC Ip_err ipfirewall_http_insert_activex_filter ( const char *id );

DESCRIPTION This routine inserts the ActiveX filter into an HTTP filter.

Parameters

idThe ID of the HTTP filter.


ERRNO

SEE ALSO ipfirewall

ipfirewall_http_insert_cookie_filter( )

NAME ipfirewall_http_insert_cookie_filter( ) – set cookie filter in an HTTP filter

SYNOPSIS IP_PUBLIC Ip_err ipfirewall_http_insert_cookie_filter ( const char *id );

DESCRIPTION This routine inserts the cookie filter into an HTTP filter.

Parameter:



ERRNO

SEE ALSO ipfirewall


162

ipfirewall_http_insert_java_filter( )

NAME ipfirewall_http_insert_java_filter( ) – set Java filter in an HTTP filter

SYNOPSIS IP_PUBLIC Ip_err ipfirewall_http_insert_java_filter ( const char *id );

DESCRIPTION This routine inserts the java filter into an HTTP filter.

Parameter:



ERRNO

SEE ALSO ipfirewall

ipfirewall_http_insert_proxy_filter( )

NAME ipfirewall_http_insert_proxy_filter( ) – set proxy filter in an HTTP filter

SYNOPSIS IP_PUBLIC Ip_err ipfirewall_http_insert_proxy_filter ( const char *id );

DESCRIPTION This routine inserts the proxy filter into an HTTP filter.

Parameter:



ERRNO

SEE ALSO ipfirewall

C Wind River Firewall Routines ipfirewall_http_insert_url_filter( )

163

C

ipfirewall_http_insert_url_filter( )

NAME ipfirewall_http_insert_url_filter( ) – add a URL or keyword to an HTTP filter

SYNOPSIS IP_PUBLIC Ip_err ipfirewall_http_insert_url_filter ( const char *id, const char *url, Ip_bool keyword );

DESCRIPTION This routine adds a URL or keyword to an HTTP filter.

Parameters:


urlThe URL path or keyword.

keywordSet to IP_TRUE for keyword.


ERRNO

SEE ALSO ipfirewall

ipfirewall_http_remove_filter( )

NAME ipfirewall_http_remove_filter( ) – remove an HTTP filter

SYNOPSIS IP_PUBLIC Ip_err ipfirewall_http_remove_filter ( const char *id );

DESCRIPTION This routine removes an HTTP filter, if there is no IP filter rule that refers to the filter. It fails if there is. To remove an IP filter rule, use ipfirewall_remove_rule( ).

Parameter:

idThe ID of the HTTP filter to remove.


164


ERRNO

SEE ALSO ipfirewall

ipfirewall_mac_add_rule( )

NAME ipfirewall_mac_add_rule( ) – add a MAC filter rule

SYNOPSIS IP_PUBLIC Ip_err ipfirewall_mac_add_rule ( const char *rule );

DESCRIPTION The ipfirewall_mac_add_rule( ) routine adds a MAC filter rule to the current ruleset

Parameters:

ruleThe rule to add.




ERRNO

SEE ALSO ipfirewall

ipfirewall_mac_flush_group( )

NAME ipfirewall_mac_flush_group( ) – remove all MAC filter rules in a group

SYNOPSIS IP_PUBLIC Ip_err ipfirewall_mac_flush_group ( Ip_s32 group );

C Wind River Firewall Routines ipfirewall_mac_flush_log( )

165

C

DESCRIPTION The ipfirewall_mac_flush_rules( ) routine removes all MAC filter rules in a specified group.

Parameter:

groupThe group from which the MAC filter rules are to be removed.


IPCOM_ERR_FAILEDFailed to flush rules in the group

ERRNO

SEE ALSO ipfirewall

ipfirewall_mac_flush_log( )

NAME ipfirewall_mac_flush_log( ) – remove all entries in the MAC filter log

SYNOPSIS IP_PUBLIC Ip_err ipfirewall_mac_flush_log(void);

DESCRIPTION The ipfirewall_mac_flush_log( ) routine removes all entries in the MAC filter log.


IPCOM_ERR_FAILEDFailed to flush log.

ERRNO

SEE ALSO ipfirewall

ipfirewall_mac_flush_rules( )

NAME ipfirewall_mac_flush_rules( ) – remove all MAC filter rules

SYNOPSIS IP_PUBLIC Ip_err ipfirewall_mac_flush_rules(void);


166

DESCRIPTION The ipfirewall_mac_flush_rules( ) routine removes all MAC filter rules in the current ruleset.


IPCOM_ERR_FAILEDFailed to flush rules.

ERRNO

SEE ALSO ipfirewall

ipfirewall_mac_remove_rule( )

NAME ipfirewall_mac_remove_rule( ) – remove a MAC filter rule

SYNOPSIS IP_PUBLIC Ip_err ipfirewall_mac_remove_rule ( const char *rule );

DESCRIPTION The ipfirewall_mac_remove_rule( ) routine removes a MAC filer rule from the current ruleset

Parameters:

ruleThe rule to remmove.




ERRNO

SEE ALSO ipfirewall

C Wind River Firewall Routines ipfirewall_register_userdef( )

167

C

ipfirewall_register_userdef( )

NAME ipfirewall_register_userdef( ) – register a user-defined function

SYNOPSIS IP_PUBLIC Ip_err ipfirewall_register_userdef ( IP_CONST char *id, Ipfirewall_userdef_match match, Ipfirewall_userdef_check check, Ipfirewall_userdef_destroy destroy, void *cookie );

DESCRIPTION This routine registers a user-defined function for use with the userdef rule parameter. Before a user-defined function can be specified in a rule it must be registered with this routine.

Parameters:

idAn identifier for the user-defined function.

matchA pointer to a user-defined match routine.

checkA pointer to a user-defined check routine (optional).

destroyA pointer to a user-defined destroy routine (optional).

cookieA cookie that will be supplied in the calls to the user-defined function's match, destroy and check routines.


ERRNO

SEE ALSO ipfirewall

ipfirewall_remove_rule( )

NAME ipfirewall_remove_rule( ) – remove an IP filter rule

SYNOPSIS IP_PUBLIC Ip_err ipfirewall_remove_rule


168

( Ip_s32 family, const char *rule );

DESCRIPTION The ipfirewall_remove_rule( ) routine removes an IP filer rule from the current ruleset

Parameters:

familyThe Internet address family that the IP filter rule applies to. Set to IP_AF_INET or IP_AF_INET6.

ruleThe rule to remove.




ERRNO

SEE ALSO ipfirewall

ipfirewall_unregister_userdef( )

NAME ipfirewall_unregister_userdef( ) – deregister a user-defined function

SYNOPSIS IP_PUBLIC Ip_err ipfirewall_unregister_userdef ( IP_CONST char *id );

DESCRIPTION This routine deregisters a user-defined routine.

Parameter:

idIdentifier of the user-defined function.


C Wind River Firewall Routines ipfirewall_unregister_userdef( )

169

C

ERRNO

SEE ALSO ipfirewall


170

171

D Wind River Firewall

Shell Command

ipf

Name

ipf – enable, disable, and modify the firewall

Synopsis

ipf [rule]{[-6 rule][-f filename][-r rule][-n rule][-m rule] [-D][-E][-F {[r][s][l][u][a][gid]}][-P {[r][s][l][u][a][gid]}][-S][-V][-Z]}

Description

ipf configures IP filter and MAC filter rules. The command runs on a target shell. The default operation is to add an IP filter rule. Use the -m flag to add a MAC filter rule and the -r flag to remove rules. ipf can also be used to display or flush rule, state or log tables.

The shell command options are as follows:

-mAdd a MAC filter rule.

-6Add an IPv6 filter rule.



172

-rRemove rule.

-fAdd rules from the specified file.

-nCheck rule syntax.

-DDisable the firewall.

-EEnable the firewall.

-F{[r][s][l][u][a][gid]}Flush table(s). To flush a particular table, use the following options, either singly or in combination:

r (rules)

s (state)

l (log)

u (user)

a (all)

gid (rule group, where id specifies the group number)

-P{[r][s][l][u][a][gid]}Display table(s). To display a particular table, use the following options, either singly or in combination:

r (rules)

s (state)

l (log)

u (user)

a (all)

gid (rule group, where id specifies the group number)

-SDisplay statistics.

-VShow firewall version.

D Wind River Firewall Shell Command

173

D

-ZClear statistics.


174

175

E Wind River NAT Keywords

E.1 Introduction 175

E.2 Syntax 175

E.3 Keywords 176

E.1 Introduction

This appendix provides reference information for the Wind River NAT keywords used to define NAT rules.

E.2 Syntax

E.2.1 NAT Rule Syntax

[@index] {map|map-block|pt|pt-block} interface private_source_address[/mask] {-> | to } public_source_address[/mask] [[portmap|icmpidmap {tcp|udp|tcp/udp|icmp} low_port_number:high_port_number] | proxy port port_number proxyname/protocol][nonapt]


176

E.2.2 NAT Redirect Rule Syntax

[@index] rdr interface destination_address[/mask] port port_number {-> | to } private_host_address port port_number [protocol] [proxy proxyname]

E.3 Keywords

->

Description

A string used to indicate a mapping between a private address and a public address. Equivalent to to. The -> string does not work with the VxWorks target shell. Use to instead.

Syntax

{map|map-block|pt|pt-block} interface private_source_address -> public_source_address

#

Description

Precedes a comment.

Syntax

# comment

icmpidmap

Description

For ICMP echo requests or replies, instructs NAT to perform address and port translation based on the identifier field of the ICMP echo header. Used in conjunction with the map keyword to configure NAPT.

E Wind River NAT KeywordsE.3 Keywords

177

E

Syntax

map interface private_source_address {-> | to} public_source_address icmpidmap icmp low_port_number:high_port_number

interface is the interface on which the outgoing packet is transmitted.

private_source_address can be a private host address, an address space on the private network, or a wildcard signifying any private address (0/0).

public_source_address can be the public address of the gateway or the address of the specified interface.

low_port_number and high_port_number can be any port number.

map

Description

Specifies a public source address with which to replace the private source address on outgoing packets on the specified interface. Also establishes a correlation, or mapping, between the original private source address and public source address in the translated packet. This mapping is used to route incoming packets received in response to the outgoing packet to the correct private network host. Used to configure Basic NAT.

Syntax

map interface private_source_address {-> | to} public_source_address




map-block

Description

Specifies a public source address with which to replace the private source address on outgoing packets on the specified interface. Differs from map in that each private address is assigned a unique public address. Also establishes a correlation, or mapping, between the original private source address and public source


178

address in the translated packet. This mapping is used to route subsequent incoming packets to the correct private network host. Used to configure Basic NAT.

Syntax

map-block interface private_source_address {-> | to} public_source_address


public_source_address is a public address space from which a unique public address is substituted for the specified private_source_address.

nonapt

Description

Disables NAPT when a protocol does not allow the source port to be changed. In such cases, append the nonapt keyword to the proxy rule. The IKE protocol may require that the source port is not changed. See proxy, p.179, for further information on the specific usage of this keyword.

port

Specifies the port number used in proxy and rdr rules. See proxy, p.179, and rdr, p.181, for further information on the specific usage of this keyword.

portmap

Description

Specifies the source port translation for outgoing packets that meet the specified parameters for source address, interface, and protocol. Used in conjunction with the map keyword to configure NAPT.

Syntax

map interface private_source_address {-> | to} public_source_address portmap protocol low_port_number:high_port_number



179

E



protocol can be tcp, upd, or tcp/udp.

low_port_number and high_port_number can be any port number.

proxy

Description

Used in conjunction with the keywords map, map-block, pt, pt-block, or rdr to configure an ALG.

Syntax

{map|map-block|pt|pt-block} interface private_source_address {-> | to} public_source_address proxy port port_number alg[/protocol][nonapt]



public_source_address is a public address space from which a unique public address is substituted for the specified private_source_address.

port_number is the trigger port that causes the ALG to be called (typically the well known port for the service the ALG is meant to handle). The new source port is allocated from the automatic port interval set in the Workbench kernel components IPNAT_AUTOPORT_START_INTERVAL and IPNAT_AUTOPORT_END_INTERVAL. For further information on these variables, see 10.3.1 Components and Parameters, p.86.

alg is the identifier of the ALG.

protocol is the protocol that, in combination with the specified port, causes the ALG to be called. protocol must be the same as the protocol for which the ALG is registered.

In some rare cases, it may be necessary for the proxy rule to disable NAPT when the protocol does not allow the source port to be changed. For this purpose, append the nonapt keyword to the proxy rule. The IKE protocol may require that the source port is not changed.


180

For Bidirectional NAT, a port keyword specifying the proxy trigger port precedes the -> string. A second port keyword follows the private host address, specifying the port on the private host to which the packet is to be redirected.

rdr interface destination_address port port_number {-> | to} private_host_address port port_number protocol proxy proxyname

pt

Description

Specifies an IPv4 public source address with which to replace the IPv6 private source address on outgoing packets on the specified interface. Also establishes a correlation, or mapping, between the original private source address and public source address in the translated packet. This mapping is used to route incoming packets received in response to the outgoing packet to the correct private network host. Used to configure NAT-PT.

Syntax

pt interface private_source_address {-> | to} public_source_address

interface is the incoming interface on the IPv6 side of the gateway.

private_source_address is the IPv6 address of the private host transmitting the packet. Can optionally include an IPv6 prefix of up to 128 bits.

public_source_address is the translated source address in IPv4 format of the outgoing packet.

pt-block

Description

Specifies an IPv4 public source address with which to replace the IPv6 private source address on outgoing packets on the specified interface. Differs from pt in that each private address is assigned a unique public address. Also establishes a correlation, or mapping, between the original private source address and public source address in the translated packet. This mapping is used to route subsequent incoming packets to the correct private network host. Used to configure NAT-PT.

Syntax

pt-block interface private_source_address {-> | to} public_source_address


181

E

interface is the incoming interface on the IPv6 side of the gateway.

private_source_address is the IPv6 address of the private host transmitting the packet. Can optionally include an IPv6 prefix of up to 128 bits.

public_source_address is the translated source address in IPv4 format of the outgoing packet.

public_source_address is a public address space from which a unique IPv4 public address is substituted for the specified IPv6 private_source_address.

rdr

Description

Redirects incoming packets that meet the specified parameters for destination address, interface, port, and protocol to the specified private host and port. Used to configure Bidirectional NAT, a DMZ host, or an ALG.

Syntax

rdr interface destination_address[/mask] port port_number {-> | to} private_host_address port port_number [protocol] [proxy proxyname]

interface is the interface on which the incoming packet is received.

destination_address is the destination address specified in the packet of the incoming packet.

port_number appears twice in an rdr rule. In the first instance, port_number is the destination port number of the incoming packet. In the second instance, port_number is the port number of the private host to which the packet is redirected. To specify any port, use 0.

private_host_address is the address of the private host to which the incoming packet is redirected.

protocol is the protocol of the incoming packet, which can be gre, icmp, ip, tcp, udp, or tcp/udp. The protocol number can also be used.


182

to

Description

A string used to indicate a mapping between a private source address and a public source address. Equivalent to ->. If you are using the VxWorks target shell, the -> does not work. Use to instead.

Syntax

{map|map-block|pt|pt-block} interface private_source_address to public_source_address

183

FWind River NAT Libraries

ipnet_nat – Public API of Wind River NAT 184


184

ipnet_nat

NAME ipnet_nat – Public API of Wind River NAT

ROUTINES ipnet_nat_enable( ) – enable NATipnet_nat_disable( ) – disable NATipnet_nat_add_rule( ) – add a NAT ruleipnet_nat_remove_rule( ) – remove a NAT ruleipnet_nat_flush_rules( ) – remove all NAT rulesipnet_nat_flush_mappings( ) – remove all NAT mappingsipnet_nat_proxy_add_mapping( ) – add a public-to-private NAT mappingipnet_nat_proxy_set_mapping_timeout( ) – set a timeout for a mappingipnet_nat_proxy_get_time( ) – return the elapsed time since the last bootipnet_nat_proxy_timeout_schedule( ) – schedule a timeout handleripnet_nat_proxy_timeout_reschedule( ) – reschedule a timeout handleripnet_nat_proxy_timeout_cancel( ) – cancel a timeoutipnet_nat_add_proxy( ) – add a proxy to NATipnet_nat_remove_proxy( ) – remove a proxy from NAT

DESCRIPTION This library contains the APIs used for configuration of Wind River NAT.

INCLUDE FILES none

185

GWind River NAT Routines

ipnet_nat_add_proxy( ) – add a proxy to NAT 185ipnet_nat_add_rule( ) – add a NAT rule 186ipnet_nat_disable( ) – disable NAT 187ipnet_nat_enable( ) – enable NAT 187ipnet_nat_flush_mappings( ) – remove all NAT mappings 188ipnet_nat_flush_rules( ) – remove all NAT rules 188ipnet_nat_proxy_add_mapping( ) – add a public-to-private NAT mapping 189ipnet_nat_proxy_get_time( ) – return the elapsed time since the last boot 190ipnet_nat_proxy_set_mapping_timeout( ) – set a timeout for a mapping 190ipnet_nat_proxy_timeout_cancel( ) – cancel a timeout 191ipnet_nat_proxy_timeout_reschedule( ) – reschedule a timeout handler 192ipnet_nat_proxy_timeout_schedule( ) – schedule a timeout handler 192ipnet_nat_remove_proxy( ) – remove a proxy from NAT 193ipnet_nat_remove_rule( ) – remove a NAT rule 194

ipnet_nat_add_proxy( )

NAME ipnet_nat_add_proxy( ) – add a proxy to NAT

SYNOPSIS IP_PUBLIC Ip_err ipnet_nat_add_proxy ( const char *label, const char *proto, Ipnet_nat_proxy_func func, void *cookie );

DESCRIPTION The ipnet_nat_add_proxy( ) routine adds a proxy (ALG) to NAT.


186

Parameters:

labelAn ASCII string identifier.

protoThe IP protocol the proxy applies to. Either a protocol name or numerical string is allowed.

funcA pointer to the ALG function.

cookieA cookie that is supplied in the call to the proxy function. The memory location referred to by the cookie must be valid as long as the proxy has not been removed.


ERRNO

SEE ALSO ipnet_nat

ipnet_nat_add_rule( )

NAME ipnet_nat_add_rule( ) – add a NAT rule

SYNOPSIS IP_PUBLIC Ip_err ipnet_nat_add_rule ( const char *rule );

DESCRIPTION The ipnet_nat_add_rule( ) routine adds a NAT rule to the curent set of NAT rules.

Parameter:

ruleA pointer to a string containing the rule.


ERRNO

SEE ALSO ipnet_nat

G Wind River NAT Routines ipnet_nat_disable( )

187

G

ipnet_nat_disable( )

NAME ipnet_nat_disable( ) – disable NAT

SYNOPSIS IP_PUBLIC Ip_err ipnet_nat_disable(void);

DESCRIPTION The ipnet_nat_disable( ) routine disables NAT and flushes all mappings.

Parameters:

None.


ERRNO

SEE ALSO ipnet_nat

ipnet_nat_enable( )

NAME ipnet_nat_enable( ) – enable NAT

SYNOPSIS IP_PUBLIC Ip_err ipnet_nat_enable(void);

DESCRIPTION The ipnet_nat_enable( ) routine enables NAT and reads configuration settings for it.

Parameters:

None.


ERRNO

SEE ALSO ipnet_nat


188

ipnet_nat_flush_mappings( )

NAME ipnet_nat_flush_mappings( ) – remove all NAT mappings

SYNOPSIS IP_PUBLIC Ip_err ipnet_nat_flush_mappings(void);

DESCRIPTION The ipnet_nat_flush_mappings( ) routine removes all NAT mappings.

Parameters:

None.


ERRNO

SEE ALSO ipnet_nat

ipnet_nat_flush_rules( )

NAME ipnet_nat_flush_rules( ) – remove all NAT rules

SYNOPSIS IP_PUBLIC Ip_err ipnet_nat_flush_rules(void);

DESCRIPTION The ipnet_nat_flush_rules( ) routine removes all NAT rules.

Parameters:

None.


ERRNO

SEE ALSO ipnet_nat

G Wind River NAT Routines ipnet_nat_proxy_add_mapping( )

189

G

ipnet_nat_proxy_add_mapping( )

NAME ipnet_nat_proxy_add_mapping( ) – add a public-to-private NAT mapping

SYNOPSIS IP_PUBLIC int ipnet_nat_proxy_add_mapping ( Ipnet_nat_proxy_tuple *proxy_tuple, Ip_u32 timeout, void *parent, Ip_bool use_napt, Ip_bool use_inbound, Ipnet_nat_proxy_func proxy_func, void *proxy_cookie );

DESCRIPTION The ipnet_nat_proxy_add_mapping( ) routine adds a mapping between a host on the private side of the NAT and a host on the public side of the NAT. Such a mapping is typically used to open a port through the NAT, which is usually closed to incoming connections. It can also be used to open an outgoing path through the NAT, if there is no matching rule.

The proxy_tuple parameter specifies the private and public addresses and ports, as well as the protocol. If the source port of the connecting host is unknown, it can be set to zero to allow any source port to be used. Likewise, if the source address of the connecting host is unknown, it can be set to zero to allow any host connect. Once the mapping has been used for the first time, it can only be used by the host that connected first. Setting both the the private and public addresses to zero is not allowed.

The protocol can be any protocol, except for ICMP. For non-TCP/UDP protocols, the ports must be set to zero. Additionally, the source address can be set to zero to allow any host to connect. The source port is be the same on the private host and the NAT gateway unless the use_napt parameter is set to IP_TRUE. In this case, a new port is automatically allocated and port translation takes place.

Optionally, packets matching the mapping can be configured to call an application proxy if the proxy_func and proxy_cookie parameters are set.

Parameters:

proxy_tupleA pointer to the proxy tuple.

timeoutA timeout, after which the port is closed if no packets arrive. A timeout of 0 means that default values are applied).

parentA pointer to the NAT mapping that caused the call to the proxy function. This pointer must have the same pointer value as was received in the call to the proxy function in the argument param->mapping


190

use_naptSet to IP_TRUE for port translation.

use_inboundSet to IP_TRUE to indicate that the session will start inbound.

proxy_funcAn optional proxy function.

proxy_cookieAn optional proxy cookie.

RETURNS The NAT port, or -1 on failure.

ERRNO

SEE ALSO ipnet_nat

ipnet_nat_proxy_get_time( )

NAME ipnet_nat_proxy_get_time( ) – return the elapsed time since the last boot

SYNOPSIS IP_PUBLIC Ip_u32 ipnet_nat_proxy_get_time(void);

DESCRIPTION The ipnet_nat_proxy_get_time( ) routine returns the time elapsed since booting, in seconds.

Parameters:

None.

RETURNS The number of seconds since booting.

ERRNO

SEE ALSO ipnet_nat

ipnet_nat_proxy_set_mapping_timeout( )

NAME ipnet_nat_proxy_set_mapping_timeout( ) – set a timeout for a mapping

SYNOPSIS IP_PUBLIC void ipnet_nat_proxy_set_mapping_timeout

G Wind River NAT Routines ipnet_nat_proxy_timeout_cancel( )

191

G

( Ip_u32 sec, void *mapping );

DESCRIPTION The ipnet_nat_proxy_set_mapping_timeout( ) routine sets a timeout for a mapping.

Parameters:

secThe number of seconds after which the mapping times out.

mappingA pointer to the NAT mapping that caused the call to the proxy function. This pointer must have the same pointer value as was received in the call to the proxy function in the argument param->mapping

RETURNS No return value.

ERRNO

SEE ALSO ipnet_nat

ipnet_nat_proxy_timeout_cancel( )

NAME ipnet_nat_proxy_timeout_cancel( ) – cancel a timeout

SYNOPSIS IP_PUBLIC void ipnet_nat_proxy_timeout_cancel ( void *tmo );

DESCRIPTION The ipnet_nat_proxy_timeout_cancel( ) routine cancels a scheduled timeout.

Parameter:

tmoA pointer to the timeout structure.

RETURNS No return value.

ERRNO

SEE ALSO ipnet_nat


192

ipnet_nat_proxy_timeout_reschedule( )

NAME ipnet_nat_proxy_timeout_reschedule( ) – reschedule a timeout handler

SYNOPSIS IP_PUBLIC int ipnet_nat_proxy_timeout_reschedule ( Ip_u32 sec, Ipnet_nat_proxy_timeout_handler handler, void *cookie, void **ptmo );

DESCRIPTION The ipnet_nat_proxy_timeout_reschedule( ) routine resets the timeout period, in seconds, on a running timer with a new timeout period, after which a user-defined timeout handler is called.

Parameters:

secThe length of time, in seconds, after which the function is called.

handlerA pointer to the function to be called.

cookieA cookie for use by the called function.

ptmoA pointer that stores the location of a pointer to the timeout structure used by the timeout handler. The pointer must be provided by the user and kept until the timeout handler has been called.

RETURNS 0 for success; a negative value for failure.

ERRNO

SEE ALSO ipnet_nat

ipnet_nat_proxy_timeout_schedule( )

NAME ipnet_nat_proxy_timeout_schedule( ) – schedule a timeout handler

SYNOPSIS IP_PUBLIC int ipnet_nat_proxy_timeout_schedule ( Ip_u32 sec,

G Wind River NAT Routines ipnet_nat_remove_proxy( )

193

G

Ipnet_nat_proxy_timeout_handler handler, void *cookie, void **ptmo );

DESCRIPTION The ipnet_nat_proxy_timeout_schedule( ) routine sets a timeout period, in seconds, after which a user-defined timeout handler is called.

Parameters:

secThe length of time, in seconds, after which the function is called.

handlerA pointer to the function to be called.

cookieA cookie for use by the called function.

ptmoA pointer that stores the location of a pointer to the timeout structure used by the timeout handler. The pointer must be provided by the user and kept until the timeout handler has been called.

RETURNS 0 for success; a negative value for failure.

ERRNO

SEE ALSO ipnet_nat

ipnet_nat_remove_proxy( )

NAME ipnet_nat_remove_proxy( ) – remove a proxy from NAT

SYNOPSIS IP_PUBLIC Ip_err ipnet_nat_remove_proxy ( const char *label, const char *proto );

DESCRIPTION The ipnet_nat_remove_proxy( ) routine removes a proxy (ALG) from NAT.

Parameters:

labelAn ASCII string identifier.


194

protoThe IP protocol the proxy applies to. Either a protocol name or numerical string is allowed.


ERRNO

SEE ALSO ipnet_nat

ipnet_nat_remove_rule( )

NAME ipnet_nat_remove_rule( ) – remove a NAT rule

SYNOPSIS IP_PUBLIC Ip_err ipnet_nat_remove_rule ( const char *rule );

DESCRIPTION The ipnet_nat_remove_rule( ) routine removes a NAT rule from the curent set of NAT rules.

Parameter:

ruleA pointer to a string containing the rule.


ERRNO

SEE ALSO ipnet_nat

195

H Wind River NAT Shell

Command

nat

Name

nat – enable, disable, and modify NAT.

Synopsis

nat [-silent] {rule | -f filename | -r rule | -n rule | -p | -s | -l | -m | -C | -D | -E | -F | -V | -Z}

Description

nat is used to add or remove NAT rules and to display NAT statistics. The command runs on a target shell. If you are using the VxWorks target shell, the -> string cannot be used to join translated addresses. Use to instead.

The shell command options are as follows:

-silentSuppress error output. This option is required for shell commands that are automatically executed at system startup.

-fAdd rules from the specified file.



196

-rRemove the specified rule.

-nCheck syntax for the specified rule.

-pDisplay loaded ALGs.

-sDisplay NAT statistics.

-lDisplay rules.

-mDisplay mappings.

-CClear active NAT mappings.

-EEnable NAT.

-DDisable NAT.

-FFlush all rules and mappings.

-VShow NAT version.

-ZClear NAT statistics.

197

Index

Symbols! (firewall keyword) 39, 52

reference entry 138# (comment delimiter)

for firewall 35reference entry 138

for NAT 106reference entry 176

#define commandsINCLUDE_FEI_END

for firewall 14for NAT 88

INCLUDE_USER_APPLfor firewall 17for NAT 91

IPFIREWALL_MAX_IP_LOG_ENTRIES 42IPFIREWALL_MAX_MAC_LOG_ENTRIES

42IPNET_USE_NAT_DNS_ALG 122IPNET_USE_NAT_FTP_ALG 97, 123IPNET_USE_NAT_H323_ALG 124IPNET_USE_NAT_IPSEC_ALG 125IPNET_USE_NAT_PPTP_ALG 126IPNET_USE_NAT_TRIGGER_ALG 127USER_APPL_INIT


#define statementsINCLUDE_VXBUS 14

for NAT 87+ (firewall keyword) 35-> (NAT keyword) 105, 106

reference entry 176@ (index parameter)


AActiveX controls 71ActiveX filters 72adding

ALGs 127firewall rules 42, 43hooks for firewall rules 17hooks for NAT rules 91NAT rules 112, 113, 128

additional documentationfor firewall 7for NAT 82

addressfilters 52, 60mapping 104resolution 79

address blocks, mapping between 108


198

address scope 34IP filter 52, 138MAC filter 60, 138

addresses used in examples 3, 78adjusting log capacity 42ALGs 81

configuring 118custom 127DNS 121, 133fragments with 104FTP 122, 132, 133H.323 123, 132ICMP 121introduction to 118IPsec 125, 132port trigger 126PPTP 125, 132program example 132provided with NAT 120routine type 128routines for 131

all (firewall keyword) 34, 52, 60reference entry 139

any (firewall keyword) 34, 52, 60reference entry 139

APIadding firewall rules with 3, 35, 43creating firewall rules with 36developing rule sets with

firewall 36NAT 107

firewall functionality available with 7for integrating a custom ALG with Wind River

NAT 81, 118NAT

functionality available with 82routines for custom ALGs 81

appdata parameter 129applen parameter 129application programming interface, see APIapplication-level gateways, see (ALGs)

BBasic NAT 79

configuring 107limitations with 107

Bidirectional NAT 104configuring 109enabling DMZ host support with 111overview of 79

block (firewall keyword) 34reference entry 139

blocked packets 57responding to 57

booting the target 18, 92building

firewallfrom Workbench 18, 91

burst (firewall keyword) 38reference entry 139

Ccheck routine 64checking

rule syntaxfirewall 45NAT 114

clearingactive mappings 114firewall log 42firewall statistics 47firewall tables 48–50NAT statistics 116

code examplehome/SOHO gateway firewall 28NAT code 97simple firewall 23

commentsin firewall rule files 35

componentsfirewall

excluding 17NAT

excluding 90

Index

199

Index

config.h 14and additional interfaces 14, 16, 90

for NAT 87NAT 88

configNet.hand additional interfaces 14

NAT 88configuring

ALGs 118Basic NAT 107Bidirectional NAT 109DMZ hosts 111firewall 11

on a gateway 13NAPT 108NAPT-PT 111NAT 85

on a gateway 87NAT-PT 110network interfaces 15

at build time 15, 89for firewall 15for NAT 88at run time 16, 90

stateful inspection 56connection tracking, see stateful inspectioncookie parameter 126, 130cookies

custom routines 64filtering 72

creatinghome/SOHO gateway firewall 25IP filters 51MAC filters 59simple firewall 21

custom routines 64–65introduction to (firewall) 63table of 49viewing 65

Ddefining custom routines 63destroy routine 64

developing firewall applications 12, 85devname parameter 15, 89disabling

the firewall 42NAT 112

DMZ hostconfiguring 111enabling 111ICMP requests to 105NAT operation with 105overview of 80

DNS ALG 79, 81, 120, 121

Eenabling

the firewall 42HTTP content filtering 68NAT 112

ESP packets 125exclamation point, see ! (firewall keyword) 52excluding

firewall components 17NAT components 90

Ffile system 45, 115filtering

ActiveX controls 71by address 52, 60cookies 72fragments 55by frame type 61HTTP content 6, 67by ICMP type and code 54by interface 34, 60by IP options and fragments 55IP traffic 52Java applets 71MAC traffic 60by port (UDP and TCP protocols) 54


200

by protocol 53proxy traffic 70by TCP flags 54by time to live 53by type of service or traffic class 53

firewallaction 34building 12, 85components

excluding 17configuring

introduction to 11disabling 42enabling 42fundamentals of 32–50including in VxWorks image 11information

viewing 46introduction to 3log 25

clearing 42viewing 41

operation of 32overview of 3–9rule matching algorithm 37rules

adding 42, 43elements of 34examples of 6inserting in group 44methods for writing 35removing 42restoring 45saving 45

shell commandreference 171

statistics 25, 30, 46clearing 47viewing 46

tablesclearing 48–50viewing 48

tutorial 19introduction to 19

first (firewall keyword) 41reference entry 140

flags (firewall keyword)reference entry 140

for firewall 14frag (firewall keyword) 55

reference entry 141fragid parameter 130fragments

filtering 55handling of 104

fragmf parameter 130fragoff parameter 130frame type 61FreeBSD 3from (firewall keyword) 52, 60

reference entry 141FTP ALG 81, 120, 122func parameter 126

Ggateway parameter 16, 89gateway6 parameter 16, 90GRE protocol 109group (firewall keyword) 36

reference entry 142group rule table 50grouped rule sets 37growspace parameter 129

HH.225 protocol 123H.245 protocol 123, 124H.323 ALG 81, 120, 123H.323 standard 123head (firewall keyword) 36

reference entry 142hooks

for firewall rules 17for custom routines 64

Index

201

Index

for NAT rules 91HTTP content filtering 6, 67

ActiveX controls 71, 72enabling 68introduction to 67of Java applets 72of proxy traffic 70program example 73of URLs and keywords 69

IICMP

ALG 81, 121code 54type 54

ICMP echo packets, stateful inspection with 56ICMP echo requests, NAT mapping 103ICMP requests to DMZ host 105ICMP type and code 54icmpidmap (NAT keyword) 109, 111

reference entry 176icmp-type (firewall keyword)

reference entry 142ICMPv6 echo packets

stateful inspection with 56ICMPv6 message 58ifconfig shell command 16, 90IFCONFIG_N parameter 15, 89ifname parameter 15, 89implementing

an ActiveX filter 72a cookie filter 72a Java applet filter 71NAT 95proxy filtering 71a URL filter 70

in (firewall keyword) 34reference entry 143

inbound packets 104inbound parameter 130INCLUDE_FEI_END


INCLUDE_IPNET_IFCONFIG_N component 15, 89

INCLUDE_USER_APPLfor firewall 17for NAT 91

incoming parameter 130inet dhcp parameter 15, 89inet driver parameter 15, 89inet parameter 15, 89inet rarp parameter 15, 89inet6 parameter 16, 89info parameter, custom routine 64, 65infolen parameter, custom routine 64inserting a rule within a group 44interfaces, filtering by 34, 60internet address spaces, private 3, 78Internet protocol, filtering by 53Internet Security Association and Key Management

Protocol (ISAKMP) 125IP filter 3, 52

address scope 52, 138creating 51described 32introduction to 51logging traffic 40responding to blocked packets 57rule syntax 137

IP fragments 55IP options 55ipAttach shell command 16, 90ipcom_malloc( ) 129ipf shell command

adding rules with 3, 35, 42, 43checking rule syntax with 45clearing statistics with 47clearing tables with 48–50creating firewall rules with 36developing rule sets with 36disabling the firewall with 42displaying statistics with 47enabling the firewall 42functionality of 7reference entry 171removing rules with 45specifying rule position with 44


202

viewing custom routines with 65viewing firewall version with 18viewing tables with 48–50

IPF_FWMAC_RULE_FILE 12, 46IPF_ICMP_TIMEOUT 12, 57IPF_IPV4_RULE_FILE 12, 46IPF_IPV6_RULE_FILE 12, 46IPF_MAX_STATEFUL_MAPPINGS 12, 56IPF_OTHER_TIMEOUT 13, 57IPF_TCP_TIMEOUT 13, 57IPF_UDP_TIMEOUT 13, 57ipfirewall_add_rule( ) 17, 22, 26ipfirewall_h.h 42ipfirewall_http_add_filter( ) 68ipfirewall_http_insert_activex_filter( ) 72ipfirewall_http_insert_cookie_filter( ) 72ipfirewall_http_insert_java_filter( ) 71ipfirewall_http_insert_url_filter( ) 70, 71IPFIREWALL_MAX_IP_LOG_ENTRIES 42IPFIREWALL_MAX_MAC_LOG_ENTRIES 42ipfirewall_register_userdef( ) 65ipfirewall_unregister_userdef( ) 65IPFIREWALL_USE_HTTP_FILTER_TEST 73IPNAT_AUTOPORT_END_INTERVAL 86, 119IPNAT_AUTOPORT_START_INTERVAL 86, 119IPNAT_ICMP_MAPPING_TIMEOUT 86IPNAT_MAX_MAPPING 86IPNAT_OTHER_MAPPING_TIMEOUT 86IPNAT_TCP_MAPPING_TIMEOUT 86IPNAT_UDP_MAPPING_TIMEOUT 86ipnet_config.h 90ipnet_nat_add_proxy( ) 126, 127ipnet_nat_add_rule( ) 96ipnet_nat_add_rule( ), 91ipnet_nat_proxy_add_mapping( ) 131ipnet_nat_proxy_get_time( ) 131ipnet_nat_proxy_set_mapping_timeout( ) 131ipnet_nat_proxy_timeout_cancel( ) 131ipnet_nat_proxy_timeout_reschedule( ) 131ipnet_nat_proxy_timeout_schedule( ) 131ipnet_nat_remove_proxy( ) 127IPNET_USE_NAT_DNS_ALG 122IPNET_USE_NAT_FTP_ALG 97, 123IPNET_USE_NAT_H323_ALG 124IPNET_USE_NAT_IPSEC_ALG 125

IPNET_USE_NAT_PPTP_ALG 126IPNET_USE_NAT_TRIGGER_ALG 127ipopts (firewall keyword) 55

reference entry 143IPsec Passthrough ALG 81, 120, 125IPv4

addresses 80rules 55

IPv6addresses 53, 80packet translation 103rules 55

JJava applet filter 71, 72

Kkeep state (firewall keyword) 56

reference entry 143keyword reference

firewall 138NAT 176

Llimit (firewall keyword) 38

reference entry 144log 25, 46

clearing 42formats 40table 49viewing 41

log (firewall keyword) 30, 41reference entry 144

logging 6, 34, 39, 41IP filter traffic 40MAC traffic 40

Index

203

Index

MMAC

frame types 61MAC filter

address scope 138creating 59described 32introduction to 59logging traffic 40rule syntax 138

MAC trafficfiltering 60

mac-type (firewall keyword) 61reference entry 145

map (NAT keyword) 105, 107reference entry 177

map-block (NAT keyword) 108reference entry 177

mappingbetween address blocks 108

mapping parameter 130mappings

clearing 114match routine 64matching algorithm

firewall 37me (firewall keyword) 34, 52, 60

reference entry 145methods for

filtering IP traffic 52filtering MAC traffic 60writing rules

firewall 35NAT 106

multicast traffic 27

NNAPT 79

configuring 108for ICMP protocol 97for TCP and UDP protocols 97operation 103

NAPT-PT 80configuring 111operation 103

NATcomponents

excluding 90configuring

introduction to 85fundamentals of 101–116information, viewing 115introduction to 77–84keyword reference 176operation 102, 103redirect rule syntax 176rule processing algorithm 102, 105, 128rules

adding 112, 113, 128elements of 105removing 112restoring 115saving 115simple gateway example 96syntax 175

statistics 99, 116viewing 116

tutorial 93introduction to 93

NAT routerwith ALG support 132with ALG support and DMZ host 132

nat shell commandadding rules with 77, 106, 113, 115checking rule syntax with 114checking statistics with 99clearing active mappings with 114clearing rules and mappings with 115clearing statistics with 116developing rule sets with 107disabling NAT with 98, 112enabling NAT with 98, 112functionality of 82reference entry 195removing rules with 114specifying rule position with 113viewing NAT version with 92


204

viewing rules and mappings with 115viewing statistics with 116

nat_addr parameter 130nat_port parameter 130NAT-PT 80

configuring 110operation 103

natpt parameter 130NAT-PT router

with ALG support 133NAT-T 80NetBSD 3network configuration

firewall tutorial 20NAT tutorial 94

network interfaceconfiguring 15


network interfacesadding


configuringat build time 15, 89for firewall 15–16for NAT 88–90

filtering by 34newdata parameter 129newhdr parameter 129no (firewall keyword) 55

reference entry 146nonapt (NAT keyword) 119

reference entry 178nonvolatile storage

for firewall 7, 45for NAT 115

Oon (firewall keyword) 34

reference entry 145OpenBSD 3

out (firewall keyword) 34reference entry 146

outbound packets 102

Pparam parameter 129pass (firewall keyword) 34

reference entry 146pcPentium BSP

firewall 14NAT 88

pkt parameter, custom routine 64point-to-point protocol (PPP) 125port (firewall keyword) 54

reference entry 147port (NAT keyword)

reference entry 178port entries

TCP/UDP 81port translation 79, 80, 103port triggering 81, 120, 126porthi parameter 126portlo parameter 126portmap (NAT keyword) 108, 109, 111

reference entry 178ports, filtering by 54PPTP Passthrough ALG 81, 120prefix parameter 130PREFIX::/96 network 103private internet address spaces 3, 78private networks 27private_address parameter 131private_port parameter 131proto (firewall keyword)

reference entry 148protocol

filtering by 53translation 80

protocol parameter 126, 131proxy (NAT keyword) 118, 119, 120

reference entry 179proxy filter 70

Index

205

Index

pt (NAT keyword) 105, 110, 111reference entry 180

pt-block (NAT keyword) 110reference entry 180

PTTP Passthrough ALG Operation 125public_address parameter 131public_port parameter 131

Qquick (firewall keyword) 23, 27, 37

reference entry 148

Rrate limiting 5, 38, 38–39rdr (NAT keyword) 105, 109

reference entry 181rdr rule syntax 176Related RFCs

for NAT 83removing rules

firewall 42, 45NAT 112, 114

Request for Comments, see RFCsresponding to blocked packets 57restoring rules

firewall 45NAT 115

return-icmp (firewall keyword) 57, 58reference entry 148

return-icmp-as-dest (firewall keyword) 58reference entry 150

return-rst (firewall keyword) 57reference entry 151

RFCs1034, Domain Names – Concepts and

Facilities 83, 1211035, Domain Names – Implementation and

Specification 83, 1211701, Generic Routing Encapsulation (GRE)

84, 125

1886, DNS Extensions to support IP version 684, 121

1918, Address Allocation for Private Internets3, 9, 78, 84

2196, Site Security Handbook 92406, IP Encapsulating Security Payload

(ESP) 84, 119, 1252408, Internet Security Association and Key

Management Protocol (ISAKMP) 84, 125

2428, FTP Extensions for IPv6 and NATs 84, 122

2616, Hypertext Transfer Protocol 702663, Application Level Gateways 812663, IP Network Address Translator (NAT)

Terminology and Considerations 832766 Network Address Translation—Protocol

Translation (NAT-PT) 83, 1222766, Network Address Translation—Protocol

Translation (NAT-PT) 1032874, DNS Extensions to Support IPv6 Address

Aggregation and Renumbering 84, 121

3022, Traditional IP Network Address Translator (Traditional NAT) 82, 83, 122

3519, Mobile IP Traversal of Network Address Translation (NAT) Devices 81

3947, Negotiation of NAT-Traversal in the IKE 80

relatedNAT 83

routinesavailable for ALGs 131custom 64–65

rule filesdeveloping rule sets with

firewall 35, 43NAT 106

separating 45rule matching algorithm

firewall 37rule position 44

firewall 44NAT 113


206

rule processing algorithmfirewall 37NAT 102, 105, 128

rule syntaxfirewall 137–138IP filter 137MAC filter 138NAT 175

rule table 48group 50

rulesgrouping 44and rule groups 36writing


Ssample rule set

ALG support 132simple NAT router 111

sample rule setshome/SOHO gateway firewall 28

saving firewall rules 45saving NAT rules 115security policy

home/SOHO gateway firewall example 26simple firewall example 22

sendingdestination unreachable message (ICMP

only) 57reset segment (TCP only) 57

simple NAT routerprogram example 111

SMPand firewall 13and NAT 87

smurf attacks 27special networks 27specifying

rule positionfirewall 44NAT 113

spoofing attacks 27state table 49stateful inspection 4, 22, 56, 56–57

of ICMP packets 23, 28of TCP/UDP packets 28, 23

statisticsfirewall 25, 30, 46NAT 116

supported RFCs (NAT) 83symmetric multiprocessing, see SMPsyntax

firewall rules 137–138IP filter rules 137ipf shell command 171MAC filter rules 138NAT rules 175nat shell command 195rdr rules 176

Ttables, firewall 46, 48TCP

filtering by 53filtering by port 54NAT mapping 103port entries 81protocol

stateful inspection with 56TCP flags 54

filtering by 54mask 55

TCP/IP stack 80testing

home/SOHO gateway firewall example 29NAT implementation 98simple firewall example 24

time to live 53filtering by 53

timeout parameter 126to (firewall keyword) 52, 54, 60

reference entry 151to (NAT keyword) 106

reference entry 182

Index

207

Index

token bucket filter 38tos (firewall keyword)

reference entry 151tos field 53traffic class 53transport layer headers 56ttl (firewall keyword)

reference entry 152ttl field 53tuple parameter 130tutorial network configuration

for firewall 20–21for NAT 94–95

tutorialstesting firewall setup 24writing filtering rules 22

type of service 53filtering by 53

UUDP

filtering by 53filtering by port 54NAT mapping 103port entries 81stateful inspection with 56

URL filter 69USER_APPL_INIT 17, 91


user-defined routines, see custom routinesusrAppInit.c

firewall 22, 26, 36NAT 96, 107

Vverifying inclusion in build

firewall 18NAT 92

viewing

custom routines 65firewall information 46firewall log 41firewall statistics 46firewall tables 48NAT information 115NAT rules and active mappings 115NAT statistics 116

WWind River documentation 8, 82with (firewall keyword) 55

reference entry 152writing

ALG routine 128custom ALGs 127rules


Wind River Firewall and NAT for VxWorks 6 User's Guide,...

Documents

Transcript of Wind River Firewall and NAT for VxWorks 6 User's Guide,...