Catchpoint Synthetic Monitoring – Firewall & Network Requirements

Catchpoint Synthetic Monitoring

Firewall & Network Requirements

Expanded guidance for public synthetic tests, Enterprise Nodes / on-prem agents, and internal-only monitoring scenarios.

Purpose

This document clarifies the firewall posture required for Catchpoint Internet Performance Monitoring (IPM). It separates three common scenarios that are often conflated:

1. Catchpoint public nodes testing customer endpoints
2. Enterprise Nodes installed inside a customer environment
3. Enterprise Nodes testing public Internet destinations

Key Operating Principle

Firewall configuration depends on the testing perspective.

Public Catchpoint nodes require customer endpoints to accept test traffic from Catchpoint public node ranges.

Enterprise Nodes generally require outbound access to Catchpoint SaaS / Command & Control and access to the destinations they test.

Internal-only Enterprise Node tests usually do not require Internet egress to the monitored target, but the node still needs management/reporting connectivity to Catchpoint unless an approved proxy or network path is used.

1. Use Case Summary

The firewall requirement is not a single universal rule. It depends on where the agent or node runs and where the monitored target lives.

2. Feasibility Verdict

Yes — Catchpoint has firewall requirements, but they are scenario-specific.

• Enterprise Node / on-prem agent: primarily outbound requirements — access to Catchpoint Command & Control plus access to monitored targets.
• Internal-only monitoring: usually low-friction if the node can reach internal targets and report back to Catchpoint.
• Internal-to-public monitoring: customer firewall/proxy/SASE may need egress rules for the public destinations being tested.
• Public-to-internal monitoring: requires customer-side allowlisting, NAT, VPN, private exposure, or an Enterprise Node alternative.

3. Key Principles

• Catchpoint public synthetic tests are initiated from Catchpoint nodes toward customer endpoints.
• Enterprise Nodes are deployed inside the customer environment and are managed through the same Catchpoint SaaS portal used for public nodes.
• Enterprise Nodes do not normally require inbound connections from Catchpoint into the customer environment for Command & Control.
• Enterprise Nodes need outbound communication to Catchpoint Command & Control to receive test schedules and send results.
• Enterprise Nodes also need network access to the actual destinations they are testing.
• Public node testing of private/internal apps is not automatic; the customer must make those apps reachable via an approved network/security pattern.

4. Recommended Architecture

A. Public Synthetic Monitoring

Use Catchpoint Backbone, Last Mile, Wireless, and Cloud nodes to monitor Internet-facing web, API, DNS, SSL, CDN, BGP, and network paths from outside the customer environment.

• Node types: Backbone for ISP/carrier perspective; Last Mile for consumer ISP perspective; Wireless for cellular/mobile perspective; Cloud for cloud-region perspective.
• Test types: Web/Object, Browser/Playwright, API, DNS Experience/Direct, SSL, Ping, Traceroute, Transport, SMTP/FTP/IMAP/MQTT as needed.
• Firewall expectation: public customer endpoints must permit traffic from the selected Catchpoint public node ranges and protocols.

B. Enterprise Node / On-Prem Agent Monitoring

Deploy Enterprise Nodes as physical appliances, virtual appliances, containers, or supported software installs in data centers, branch offices, call centers, factories, stores, or other internal locations.

Enterprise Nodes are used when the monitoring perspective must originate inside the customer network, or when targets are not reachable from public nodes.

• Node types: Enterprise Standard for full test coverage; Enterprise Light for smaller-footprint protocol/network tests.
• Test types: Web/Object, Browser/Playwright, API, DNS, SSL, Ping, Traceroute, Transport, Node-to-Node, Custom tests where appropriate.
• Synthetic vs Endpoint vs RUM: Enterprise Nodes provide controlled synthetic tests from fixed internal locations. Endpoint Monitoring provides user-device perspective. RUM captures real user browser/application interactions where deployed.
• Data surfaces: Dashboards, Smartboard, Explorer, Records, Alerts, Stack Map, and SLO views depending on the use case.

5. Required Network Access

A. Public Catchpoint Synthetic Nodes → Customer Endpoints

• Customers should allowlist the selected Catchpoint public node IP ranges when public nodes must test restricted customer endpoints.
• No special firewall product-specific configuration is inherently required for Palo Alto, Cisco Firepower, Fortinet, or similar platforms beyond normal policy and allowlisting controls.
• For public Catchpoint agents attempting to test internal apps or private IP addresses, the customer must explicitly confirm firewall/NAT/VPN/private exposure design. Otherwise, those targets are unreachable from public nodes.

Optional HTTP Identification — User-Agent Allowlisting

For HTTP/HTTPS synthetic tests, customers may optionally identify or allow Catchpoint traffic using a User-Agent string containing catchpoint, where supported by their WAF, CDN, bot mitigation platform, proxy, or security tooling.

This is most relevant when Catchpoint public nodes are testing protected customer web or API endpoints.

User-Agent allowlisting should be treated as supplemental to IP/FQDN allowlisting, not a replacement, because User-Agent headers can be modified and may vary depending on test type, browser mode, or customer-defined request headers.

B. Enterprise Node / On-Prem Agent → Catchpoint Command & Control

Recommended Policy

Allow outbound HTTPS/443 from Enterprise Nodes to *.3gl.net and *.catchpoint.com.

FQDN allowlisting is preferred because hosts/IPs can change.

IP allowlisting should be treated as a last resort or automated using Catchpoint APIs where required by policy.

C. Enterprise Node / On-Prem Agent → Monitored Targets

6. Scenario-Specific Guidance

Scenario 1 — Enterprise Node Installed Internally and Staying Internal

