32 Firewall Management. Westermo RFI-219-F4G-T7G, Viper-212A-T5G-P8-HV, RFI-219-F4G-T7G-F8, RFI-211-F4G-T7G, L106-F2G, Viper-212A, L205-S1, Viper-112A-T5G, L110-F2G, Viper-112A-T3G

Westermo OS Management Guide

Version 4.22.0-0

Chapter 32

Firewall Management

When connecting your network to the Internet (or any non-trusted network) a router with firewall functionality should be used. The firewall will protect against undesired access to your local servers, or other kinds of network intrusion from attackers on the Internet.

The WeOS firewall supports the following main features:

Packet filtering: Packet filters enables you to control what traffic is allowed to pass through your router/firewall and what packets it should drop. Packet filter rules can also be specified to control access to services on your router.

Packet modification: Packet modification makes it possible to modify packets that are routed through the router/firewall.

Network Address Translation (NAT): The WeOS NAT functionality includes both network address port translation (NAPT) and 1-TO-1 NAT.

Port forwarding: Port forwarding is often used together with NAPT, and will then enable you to access servers in your private network from outside (e.g., from the Internet).

The WeOS firewall utilises connection tracking; a rule allowing traffic to pass through the firewall in one direction, will implicitly allow traffic of established connections (and traffic of related connections) to also pass in the reverse direction. Application level gateway (ALG) helper functions can be enabled to provide connection tracking of more complex protocols, such as FTP and SIP.

Section 32.1

describes the firewall functionality available in WeOS.

Sections 32.2

and

32.3

cover firewall management via the Web Interface and via the CLI.

© 2017 Westermo Teleindustri AB 757


Version 4.22.0-0

32.1

Overview

Table 32.1

summarises the supported firewall functionality.

Sections 32.1.1

-

32.1.5

provide further information on the WeOS firewall support.

Feature

Enable Firewall

Packet filtering

Enable Packet Filtering

Filtering Rules

Rule Reordering

Activate/Deactivate Rules

Default Forward Policy

Default Input Policy

Stateful Packet Inspection

Packet modification

DSCP

Network Address Translation

NAPT

1-TO-1 NAT

Port Forwarding

ALG Helpers

Logging

X

X

X

X

X

Web

CLI

General Description

X

X

X

Sections 32.1.1

-

32.1.2

Sections 32.1.1

-

32.1.2

X

Sections 32.1.1

-

32.1.2

X

Sections 32.1.1

-

32.1.2

X

Sections 32.1.1

-

32.1.2

X

Sections 32.1.1

-

32.1.2

X

Sections 32.1.1

-

32.1.2

X

Sections 32.1.1

-

32.1.2

X

Sections 32.1.1

-

32.1.2

Sections 32.1.1

,

32.1.3

X

Section 32.1.3.3

X

X

X

X

X

X

X

X

X

X

Sections 32.1.1

Sections 32.1.1

Sections 32.1.1

Section 32.1.1

Section 32.1.6

,

,

,

32.1.4

32.1.4

32.1.5

View Firewall Configuration

View Firewall Status

X X

X

Table 32.1: Summary of Firewall functionality in WeOS

32.1.1

Firewall introduction

The WeOS firewall includes support for three related types of functionality:

Packet Filtering: The packet filtering support is primarily used to control what traffic is allowed to be routed via the switch (forward filtering), but can also be used to control accessibility to services on the switch itself (input filtering).

758 © 2017 Westermo Teleindustri AB


Version 4.22.0-0

The WeOS firewall utilises connection tracking; a filter rule allowing traffic to pass through the firewall in one direction, will implicitly allow traffic of

established connections (and traffic of related connections) to also pass in the reverse direction. Connection tracking can configured to handle more complex protocols by enabling ALG helpers (see below).

WeOS supports up to 1024 filtering rules. The WeOS packet filtering support is further described in

sections 32.1.2

and

32.1.2.3

.

Packet modification: WeOS currently supports one kind of packet modification:

– DSCP: The Differentiated Services Code Point (DSCP) field of the IP header is used for classifying traffic in some environments. The value of this field can be modified by WeOS when routing the IP packets.

WeOS supports up to 32 packet modifier rules. The WeOS packet modification support is further described in

section 32.1.3

.

Network Address Translation (NAT): WeOS supports two kinds of NAT support:

– NAPT: NAPT is the most common NAT form, where a common (public) IP address is shared by a set of hosts in a private network. This form of NAT is sometimes referred to as IP Masquerading or port address translation

(PAT). NAPT is often used together with port forwarding, see below.

– 1-TO-1 NAT: 1-TO-1 NAT enables you to translate a whole range of IP addresses to another set of addresses.

WeOS supports up to 512 NAT rules. The WeOS NAT support is further described in

section 32.1.4

.

Port Forwarding: Port forwarding is commonly used together with NAPT. With port forwarding a service (such as a Web Server) located in a private network, can be made accessible from the public network, typically from the

Internet.

WeOS supports up to 256 port forwarding rules. The WeOS port forwarding support is further described in

section 32.1.5

.

Some network protocols are more complex and therefore more difficult than others to handle by the connection tracking function in a firewall or NAT device. An example is FTP, which utilises a control connection to exchange information on

TCP port numbers for data connections for the actual file transfers – to enable a

PC to download files through a firewall from an FTP server on the Internet, the



Version 4.22.0-0 firewall must inspect the FTP control connection to learn which connections to let through. To make the firewall handle such protocols correctly, protocol specific

ALG helpers can be enabled. As of WeOS v4.22.0 ALG helpers for FTP, TFTP, SIP,

IRC, H323 and PPTP are supported. ALG helpers have some impact on the unit’s routing performance, thus are by default disabled.

32.1.2

Packet Filtering

To Switch

(HTTP, SSH, SNMP, ...)

INPUT

FILTERING

Packet

Filtering

Packet

Modification

PREROUTING

FORWARD

MODIFICATION

Port

Forwarding

1−1 NAT

FORWARD

FILTERING

NAPT

From Switch

(HTTP, SSH, SNMP, ...)

OUTPUT

FILTERING

POSTROUTING

NETWORK NETWORK

Figure 32.1: Overview of Firewall mechanism. Thick lines represent packet flows.

Fig. 32.1

presents an overview of the firewall mechanism, including the components for packet filtering, packet modification, NAT, and port forwarding.

The following sections provide a more in-depth description of the WeOS packet

filtering functions.

Filtering chains (input, forward, output): Filter rules can apply to

– traffic destined to the switch (input filtering), e.g., HTTP traffic to manage the switch,

– traffic forwarded/routed by the switch (forward filtering), or

– traffic generated by the switch (output filtering).



Version 4.22.0-0

The WeOS firewall supports input and forward filtering, but not output filtering.

Section 32.1.2.1

gives more details on WeOS handling of filtering chains.

Configurable allow/deny filter rules: The user can define filter rules to specify traffic to be allowed or denied, and the order of the configured rules.

Incoming packets are evaluated against the filter rules – the first matching rule will decide how to treat the packet (allow or deny).

Section 32.1.2.2

describes packet matching parameters for filter rules, and

section 32.1.2.3

provides more information on filter evaluation order (both for configured filter rules and implicit filter rules described below).

Default rules to allow ”ping”

When enabling the firewall, the user is offered to add a set of default

rules - these rules allow ICMP packet to pass the input filter, thereby enabling operators to ping the unit after enabling the firewall. These rules are treated as any other configured rule, thus can be removed, etc.

Implicit filter rules: The WeOS firewall implicitly adds firewall rules for services enabled on the unit, e.g., for DHCP, OSPF or DNS. The primary purpose of this is to simplify management of those services when the firewall is enabled. With a few exceptions, these implicit rules are evaluated after the

configured rules (see above), thus, a user could override or complement the implicit rules by configuring additional filter rules. Below is a list of services associated with implicit filter rules.

– IPsec VPN:

* IPsec signalling and data encapsulation: If at least one IPsec tunnel is enabled, rules are implicitly added to allow IP protocol 50 (ESP), and UDP port 4500 (IKE/ESP for NAT traversal) to enter the unit on all interfaces.

* Allowing data to pass through tunnels: For every IPsec VPN tunnel

(see

chapter 36 ) filter rules are implicitly added to the forward filter

to allow between the local subnet and remote subnet defined for the VPN tunnel.

As of WeOS v4.22.0, the implicit IPsec VPN rules are added before the configured filter rules (for performance reasons). Thus, the implicit

IPsec VPN rules can not be overridden by rules configured by the user.



Version 4.22.0-0

– Port Forwarding: With port forwarding ( section 32.1.5

) it is possible

to map incoming data to a given destination IP and (UDP/TCP) port to another destination IP/port when forwarding the packet. As shown in

fig. 32.1

this mapping is conducted at the pre-routing stage of the packet processing. For every configured port forwarding rule, a filter rule is implicitly added to the forwarding filter to allow the packet to pass through the router. This is hinted by a dashed arrow in

fig. 32.1

.

– NAT: Network address translation ( section 32.1.4

) involves ”translation

operations” both in the pre-routing (”1-TO-1 NAT”) and in the postrouting stage (”1-TO-1 NAT” and ”NAPT”) as shown in

fig. 32.1

. For

every configured NAT rule, an associated filter rule can be added to the forwarding filter to allow the packet to pass through the router. This is hinted by a dashed arrow in

fig. 32.1

.

Note

The user can choose if an associated filter rule should be added for each NAT rule or not. If disabled, the user needs to configure own filter rule(s) to make the data packets pass through the firewall.

See

sections 32.1.4.1

and

32.1.4.2.3

for more information.

– Services: Filter rules are implicitly added to to the input filter to allow packets for enabled services to enter the unit. This includes config-

urable services such as DHCP Server ( chapter 23

), Serial Over IP ( chapter 40

), VRRP ( chapter 31 ), etc., where allow rules are added matching

TCP/UDP port numbers, IP protocols, and/or incoming interfaces appropriate for the configured services. As the WeOS unit acts as a DNS forwarder, implicit allow rules to accept incoming DNS requests are also added.

TTDP is a protocol for train routers( chapter 43 ). TTDP will implicitly add

(hidden) 1-1 NAT rules and matching (hidden) filter rules to the forward

filter to allow the NAT:ed traffic to pass.

Management interface: The WeOS management interface feature

( section 22.2.7

) utilises firewall functionality to control which network inter-

faces the unit can be managed through.

Other filter rules:

– Connection tracking (related/established): The WeOS firewall will allow all packets associated with established connections, as well as packets related to established connections. This means that an a rule allowing



Version 4.22.0-0 traffic to pass through the firewall in one direction, will implicitly allow traffic of established connections (and traffic of related connections) to also pass in the reverse direction. Application level gateway (ALG) helper functions can be enabled to provide connection tracking of more complex protocols, such as FTP and SIP.

