Enterasys Networks X-PeditionTM manual Firewall Limitations

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 P-intExtFtpis the CLI policy name and _0-2is the gating rule extension.

•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 “Memory Management” on page 2-37for more details.

•Session Timeouts - Idle timeout defaults for the three firewall session types are enforced as follows:

–TCP idle timeout sessions: 3600 seconds

–UDP and ICMP idle timeout sessions: 60 seconds

•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