Skip to main content

​
Overview

Firewall rules control which external services and resources your Entegrata instance can communicate with. By defining application rules (for domain names) and network rules (for IP addresses), you establish granular control over your instance’s outbound network access. This is a critical security feature that:
  • Restricts outbound connections to only approved destinations
  • Prevents unauthorized data exfiltration
  • Ensures compliance with security policies
  • Enables safe communication with data sources and third-party services
Firewall Settings Overview
Firewall rules complement your network connection settings (S2S VPN or VNet Peering) by controlling what your Entegrata instance can access once connected to your infrastructure.

​
Understanding Firewall Rules

​
Rule Categories

Entegrata organizes firewall rules into two distinct categories:
Purpose: Data sources and systems accessed by Entegrata collectorsCharacteristics:
  • Created automatically when collectors are configured
  • Can be viewed and managed by administrators
  • Represent actual data collection endpoints
Examples:
  • api.salesforce.com - Salesforce API access
  • graph.microsoft.com - Microsoft Graph API
  • 192.168.1.50 - On-premises database server
Collector rules are typically generated by the collector configuration process but can be manually adjusted if needed.
Purpose: User-defined rules for specific business requirementsCharacteristics:
  • Fully customizable by administrators
  • Can be added, edited, and deleted as needed
  • Used for special integrations or custom data sources
Examples:
  • *.customapi.company.com - Internal API endpoints
  • 203.0.113.100 - Third-party service IP
  • webhook.service.io - External webhook destinations
Use custom rules to whitelist services that aren’t automatically detected by collector configuration.

​
Rule Types

Firewall rules come in two types, each serving different networking scenarios:
What they are: Domain-based rules that match Fully Qualified Domain Names (FQDNs)Use cases:
  • Cloud APIs (e.g., api.example.com)
  • SaaS platforms (e.g., app.salesforce.com)
  • Services with dynamic IPs
  • CDN-backed services
Supported formats:
  • Exact domains: api.example.com
  • Wildcard subdomains: *.example.com
  • Multiple domain levels: app.subdomain.example.com
Advantages:
  • Works with cloud services that use dynamic IPs
  • Clearer, more readable than IP addresses
  • Automatically adapts to IP changes
api.salesforce.com
graph.microsoft.com
webhook.slack.com

​
Understanding the Rules Display

Each firewall rule displays the following information:
​
Rule Name/Value
string
The FQDN or IP address that the rule applies to.Examples:
  • api.salesforce.com (Application rule)
  • 192.168.1.100 (Network rule)
  • *.azure.com (Wildcard application rule)
​
Rule Type
badge
Indicates whether the rule is an Application (FQDN) or Network (IP/CIDR) rule.
​
Category
badge
Shows if the rule is Collector or Custom.
​
Actions
buttons
For Collector and Custom rules, edit and delete actions are available.

​
Adding New Firewall Rules

​
Create a New Rule

1

Open Add Rule Dialog

In the firewall management interface, click the Add Rule button in the Collector or Custom section.
Add Rule Button
2

Select Rule Type

Choose between Application Rule (FQDN) or Network Rule (IP/CIDR) based on your needs.
Select Rule Type
Select Application Rule if you’re adding access to:
  • Cloud APIs with domain names
  • SaaS platforms
  • Services with dynamic IPs
3

Enter Rule Details

Fill in the required information based on your rule type.
FQDN (Domain Name)Enter the fully qualified domain name:
  • Exact match: api.example.com
  • Wildcard subdomain: *.example.com
Validation requirements:
  • Domain length: 3-255 characters
  • Each label (part between dots): max 63 characters
  • Must have valid top-level domain (TLD)
  • Supports single wildcard at beginning (*.)
Enter FQDN
Wildcard rules like *.com are not allowed. The wildcard can only replace one subdomain level, e.g., *.example.com.
4

Choose Rule Category

Select whether this rule should be categorized as Collector or Custom.Collector: For data sources accessed by collectors Custom: For other integrations and services
5

Save the Rule