For performance reasons, packets of related/established connections are evaluated early in the filter chains, thus cannot be overridden by filter rules configured by the user.

– Stateful Packet Inspection (ability to drop packet of invalid state): It is also possible to fine-tune the connection tracking behaviour to drop

packets of invalid 1

state – this is done by enabling the stateful packet

inspection (SPI) setting. In some situations that can be considered as a security enhancement, however, it may cause problems in topologies with asymmetric routing and is therefore disabled by default.

– Default filter rules: Packets not matching any filter rule will be handled according to the default filter policy. The default filter policy for the input

filter and forwarding filter chains are configurable, see

section 32.1.2.1

.

32.1.2.1

Filtering chains (input, forward, output)

Fig. 32.1

presents an overview of the firewall mechanism including the filtering chains (input, forward and output). Packets are treated differently if they:

are destined to the switch: Examples include HTTP/HTTPS, SSH, Telnet, and

SNMP traffic used to manage the switch remotely, and ICMP (Ping) traffic to check if the switch is up or not. Such packets are subject to pre-routing and

input filtering firewall mechanisms.

originate from switch: This includes the same examples as above (HTTP/HTTPS,

SSH, Telnet, SNMP, ICMP, etc.) with the difference that this is the packets from the switch instead of the packets to the switch. Such packets are subject to output filtering and post-routing firewall mechanisms, however WeOS does not include primitives to control output filtering.

are routed via the switch: This includes traffic that is not destined for the switch or originate from the switch. Such packets are subject to pre-routing,

forward filtering and post-routing firewall mechanisms.

1

An example of a packet with an ”invalid” state is when a firewall sees a TCP ”SYN+ACK”, without having seen the preceding TCP ”SYN” in the other direction.



Version 4.22.0-0

As of WeOS v4.22.0, the selection of filter chain for configured filter rules is implicitly derived from the ”outbound interface” and ”destination IP Address/subnet” settings (see

section 32.1.2.2

) for the rule:

Apply rule to forwarding filter: If ”outbound interface” and/or ”destination

IP Address/subnet” are specified in the filter rule, it will apply to the ”Forwarding Filter” chain.

Apply rule to input filter: If neither ”outbound interface” nor ”destination

IP Address/subnet” are specified, the filter rule will apply to the ”Input Filter” chain.

WeOS does not support adding filter rules for the ”Output Filter” chain.

Associated with each filtering chain there is a default policy, defining what to do with packets that do not match any of the defined filter rules. When the firewall is enabled, the default policies for packet filtering are as follows:

Input Filtering: Deny, i.e., packets to the switch are dropped unless they are explicitly allowed.

Forward Filtering: Deny, i.e., when enabling the firewall no packets will be routed by the switch until such packet filter rules are defined.

Output Filtering: Accept, i.e., there are no restrictions on the traffic originating from the switch.

32.1.2.2

Filter Rules Packet Matching

Packet filtering allow and deny rules can be specified to match IP packets based on the following filtering parameters:

Inbound Interface: The interface where the packet comes in.

Outbound Interface: The interface where the packet is sent out.

Source IP Address/Subnet: The source IP address of the packet. This can be specified as a single IP address, or the rule could match a whole IP subnet.

Destination IP Address/Subnet: The destination IP address of the packet.

This can be specified as a single IP address, or the rule could match a whole

IP subnet.



Version 4.22.0-0

Protocol: The protocol type of the IP payload. Typically TCP or UDP, but the

filtering can also be made to match other protocols such as ICMP and ESP 2 .

Destination (UDP/TCP) Port: When protocol is specified as UDP or TCP, the filter can match on the associated destination UDP/TCP port number(s).

Source (UDP/TCP) Port: When protocol is specified as UDP or TCP, the filter can match on the associated source UDP/TCP port number(s).

As described in

section 32.1.2.1

the filter setting for ”outbound interface” and

”destination IP Address/subnet” implicitly controls whether the rule will apply to the input filter or forwarding filter.

An incoming packet will be processed according to the rules defined for input filter when the packet is destined to the switch, or the rules defined for the forwarding

filter when the packet is being routed through the switch. The list of rules is searched (in order) until a match is found; if no matching rule is found, the packet is treated according default policy of the chain.

For more information on the rule evaluation order in the input filter and forward filter, see

section 32.1.2.3

.

32.1.2.3

Rule Evaluation Order in Input and Forward Filters

When the firewall is enabled, incoming packets are subject to input filtering or

forward filtering depending if the packet is destined to the switch itself, or if it should be routed to another network. Once the packet has been classified for the input or output filter chain, the list of that chain is traversed to find a matching rule. If a match is found, the packet will either be accepted or dropped depending on the type of matching rule (allow or deny). If no matching rule is found, the packet will be handled according to the default policy of the chain.

The filter rules are inserted in the list in a certain order; the same order as the packet matching evaluation is conducted. To view the current input and forward filter evaluation lists, use the command ”show firewall” (see

section 32.3.13

)

from the Admin Exec context. The order in which rules are inserted in the input and forward filters is described below.

2

See http://www.iana.org/assignments/protocol-numbers/ for a list of defined IP protocols.



Version 4.22.0-0

32.1.2.3.1

Input Filter

1. Established/Related: Packets part of (or related) to established connections will be accepted. This rule is inserted first for performance reasons - the majority of all accepted packets will match this rule.

2. Drop invalid: If the stateful packet inspection (SPI) setting has been enabled, packets of invalid state will be dropped. (See

section 32.1.2

for more information on what the SPI setting does.)

3. VPN Rules: If the WeOS unit is configured as VPN gateway, rules to accept

IKE and ESP traffic are implicitly inserted here (UDP port 500 and 4500, and

IP protocol 50).

4. Configured Packet Filter Rules: Then the configured packet filter rules are inserted, i.e., the configurable allow/deny rules described here in

section 32.1.2

.

The relative order of these packet filter rules is configurable.

As all packet rules are configured before the rules for ”Enabled Services” and ”Management Interfaces” (see below), the packet filter rules can be used to override those rules. E.g., if the management interface configura-

tion has disabled SNMP management via interface vlan1 (”no management

snmp”, see

section 22.6.6

), a packet filtering rule allowing host 192.168.3.1

SNMP access (”filter allow src 192.168.3.1 proto udp dport 161”, see

section 32.3.3

) will have precedence, and thus allow SNMP manage-

ment from that particular host even if the SNMP traffic enters via interface

vlan1.

5. Enabled Services: Depending on what additional services are enabled in the configuration, additional allow rules will be inserted to enable those services to operate correctly. As of WeOS v4.22.0, this includes

DHCP Server: UDP port 67 is allowed for appropriate interfaces if a DHCP server is configured (see

chapter 23 ).

OSPF: IP protocol 89 is allowed if the unit is configured to run OSPF for dynamic routing (see

chapter 28 ).

RIP: UDP port 520 is allowed if the unit is configured to run RIP for dynamic routing (see

chapter 29 ).

VRRP: IP protocol 112 is allowed for appropriate interfaces if VRRP is configured on the unit (see

chapter 31 ).

Serial Over IP: If Serial Over IP is configured (Server, Peer or AT command mode), an allow rule according to the configured (UDP/TCP) port



Version 4.22.0-0 and interface is added (see

chapter 40 ).

Modbus: If the unit is configured as a Modbus gateway (server mode), an allow rule according to the configured TCP port and interface is added

(see

chapter 41 ).

DNS: UDP/TCP port 53 is allowed on all interfaces as the WeOS unit acts as a DNS forwarder.

6. Enabled Management Interfaces: As described in

section 22.2.7

, an operator

can use the Management Interface feature to enable/disable services per network interface. The management interface configuration is kept separate from the firewall configuration, but both configuration methods can affect the Input Filter. Allow rules for enabled management services are added

per interface 3 .

SSH: TCP port 22 is opened for interfaces where management via SSH has been enabled. (This also enables use of SCP for remote file access, see

section 7.1.5.3

).

Telnet: TCP port 23 is opened for interfaces where management via

Telnet has been enabled.

HTTP: TCP port 80 is opened for interfaces where management via HTTP has been enabled.

HTTPS: TCP port 443 is opened for interfaces where management via

HTTPS has been enabled.

SNMP: UDP port 161 is opened for interfaces where management via

SNMP has been enabled.

(IPConfig:) If management via IPConfig service has been enabled, no corresponding allow rule is required - IPConfig protocol packets are instead filtered by other (lower-level) mechanisms in WeOS.

7. Default Policy: Packets not matching any of the rules above will be handled according the default policy for the input filter chain.

3

As of WeOS v4.22.0 ”allow” rules for enabled management services are added given that the

”Default policy” for the input filter is set to ”deny”. If the default policy is changed to ”allow”, then

”deny” rules for disabled management interfaces will be inserted instead.



Version 4.22.0-0

32.1.2.3.2

Forwarding Filter

1. Packet modification: Defined packet modifications are always performed before all filter rules, implicit and configured. Please see

section 32.1.3

for additional details.

2. Established/Related: Packets part of (or related) to established connections will be accepted. This rule is put first of the forwarding filters for performance reasons - the majority of all accepted packets will match this rule.

3. Drop invalid: If the stateful packet inspection (SPI) setting has been enabled, packets of invalid state will be dropped. (See

section 32.1.2

for more information on what the SPI setting does.)

4. VPN Rules: If the WeOS unit is configured as VPN gateway, rules to accept traffic between the local and remote subnets specified in the respective IPsec tunnel definitions are added to the forward filter. The reason for adding the implicit IPsec allow filter rules early in the evaluation order is to improve routing performance of VPN traffic. (In case you wish to limit the traffic to pass through the IPsec tunnel further, the recommendation is to update the IPsec tunnel definitions of local and remote subnet accordingly, see

section 36.1.1

.)

5. Configured Packet Filter Rules: Then the configured packet filter rules are inserted, i.e., the configurable allow/deny rules described here in

section 32.1.2

.

The relative order of these packet filter rules is configurable.

6. NAT and Port Forwarding Rules: As described in

section 32.1.2

implicit allow filter rules are added for every configured port forwarding rule.

This is also true for NAT rules, however, here the user can choose whether the associated rule should be created or not (see

sections 32.1.4.1

and

32.1.4.2.3

). The internal order of the NAT rules can be changed, which also

affects the order in which the associated filter rules are inserted in the forwarding filter chain.

7. Enabled Services (TTDP): If TTDP is enabled ( chapter 43 ), implicit (hidden)

filter rules will be added to allow the ”railway NAT” traffic to pass.

8. Default Policy: Packets not matching any of the rules above will be handled according the default policy for the forwarding filter chain.



Version 4.22.0-0

32.1.3

Packet modification

WeOS supports modification of packets that are routed through the router/firewall.

In the firewall overview,

fig. 32.1

in

section 32.1.2

