# Cox Business BGP / Routing Escalation Ticket — Draft

**Account / Service:** Mike Swanson, AZ Computer Guru — business static-IP block 72.194.62.0/29
**WAN / upstream:** Cox Business, Tucson AZ (or wherever applicable)
**Circuit public IP (pfSense WAN):** 98.181.90.163
**Destination affected public IPs:** 72.194.62.2, .3, .4, .5, .8, .9, .10

---

## Subject

Asymmetric/unreachable routing from Cox customer block 72.194.62.0/29 to specific Cloudflare /16 and /18 IP prefixes

## Summary

Cloudflare PoP in Phoenix (PHX) cannot successfully establish TCP connections to our public IPs (72.194.62.2-.10) for origin-pull requests. HTTP requests from public clients reaching Cloudflare get a 521 "web server is down" response, because Cloudflare's origin-pull source prefixes cannot complete TCP handshakes to our netblock.

## Evidence

### 1. Our WAN firewall can reach ~half of Cloudflare's IP ranges, not the others

From our pfSense firewall (FreeBSD, 2.8.1), TCP connect test to port 443 on representative IPs in each Cloudflare-advertised prefix:

| Cloudflare Prefix | Sample IP | TCP:443 connect |
|---|---|---|
| 104.16.0.0/13 | 104.16.0.1 | succeeds |
| 104.16.0.0/13 | 104.17.0.1 | succeeds |
| 104.24.0.0/14 | 104.26.0.1 | succeeds |
| 162.158.0.0/16 | 162.158.0.1 | **timeout** |
| 162.158.0.0/16 | 162.158.100.1 | **timeout** |
| 172.64.0.0/13 | 172.64.0.1 | **timeout** |
| 172.64.0.0/13 | 172.67.0.1 | **timeout** |
| 173.245.48.0/20 | 173.245.48.1 | **timeout** |
| 141.101.64.0/18 | 141.101.64.1 | **timeout** |

Reference list Cloudflare publishes at https://www.cloudflare.com/ips-v4

### 2. ICMP traceroute to failing Cloudflare prefixes reveals an unusually indirect path

Traceroute from pfSense WAN (98.181.90.163) to 162.158.0.1 — 8 hops, ~173 ms (suggests routing via a distant peering point):

```
1  * * *
2  100.120.164.200  3.236 ms
3  68.1.0.191  4.180 ms
4  184.183.131.9  23.671 ms
5  198.41.140.124  14.635 ms
6  198.41.140.244  161.626 ms   <- huge latency jump (likely cross-country)
7  108.162.247.54  163.073 ms
8  162.158.0.1  173.018 ms
```

Compare to traceroute to the working prefix 104.26.8.237 — 6 hops, ~3.6 ms:

```
1  * * *
2  100.120.164.200  3.022 ms
3  68.1.0.191  3.799 ms
4  184.183.131.9  8.973 ms
5  162.158.140.21  3.909 ms   <- nearby Cloudflare peering
6  104.26.8.237  3.445 ms
```

The ~170 ms added round-trip to 162.158.0.0/16 vs ~3.5 ms to 104.x suggests routes for 162.158, 172.64, 173.245, 141.101 are being withdrawn from the local peering and defaulting to a distant one (Ashburn or similar), with packet loss or asymmetric return on that path.

### 3. Direct-internet users reach our origin fine; only Cloudflare-proxied traffic fails

Our state table currently shows 285 active inbound :443 connections to our origin server from various non-Cloudflare IPs (Philippines, Russia, India, Pakistan users — direct clients). Zero inbound connections from any Cloudflare prefix. Origin is healthy; the problem is specifically the return path to Cloudflare's origin-pull source IPs.

### 4. Third-party test confirms routing is not symmetric

From an external network (different ISP egress), connecting to our public IP 72.194.62.5 on port 443 with correct SNI succeeds with HTTP 200.

## Ask

Please have network engineering check the BGP advertisements and/or routing policy for:

- Cloudflare prefixes **162.158.0.0/16**, **172.64.0.0/13**, **173.245.48.0/20**, **141.101.64.0/18**
- Return path from our block **72.194.62.0/29** to those Cloudflare prefixes

It appears these prefixes are being routed through a distant Cox peering point rather than the nearby Cloudflare peering (visible at hop 5 on the working route), and the return path is either black-holed or lossy enough to drop TCP handshakes.

Contact: Mike Swanson, AZ Computer Guru
Timeline: urgent — hosted sites (azcomputerguru.com, analytics., community., radio.) are intermittently unreachable to any visitor whose nearest Cloudflare PoP chooses an origin-pull source in one of the affected prefixes.

## Workaround in place

We are setting up a Cloudflare Tunnel from inside our network outbound to Cloudflare (initiated from our side using working prefixes), so customer-visible outage is mitigated. Resolution of the underlying BGP issue is still required for any direct-proxied traffic and general Cox–Cloudflare connectivity health.