Click Add Rule to save. The rule is immediately added to your configuration and you’ll see a success notification.
The rule is saved to your configuration but not yet active. You must click Apply Changes to deploy the rule to your infrastructure.

​
Validation Examples

✅ These will be accepted:
  • api.salesforce.com
  • *.azure.com
  • app.subdomain.example.com
  • service-123.cloud.provider.net
  • my-api.example.co.uk
❌ These will be rejected:
  • *.com (wildcard too broad)
  • example (missing TLD)
  • http://api.example.com (includes protocol)
  • api.example.com:443 (includes port)
  • api..example.com (double dots)
✅ These will be accepted:
  • 192.168.1.100
  • 192.168.1.100/32
  • 10.0.0.0/24
  • 172.16.0.0/16
  • 203.0.113.0/28
❌ These will be rejected:
  • 256.1.1.1 (octet > 255)
  • 192.168.1.1/33 (CIDR > 32)
  • 192.168.1 (incomplete IP)
  • 2001:db8::1 (IPv6 not supported)
  • 192.168.1.1-192.168.1.10 (range notation not supported)

​
Editing Existing Rules

​
Modify a Rule

1

Locate the Rule

In the Collector or Custom tab, find the rule you want to modify.
2

Open Edit Dialog

Click the Edit icon (pencil) next to the rule.
Edit Rule Button
3

Modify Rule Details

Update the FQDN, IP address, or CIDR range as needed.The same validation rules apply as when creating a new rule.
Edit Rule Dialog
4

Save Changes

Click Save to update the rule. You’ll see a success notification confirming the update.
Like new rules, edits are saved to configuration but require Apply Changes to take effect in your infrastructure.

​
When to Edit Rules

Common scenarios requiring rule edits:
  • Domain migration: Service moves to new domain
  • IP address change: On-premises system gets new IP
  • Scope adjustment: Expand or narrow CIDR range
  • Subdomain change: API endpoint URL changes
  • Typo correction: Fix incorrectly entered domain or IP

​
Deleting Firewall Rules

​
Remove a Rule

Before deleting a rule, ensure it’s not required for active data collection or critical integrations. Removing a rule may cause collectors or integrations to fail.
1

Identify Rule to Delete

Navigate to the Collector or Custom tab and locate the rule you want to remove.
2

Click Delete Action

Click the Delete icon (trash can) next to the rule.
Delete Rule Button
3

Confirm Deletion

A confirmation dialog appears to prevent accidental deletions.
Confirm Delete Dialog
Review the rule details carefully before confirming.
4

Complete Deletion

Click Delete to confirm. The rule is removed from your configuration and you’ll see a success notification.
The deletion is saved to configuration but requires Apply Changes to remove the rule from your infrastructure.

​
When to Delete Rules

Delete rules when:
  • Data source retired: No longer collecting from this system
  • Integration removed: Service no longer in use
  • Duplicate entries: Consolidating overlapping rules
  • Security audit: Removing overly permissive rules
  • Testing completed: Temporary test rules no longer needed
Before deleting a rule, consider whether you might need it again. If there’s any uncertainty, keep the rule but document why it exists.

​
Applying Firewall Changes

​
Understanding the Two-Step Process

Firewall rule management uses a save-then-apply workflow:
1

Make Changes

Add, edit, or delete rules as needed. All changes are saved to your configuration immediately.
2

Review Changes

Changes are staged but not yet deployed to your infrastructure. Your instance continues using the previous firewall configuration.
You can make multiple changes (add several rules, edit others, delete some) before applying. All changes will be deployed together.
3

Apply Changes

Click the Apply Changes button to deploy your staged changes to Azure infrastructure.
Apply Changes Button
4

Infrastructure Update

The system triggers an infrastructure update:
  • Status changes to Transitioning
  • A loading screen displays progress showing “Infrastructure is transitioning”
  • System polls for completion every 30 seconds
  • Changes are deployed via Pulumi Infrastructure as Code
5

Changes Active

Once the transition completes, you’ll see a success message and:
  • Status returns to Idle
  • New firewall rules are now enforced
  • Your instance can access newly allowed destinations
  • Previously allowed destinations (if removed) are now blocked