Verdict: Usually straightforward.

If the Enterprise Node only tests internal systems and those systems are reachable from the node network segment, no special inbound Internet rule should be required for the test path.

• Confirm the node can resolve internal DNS names.
• Confirm the node can reach the target app/service over the same protocols users or systems use.
• Confirm outbound Catchpoint C&C access is allowed so the node can receive tests and upload results.
• If the customer uses tight segmentation, explicitly permit traffic from the node subnet to the internal target subnets.

Scenario 2 — Enterprise Node Installed Internally and Testing Public Websites

Verdict: Feasible, but the customer may need to allow egress.

This is the main firewall requirement for an on-prem agent that needs to talk to the public Internet.

• Allow outbound access from the node to the public websites/SaaS/API destinations under test.
• Confirm whether traffic must traverse a proxy, SASE/SWG, CASB, or SSL inspection layer.
• If proxy is required, configure Enterprise Node proxy settings directly on the node.
• Permit DNS resolution and diagnostic protocols if the test plan includes DNS, Ping, Traceroute, Transport, or SSL checks.

Scenario 3 — Public Catchpoint Agents Attempting to Test Internal Apps or Private IPs

Verdict: Requires customer-side firewall and reachability design.

Catchpoint public nodes cannot test private applications or RFC1918/private IP addresses unless the customer provides a secure reachable path.

• Allowlist Catchpoint public node IP ranges for the specific selected nodes/locations.
• Expose a public endpoint, configure NAT, use a secure proxy/VPN/private access path, or deploy Enterprise Nodes instead.
• Confirm the target ports/protocols with the customer firewall team.
• For sensitive internal apps, Enterprise Nodes are usually the cleaner architecture because traffic originates inside the customer network rather than from public Catchpoint nodes.

Scenario 4 — Public Catchpoint Agents Testing Public Apps Protected by WAF/CDN/Bot Controls

Verdict: Feasible, but allowlisting or test identity handling may be required.

• WAF, CDN, bot mitigation, or geo controls may block or challenge synthetic traffic.
• Allowlist Catchpoint node IPs or configure controlled bypass headers/cookies where appropriate.
• Use headers, cookies, or request rules to identify monitoring traffic without weakening customer security controls.
• Use Browser/Playwright tests when the customer needs full user journey validation through CDN/WAF layers.

7. Proxy, SASE, and SSL Inspection Considerations

• Enterprise Nodes can operate in proxy-controlled environments, but proxy configuration must be applied directly on the node.
• Supported proxy approaches may include Direct, Static, and PAC configurations, depending on Enterprise Node edition and deployment pattern.
• Authenticated proxies may require credential handling and validation with the customer security team.
• SSL inspection can change certificate chains, response headers, and timing. Validate whether the test should measure the inspected path or bypass inspection.
• SASE/SWG policies may treat the node differently from normal user devices; validate policy group, source IP, user identity, and egress path.

8. Implementation Considerations

• Choose the right perspective: public nodes for outside-in Internet/customer experience; Enterprise Nodes for inside-out/private network perspective; Endpoint for real workforce/user-device perspective.
• Place Enterprise Nodes close to the user or system boundary: data center, office, branch, factory, call center, store, or cloud/VPC segment depending on the question being answered.
• Use selected node sets: avoid allowing every public node if the use case only requires a smaller representative set.
• Document test protocols: each test type maps to different firewall needs. Browser tests use web traffic; DNS tests need DNS paths; network tests may need ICMP/TCP/UDP/QUIC.
• Validate before production rollout: create a small pilot test set, verify C&C connectivity, target reachability, proxy behavior, and alerting.
• Use labels and dashboards: separate internal-only tests, public-Internet egress tests, and public-node inbound tests for operational clarity.

9. Constraints / Gaps

• Catchpoint does not control customer firewall, proxy, SASE, segmentation, DNS, or endpoint exposure policies.
• Catchpoint does not replace firewall management, SNMP/NetFlow/WMI/device telemetry, or infrastructure monitoring. Those belong to the infrastructure telemetry portfolio, e.g., LogicMonitor Envision Platform.
• Catchpoint does not provide code-level instrumentation, database monitoring, JVM/.NET profiling, or deep backend infrastructure resource monitoring as primary capabilities.
• Private app testing from public nodes is not possible unless the customer deliberately exposes or routes access to those targets.
• ICMP/traceroute may be blocked or rate-limited by intermediate devices; use TCP/UDP traceroute or transport tests where appropriate.

10. Optional Protocols — Only If Used

11. Not Required for Standard Catchpoint IPM Synthetic Monitoring

• SNMP 161/162 for infrastructure polling is not required for Catchpoint synthetic IPM tests.
• NetFlow/sFlow/IPFIX ingestion is not required for Catchpoint synthetic IPM tests.
• WMI, device traps, router/switch CPU/memory polling, and backend host resource monitoring are outside Catchpoint primary IPM scope.
• NTP is not required unless an NTP test is explicitly configured.

12. When to Engage Value Engineering

• Customer wants public Catchpoint nodes to test internal/private applications.
• Customer security policy restricts all wildcard FQDN allowlisting and requires IP-only allowlists.
• Customer uses complex proxy/SASE/SWG/SSL inspection controls.
• Customer needs Enterprise Node placement design across data centers, branches, factories, stores, or cloud networks.
• Customer wants node-to-node mesh, internal DNS, private app transaction monitoring, or internal-to-external correlation.
• Customer asks for architecture across Catchpoint IPM, LogicMonitor infrastructure telemetry, and Edwin AI correlation.

13. Recommended Customer Validation Checklist