, you can see that the modifi-

cation is performed just before the forward filtering. Current limitations are that you can only modify the DSCP field of the IP header, and that modification is only possible for forwarded traffic, not for inbound or outbound local traffic.

Packet modification is specified as rules, similar to filters, and they are evaluated

in the same order as they are listed. Opposite to filters ( section 32.1.2

), packet

modification rules are non-terminating. This means that every rule will be evaluated for packets passing through, and packets may be modified more than once on its way through the modifier step.

32.1.3.1

Performance considerations

The packet filtering mechanism utilises the connection tracking mechanism to optimise handling for already established sessions, while packet modification rules can not use this connection tracking benefit. The modification rules will be evaluated for every single forwarded packet passing the router/firewall, which means that modification rules have a much bigger performance impact than filtering rules.

As using modifier rules decreases the total routing throughput of the router/firewall, you should use this feature with care and avoid adding unnecessary rules.

32.1.3.2

Packet modification matching

Much like packet filters, modification rules can have match parameters defining what traffic the rules apply to. The matching parameters are optional – if skipped the modifier rule runs for ALL packets.

These are the matching parameters that can be used:

Inbound Interface: The interface where the packet comes in.

Outbound Interface: The interface where the packet is sent out.

Source IP Address/Subnet: The source IP address of the packet. This can be specified as a single IP address, or the rule could match a whole IP subnet.



Version 4.22.0-0

Destination IP Address/Subnet: The destination IP address of the packet.

This can be specified as a single IP address, or the rule could match a whole

IP subnet.

Protocol: The protocol type of the IP payload. Typically TCP or UDP, but the

filtering can also be made to match other protocols such as ICMP and ESP 4 .

Destination (UDP/TCP) Port: When protocol is specified as UDP or TCP, the filter can match on the associated destination UDP/TCP port number(s).

Source (UDP/TCP) Port: When protocol is specified as UDP or TCP, the filter can match on the associated source UDP/TCP port number(s).

32.1.3.3

Modification of the DSCP field

32.1.3.3.1

DSCP Introduction

DSCP, Differentiated Services Code Point (or Diffserv Code Point), is a standardised method for marking IP packets that they belong to a specific class of traffic.

Its use in the IP header is specified in RFC 2474[ 32 ].

Octet 0 Octet 1

Version IHL Type of Service

Octet 8

Time to Live

Octet 16

Octet 9

Protocol

Octet 2

Octet 10 Octet 11

Header Checksum

Octet 17 Octet 18

Destination Address

Octet 3

Total Length

Octet 19

Octet 4

Identification

Octet 5

Octet 12

Flags

Octet 6

Octet 13 Octet 14

Source Address

Octet 7

Fragment Offset

Octet 15

Octet 20 Octet ...

...

Options, padding, payload data ...

...

Figure 32.2: The IPv4 header

For the IPv4 header (RFC 791[ 35 ]), the ”Type of service” (or ToS) octet on offset

1 is used for carrying this kind of data. See

fig. 32.2

.

The IPv4 ToS octet has historically been used in different ways.

0 1 2

Precedence

3

D

4

T

5

R

6

M 0

7

Figure 32.3: ToS bits according to RFC 791 + RFC 1349

4

See http://www.iana.org/assignments/protocol-numbers/ for a list of defined IP protocols.



Version 4.22.0-0

The original definition of ToS in RFC 791 has 3 precedence bits, and bits 3-5 as

flags for ”cost” aspects: ”Delay”, ”Throughput” and ”Reliability”. RFC 1349[ 2 ]

updated ToS by adding the utilisation of bit 6 for ”Monetary cost”. See

fig. 32.3

.

0 4 5 1 2 3

DSCP

6 7

ECN

Figure 32.4: ToS bits according to RFC 2474 + RFC 3168

Later on, RFC 2474 redefined the use of the octet to carry DSCP information in

the first 6 bits. RFC 2481[ 36 ] and its replacement RFC 3168[ 37 ] complement this

by defining bits 6-7 for ”Enhanced Congestion Notification” (ECN), see

fig. 32.4

.

Both these conflicting interpretations are still in use today confusingly enough.

The DSCP modification and the Layer-2 prioritising mechanisms ( section 10.1.4

)

in WeOS are adapted to the RFC 2474 use.

32.1.3.3.2

Setting DSCP

WeOS can set the 6 DSCP bits in the IP ToS field with a modifier rule. The two last bits (Enhanced Congestion Notification) are not modified by this operation.

The decimal values 0-63 must be used when setting DSCP.

Several RFCs define standard DSCP values called ”Per-Hop Behaviors” or PHBs.

WeOS does not support the PHB names for configuration, but the table below can be used to convert PHB names to the corresponding decimal values.

PHB Name DSCP value

DF

CS1

AF11

AF12

AF13

CS2

AF21

AF22

AF23

CS3

AF31

14

16

18

20

0

8

10

12

22

24

26

PHB Name

AF32

AF33

CS4

AF41

AF42

AF43

CS5

VA

EF

CS6

CS7

DSCP value

36

38

40

44

28

30

32

34

46

48

56



Version 4.22.0-0

32.1.3.3.3

DSCP Adjust priority

There is an additional parameter called ”adjust priority” that can be added to a

DSCP modifier rule. This parameter enables adjustment of the router’s internal packet priority handling inline with the modified DSCP value. Furthermore, if traffic is routed out on a port that has tagged VLAN, this will affect the IEEE

802.1p priority field in the outbound packets.

This is useful in some scenarios when the DSCP is overridden. The priority adjustment function is made to mimic the behaviour of the Layer-2 priority support when configured in the IP ToS/DiffServ mode, as described in

chapter 10 ,

section 10.1.4

.

Enabling this flag will introduce more work for the CPU inside the WeOS unit for every packet that is modified. As this decreases the maximum routing performance, it should only be enabled when necessary.



Version 4.22.0-0

32.1.4

Network Address Translation

WeOS supports two kinds of NAT: NAPT ( section 32.1.4.1

) and 1-to-1 ( section 32.1.4.2

).

32.1.4.1

NAPT style NAT

NAPT, or ”Network Address and Port Translation” enables hosts on a private network to share an Internet connection with a single public IP address. NAPT is also known as IP Masquerading or PAT (Port Address Translation) in the Cisco world.

Public Network (Internet)

NAPT

Gateway

Outbound Interface

(public IP address)

Inbound Interface

Internal/Private

Network

Figure 32.5: NAPT gateway providing access to the Internet. All hosts in the private network share a single public IP address.

When configuring a NAPT rule, you need to specify the outbound interface 5 . The

appropriate rule will then be added to the post-routing step (see

fig. 32.1

) han-

