Technical Tip: Introduction to the iprope policy groups on FortiGate for the local-in traffic

[GeorgeZhong]

Description	This article describes different types of iprope policy groups for local-in traffic and how they are enforced on local-in traffic.
Scope	FortiGate.
Solution	The iprope table on FortiGate devices contains various iprope policy groups designed to match different types of traffic. Each policy group is critical for determining how traffic is processed upon reaching the FortiGate. For a comprehensive explanation of iprope policy groups, refer to Technical Tip: Iprope policies group. For the local-in traffic, there are five different iprope policy groups to be enforced to. They are: 00100000 [VIP] 00100011 [ ZTNA_PROXY ] 00100001 [ CUST_LOCAL_IN ] 0010000e [ IMPLICIT_IN ] 0010000f [ ADMIN_IN ] 00100000 [VIP]  and 00100011 [ ZTNA_PROXY ]: When a Virtual IP (VIP) or Zero Trust Network Access (ZTNA) proxy is configured on a FortiGate device, the corresponding iprope policies are automatically populated in their respective groups. This automatic configuration ensures that incoming traffic can access the specified external IP and port. For a detailed understanding of how iprope VIP policies are matched, refer to this article. Policy Matching Behaviour: When local-in traffic matches any iprope policy with an 'accept' action in the VIP or ZTNA proxy groups, the policy matching process stops, and the traffic is allowed by FortiGate. This behavior means that once a match is found, no further policies are evaluated. Precedence of VIP and ZTNA Proxy Policies: The iprope policy groups for VIP and ZTNA proxy have the highest precedence over all other groups, including the custom local-in policy group. Consequently, the custom local-in policy cannot be enforced for traffic directed towards the VIP or ZTNA proxy. This implies that such traffic will not be blocked by the custom local-in policy. Considerations for External IPs and Ports: Since the VIP and ZTNA proxy policies take precedence, external IPs and port numbers used by these services should not overlap with those used by other services or administrative access. If they do, the traffic will be intercepted by the VIP or ZTNA proxy at the initial stage, potentially leading to conflicts and undesired access behavior. 00100001 [ CUST_LOCAL_IN ]: This is the iprope policy group for the custom local-in policy configured on FortiGate. This group will be matched by the local-in traffic if there is no match in VIP and ZTNA. When the custom local-in policy is configured, the corresponding iprope policy will populate in the group 00100001. For example: The corresponding group policy is below: The following debug flow indicates that when the local-in traffic hit this policy 2 in the group 00100001, it was dropped immediately. Key point: if the incoming traffic matches with any custom local-in policy with the ‘accept’ action, it will be accepted by the FortiGate and move onto the next policy group even if there is another custom local-in policy with ‘deny’ action. The ‘accept’ policy is typically created to permit local-in traffic from specific subnets while denying access to all other sources. This approach ensures that only trusted sources can access the FortiGate device. See this article for an example. 0010000e [ IMPLICIT_IN ]: The iprope policy group 0010000e is designated for managing local-in policies related to various services running on FortiGate devices, including BGP, IPsec, SSL VPN, and others. This policy group ensures that the necessary ports are opened to facilitate the operation of these services. For example, when the IPsec VPN is configured, UDP port 500 and UDP/TCP 4500 are opened to accept the incoming IPsec tunnel negotiation. If the IKE port is changed in the system settings, the policy within this group will automatically update to reflect the new port configuration. If a specific service is not enabled on the FortiGate device, no corresponding local-in policy will be generated for its associated ports within this group. As a result, any incoming traffic targeting those ports will be dropped by the last policy in this group, as below: 0010000f [ ADMIN_IN ]: The iprope policy group 0010000f consists of local-in policies that restrict the admin access to the FortiGate. Policies in this group are automatically populated based on the protocol type of ‘Administrative Access’ enabled on the interface and trust host setting under system administrator. When the specific ‘Administrative Access’ (such as HTTPS, SSH, HTTP, SNMP) is enabled on the interface level, the corresponding port will be opened by the auto-populated policy in this group. In the following example, when ping, https, ssh, http and telnet are all enabled on the interface, the policy is generated to open up the TCP port 443, 22, 23 and 80. Also, the proto 1 is added in the policy to allow the ICMP traffic. If all the system administrators have the trust host enabled, the policy with the corresponding trust host IP as source will be populated to allow the admin traffic from these hosts. In the following example, only traffic from these hosts is able to match these two policies: otherwise, it will be dropped by the implicit policy at the end of this group (similar to 0010000e). Note: the ICMP will not be restricted by the trust host. Thus, the proto 1 is not added into these two policies. Instead, there is another separate policy in this group to allow the ICMP in this scenario as below. There has been a vulnerability FG-IR-24-535 that could potentially allow remote users to access FortiGate via HTTPS/HTTP without authentication in v7.0. The workaround is to apply the local-in policy for the HTTPS/HTTP port or disable the HTTPS/HTTP ports on public facing interfaces. These two methods are respectively enforced by the custom local-in policy group and implicit-in group.  Trust host is another workaround but when using this feature to mitigate the vulnerability of FG-IR-24-535, please make sure all administrators have trust host configured as in the above example.  Summary: VIP and ZTNA Proxy Policies: The VIP and ZTNA proxy policies have the highest precedence for local-in traffic. Traffic matching these policies will be accepted. To avoid conflicts with administrative access or other services, carefully select the external IP and port. Custom Local-In Policy: The custom local-in policy (group 00100001) holds the second-highest precedence. It is recommended to use this policy to block traffic from specific source subnets that should not access the FortiGate for administration or other services like SSLVPN or IPsec. Admin-In and Implicit-In Groups: The admin-in (0010000f) and implicit-in (0010000e) groups are automatically populated to allow access based on the Admin access settings and enabled services on the FortiGate.