​
Why the Two-Step Process?

This design provides several benefits:

Safety: Review all changes before deploying to productionEfficiency: Batch multiple rule changes into a single infrastructure updateFlexibility: Experiment with rules without immediately affecting infrastructureTransparency: Clear separation between configuration and deployment

​
During Transition State

While your instance is in Transitioning state:
  • ✅ Existing firewall rules remain active
  • ✅ Data collection continues normally
  • ❌ Cannot make additional firewall changes
  • ❌ Cannot modify other instance settings
  • ❌ Cannot apply new changes until transition completes
Firewall infrastructure transitions typically take 5-15 minutes depending on the complexity of changes being deployed.

​
Common Firewall Configurations

​
Example: Whitelist Azure Services

To allow your instance to access Azure-specific services beyond system defaults: 
*.servicebus.windows.net
*.database.windows.net
*.azurecr.io
*.azurewebsites.net

​
Example: Allow Specific On-Premises IPs

For hybrid cloud scenarios with on-premises data sources: 
192.168.10.50/32    (Database server)
192.168.10.51/32    (Application server)
10.0.5.0/24         (Collector subnet)
172.16.0.0/16       (Corporate network range)

​
Example: SaaS Platform Integration

For collecting data from common SaaS platforms: 
*.salesforce.com
*.force.com
graph.microsoft.com
*.office365.com
*.slack.com
api.github.com

​
Example: Restrictive Configuration

For high-security environments requiring minimal access:
  1. Add specific rules only as collectors require them
  2. Use exact FQDNs instead of wildcards
  3. Use /32 CIDR for individual IPs, not ranges
  4. Regularly audit and remove unused rules

​
Troubleshooting

​
Common Issues and Solutions

Symptoms: Collector reports connection failures despite rule being addedPossible causes:
  1. Changes not yet applied (still in staging)
  2. System still in Transitioning state
  3. Incorrect FQDN or IP in rule
  4. Rule added to wrong category
Solutions:
  • Verify you clicked Apply Changes
  • Wait for Transitioning state to complete
  • Double-check rule value matches collector configuration
  • Ensure rule uses correct type (FQDN vs IP)
  • Check collector logs for actual connection target
Use collector logs to identify the exact domain or IP being blocked. Sometimes services use different endpoints than expected.
Symptoms: Add Rule button is disabled or form won’t submitPossible causes:
  1. System in Transitioning state
  2. Validation error in rule input
  3. Network connection issue
Solutions:
  • Wait for any infrastructure transitions to complete
  • Review validation messages in the form
  • Ensure FQDN/IP format is correct
  • Try refreshing the page
  • Check browser console for errors
Symptoms: Connection fails despite wildcard rule that should matchPossible causes:
  1. Wildcard only covers one subdomain level
  2. Service uses different domain than expected
  3. Rule not yet applied to infrastructure
Solutions:
  • Remember *.example.com matches api.example.com but NOT api.sub.example.com
  • For nested subdomains, add multiple rules or use exact domains
  • Verify the rule has been applied (not just saved)
  • Check service documentation for actual endpoints used
Wildcard *.example.com does not match example.com itself. Add both *.example.com and example.com if you need both.
Symptoms: Apply Changes triggered but state doesn’t return to IdlePossible causes:
  1. Azure infrastructure provisioning delay
  2. Backend service issue
  3. Network connectivity problem
Solutions:
  • Wait at least 15-20 minutes for infrastructure updates
  • Refresh the page to ensure you’re seeing current status
  • Check Azure portal for any alerts in your subscription
  • If persists beyond 30 minutes, contact Entegrata support
The system polls status every 30 seconds during transitions. If the loading screen stops updating, try refreshing your browser.
Symptoms: Traffic continues to flow through a deleted rulePossible causes:
  1. Changes not applied yet (rule still in staging)
  2. Infrastructure update hasn’t completed
  3. Cached connections still active
Solutions:
  • Ensure you clicked Apply Changes after deletion
  • Wait for Transitioning state to complete
  • Some connections may remain active for minutes after rule removal
  • Verify the rule is actually gone from the rules list