dling the address translation. A rule is also needed in the forward filtering chain to enable the forwarding (routing) of traffic, and that can be added automatically by using the ”addfilter” option as shown in the example below (here we assume that the interface ”Outbound/Public” side is named ”vlan2”.

Example

example:/config/ip/firewall/#> nat type napt out vlan2 addfilter

5

Appropriate interface IP settings must be configured, and IP routing must also be enabled, see

chapter 22 .



Version 4.22.0-0

The resulting firewall allow rule is shown below:

Example

example:/#> show firewall

=== Forwarding Packet Filter Rules ===========================================

Forwarding Policy DROP target

...

prot in out source destination

ACCEPT all any vlan2 anywhere anywhere

...

Connection tracking will ensure that packets in the reverse direction (from the

Internet to the private network) are accepted and managed properly.

32.1.4.2

1-to-1 style NAT

1-to-1 NAT, also called Full NAT, maps an entire network block in a one-to-one fashion.

32.1.4.2.1

Forward 1-to-1 NAT


Inbound Interface

External (public) IP network

Ex: 10.20.30.0/24

1−TO−1

NAT

Gateway

IP Destination

10.20.30.2

.1

IP Destination

192.168.0.2

Internal/Private Network

192.168.0.0/24

.33

.79

Web

Server

.2

Host

Host

Figure 32.6: 1-to-1 NAT mapping external IP addresses to internal addresses.



Version 4.22.0-0

A 1-to-1 NAT rule is defined by an inbound interface and two network blocks, the externally (publicly) visible network block and the internal block (typically private

IP addresses). IP packets entering the router through the inbound interface targeted to the external network will be transformed so they become targeted to the internal block instead (see

fig. 32.6

). Packets going to the first IP in the external

block will be mapped so they go to the first IP in the internal block, packets to the second external IP to the second internal IP, and so on. This one-to-one mapping requires that the external and internal network blocks are of the exact same size.

1-to-1 NAT mapping is done in the pre-routing step in the firewall (see

fig. 32.1

).

This means (for inbound packets affected by a 1-to-1 NAT rule) that the destination IP address is changed to another IP address before routing is done and before rules in the input filtering and forward filtering chains are evaluated. Make sure that you only use the internal network block (called ”new destination” in the web configuration and ”to-dst” in CLI config) in routing and filtering as the external network is not visible inside the unit.

32.1.4.2.2

Reverse 1-to-1 NAT


Inbound Interface

1−TO−1

NAT

Gateway

IP Source

10.20.30.2

.1

IP Source

192.168.0.2

Web

Server

.2

Figure 32.7: Reverse 1-to-1 NAT mapping

1-to-1 NAT is bi-directional which means that the NAT works in the reverse direction too. A request coming from an internal IP will be transformed so it appears to come from the external net when leaving the router through the configured

”inbound” interface (see

fig. 32.7

).



Version 4.22.0-0

In this case the translation of the IP source address will be performed in the post-

routing chain ( fig. 32.1

), just before packets leave the router. This means that

the original internal network IP will be matched as source in any forward filtering and output filtering rules. The external addresses will not be visible here similar to the forward direction NAT.

32.1.4.2.3

1-1 NAT and implicit firewall rules Consider the sample network setup shown in

figs. 32.6

and

32.7

. Assuming the ”inbound” interface is

named ”vlan2”, then the ”1-to-1” NAT rule could be achieved with the following

CLI command.

Example

# Example with implicit firewall rule example:/config/ip/firewall/#> nat type 1-to-1 in vlan2 dst 10.20.30.0/24 to-dst 192.168.2.0/24 addfilter

The ”addfilter” attribute will add implicit firewall rules to allow forward traffic

( fig. 32.6

) and reverse traffic ( fig. 32.7

) to automatically pass through the firewall.

One rule is created in each direction, as shown below.

Example


...


Forwarding Policy DROP target prot in out source destination

...

ACCEPT

ACCEPT

...

all all vlan2 any any vlan2 anywhere

192.168.2.0/24

192.168.2.0/24 anywhere

Using the ”addfilter” makes it easy to get your NAT-traffic through the firewall in either direction. But in cases where there are security concerns, such as when the ”inbound” interface is located on the public Internet, use of the ”addfilter” option for ”1-to-1 NAT” is too permissive. Instead you could add explicit firewall rules to allow traffic according to your specific requirements. An example is shown below where traffic is only allowed to be initiated from the private network

(i.e., the ”reverse” direction as shown in

fig. 32.7

). Note that the ”nat” command

does not include the ”addfilter” option here.



Version 4.22.0-0

Example

# Example with explicit firewall rule instead of implicit example:/config/ip/firewall/#> nat type 1-to-1 in vlan2 dst 10.20.30.0/24 to-dst 192.168.2.0/24 example:/config/ip/firewall/#> filter allow out vlan2 src 192.168.2.0/24

The resulting firewall rule is shown below.

Example


...


Forwarding Policy DROP target prot in

...

ACCEPT

...

all any out vlan2 source

192.168.2.0/24 destination anywhere

32.1.4.2.4

Proxy ARP and 1-to-1 NAT

WeOS 1-to-1 NAT includes a proxy ARP mechanism, which makes the WeOS unit answer on ARP requests for the external network specified in the configuration

(the ”dst” parameter in the CLI or Destination Address(es) field in the Web interface). The router will only answer on ARP requests originating from the network connected to the inbound interface (CLI: ”in” parameter, Web: Incoming

Interface). This makes it possible to use 1-to-1 NAT to pick up traffic to a specific subnet from within a larger network without the need of explicit routing settings.

An example is shown in

fig. 32.8

: You have a subnet 10.0.0.0/16 set on your

external LAN, and want to use 1-to-1 NAT to take care of the specific subnets

10.0.1.0/24, 10.0.2.0/24 and 10.0.3.0/24, which should be translated and routed to the inside of the Router1, Router2 and Router3 respectively. In this case, hosts at the external LAN, such as the management PC (10.0.0.99), will use ARP when they want to reach something within the 10.0.0/16 range. If the PC sends an

ARP Request for 10.0.1.33 (PLC3), WeOS Router1 will respond and announce its own MAC address in the ARP reply. Traffic from the management PC (and other hosts on the external network) to 10.0.1.33 (PLC3) will be sent to Router1, which performs 1-to-1 NAT (10.0.1.33⇒192.168.1.33) before forwarding the packets towards PLC3.

Proxy ARP removes the need for explicit routing in some scenarios, but if you are setting up a purely routed configuration, proxy ARP might not be useful, and in



Version 4.22.0-0

PC

(Mgr)

.99

1−1 NAT with

Proxy ARP

.1 WeOS

Router1

.1

192.168.1.0/24 (10.0.1.0/24)

.5

PLC1

.11

PLC2

.33

PLC3

1−1 NAT with

Proxy ARP

.2 WeOS

Router2

.1

192.168.1.0/24 (10.0.2.0/24)

.5

PLC4

.11

PLC5

.33

PLC6

1−1 NAT with

Proxy ARP

.3

WeOS .1

Router3

192.168.1.0/24 (10.0.3.0/24)

.5

.11

.33

PLC7 PLC8 PLC9

Figure 32.8: Use of proxy ARP with 1-to-1 NAT. The Management PC can reach the

PLCs without explicit routes to networks 10.0.1.0/24, 10.0.2.0/24 or 10.0.3.0/24.

some special cases even undesirable. For these special scenarios it is possible to disable Proxy ARP for a 1-to-1 NAT rule. This is done by specifying the CLI keyword ”noarp” or by un-checking the Proxy ARP checkbox in the Web. See

sections 32.2.2.2

(Web) and

32.3.5

(CLI) for configuration details.

32.1.4.3

NAT and IP Multicast

Chapter 30

describes WeOS support for IP multicast routing. Combining NAT and IP multicast routing is not generally supported, although there exist some specific use cases which work as of WeOS v4.22.0. Furthermore, when using

NAT for IP multicast traffic, the address translation only applies to the source IP address of the multicast packet (the source address is a unicast IP address).



Version 4.22.0-0

32.1.5

Port Forwarding

Port Forwarding is commonly used together with NAPT, to enable access from the

Internet to a server inside the private network.

Fig. 32.9

shows a typical setup when port forwarding is useful:

The switch acts as a NAT/NAPT gateway to the Internet: routing is enabled

(see

section 22.1

) and a NAPT rule defining the external (outbound) interface

has been configured (see

section 32.1.4

).

A Web Server on the ”internal” network serves users on the Internet: A port forwarding rule has been added to allow users on the Internet to initiate connections to the Web server on host 192.168.0.2 (TCP port 80).


External Interface

(public IP address, e.g., 1.2.3.4)

NAT/NAPT

Gateway

TCP TCP

Port 8080 Port 80

Web

Server

.2

Internal/Private Network

192.168.0.0/24

.33

.1

.79

Host

Host

Figure 32.9: Use of port forwarding to enable Internet hosts to access a Web server inside the private network via a NAT/NAPT gateway.

With port forwarding, users on the Internet will connect to the internal Web Server as if it was running on the NAT/NAPT gateway, i.e., users on the Internet will connect to the Web server using the public IP address (here 1.2.3.4) and TCP port number (here 8080), without knowing that the traffic is forwarded to a server inside the internal network.



Version 4.22.0-0

Configuration of port forwarding rules include the following parameters:

Inbound Interface: Packets which are subject to port forwarding should come in on the specified interface. In the example network shown in

fig. 32.9

, this

would be the external interface, i.e., the attached to the Internet.

Inbound Port (Range): Defines the range of TCP/UDP port numbers, which are to be mapped by this rule. In the example in

fig. 32.9

Internet hosts would reach the Web server using TCP port 8080.

Source IP Address/Subnet: Optional argument limiting the port forwarding rule to concern a limited set of Internet hosts.

Destination IP Address: Specifies the IP address of the private server, i.e., where packets are to be sent. The Web server in in

fig. 32.9

has IP address

192.168.0.2.

Destination Port (Range) Specifies which TCP/UDP port number(s) to use on the in the forwarded packet. The default is to use the same port number(s) as on the inbound interface. In the example, the Web server on the internal server uses TCP port 80. Note that only single port forwards can change the destination port so that it is different from the original inbound port.

Forwarding of a range of ports always keep the port numbers. Multiple single port forwarding rules can be used to form a range in case the destination port numbers must be changed.

Transport Protocol (TCP/UDP): Specify if this rule applies to TCP, UDP or both.

In the example, the rule applies only to TCP.

32.1.6

Firewall Logging

The WeOS firewall supports logging for monitoring and debugging purposes.

Firewall logging is done to the kernel log file kern.log, and to a remote syslog if configured. Internal system information will also be written to this file during

(re)boot of the system, and some configuration changes may also add information to this log.

This log file can be viewed from the web interface via the ”View Log” function under the menu: ”Maintenance”. It can also be viewed in the CLI with the command ”show log://kern.log”. For more information about log files and configuration of remote syslog, please see

chapter 26 .



Version 4.22.0-0

Details about configuration options can be found in

section 32.2

(Web), and

section 32.3

(CLI).

32.1.6.1

Enabling logging for firewall rules

Logging is enabled for individual rules in the firewall.

Logging is possible for packet filtering rules (both allow and deny), for NAT rules

(both NAPT and 1-to-1 types) and for port forwarding rules.

Logging is currently not possible for the packet modify operation, however traffic that is modified by packet modify rules is also passing through the forward filtering chain (see

fig. 32.1

). It is possible to simulate logging for packet modify by

adding a filter allow rule in the forward chain with the same matching condition as the modify rule, and enable logging for that filtering rule.

An entry is added to the log file when an IP packet hits a specific rule with logging enabled. Note that only the first packet in a connection will be logged.

Subsequent packets or return traffic packets belonging to the same session will not be logged (that would quickly overflow the logs).

Logging enabled for packet filter “deny” rules behave different though, and EV-

ERY packet hitting such a rule will be logged.

32.1.6.2

Settings for rate limitation

The firewall logging system has a rate limitation functionality, preventing excessive amount of log entries to be created upon problems. This will reduce problems due to malicious traffic from outside or inside the network, so called “denial of service” attacks (or DOS attacks), port scannings or similar. It will also avoid problems by excessive logging caused by bad configuration or malfunctioning units in the network causing traffic storms.

The limitation is configured as a maximum rate of log entries per time unit. The time units available are: second, minute, hour or day.

The configuration: “10 per second”, means just that, max 10 log entries will be written to the log file each second.

The rate is continous. This means that the allowance of log entries will be evenly distributed over the time unit. An example: “60 per hour” will allow 60 entries per hour, but distributed evenly as max one log entry per minute.



Version 4.22.0-0

This makes a rate of “1 per second” to be exactly the same as “60 per minute” and “3600 per hour” (also “86400 per day”, but that can not be configured as the biggest permitted value for any unit is 10000)

It is not possible to set non-continous rates like: 100 entries per calendar day etc.

If the rate limit of log entries is reached, the logging system will instantly begin

throwing away excessive log entries. The logging will not be buffered or delivered later to the log file.

The rate limitation can be disabled through configuration, but this will open up for potential problems with malicious attacks or storms, therefore it is not rec-

ommended that you disable the limitation mechanism. But you can and should adjust the limit to fit your needs.

Firewall logging can also be disabled on a system level. Nothing will be logged even if there is logging configured for individual firewall rules.

The default rate limitation will be set to “5 per second” when the firewall is enabled through the web or CLI.

32.1.6.3

Firewall log format

WeOS uses the Linux Netfilter logging mechanism. The standard Netfilter log format is used for recorded entries.

Log entries will be prefixed with the type of rule that was hit, and will always be one of: FW-ALLOW, FW-DENY, FW-NAPT, FW-1TO1 or FW-PF (port forwarding).

Remember that the kernel log is shared with other types of logging. The prefixes are a good way to find the relevant log entries in the file.

You will not see exactly which firewall rule that triggered a log entry, only the type of it. This can be a problem if you use many rules with logging enabled. However, the information provided in the log should be enough to figure out what specific rule was causing it.

A rule position number or some other helping reference to the specific rule may be added in a later release of WeOS.



Version 4.22.0-0

Here is an example of a kernel log entry generated when a filter ALLOW rule is hit:

Jan 15 14:44:49 example kernel: FW-ALLOW: IN=vlan1 OUT=vlan2

MAC=00:07:7c:10:de:c1:00:80:c8:3c:25:b7:08:00:45:00:00:54:c9:84

SRC=192.168.2.10 DST=192.168.3.100 LEN=84 TOS=0x00 PREC=0x00

TTL=63 ID=51588 DF PROTO=ICMP TYPE=8 CODE=0 ID=10941 SEQ=1

The same log entry line broken down in parts:

Log text part Explanation

Jan 15 14:44:49 example kernel:

FW-ALLOW:

Timestamp

The system host name

Identifies origin, kernel.log

This originates from a firewall filter “allow” rule

IN=vlan1

OUT=vlan2

PROTO=ICMP

TYPE=8

CODE=0

ID=10941

SEQ=1

Inbound interface “vlan1”, may be empty for NAT rules

Outbound interface “vlan2”

MAC= This is the first part from the ethernet packet

(this field may be empty for some rules)

00:07:7c:10:de:c1: The first part is destination MAC address

00:80:c8:3c:25:b7: This part is the source MAC address

08:00:

45:00:00:54:c9:84

Ethertype, 08:00 is IP

More data, first part of the IP header

SRC=192.168.2.10

Source IP address, always the original IP before any NAT transformation

DST=192.168.3.100

Destination IP address, before NAT

LEN=84 Packet length and other IP header options

TOS=0x00

PREC=0x00

TTL=63

ID=51588

DF

The IP protocol

The rest is protocol specific data and flags, in this specific case an ICMP ping request



Version 4.22.0-0

Here are example entries for the other types:

Jan 15 12:45:25 example kernel: FW-NAPT: IN= OUT=vlan1 SRC=192.168.2.200

DST=192.168.2.10 LEN=94 TOS=0x00 PREC=0x00 TTL=64 ID=59200 DF

PROTO=UDP SPT=514 DPT=514 LEN=74

Jan 15 14:45:12 example kernel: FW-1TO1: IN=vlan1 OUT=

MAC=00:07:7c:10:de:c1:00:80:c8:3c:25:b7:08:00:45:00:00:3c:bd:4b


TTL=64 ID=48459 DF PROTO=TCP SPT=55301 DPT=80 WINDOW=14600

RES=0x00 SYN URGP=0

Jan 15 14:45:29 example kernel: FW-PF: IN=vlan1 OUT=

MAC=00:07:7c:10:de:c1:00:80:c8:3c:25:b7:08:00:45:00:00:3c:ca:59


TTL=64 ID=51801 DF PROTO=TCP SPT=55631 DPT=8080 WINDOW=14600

RES=0x00 SYN URGP=0

Jan 15 14:49:16 example kernel: FW-DENY: IN=vlan1 OUT=

MAC=00:07:7c:10:de:c1:00:80:c8:3c:25:b7:08:00:45:00:00:1c:4a:ca


TTL=64 ID=19146 PROTO=UDP SPT=2702 DPT=2000 LEN=8



Version 4.22.0-0

32.2

Firewall Management via the Web Interface

Menu path: Configuration ⇒ Firewall ⇒ Common

On the firewall common settings page you may enable or disable the firewall.

When disabling the firewall all rules will be lost. A confirmation is required if you try to disable the firewall to not loose rules by accident.

Enabled

Logging Enabled Check to enable logging for the firewall. This is a master control enabling the logging feature. Note: you also need to enable logging on individual firewall rules for anything to be logged.

Limit Logging

Check this box to enable firewall functionality.

Note:

When disabling the firewall, the firewall is stopped and all existing NAT rules, Port Forwarding rules, Packet Filter rules and Packet Modify rules are deleted.

Check to enable rate limitation of the logging. The limit is set in the input boxes below. Warning: Disabling the limitation may lead to lots of data being logged. This can in a short time fill up the log files.

Limit Set the threshold rate value and time unit for the limitation. See

section 32.1.6

for information about how the limitation operates.



Version 4.22.0-0

32.2.1

NAT Rules

Menu path: Configuration ⇒ Firewall ⇒ NAT

On the Firewall NAT configuration page you are presented to the list of current

NAT rules. (If the firewall function is disabled or no rules have been created you will not see any list, but be presented to an information message.)

New Nat Rule

Select

Order

Active

Click this button to create a new NAT rule. You will be presented to a form where you can configure the new rule.

Check this box to select one or a set of rules for group rule management. Check the Select all box at the bottom of the page to select all rules.

The order in which the rules will be applied. When using a JavaScript enabled browser, it is possible to select one or more rules and perform an action on multiple rules, see below. If not using a JavaScript enabled browser, there will be a set of arrows available to move rules up or down to change the order of application.

A green check-mark means the rule is active, and a dash means it is inactive.

Continued on next page



Version 4.22.0-0

Type

Continued from previous page

The NAT type for this rule: NAPT or 1-TO-1

Incoming

Interface

Source

Address(es)

The IP address and subnet mask (CIDR) for matching the source address of packets

The outbound interface.

Destination

Interface

Destination

Address(es)

New Address(es) The target IP address and subnet mask (CIDR) for

1-TO-1 NAT

Filter Rule

The IP address and subnet mask (CIDR) for matching the destination address of packets

If automatic forwarding filter rules are created for this rule. A green check-mark means yes and a dash means no.

Proxy ARP

The inbound interface for packets that should be

NATed

Log

If Proxy ARP is enabled for a 1-to-1 NAT rule. A green check-mark means yes and a dash means no.

Controls if a match on this rule should be logged in the kernel log file. Nothing will be logged unless logging is also enabled under the common firewall settings.

Edit Click this icon to edit a NAT rule.

Delete

Selected Rules

Click this icon to remove a NAT rule. You will be asked to acknowledge the removal before it is actually executed.

Selected rules may be modified by selecting the rules to modify and select the modification action in the drop-down list and then click the Apply button.

32.2.2

New NAT Rule

Menu path: Configuration ⇒ Firewall ⇒ NAT ⇒ New NAT Rule

In the New NAT Rule configuration page you can specify a new NAT rule. This page exists in two views depending on what NAT type you want to create. When you enter this page initially, the ”NAPT” type is pre-selected. Change the type to

”1-TO-1” to see the other view. If you have disabled JavaScript you will only see one view with all fields from both NAPT and 1-TO-1 together.


32.2.2.1

New NAT Rule - NAPT view


Version 4.22.0-0

Active Rule is active if checked.

Type NAPT. If you change to 1-TO-1 NAT, the view will change. See

section 32.2.2.2

.

Incoming Interface Optional. The interface connected to your subnet whose addresses you want to translate (the interface to your internal/private network).

Source Address(es) Optional. The IP address and subnet mask (CIDR) identifying the IP subnet where this NAT rule should be applied.

Destination

Interface

Mandatory.

The interface that should represent all IP addresses on the subnet of the internal

interface.

This is the external/public interface, typically the interface connected to the Internet.




Version 4.22.0-0

Automatic Packet

Filter Rule

Log


Keep as checked if you want an automatically created rule in the firewall forwarding filter allowing packets that matches this NAT rule. This rule is invisible in the filter configuration. Uncheck it if you want to set up your own rules for controlling traffic.


32.2.2.2

New NAT Rule - 1-TO-1 NAT view

Active

Type

Rule is active if checked.

1-TO-1. If you change to NAPT, the view will change.

See

section 32.2.2.1

.




Version 4.22.0-0

Destination

Address(es)


Incoming Interface Mandatory. The inbound interface where traffic arrives to the router

Mandatory. The original external IP address and subnet mask (CIDR) that should be NATed

New Destination

Address(es)

Mandatory. The new internal IP address and subnet mask (CIDR) set by the NAT

Automatic Packet

Filter Rule

Check if you want automatically created rules in the firewall forwarding filter allowing packets that matches this NAT rule. Rules will be created for both forward direction and for the reverse direction. Keep unchecked if you want to set up your own rules for controlling traffic.

Proxy ARP Check to enable ARP proxying for the Destination

Address(es) on the Incoming Interface. You should have this enabled in most cases.

Log Controls if a match on this rule should be logged in the kernel log file. Nothing will be logged unless logging is also enabled under the common firewall settings.

32.2.3

Edit NAT Rule

Menu path: Configuration ⇒ Firewall ⇒ NAT ⇒

In the Edit NAT Rule configuration page you can change an existing NAT rule.

See

section 32.2.2

for description of editable fields.



Version 4.22.0-0

32.2.4

Port Forwarding Rules

Menu path: Configuration ⇒ Firewall ⇒ Port Forwarding

Port forwarding is e.g. used to give external units access to specific services in a subnet hidden by NAT/NAPT. If the firewall is disabled or no rules have been created you will see no list, but be presented to an information message.

New Forwarding

Rule

Select

Order

Active

Click this button to create a new port forwarding rule. You will be presented to a form where you can configure the new rule.


The order in which the rules will be applied. When using a JavaScript enabled browser, it is possible to select one or more rules and perform an action on multiple rules, see below. If not using a JavaScript enabled browser, there will be a set of arrows available to move rules up or down to change the order of application.





Version 4.22.0-0

Protocol

Incoming Interface

Incoming Destination

Port

Incoming Source

Address(es)

Destination Address

Destination New

Port

Log

Edit

Delete

Selected Rules


Traffic may be filtered on transport layer protocol.

Available are TCP and UDP.

The interface from which inbound traffic should be allowed.

The range of transport layer ports to match. E.g. 80 for standard web-server access.

Optional. The source IP address(es) of packets allowed to be forwarded. Either a single address, or a subnet. Subnet mask is displayed in CIDR notation

(prefix length).

The destination IP address to which the packets will be forwarded.

If another port or set of ports are used by the destination host for the service you can map the port(s) by entering another port or set of ports. Number of ports must match the number of incoming destination ports. Empty means that the incoming destination port will be used. Note: New destination port can only be set for single ports. Multi-port ranges can not be remapped to a new port range. You must use multiple single-port mappings to achieve this.


Click this icon to edit a port forwarding rule.

Click this icon to remove a port forwarding rule. You will be asked to acknowledge the removal before it is actually executed.

Selected rules may be modified by selecting the rules to modify and select the modification action in the drop-down list and then click the Apply button.



Version 4.22.0-0

32.2.5

New Port Forwarding Rule

Menu path: Configuration ⇒ Firewall ⇒ Port Forwarding ⇒ New Forwarding Rule

Active

Protocol

Incoming

Interface

Incoming

Destination

Port(s)

Source

Destination

Address

Rule is active if checked.

Mandatory. Traffic may be filtered on transport layer protocol. Available are TCP and UDP. Choose any to allow both TCP and UDP packets.

Mandatory.

The interface from which inbound traffic should be allowed.

Mandatory. The range of transport layer ports to match.

E.g. 80 for standard web-server access. If JavaScript is enabled, the range start may be selected in the drop down.

Optional. The source IP address(es) of packets allowed to be forwarded. Either a single address, or a subnet.

If single is selected, enter a single address. If subnet is selected a netmask (e.g. 255.255.255.0) must also be entered to define the subnet. If you have a JavaScript enabled browser the netmask field will not be displayed unless you check the subnet radio button.

Mandatory. The destination IP address to which the packets will be forwarded.




Version 4.22.0-0

New

Destination

Port

Log


Optional. If another port or set of ports are used by the destination host for the service you can map the port(s) by entering another port or set of ports. Number of ports must match the number of incoming destination ports.

Empty means that the incoming destination port will be used. Note: New destination port can only be set for single ports. Multi-port ranges can not be remapped to a new port range. You must use multiple single-port mappings to achieve this. If JavaScript is enabled, the range start may be selected in the drop down.


32.2.6

Edit Port Forwarding Rule

Menu path: Configuration ⇒ Firewall ⇒ Port Forwarding ⇒

In the Edit Port Forwarding Rule configuration page you can change an existing port forwarding rule.

See

section 32.2.5




Version 4.22.0-0

32.2.7

Packet Filter Rules

Menu path: Configuration ⇒ Firewall ⇒ Packet Filter

Packet filter rules are set up to allow traffic to pass through the firewall. Traffic is by default denied, except for a set of default allow rules created.

If the firewall is disabled or no rules have been created you will see no list, but be presented to an information message.

Default

Forward

Policy

Filter Rules

Enabled

Edit

The policy defines how to handle data for which no matching rule can be found. The forward chain controls traffic passing through the switch, not traffic destined to the switch itself. Possible values are:

Allow Packets will be allowed through.

Drop Packets will be dropped and no other actions are taken.

Yes means rules are active. No means rules are deactivated and all traffic is allowed through. Individual deactivation of rules override when this setting is yes (active).

Click this icon to edit the global settings.




Version 4.22.0-0

New Rule

Select

Order

Active

Policy

In Interface

Out Interface

Source

Address(es)

Source

Port

Destination

Address(es)

Destination

Port


Click this button to create a new packet filter rule. You will be presented to a form where you can configure the new rule.


The order in which the rules will be applied. When using a

JavaScript enabled browser, it is possible to select one or more rules and perform an action on multiple rules, see below. If not using a JavaScript enabled browser, there will be a set of arrows available to move rules up or down to change the order of application.


The type of rule, Allow or Deny.

The rule will be applied to traffic entering on this interface.

The rule will be applied to traffic exiting on this interface.

If neither Out Interface nor Destination Address (see below) are specified, the rule will apply to the INPUT chain, i.e., traffic destined to the switch itself (ICMP pings, SSH management, etc.).

The rule will be applied to traffic originating from a source with this specific IP-address or an IP-address in the specified subnet.

The rule will be applied to traffic originating from this set of (UDP/TCP) ports.

The rule will be applied to traffic destined to this specific

IP-address or to an IP-address in the specified subnet. If neither Out Interface (see above) nor Destination Address are specified, the rule will apply to the INPUT chain, i.e., traffic destined to the switch itself (ICMP pings, SSH management, etc.).

The rule will be applied to traffic destined to this set of

(UDP/TCP) ports.




Version 4.22.0-0

Protocol

Log


The rule will be applied to traffic using this protocol. Select the protocol name or enter the protocol number. If

ANY the rule will be applied for all protocol types.


Edit Click this icon to edit a packet filter rule.

Delete Click this icon to remove a packet rule. You will be asked to acknowledge the removal before it is actually executed.

Selected Rules Selected rules may be modified by selecting the rules to modify and select the modification action in the dropdown list and then click the Apply button.



Version 4.22.0-0

32.2.8

Edit Common Packet Filter Settings

Menu path: Configuration ⇒ Firewall ⇒ Packet Filter ⇒ (Common Settings)

Here you may change the common settings for the packet filter rules.

Default

Forward

Policy

Filter Rules

Enabled

The policy defines how to handle data for which no matching rule can be found. The forward chain controls traffic passing through the switch, not traffic destined to the switch itself. Possible values are:

Allow Packets will be allowed through.

Drop Packets will be dropped and no other actions are taken.

Select the policy by clicking the radio button.

Check the box to activate the rules, or uncheck to deactivate the rules. Deactivation means all traffic is allowed through (policy is changed to allow).



Version 4.22.0-0

32.2.9

New Packet Filter Rule

Menu path: Configuration ⇒ Firewall ⇒ Packet Filter ⇒ New Rule


Policy

Position (order) The position in the list defining in what order rules will be applied. Defaults to last position. Change the value to insert this rule in another position.

In Interface

Choose Allow/Deny to select if this rule should allow or deny traffic.





Version 4.22.0-0

Out Interface

Protocol



If neither Out Interface nor Destination Address (see below) are specified, the rule will apply to the INPUT chain, i.e., traffic destined to the switch itself (ICMP pings, SSH management, etc.).

The rule will be applied to traffic using this protocol. Select IP protocol in drop-down or enter the protocol number to specify for which protocol to apply this rule (see also

Destination Port option below). Select any to allow traffic from any IP Protocol (ICMP, TCP, UDP, . . . ) through.

Source

Address(es)

The rule will be applied to traffic originating from a source with this specific IP-address or an IP-address in the specified subnet. Select Single and enter the single source address into the address field. Select Subnet and enter an address into the address field and a subnet mask into the

Netmask field.

Source Port

Destination

Address(es)

The rule will be applied to traffic originating from this set of (UDP/TCP) ports. If JavaScript is enabled, the range start may be selected in the drop down. Only valid if Pro-

tocol TCP or UDP has been selected (see above).


IP-address or to an IP-address in the specified subnet. Select Single and enter the single source address into the address field. Select Subnet and enter an address into the address field and a subnet mask into the Netmask field.

If neither Out Interface (see above) nor Destination Ad-

dress are specified, the rule will apply to the INPUT chain, i.e., traffic destined to the switch itself (ICMP pings, SSH management, etc.).

Destination Port The rule will be applied to traffic destined to this set of

(UDP/TCP) ports. If JavaScript is enabled, the range start may be selected in the drop down. Only valid if Protocol

TCP or UDP has been selected (see above).



Log


Version 4.22.0-0


Controls if a match on this rule should be logged in the kernel log file. Nothing will be logged unless logging is also enabled under the common firewall settings. Note:

Logging differs in behavior between policy Accept and

Deny. See

section 32.1.6

for more details.



Version 4.22.0-0

32.2.10

Edit Packet Filter Rule

Menu path: Configuration ⇒ Firewall ⇒ Filter ⇒

In the Edit Packet Filter Rule configuration page you can change an existing packet filter rule.

See

section 32.2.9




Version 4.22.0-0

32.2.11

Packet Modify Rules

Menu path: Configuration ⇒ Firewall ⇒ Modify

Modify rules are set up to change the priority of packets passing through the firewall.

Rules are evaluated in the listed order from the top and downwards.

Rules are only used if the configured parameters match.

A matching rule will result in the DSCP field in the packets being changed to the configured value, and the next rule is then evaluated. The final value will thus be from the last matching rule.

Optionally the adjust priority adjusts the (internal) priority handling of the packet inline with to the new DSCP value. In addition, the VLAN tag priority will be set accordingly if the packet egresses the switch tagged.

If the firewall is disabled or no rules have been created you will see no list, but be presented to an information message.

New Click this button to create a new modify rule. You will be presented to a form where you can configure the new rule.




Version 4.22.0-0

Order

Active

In Interface

Out Interface

Source

Address(es)

Source

Port

Destination

Address(es)

Destination

Port

Protocol

DSCP

Adjust


The order in which the rules will be applied. When using a

JavaScript enabled browser, it is possible to select one or more rules and perform an action on multiple rules, see below. If not using a JavaScript enabled browser, there will be a set of arrows available to move rules up or down to change the order of application.




The rule will be applied to traffic originating from a source with this specific IP-address or an IP-address in the specified subnet.

The rule will be applied to traffic originating from this set of (UDP/TCP) ports.


IP-address or to an IP-address in the specified subnet.

The rule will be applied to traffic destined to this set of

(UDP/TCP) ports.

The rule will be applied to traffic using this protocol. Select the protocol name or enter the protocol number. If

ANY the rule will be applied for all protocol types.

The DSCP value to be set for packets matching this rule.

Indicates if the modified DSCP value should be used for switch internal prioritising and applied to VLAN-priority on tagged packets. A green check-mark means yes and a dash means no.

Edit Click this icon to edit a modify rule.

Delete Click this icon to remove a modify rule. You will be asked to acknowledge the removal before it is actually executed.

Selected Rules Selected rules may be modified by selecting the rules to modify and select the modification action in the dropdown list and then click the Apply button.



Version 4.22.0-0

32.2.12

New Modify Rule

Menu path: Configuration ⇒ Firewall ⇒ Modify ⇒ New


Position (order) The position in the list defining in what order rules will be applied. Defaults to last position. Change the value to insert this rule in another position.

In Interface

Out Interface






Version 4.22.0-0

Protocol

Source

Address(es)

Source Port


The rule will be applied to traffic using this protocol. Select IP protocol in drop-down or enter the protocol number to specify for which protocol to match with this rule (see also Destination Port option below). Select any to match any IP Protocol (ICMP, TCP, UDP, . . . ).

The rule will be applied to traffic originating from a source with this specific IP-address or an IP-address in the specified subnet. Select Single and enter the single source address into the address field. Select Subnet and enter an address into the address field and a subnet mask into the

Netmask field.

The rule will be applied to traffic originating from this set of (UDP/TCP) ports. If JavaScript is enabled, the range start may be selected in the drop down. Only valid if Pro-

tocol TCP or UDP has been selected (see above).

Destination

Address(es)


IP-address or to an IP-address in the specified subnet. Select Single and enter the single source address into the address field. Select Subnet and enter an address into the address field and a subnet mask into the Netmask field.

Destination Port The rule will be applied to traffic destined to this set of

(UDP/TCP) ports. If JavaScript is enabled, the range start may be selected in the drop down. Only valid if Protocol

TCP or UDP has been selected (see above).

DSCP - Set Value The DSCP value to be set for packets matching this rule.

Valid values 0-63.

DSCP Adjust

Priority

Indicates if the modified DSCP value should be used for switch internal prioritising and applied to VLAN-priority on tagged packets. Check to enable.



Version 4.22.0-0

32.2.13

Edit Modify Rule

Menu path: Configuration ⇒ Firewall ⇒ Modify ⇒

In the Edit Modification Rule configuration page you can change an existing modify rule.

It is also possible to move the rule to a certain position in the list by changing the

Position (order) field. The rule will be inserted on requested position and the rule currently on the position will be shifted down.

See

section 32.2.12




Version 4.22.0-0

32.2.14

Configure ALG Helpers

Menu path: Configuration ⇒ Firewall ⇒ ALG Helper

In the ALG Helper configuration page you can activate Application Level Gateway

(ALG) Helpers in the firewall.

Check the box for the ALG helper to activate.

See

section 32.1.1

for description of ALG helpers.



Version 4.22.0-0

32.3

Firewall Management via the CLI

Command

Configure Firewall Settings

[no] firewall

[no] enable

[no] filter [pos <NUM>] <allow|deny>

[in <IFNAME>] [out <IFNAME>]

[src <ADDR[/LEN]>] [sport <RANGE>]

[dst <ADDR[/LEN]>] [dport <RANGE>]

[proto <NAME|NUM>] [passive] [log]

[no] modify [pos <NUM>]

[match [in <IFNAME>] [out <IFNAME>]

[src <ADDR[/LEN]>] [sport <RANGE>]

[dst <ADDR[/LEN]>] [dport <RANGE>]

[proto <NAME|NUM>] ] set dscp <NUM> [adjust-prio] [passive]

[no] nat [<NUM>] type <NAPT|1-TO-1>

[in <IFNAME>] [out <IFNAME>]

[src <ADDR[/LEN]>] [dst <ADDR[/LEN]>]

[to-dst <ADDR[/LEN]>] [addfilter]

[noarp] [passive] [log]

[no] port-forward in <IFNAME>:<PORTRANGE>

[src <ADDR/LEN>] dst <ADDR>[:PORTRANGE]

[proto <tcp|udp>] [passive] [log]

[no] alg <ftp|tftp|sip|irc|h323|pptp>

[no] spi policy [forward|input] <deny|allow> move [filter|modify|nat|port-forward]

<FROM-POS> <TO-POS>

[no] passive [filter|modify|nat|port-forward]

<POS>

[no] log limit ( none |

<entries>/(second|minute|hour|day) )

[no] log [filter|nat|port-forward] <POS>

Default Section

Disabled

Section 32.3.1

Enabled

Section 32.3.2

Section 32.3.3

Section 32.3.4

Section 32.3.5

Section 32.3.6

Disabled

Section 32.3.7

Disabled

Section 32.3.8

Deny

Section 32.3.9

Section 32.3.10

Section 32.3.11

Section 32.3.12

Section 32.3.12



Command

View Firewall Status show firewall


Version 4.22.0-0


Default Section

Section 32.3.13

32.3.1

Managing the Firewall

Syntax [no] firewall

Context

IP Configuration

context

Usage Enter the

Firewall Configuration

context. This will enable the firewall (unless it is already enabled).

Use ”no firewall” to disable the firewall, and to delete all existing NAT,

Port Forwarding, Packet filter (allow/deny), and ALG helper rules.

Use ”show firewall” to show the firewall configuration. If the firewall is enabled, the list of currently configured Packet filtering, Modify, NAT and

Port forwarding rules are presented. Also available as ”show” command within the


context.

Default values Disabled.

32.3.2

Enable Packet Filter Rules

Syntax [no] enable

Context


context

Usage Enable/disable packet filtering. This setting affects the activation of packet filtering (allow/deny) rules, and the activation of the default policies. Modify,

NAT, Port Forwarding, and ALG helper rules are unaffected (they are always enabled).

Use ”enable” to (re)activate all configured packet filtering (allow/deny) rules and the configured default policies for the input and forward filter.



Version 4.22.0-0

Use ”no enable” to deactivate all the configured packet filtering (allow/deny) rules. Default forward policy will be accept and default input policy will be

drop. ICMP will be allowed on the ingress filter.

Use ”show enable” to show whether the configured packet filters are enabled or disabled.

It is also possible to activate/deactivate individual allow/deny rules (as well as NAT and port forwarding rules), see

section 32.3.11

.

Default values Enabled

32.3.3

Configure Packet Filter Rule

Syntax [no] filter [pos <NUM>] <allow|deny> [in <IFNAME>]

[out <IFNAME>] [src <ADDR[/LEN]>] [sport <PORTRANGE>]

[dst <ADDR[/LEN]>] [dport <PORTRANGE>] [proto <NAME|NUM>]

[passive] [log]

Context


context

Usage Add or delete a packet filter allow or deny rule.

Rule maintenance parameters (insert position, activate/deactivate or

delete rule):

– Allow and deny rules are inserted (and thus evaluated) in a certain order in the input or forward filter. The ”pos <NUM>” parameter controls at what position in the rule order this packet filter rule should be inserted, or when it comes to removing a rule, which packet filter rule to remove. The order is kept compact (see ”Delete rule” below). Use the ”show filter” command to list the current packet filter rule list and their position numbers. Examples:

* Insert rule: Use, e.g., ”filter pos 4 allow in vlan2” will insert an allow rule at a specific position (here position 4) in the list of packet filter rules. The rule previously at position 4 will now have position 5, and so on.

If no position argument is given, the packet filter rule will be inserted last in the list. The position of a command can be modified using the ”move” command (see

section 32.3.10

).


812


Version 4.22.0-0

* Delete rule: Use, e.g., ”no filter pos 5” to delete the packet filter rule (allow or deny) at a specific position (here position 5) in the list of packet filter rules. The rule previously at position 6 will now have position 5, and so on, keeping the list compact.

A rule can also be deleted by using the no-form of the filter specification, e.g., the rule ”filter deny in vlan1 out vlan2” can be deleted by the command ”no filter deny in vlan1 out

vlan2”.

– The ”passive” parameter specify that this rule is created as inactive. It will be shown in config but not used. To enable use

”passive” command, see

section 32.3.11

.

– The ”log” parameter enables logging for traffic that matches this filter rule. Nothing will however be logged if logging is enabled here but disabled under the common settings. See

section 32.3.12

.

Note: Logging differs in behavior between policy Accept and Deny.

See

section 32.1.6

for more details.

Filter specification parameters:

– The first parameter is mandatory and select the action type ”allow” or ”deny”.

– The ”in <IFNAME>” and ”src <ADDR[/LEN]>” are used to match the inbound interface and source IP address of a packet. If the ”LEN” parameter is omitted the ”src <ADDR/LEN>]” argument will match a single source IP address. If included it will match a whole IP subnet.

