Allow CircleCI Traffic Through Your Firewall with IP Ranges (2026)

CircleCI’s infrastructure needs to reach out to your services, and if you’ve got a firewall in place, it’s going to block them.

The core issue is that CircleCI’s build agents, which execute your jobs, need to make outbound connections to your private network resources (like databases, internal APIs, or artifact repositories) to perform their tasks. When a firewall intercepts these connections because it doesn’t recognize the source IP address, the build fails. The solution is to explicitly permit traffic originating from CircleCI’s known IP address ranges.

Here are the common reasons this fails and how to fix them:

1. Outdated IP Ranges

CircleCI’s IP ranges are not static and can change over time as they scale their infrastructure. If your firewall rules are based on old information, legitimate traffic will be blocked.

• Diagnosis: Check the current official CircleCI IP ranges. The most reliable place is their documentation.
• Fix: Update your firewall rules to include all of the current IPv4 and IPv6 ranges listed in the CircleCI documentation. For example, if a new range 203.0.113.0/24 was added, you’d add a new rule allowing outbound traffic from this subnet.
• Why it works: This ensures your firewall has the most up-to-date list of addresses CircleCI’s build agents use, allowing their connections to pass through.

2. Incorrect Protocol/Port Configuration

You might be allowing the IP addresses but not the specific protocols or ports they need to communicate on. CircleCI agents typically use TCP on ports like 80 (HTTP) and 443 (HTTPS), but may need others for specific integrations.

• Diagnosis: Review your firewall’s access control list (ACL) for rules related to CircleCI IPs. Check if the rule specifies TCP and the correct ports.
• Fix: Ensure your firewall rules explicitly allow TCP traffic on ports 80 and 443 (and any other ports your builds require) from the CircleCI IP ranges. For example, on iptables, you might have a rule like iptables -A OUTPUT -p tcp --dport 443 -s 203.0.113.0/24 -j ACCEPT.
• Why it works: This allows the handshake and data transfer to occur over the necessary network channels.

3. Geo-IP Filtering or Regional Restrictions

Some firewalls or network security policies might block traffic based on the perceived geographic origin of the IP address. If CircleCI’s IPs are being flagged incorrectly or if you have regional blocks that don’t account for CircleCI’s distributed infrastructure, connections will fail.

• Diagnosis: Examine your firewall’s geo-IP database and any regional blocking policies. See if the CircleCI IP ranges are being inadvertently categorized or blocked.
• Fix: Either disable geo-IP filtering for the specific CircleCI IP ranges or ensure your geo-IP database is up-to-date and correctly identifies the origin of these IPs. If using specific regional blocks, ensure they are configured to allow the CircleCI ranges.
• Why it works: This prevents the firewall from rejecting connections based on a false assumption about the traffic’s origin.

4. Statefulness Issues in Firewalls

Stateful firewalls track the state of active network connections. If a firewall is misconfigured or has issues maintaining connection states, it might drop return traffic from your internal services back to CircleCI agents, even if the initial outbound connection was permitted.

• Diagnosis: Check the state table of your firewall for any anomalies or dropped packets related to connections originating from CircleCI IPs. Look for logs indicating state-related rejections.
• Fix: Ensure your firewall is configured to correctly track and allow established and related TCP connections. For example, in iptables, the filter table should have a rule like iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT applied before any specific rules that might block return traffic.
• Why it works: This tells the firewall to allow traffic that is part of an already established, legitimate conversation.

5. NAT Gateway or Proxy Configuration Errors

If your internal network uses a NAT gateway or a proxy for outbound internet access, misconfigurations in these devices can also block CircleCI traffic, especially if they are not correctly set up to handle dynamic IP sources or specific protocols.

• Diagnosis: Inspect the configuration of your NAT gateway or proxy server. Look for any rules that might be restricting outbound connections from the CircleCI IP ranges or interfering with their traffic.
• Fix: Configure your NAT gateway or proxy to allow traffic from the CircleCI IP ranges to reach your internal resources. This might involve adding specific NAT rules or proxy bypass rules for these IPs.
• Why it works: This ensures that traffic from CircleCI isn’t being incorrectly translated or blocked by intermediate network devices.

6. Overly Restrictive Egress Filtering

You might have aggressive egress (outbound) filtering rules in place that are too broad. While intended for security, these can inadvertently block necessary outbound connections from CircleCI agents.

• Diagnosis: Review all egress filtering rules on your firewall. Identify any rules that might be blocking traffic to your internal network based on source IP (CircleCI’s IPs) or destination ports/protocols that are not explicitly allowed.
• Fix: Create specific "allow" rules for the CircleCI IP ranges to access the necessary internal resources on the required ports and protocols. These explicit allow rules should generally precede more general "deny" rules. For instance, firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="203.0.113.0/24" destination port port="5432" protocol="tcp" accept' in firewalld.
• Why it works: This creates a specific exception for CircleCI’s traffic, overriding any broader, more restrictive policies.

Once these are correctly configured, you’ll likely encounter errors related to your build environment setup or specific dependencies not being accessible.