Symptoms: Cannot add network rule with desired CIDR rangePossible causes:
  1. Range exceeds security policy limits
  2. Attempting to use /0 (all IPs)
Solutions:
  • Use more specific CIDR ranges
  • Break large ranges into smaller, justified subnets
  • Document business justification for broad ranges
  • Consider multiple specific rules instead of one broad rule
While technically valid, very broad CIDR ranges like /8 or /0 may be blocked by policy. Contact your security team if you have a legitimate need for broad ranges.

​
Diagnostic Steps

If you’re experiencing firewall-related issues:
1

Verify Rule Exists

Check the firewall management interface to confirm the rule is present in Collector or Custom categories.
2

Confirm Changes Applied

Ensure the Apply Changes button has been clicked and the transition completed successfully.
3

Check Rule Accuracy

Verify the FQDN or IP exactly matches what your service needs to access. Check for typos.
4

Review System Status

Confirm the instance is in Idle state, not Transitioning.
5

Test Connectivity

Use collector logs or diagnostic tools to verify the connection attempt and see actual failure reasons.
6

Examine Rule Type

Ensure you’re using the correct rule type (Application for domains, Network for IPs).
7

Contact Support

If issues persist after verifying all above steps, contact Entegrata support with:
  • Rule configuration details
  • Error messages from collector logs
  • Timeline of when issue started
  • Recent changes made to firewall rules

​
Security Best Practices

​
Rule Management Guidelines

Firewall Security Recommendations

Principle of Least Privilege
  • Only allow access to services actively in use
  • Use specific FQDNs over wildcards when possible
  • Prefer /32 CIDR (single IP) over broad ranges
  • Document the purpose of each custom rule
Regular Audits
  • Review firewall rules quarterly
  • Remove rules for retired systems or integrations
  • Verify collector rules match active collectors
  • Update rules as services migrate or change
Change Management
  • Test rule changes in non-production environments first
  • Document why each rule is needed
  • Coordinate firewall changes with security team
  • Plan changes during maintenance windows
Monitoring
  • Set up alerts for failed collector connections
  • Review logs for blocked connection attempts
  • Track when rules were last modified
  • Monitor for unexpected rule additions

​
Wildcard Usage Guidelines

When to use wildcards:
  • Cloud services with many subdomains (e.g., *.salesforce.com)
  • CDN-backed services with dynamic endpoints
  • Multi-tenant SaaS platforms
When to avoid wildcards:
  • Services with single, stable domains
  • High-security environments
  • When exact endpoint is known and unlikely to change
  • Government or compliance-sensitive deployments

​
IP Range Best Practices

When creating network rules with CIDR ranges:
Use a CIDR calculator to ensure your range includes only the intended IPs.Example: If you need IPs 192.168.1.5 through 192.168.1.10 (6 IPs):
  • ❌ Don’t use: 192.168.1.0/24 (256 IPs - too broad)
  • ✅ Do use: 192.168.1.5/32, 192.168.1.6/32, … (individual IPs)
  • ✅ Or use: 192.168.1.4/29 (8 IPs - closest range)
Maintain documentation of what each IP or range is used for:
Example Documentation
192.168.10.50/32  - Primary SQL Server
192.168.10.51/32  - Replica SQL Server
10.0.5.0/24       - Collector Subnet (16 collectors)
172.16.0.0/20     - Corporate HQ Network
This helps with audits and troubleshooting.
If you expect to add more IPs in the future, consider using a slightly broader CIDR range from the start:Scenario: Currently need 2 IPs, expect to grow to 10 IPs in subnet
  • Current need: 192.168.1.5/32, 192.168.1.6/32
  • Better choice: 192.168.1.0/28 (16 IPs) - allows for growth
Balance security (minimal range) with operational efficiency (avoid frequent updates).

Network Connections

Configure S2S VPN or VNet Peering for network connectivity

Instance Overview

Learn about instance administration concepts

Collector Configuration

Set up data collectors that use firewall rules

Contact Support

Get help with firewall configuration issues