– Include the ”out <IFNAME>” and/or ”dst <ADDR[/LEN]>” arguments to define a FORWARDING rule (i.e., packets being routed through the switch). If both the ”out <IFNAME>” and the ”dst <ADDR[/LEN]>” arguments are omitted, the rule will apply to the INPUT chain, i.e., traffic destined to the switch itself (ICMP pings, SSH management, etc.).

The ”out <IFNAME>” argument is used to match the outbound interface of a packet.

Use the ”dst <ADDR[/LEN]>” to match a single destination IP address or whole subnet. If both the ”out <IFNAME>” and the ”dst

<ADDR[/LEN]>” arguments are omitted, the rule will apply to the

© 2017 Westermo Teleindustri AB


Version 4.22.0-0

INPUT chain, i.e., traffic destined to the switch itself (ICMP pings,

SSH management, etc.).

– Use the ”proto <NAME|NUM>” to match the IP protocol name, e.g.,

tcp, udp or icmp. It is also possible to specify the protocol’s assigned number, see http://www.iana.org/assignments/protocol-numbers/ .

– Use the ”dport <PORTRANGE>” argument to specify a destination

UDP or TCP port number or port range (ex: 1000-1010). This argument is only valid if ”proto udp” or ”proto tcp” is included.

– Use the ”sport <PORTRANGE>” argument to specify a source UDP or

