--- title: "Basic Firewall" canonical: "https://docs.aryaka.com/space/KNOW/1275232263/Basic%20Firewall" format: markdown --- SD-WAN site and remote user subscriptions include Aryaka Basic Firewall by default. Basic Firewall inspects network traffic to identify applications, source and destination countries, and to allow the following security engines to route or drop traffic according to user-defined security policies: DOS Protection WAN Routing Internet Routing Interzone Firewall If your organization requires additional security options, Aryaka also offers the following services: NGFW-SWG IPS Anti-Malware CASB DLP This document provides an overview of the Aryaka Basic Firewall security offering and describes how to get started with configuring your service and monitoring your service in MyAryaka.  Prerequisites A site or remote user license for SD-WAN. Use Case Flexible, policy-based control over network traffic. Aryaka Basic Firewall identifies network traffic and allows you to define security policies to route permitted traffic and deny unwanted traffic for your sites and remote users. Features Basic Firewall includes the following functionality: Dynamic application discovery using AppAssure Geolocation discovery Denial of service (DOS) protection WAN routing Interzone firewall Internet routing Each of these features is described in a section that follows. See the Security topic for a high-level overview of the Aryaka security framework. Dynamic application discovery Traffic receives automatic application discovery at ANAPs and POPs. Aryaka uses Qosmos to identify the applications in your network. When a new traffic flow is intercepted by the Aryaka application classification engine, its destination IP, destination port, and hostname information (if available) are analyzed to determine if it belongs to one of the 3500+ known applications that Qosmos is able to identify. A UDP flow’s interception is transparent to the user. The flow’s exchange of packets between the client and server are briefly redirected to the application classification engine until enough packets have been buffered to successfully identify the application. The buffered packets are then forwarded to the server and subsequent packets bypass the application classification engine. A TCP flow’s interception is opaque in nature—the client notices the intercept because they must interact in the acknowledge phase, as depicted in the following graphic: The application classification engine terminates the TCP connection and responds to the client with the SYN-ACK. All subsequent interactions occur with the TCP proxy residing within the application classification engine. The intercepted data is analyzed to determine the application’s identity using its destination IP, destination port, protocol, and host name (if available). The application’s identity is then communicated to all subsequent engines so that this information is available when processing the flow. This includes engines that control security policies, routing policies, and optimization policies. The flow’s subsequent activity is acknowledged by the proxy in the application classification engine. You can use discovered applications as a match criteria in WAN Routing , Interzone Firewall , and Internet Routing policies to permit or deny network traffic. You can also use this match criteria in other optional security engines that can be added to your subscription by purchasing Unified SASE . Geolocation discovery Aryaka uses MaxMind —a leading provider of geographic IP intelligence and online fraud detection tools—for geolocation discovery. MaxMind provides a database of IP blocks assigned to countries and continents that is typically updated every two days and covers 99.9999% of IP addresses in use worldwide. Aryaka checks this database for updates every 24 hours. For more information about MaxMind service updates, see GeoIP2 Databases and Services (at maxmind.com). MaxMind maps IP blocks to countries, which enables Aryaka to identify the country a traffic flow’s public source or destination belongs to. You can use the country as a match criteria in an Interzone Firewall policy to control interzone traffic at a site and in other optional security engines that can be added to your subscription by purchasing Unified SASE . DOS protection Traffic leaving or arriving at a site is provided basic DOS protection. DOS protection uses rate-limiting traffic protocols to enforce user-configured packet rates and connection rates for each zone. In the outbound direction, DOS protection is applied to traffic when it first arrives from the client on a LAN-side zone (that is, VPN or DMZ). This rate-limited traffic then encounters other engines that are enabled as a part of Basic Firewall, as depicted in the following graphic: In the inbound direction, DOS protection is applied to traffic arriving on the ANAP’s WAN-side public zone. This engine is encountered before the internet-facing NAT is applied, as depicted in the following graphic: DOS protection allows user-defined configuration for connection rates and packet rates (for zones and for protocols). Additionally, the DOS Protection security engine includes a policy table that can be configured to bypass DOS protection for specific traffic. WAN routing The WAN Routing security engine inspects network traffic to determine whether to permit or deny it. For permitted traffic, the WAN Routing security engine determines if the traffic arriving at a site is destined to a remote destination and, if so, which network or tunnel should be used to route traffic. WAN Routing policy example: Create a policy that sends a scheduled recurring database backup over VPN Path Internet and sends more transactional traffic over VPN Path Aryaka. The following graphic depicts the WAN Routing security engine in the Aryaka processing sequence, where traffic is received from the DOS Protection security engines and is forwarded to the next security engine in the sequence after inspection: The WAN Routing security engine includes a policy table that reads policies from top to bottom. The first policy that matches the client’s traffic is applied and all subsequent policies are ignored. The WAN Routing security engine uses the following match criteria to identify traffic: Source zone Named match rules that use any or all of the following network identifiers: Source IP Destination IP Source port Destination port Protocol TOS Managed application identified using any or all of the following: Domain name or server name indicator (SNI) Discovered applications Layer 3 and Layer 4 traffic criteria For more information, see the Security rule match criteria topic. Based on your configured policies, the WAN Routing security engine performs one of the following actions on matched traffic: Routes traffic to a connected remote site Routes traffic to a public server Drops traffic These actions are described in the sections that follow. Route traffic to a connected remote site The following policy actions route traffic to a connected remote site: Route using specified order—Traffic is routed to the available networks in a user-defined sequence. Route using parallel cost—Traffic is routed to the available networks based on the lowest associated routing cost. Route using longest prefix match—Traffic is routed to the available networks based on the greatest number of matching digits in the subnet mask. Route using IPSLA—Traffic is routed to the available networks based on the networks' health. If traffic matches a policy, the configured networks' routing tables are consulted to determine if the destination is specified in the tables. If the route is found, the traffic is considered permitted by this engine and is sent to the next engine for additional security inspection. If the route is not found, the next policy in the table is evaluated by default. However, you can configure policies to drop traffic or to use the Interzone Firewall policies if the selected policy action (operation) fails. The following graphic displays the the processing sequence for traffic when a route is found and when it is not: Route traffic to a public server The Forward policy action allows you to customize your route to a public server by creating a WAN Routing policy that forwards traffic to one of the following interfaces: A cloud tunnel A specific internet-facing interface If the selected tunnel or interface is up, the traffic is considered permitted by this engine and is sent to the next engine for additional security inspection. If the tunnel or interface is not found or is down, the next policy in the table is evaluated by default. However, you can configure policies to drop traffic or to use the Interzone Firewall policies if the selected policy action (operation) fails. The following graphic displays the the processing sequence for traffic when an interface is up and when it is down: Overriding default routes Typically, a publicly hosted server is accessed using default routes specified in the Internet Routing policy table. This can be overridden by configuring a WAN Routing policy or an Internet Routing policy. For example, if you want to override a route learned from a remote site with a local internet breakout, you can do so by using a policy where the action is to forward the traffic. In the following graphic, the routing and firewall tables are described for a site: To ensure that the 132.245.12.0/24 subnet goes out using the internet interface wired to the M1 interface of the ANAP, you can specify an internet route as follows: With this configuration, the Internet Routing policy would not be encountered because the previous WAN Routing policy specifies SaaS App Access Point use VPN Path Aryaka . For the Internet Routing policy to be evaluated, you need to create a policy that overrides the WAN Routing policy, as displayed in the following graphic: Drop traffic When you configure a WAN Routing policy to drop traffic, you can select one of the following operations to perform on matched traffic: Blackhole—Traffic is denied and the client does not receive a response. Unreachable—Traffic is denied and the client receives an ICMP Unreachable response. Prohibit—Traffic is denied and the client receives an ICMP Prohibited response. When traffic matches a policy with a drop action, it is dropped immediately and no subsequent policies or policy tables are consulted. Default policy The default WAN Routing policy is to look up the routing table and route to a remote site using the best network identified according to longest prefix match and routing cost. If no routes are found, the traffic is sent to the next engine in the sequence which is the Interzone Firewall security engine. The default policy can not be edited, but it can be overridden by a policy written and placed above it in the policy table. To modify the WAN Routing policy table, see the create site-level WAN Routing policies help topic. Interzone firewall The Interzone Firewall security engine inspects network traffic to determine if zone-crossing traffic is allowed for the VPN or DMZ zones present at a site. Interzone Firewall policy example: Create a policy to deny access from the Guest Zone to the Corporate zone, or to deny access for a custom zone to the internet. Traffic arriving at the Interzone Firewall policy table has already encountered the WAN Routing security engine. The traffic either did not match any of the WAN Routing policies or one of the policy actions specified that the Interzone Firewall table should be consulted. This typically happens because the traffic destination is not on a connected network like VPN Path Aryaka, VPN Path Internet, or a connected MPLS network. This implies that the traffic is destined to another zone on the local site or that the traffic is destined to a public server on the internet. The following graphic depicts the Interzone Firewall security engine in the processing sequence: The Interzone Firewall security engine identifies the subnets that are hosted at the local site but are in other zones to determine if the destination is at that same site. It then evaluates the Interzone Firewall policy table to see if this access is permitted. The Interzone Firewall security engine includes a policy table that reads policies from top to bottom. The first policy that matches the client’s traffic is applied and all subsequent policies are ignored. The Interzone Firewall security engine uses the following match criteria to identify traffic: Destination zone Named match rules that use any or all of the following network identifiers: Source IP Destination IP Source port Destination port Protocol TOS Managed application identified using any or all of the following: Domain name or server name indicator (SNI) Discovered applications Layer 3 and Layer 4 traffic criteria Geographical match criteria using either of the following: Countries Continents For more information, see the Security rule match criteria topic. Based on your configured policies, the Interzone Firewall security engine performs one of the following actions on matched traffic: Blackhole—Traffic is denied and the client does not receive a response. Unreachable—Traffic is denied and the client receives an ICMP Unreachable response. Prohibit—Traffic is denied and the client receives an ICMP Prohibited response. Permit—Traffic is permitted. If the traffic is not dropped after encountering all engines in the path, it is forwarded to the appropriate interface, if known. If the destination zone is local to the site, the traffic is forwarded to that zone if permitted by the Interzone Firewall security engine. If the destination zone is public or cloud, the traffic is sent to the Internet Routing policy engine to determine the interface to use. Default Policy The default Interzone Firewall policy is to deny interzone traffic between any VPN or DMZ zones. This policy can not be edited, but it can be overridden by creating a new policy and placing it above the default policy in the Interzone Firewall policy table. Block traffic to and from a country Configure an Interzone Firewall policy with the following match criteria to block traffic to and from a list of countries: Source zone is any . Destination zone is any . Geographic match criteria is a to block. Action is Deny . If you want to block traffic from a specific zone (vpn0 in this example) to a specific country, configure the Interzone Firewall policy as follows: Source zone is vpn0 . Destination zone is any . Geographic match criteria is a to block. Action is Deny . Internet routing The default Internet Routing policy sends all internet-bound traffic to the default internet interface for a site. For a site with an ANAP, you can override the default behavior and send traffic to another interface or to a cloud security connector. Internet Routing policy example: Create a policy that sends SSH traffic to an internet server using your secondary ISP while all other traffic uses the primary ISP. The Internet Routing security engine includes a policy table that reads policies from top to bottom. The first policy that matches the client’s traffic is applied and all subsequent policies are ignored. Each Internet Routing policy uses the following match criteria to identify traffic: Source zone Named match rules that use any or all of the following network identifiers: Source IP Destination IP Source port Destination port Protocol TOS Managed application identified using one or more of the following: Domain name or server name indicator (SNI) Discovered applications Layer 3 and Layer 4 traffic criteria For more information, see the Security rule match criteria topic. Based on your configured policies, the Internet Routing security engine performs one of the following actions on matched traffic: Blackhole—Traffic is denied and the client does not receive a response. Unreachable—Traffic is denied and the client receives an ICMP Unreachable response. Prohibit—Traffic is denied and the client receives an ICMP Prohibited response. Forward—Traffic is forwarded to the specified interface. If the traffic is not dropped after encountering all engines in the path, it is forwarded to the appropriate interface if it is available. If the tunnel or interface is not found or is down, the next policy in the table is evaluated by default. However, you can configure policies to drop traffic if the selected policy action (operation) fails. The following graphic displays the the processing sequence when the Internet Routing security engine forwards traffic: Default Policy The default policy in the Internet Routing policy table performs the following actions on matched traffic: Routes traffic sourced from a VPN zone to the default internet interface. On an ANAP, the default internet interface is M2, which can be customized if required. Blackholes traffic sourced from DMZ, cloud, and public zones. You can not edit the default policy, but it can be overridden by creating a new policy and placing it above the default policy in the Internet Routing policy table. Best practices Consider the following best practices for Aryaka Basic Firewall: Configure all available features. Configure all of the security features included in your service to optimize your organization’s network security. Develop policy tables based on your organization’s needs. Each policy engine includes a default policy that is designed to provide a minimum level of security. Aryaka recommends that you create additional security policies based on your organization's security requirements, objectives, and compliance obligations. Test new policies . Test policies you want to add to your security configuration in a safe environment before applying them to your network. Monitor network traffic. Regularly audit your security logs to ensure your policies are operating as expected. If you discover that you need to block a certain type of traffic or create a policy exception due to a false positive, you can modify the policy or create additional policies as needed. See the Security topic for general best practices for managing your SASE service. Configuration The Aryaka security rule framework is designed to allow you to achieve your organization’s security and routing requirements using simple workflows. You can configure the security engine policy tables included in Aryaka Basic Firewall to your organizations’s specifications in MyAryaka, as described in the following sections. Configure policy tables To create a Basic Firewall security policy for a site in MyAryaka, click  Sites  in the left navigation pane. On the Sites page that appears, select the site that you want to configure a security policy for. On the siteName page, in the Site Information section, click View on the Site Details tile. Click the  Advanced Settings  icon and then do one of the following: To create a WAN Routing policy, click the WAN Routing tile. For detailed information about creating WAN Routing policies, see the Create site-level WAN Routing policies help topic. To create an Interzone Firewall or Internet Routing policy, click the Internet Policies tile. For detailed information about creating Interzone Firewall and Internet Routing policies, see the Create internet policies help topic. Configure match rules When creating policies, the security engines allow you to use match rules to identify network traffic. A match rule is configured as an asset—a component that can be created and reused in your security configuration. A match rule asset is a named collection of network identifiers (source IP, source port, destination IP, destination port, protocol, TOS). To create a match rule asset that you can reuse as match criteria when creating security policies in MyAryaka, click  Security >  Asset Management in the left navigation pane. The Asset Management page includes a tile for each of the asset types that you can create. Click the Match Rule tile. For detailed information about creating Match Rule assets, see the  Match rule assets help topic. Monitoring MyAryaka allows you to monitor the usage of the security engines included in your service and to view the security logs for any security events in your network. To monitor your security offering in MyAryaka, navigate to the Security > Monitor page. This page displays a diagram of the security engines in the order in which they receive and inspect traffic. The Security > Monitor page also displays a series of tables and graphs that provide statistics about permitted and denied traffic in your network. For detailed information about the functionality included on the Security page, see the  Monitor security help topic. To view your security logs in MyAryaka, navigate to the Security > Monitor page and then use the Quicklink toolbar floating at the bottom of the page to access the Security Logs page. The following graphic displays two security logs where traffic was permitted and one where it was denied: For detailed information about security logs, see the View security logs help topic. In this topic