Firewall Limitations - Enterasys Security Router X-PeditionTM User Manual

Firewall Limitations

Firewall Limitations
Consider the following caveats regarding firewall operations:
• Gating Rules - Internal XSR gating rules, which order traffic filtering, are stored in a temporary
file in Flash. Because one gating rule exists for each network source/destination expansion, a
potentially enormous number of rules can be generated by just a single firewall policy. For
example, when a large network that has an ANY_INTERNAL group with 200 network
addresses is used as the source address, and another group of 10 network addresses is used as
the destination address, 2000 gating rules are defined for the policy. Be aware that each
bidirectional policy produces two gating rules per address pair.
Because gating rules must be unique, those policies which create multiple gating rules when
source or destination addresses are network group objects will have a gating rule extension
appended to the actual policy name that was entered in the CLI command. Firewall log
messages specifying the policy name will display the following, for example:
Log: TCP, Policy P_intExtFtp_0-2, 10.10.10.100(1033)-> 20.20.20.100(21)
where
• Memory Limits - The number of permitted firewall objects are constrained by the size of
installed RAM in the XSR as follows. Be aware that these limits can be mitigated through the
use of memory management. Refer to
• Session Timeouts - Idle timeout defaults for the three firewall session types are enforced as
follows:
–
–
• Pre-defined Services - Some pre-defined firewall services may not work with applications which
use dynamic source ports greater than 1024. As a work around, specify a user- defined service
to cover a wider source port range.
• SNMP - SNMP is not supported for configuration, data and traps.
• ACL/Firewall - Access Control Lists (ACLs) are supported for security on a per interface basis.
Interface ACLs allow or drop packets traversing the port in a specified direction (in or out).
Heading outbound, packets face firewall inspection before ACLs. Going inbound, packets first
face ACLs, followed by the firewall. So, if the firewall is enabled on an interface, we
recommend ACLs not be used on that port so that all checks can be performed in one place.
• Firewall/NAT - On outgoing packets, stateful inspection is performed before NAT. This is due to
the fact that NAT modifies the source address of all packets to the XSR's address and policy
rules are defined with respect to internal and external addresses. On incoming packets, NAT is
performed before firewall inspection. Firewall rules are written using the actual addresses on
the internal (even if they are private IP addresses) and exterior networks, independent of
whether NAT is enabled on the interface.
• Firewall/VPN - VPN tunnels are implemented as virtual interfaces that sit on physical
interfaces. Stateful inspection is applied before encryption and encapsulation for outgoing
packets and after de-encapsulation and decryption for incoming packets.
• Firewall and Un-numbered Interface - The firewall does not interoperate with interface IP
addresses - it is concerned with IP addresses in packets that traverse an interface. So, if the
firewall is enabled on an un-numbered interface, it performs similarly as on a numbered one.
• Firewall/VRRP - The firewall does not interoperate with the Virtual Router Redundancy
Protocol (VRRP). That is, if a switch-over occurs, the firewall sessions and authentication
16-22 Configuring Security on the XSR
P-intExtFtp
is the CLI policy name and
TCP idle timeout sessions: 3600 seconds
UDP and ICMP idle timeout sessions: 60 seconds
_0-2
is the gating rule extension.
"Memory Management" on page 2-37 for more details.