TCP port number or port range (ex: 87-89). This argument is only valid if ”proto udp” or ”proto tcp” is included.

Default values Not applicable.

32.3.4

Configure Packet Modify Rule

Syntax [no] modify [pos <NUM>] [passive]

[match [in <IFNAME>] [out <IFNAME>]

[src <ADDR[/LEN]>] [sport <PORTRANGE>]

[dst <ADDR[/LEN]>] [dport <PORTRANGE>]

[proto <NAME|NUM>]] set dscp <VALUE> [adjust-prio]

Context


context

Usage Add or delete a modify rule to change the DSCP bits in the IP header for routed traffic.

Rule maintenance parameters (insert position, activate/deactivate or

delete rule):

– Modifier rules are inserted and evaluated in order. The ”pos <NUM>” parameter controls at what position in the rule order this modify rule should be inserted, or when it comes to removing a rule, which rule to remove. The order is kept compact (see ”Delete rule” below).

Use the ”show modify” command to list the current modifier rule list and their position numbers. Examples:

* Insert rule: Use, e.g., ”modify pos 4 match in vlan2 set dscp

30” will insert a modifier rule at position 4 in the list of modifier


814


Version 4.22.0-0 rules. The rule previously at position 4 will now have position 5, and so on.

If no position argument is given, the modifier rule will be inserted last in the list. The position of a command can be modified using the ”move” command (see

section 32.3.10

).

