Remote Port Forwarding (RPF) lets you direct an inbound connection from the Internet through the Cato Cloud to an internal LAN host. The connection then benefits from the different Cato security services.
Note
Note: RPF isn't supported for PoPs that are located in China. You can't choose an Allocated IP for these Chinese PoPs.
You can control inbound access control to RPF resources using either an allow-list approach or a block-list approach:
-
Allow List – blocks all sources (IP addresses and ranges) and only ALLOWS sources that are specifically configured
-
Block List - allows all sources (IP addresses and ranges) and only BLOCKS sources that are specifically configured
The block list approach is recommended for situations where you need to control access to Internet-facing RPF resources and the allowed sources are not known or defined. This approach provides an option to configure a list of blocked sources via the Cato Management Application or an API. The block list may be based on customer-maintained block-lists, private security feeds, specific geo records, and indicators from 3rd party systems.
Note
Note: The Cato IPS service protects inbound RPF traffic, however TLS inspection isn't performed on inbound traffic. This means that IPS can’t inspect content for the encrypted traffic, but IPS inspects traffic based on reputation checks (such as scanners, portsweepers, known C&Cs, and so on).
One of the basic functionalities of an NGFW is to protect against anti-spoofing attacks. The security engines in the Cato Cloud implicitly drop any connection where the source IP is outside the scope of the configured entity (such as site, network range, device, or user). This blocks anti-spoofing attacks and prevents violations of the configured logical topology.
The Remote Port Forwarding policy lets different admins edit the policy in parallel. Each admin can edit rules and save the changes to the rulebase in their own private revision, and then publish them to the account policy (the published revision). For more information on how to manage policy revisions, see Working with Policy Revisions.
The External IP for an RPF rule is a Cato allocated IP address. For more information, see Allocating IP Addresses for the Account.
When you define an RPF rule, there are different options for the Allowed Remote IPs setting:
-
Enter a specific IP address or an IP range in one of these formats:
-
Range of IP addresses - 192.0.2.10-192.0.2.20
-
Subnet (CIDR) - 192.0.2.0/24
You can also paste a comma separated list with multiple IP addresses and ranges, for example: 10.1.1.1, 10.2.1.1-10.1.2.5
-
-
Enable tracking and notifications.
Best Practice: We recommend that you configure a range of external ports by mapping them to an identical range of internal ports. You can configure a range of external ports (xxx-xxy) and a compatible range of internal ports (xxx-xxy). However, if your network requires mapping from multiple external ports to a single internal port, it is possible to configure this by creating multiple RPF rules.
The mapping for the external to internal ports is specific one-to-on mapping. For example, the external port range 5000-5005 is mapped to the internal port range 5000-5005. This means that external port 5000 is mapped to internal port 5000, external port 5001 is mapped to internal port 5001, and so on.
Note
Note: For accounts with IPsec sites, if the external IPs of an RPF rule overlap with the IP addresses of an IPsec site, make sure that the rule excludes the IPsec tunnel ports UDP/500 and UDP/4500.
To define a Remote Port Forwarding rule:
-
From the navigation menu, click Network > Remote Port Forwarding.
The Remote Port Forwarding page opens to your existing unpublished revision, or to the newest published revision.
-
Click New. The Add Rule panel opens.
-
Enter the Name for the rule.
-
(Optional) Select Forward ICMP to enable forwarding ICMP messages for this rule.
-
In the External section, define the Cato allocated External IP and External Port Range for the ports monitored by the PoP.
-
In the Internal section, enter the Internal IP address to which the traffic is forwarded and the Internal Port range.
-
In the Remote IPs section, select if this rule is an Allow List or Block List.
-
To define the only traffic that is ALLOWED to connect to the host:
-
Select Allow List.
-
Select the Traffic Sources based on the IP or Subnet. These are the IP addresses and ranges that are allowed to perform RPF to the host.
-
Click (Add) to add more allowed remote IPs.
-
-
To allow all traffic to this host, and define sources that are BLOCKED and can't connect to it:
-
Select Block List.
-
Select the Traffic Sources based on the IP or Subnet. These are the IP addresses and ranges that are blocked and can't perform RPF to the host.
-
Click (Add) to add more blocked remote IPs.
-
-
-
(Optional) Define email notifications, for the traffic that matches the rule. For more information, see Account Level Alerts and System Notifications.
-
Click Apply. The rule is added.
-
Click Save.
The changes are saved to your unpublished revision, and are available for editing until they are published or discarded.
5 comments
will these events be logged
Regarding the NOTE: “For accounts with IPsec sites, if the external IPs of an RPF rule overlaps with the IP addresses of an IPsec site, make sure that the rule excludes the IPsec tunnel ports UDP/500 and UDP/4500.” Where is the exclusion applied, as there is no selection of UDP or TCP for RPF rules. Or it is refering to some other rule?
The fact that there is no event logging capabilities for Remote Port Forwarding is a major feature gap, and while it's understandable that the potential for high volume traffic makes this challenging it should at least be addressed in the solution article.
JM Can you please clarify about event logging capabilities for RPF? There is a Security event subtype for RPF when an RPF rule is matched
Hi Yahoov, upon checking it appears you are right. The Cato Security Alert email that can be subscribed to for each RPF rule does not include a link to the relevant event log entries though, unlike for the firewall rulesets.
Please sign in to leave a comment.