You're dealing with a port connectivity issue during the Cisco FTD (Firepower Threat Defense) to CDFMC (Cloud-Delivered FMC) registration, specifically with port 8305/TCP failing to connect. The log is quite telling, and here's a breakdown and recommended steps to troubleshoot and resolve it.
What the Logs Tell Us
FTD is trying to connect to CDFMC over both IPv4 and IPv6.
IPv6 fails due to Network is unreachable.
IPv4 connection to 54.148.59.114 on port 8305 is refused:
Connect to 54.148.59.114 failed on port 8305 socket 11 (Connection refused).
This means:
DNS resolution is working.
The FTD can reach the IP, but the TCP handshake fails.
So it's not a DNS or basic routing issue, but a firewall, NAT, or access-list issue either on the path or at the target.
Checklist: What You Should Test or Review
1. Verify if port 8305 is allowed outbound
From the FTD management interface to the internet (specifically to 54.148.59.114), ensure there's no ACL, security policy, or upstream firewall blocking port 8305/TCP.
Run this from the FTD CLI:
bash
Copy
Edit
> system support diagnostic-cli
# telnet 54.148.59.114 8305
Or, if telnet is not available:
bash
Copy
Edit
# nc -zv 54.148.59.114 8305
If the port is open, you should see a successful connection. If it’s refused or times out, there's likely a block upstream (ISP, enterprise firewall, or NAT device).
2. Check if NAT is interfering
Since you're connecting to CDFMC (Cisco’s cloud), ensure there's no NAT device modifying or blocking the traffic. CDFMC expects specific traffic on specific ports from FTD.
Cisco recommends no deep inspection or NAT tampering for port 8305 traffic.
Ask:
Is the FTD behind a strict egress firewall?
Is there Outbound NAT or PAT?
Are you inspecting or proxying this traffic?
3. Check your egress firewall rules
Ensure the following IPs and ports are accessible from the FTD's management interface:
Service Destination FQDN / IP Port
CDFMC comms *.cdo.cisco.com 443, 8305
Smart Licensing tools.cisco.com 443
Time sync ntp.ubuntu.com / NTP server 123/UDP
Make sure 8305/TCP is explicitly allowed in your outbound rules.
4. Are you behind a Proxy?
If your org uses a proxy for outbound traffic, CDFMC may bypass it for port 8305. Make sure this is allowed directly without interception.
Alternative Test From External Host (Sanity Check)
From any non-FTD device in the same network (e.g., a laptop or jumpbox on the same subnet):
bash
Copy
Edit
curl -v telnet://54.148.59.114:8305
If you get Connection refused, then it's not just the FTD—your environment is blocking it or the destination isn’t listening.
Cisco Documentation Reference
Cisco’s public doc on CDFMC communication ports:
Cisco CDFMC Communication Requirements
They specifically mention 8305 must be allowed outbound and not deep-inspected.
Final Notes
Since you’ve been with TAC for 3 months, here's what to explicitly ask them or test with them:
Can they confirm the CDFMC endpoint is listening on 8305? (Sometimes cloud-side issues exist too.)
Can they provide a list of all required IP subnets and ranges used by CDFMC (instead of relying just on FQDNs)?
Can you provide a packet capture from FTD’s management interface to confirm if the SYN gets out?
Summary Next Steps
From FTD CLI, test outbound to 54.148.59.114:8305.
Confirm no egress firewall or NAT is blocking/modifying the traffic.
Validate DNS resolution and proxy settings.
Use packet captures (on FTD and upstream firewall).
Escalate with TAC and ask them to validate server-side listener on 8305.