* Delete rule: Use, e.g., ”no modify pos 5” to delete the modifier rule at position 5 from the list of modifier rules. The rule previously at position 6 will now have position 5, and so on, keeping the list compact.

A rule can also be deleted by using the no-form, e.g., the rule

”modify match in vlan1 out vlan2 set dscp 0” can be deleted by the command ”no modify match in vlan1 out vlan2 set

dscp 0”.

– The ”passive” parameter specify that this rule is created as inactive. It will be shown in config but not used. To enable use

”passive” command, see

section 32.3.11

.

Matching parameters:

Matching parameters are optional. If you do not specify matching, all routed packets will have the DSCP field set. Matching is enabled with the ”match” keyword followed by one or more of the filters described below:

– The ”in <IFNAME>” and ”out <IFNAME>” are used to match on the inbound interface or the outbound interface.

– ”src <ADDR[/LEN]>” and ”dst <ADDR[/LEN]>” match on IP source or IP destination. The ”LEN” parameter is used to define an IP subnet, and if it is omitted it will only match a specific single IP address.

– Use the ”proto <NAME|NUM>” to match on traffic with a specific IP protocol. You can use the name, e.g., tcp, udp or icmp, or the protocol’s assigned number (see http://www.iana.org/assignments/ protocol-numbers/ ).

– Use the ”dport <PORTRANGE>” argument to specify a destination

UDP or TCP port number or port range (ex: 1000-1010). This argument is only valid if ”proto udp” or ”proto tcp” is included.

– Use the ”sport <PORTRANGE>” argument to specify a source UDP or

TCP port number or port range (ex: 87-89). This argument is only



Version 4.22.0-0 valid if ”proto udp” or ”proto tcp” is included.

Setting parameters:

– Use ”set dscp <VALUE>” to define the DSCP value to be set on all packets matching the parameters described above. The value must be provided as a decimal number in the range 0-63.

– Add parameter ”<adjust-prio>” if the internal priority of the packet also should be updated in addition to the change of the DSCP field.

The internal priority is used to determine what network queue to use in WeOS networking and hardware. Avoid using this option if not necessary, as it introduces additional work for the CPU in the unit, reducing total performance of the system.


32.3.5

Configure NAT Rule

Syntax [no] nat [<POS>] [type <napt|1-to-1>] [in <IFNAME>]

[out <IFNAME>] [src <ADDR[/LEN]>] [dst <ADDR[/LEN]>]

[to-dst <ADDR[/LEN]>] [addfilter] [noarp] [passive] [log]

Context


context

Usage Add or delete a NAT rule.

Add a NAPT NAT rule

These keywords are available for creating NAPT rules:

– ”type napt”. Select NAPT.

– ”out <IFNAME>”. Mandatory. The outbound interface used for NAPT.

Outgoing packets handled by this rule will appear to originate from the IP number configured (the primary address) or acquired (DHCP) for this interface.

– ”in <IFNAME>”. Optional. Specify that packets must arrive from this interface for this rule to apply.

– ”src <ADDR[/LEN]>”. Optional. Specify that packets must originate from a specific IP subnet for this rule to apply.

– ”addfilter”. If set, an automatic (invisible) packet filter rule will be created in the forward filtering chain allowing packets matching this


816


Version 4.22.0-0

NAT rule. Do not set this option if you want to manage forwarding rules yourself.

– ”passive”. Specify that this rule is created as inactive. It will be shown in config but not used. To enable use ”passive” command, see

section 32.3.11

.

– ”log”. Enables logging for traffic that matches this NAT rule. Nothing will however be logged if logging is enabled here but disabled under the common settings. See

section 32.3.12

.

Add a 1-to-1 NAT rule

These keywords are available for creating 1-to-1 NAT rules:

– ”type 1-to-1”. Select 1-to-1 NAT.

– ”in <IFNAME>”. Mandatory. The inbound interface used for 1-to-1

NAT.

– ”dst <ADDR[/LEN]>”. Mandatory. Packets arriving on the inbound interface and has the IP destination within this subnet will be NATed.

– ”to-dst <ADDR[/LEN]>”. Mandatory. The new destination IP network for the NAT. Must be of exact same size as the ”dst” network.

– ”addfilter”. If set, automatic (invisible) packet filter rules will be created in the forward filtering chain allowing packets matching this

NAT rule. Rules are created for both the forward and reverse direction (see

section 32.1.4.2

). Do not set this option if you want to

manage forwarding rules yourself.

– ”noarp”. Specify to disable ARP proxying for this rule. (see

section 32.1.4.2

for details).

– ”passive”. Specify that this rule is created as inactive. It will be shown in config but not used. To enable use ”passive” command, see

section 32.3.11

.

– ”log”. Enables logging for traffic that matches this NAT rule. Nothing will however be logged if logging is enabled here but disabled under the common settings. See

section 32.3.12

.

Delete a NAT rule

Use the command ”no nat <POS>” to delete a specific NAT rule on the position POS as shown with the command ”show” or ”show nat”.

Delete all NAT rules with ”no nat”.



Version 4.22.0-0

Use ”show nat” to show configured NAT rules.

Default values Addresses without subnet lengths will be considered to be of length /32 i.e. as a single IP address.

32.3.6

Configure Port Forwarding Rule

Syntax [no] port-forward in <IFNAME>:<PORTRANGE> [src <IPADDRESS/LEN>] dst <IPADDRESS>[:PORTRANGE] [proto <tcp|udp>] [passive] [log]

Context


context

Usage Add/delete a Port Forwarding rule. This is commonly used when the switch is acting as NAT gateway, see

section 32.3.5

. E.g., ”port-forward

in vlan1:80 dst 10.0.0.2 proto tcp” to forward all web traffic coming in on interface vlan1 to the Web server at IP address 10.0.0.2 (port 80).

The argument ”<IFNAME>:<PORTRANGE>” specifies incoming interface, and what port or port range to match.

Use the ”[src <IPADDRESS[/LEN]>]” to match a single source IP address or whole subnet.

Use the ”dst <IPADDRESS>[:PORTRANGE]” to specify where the packets should be forwarded. If the ”PORTRANGE” parameter is omitted, the same port range as specified in the ”<IFNAME>:<PORTRANGE>” argument is used.

Use the ”[proto <tcp|udp>]” to specify if the rule applies to TCP or

UDP. If omitted, the rule applies to both.

The ”passive” parameter specify that this rule is created as inactive.

It will be shown in config but not used. To enable use ”passive” command, see

section 32.3.11

.

The ”log” parameter enables logging for traffic that matches this port forwarding rule. Nothing will however be logged if logging is enabled here but disabled under the common settings. See

section 32.3.12

.

Use ”show port-forward” to show configured port forwarding rules.

Default values Not appliable.



Version 4.22.0-0

32.3.7

Configure Application Level Gateway (ALG) Helpers

Syntax [no] alg <ftp|tftp|sip|irc|h323|pptp>

Context


context

Usage Enable/disable ALG helper for a protocol, e.g., use ”alg ftp” to make your firewall or NAT gateway handle FTP traffic appropriately.

Use ”no alg <PROTO>” to remove an enabled ALG helper for the given protocol, or use ”no alg” to remove all enabled ALG helpers.

Use ”show alg” to show list of protocols for which ALG helpers have been enabled.


32.3.8

Configure Stateful Packet Inspection

Syntax [no] spi

Context


context

Usage Stateful packet inspection will drop packet that are in an invalid state.

An example of a packet with an ”invalid” state is when a firewall sees a

TCP ”SYN+ACK”, without having seen the preceding TCP ”SYN” in the other direction.

For a true firewall it is generally a good idea to enable stateful packet inspection. However, due to potential problems with asymmetric routing, the default is to have this setting disabled.

Use ”show spi” to show if stateful inspection is enabled or disabled.


32.3.9

Configure Forwarding and Input Default Policies

Syntax policy [forward|input] <allow|deny>

Context


context



Version 4.22.0-0

Usage Configure the default policy for forward filtering and input filtering. By default, the command applies to the forwarding filter, e.g., ”policy allow” will set the default policy for forward filtering to ”allow”.

Use ”show policy” to show configured default policies for the forwarding

filter and the input filter.

Default values Deny (that is, both the forwarding filter and the input filter by default drop packets lacking a matching allow rule.)

32.3.10

Reorder/Move a Packet Filter, Modify, NAT or Port Forwarding Rule

Syntax move [<filter|modify|nat|port-forward>] <FROM_POS> <TO_POS>

Context


context

Usage Change the position (reorder) a rule in the ”filter”, ”modify”, ”nat” or

”port-forward” table, e.g., use ”move filter 6 3” to move the filter rule

(allow/deny) at position ”6” to position ”3”. The filter rule previously at position ”3” ends up at position ”4”, and so on. Similarly, ”move modify 3 6” will move the modify rule at position ”3” to position ”6”; the rule previously at position ”6” ends up at position ”5” and so on.

The tables are kept compact. Specifying a ”TO_POS” beyond the highest number in that table is equal to moving it to the last position in the table.

If no table is specified, the move operation applies to the ”filter” table, i.e., ”move 6 3” is equivalent to ”move filter 6 3”.

Examples

Example

example:/config/ip/firewall/#> show filter

001 filter allow in vlan1 out vlan2


003 filter deny in vlan1 out vlan2 proto icmp example:/config/ip/firewall/#> move filter 3 1 example:/config/ip/firewall/#> show filter

001 filter deny in vlan1 out vlan2 proto icmp





Version 4.22.0-0

32.3.11

Activate/Deactivate a Packet Filter, Modify, NAT, or Port

Forwarding Rule

Syntax [no] passive [<filter|modify|nat|port-forward>] <POS>

Context


context

Usage Activate or deactivate a packet filter (allow/deny) rule, a modify rule, a NAT rule, or a port forwarding rule. E.g., use ”passive filter 4” to deactivate the packet filter rule at position ”4”.

Use commands ”show filter”, ”show modify”, ”show nat” or

”show port-forward” to display the current list of rules for that specific type.

Use the ”no”-form to activate a previously deactivated rule, e.g., ”no passive

modify 4” activates modify rule ”4”.

Examples

Example


001 filter allow in vlan1 proto icmp



004 filter allow in vlan1 out vlan2 example:/config/ip/firewall/#> passive filter 3 example:/config/ip/firewall/#> show filter



003 filter deny in vlan1 out vlan2 proto icmp passive

004 filter allow in vlan1 out vlan2 example:/config/ip/firewall/#> no passive filter 3 example:/config/ip/firewall/#> show filter





32.3.12

Configuration of firewall logging

This command has two uses, [1] to configure logging (and limit), and [2] to toggle the log flag on firewall rules.

Syntax 1 [no] log limit ( none | <entries>/(second|minute|hour|day) )

Syntax 2 [no] log [filter|nat|port-forward] <POS>



Version 4.22.0-0

Context


context

Usage 1 Enable/disable firewall logging and set rate limitation of firewall log entries. This is a master control enabling the logging feature.

A rate limit must be provided or “none” to disable limit, i.e. log everything.

The limit is set as a number followed by a slash character “/” and a time unit. The time unit is one of “second”, “minute”, “hour” or “day”. See

section 32.1.6

for information about how limitation operates.

All firewall logging is disabled by using the command: ”no log”

Use ”show log” to show if firewall logging is enabled or disabled, and the rate limitation setting.

Note

Besides enabling logging with this command, you also need to enable logging on individual firewall rules for anything to be logged.

Warning

Enabling logging and disabling the limitation may lead to lots of data being logged. This can in a short time fill up the log files.

Usage 2 Enable/disable logging for an existing individual packet filter, NAT or port forwarding rule. E.g., use ”log filter 4” to enable logging for the packet filter rule at position ”4”.

Use commands ”show filter”, ”show nat” or ”show port-forward” to display the current list of rules for that specific type. Rules containing the keyword “log” has logging enabled.

Use the ”no”-form to disable logging for an existing rule, e.g., ”no log nat

2” disables logging for the NAT rule at position ”2”.

Logging can not be enabled for packet modify rules.

Default values Logging is enabled by default when the firewall is enabled, however no automatically created firewall rule will have the log parameter enabled by default. The default logging limit is set at 5 entries per second.

Examples with usage 1



Version 4.22.0-0

Example

example:/config/ip/firewall/#> log limit 100/day example:/config/ip/firewall/#> show log

Logging is Enabled, limited to 100 entries/day example:/config/ip/firewall/#> log limit none example:/config/ip/firewall/#> show log

Logging is Enabled, no rate limitation example:/config/ip/firewall/#> no log example:/config/ip/firewall/#> show log

Logging is Disabled

Examples with usage 2

Example





004 filter allow in vlan1 out vlan2 example:/config/ip/firewall/#> log filter 2 example:/config/ip/firewall/#> show filter


002 filter allow in vlan2 proto icmp log


004 filter allow in vlan1 out vlan2 example:/config/ip/firewall/#> no log filter 2 example:/config/ip/firewall/#> show filter





32.3.13

View Firewall Status

Syntax show firewall

Context

Admin Exec

context

Usage Show current NAT rules, Port Forwarding rules, policies and entries in the

Input and Forwarding Filters and Modifier rules. In addition, management interface configuration (see

section 22.2.7

) will appear as entries in the Input

Filter.




Version 4.22.0-0

Part IV

Virtual Private Networks and

Tunnels


No results