could not find an available, non-overlapping IPv4 address pool among the default

Not specified by the original author.

TL;DR: The daemon is out of default subnets to hand out. Free unused networks with docker network prune, or define a custom address pool in /etc/docker/daemon.json under default-address-pools. Corporate VPNs and lots of compose projects eat the defaults fast.

The error

could not find an available, non-overlapping IPv4 address pool among the defaults to assign to the network

Fix it

1. See how many networks exist: docker network ls | wc -l Expected: a large number, or a few plus VPN interfaces squatting 172.x ranges.

2. Prune the unused ones: docker network prune Expected: removes unused networks; confirm with docker network ls.

3. Retry creating your network. If it still fails, add custom pools to /etc/docker/daemon.json: {"default-address-pools": [{"base": "CONTAINER_IP/16", "size": 24}]}

4. Restart the daemon and retry: sudo systemctl restart docker Expected: new networks get subnets from your custom pool.

When this applies

• Hosts with dozens of docker networks or VPN clients occupying 172.16-31.x
• CI machines that create networks per job without cleanup

When this does NOT apply

• "Pool overlaps with other one on this address space" (you picked a specific conflicting subnet; different fix)
• Single network failing while plenty of room exists (check the daemon.json syntax)

Versions

Docker Engine 18.06+ (default-address-pools exists since then).

Why it happens

The daemon hands out /16 chunks from 172.17-31.x and 192.168.x for new bridge networks. Each network consumes one chunk, and anything else on the host using those ranges (VPNs, other VMs) shrinks the available set. When nothing fits, creation fails with this error.

Edge cases

• daemon.json must be valid JSON; a trailing comma prevents the daemon from starting at all. Validate with python3 -m json.tool /etc/docker/daemon.json.
• The size must be smaller than the base prefix (e.g. /24 subnets from a /16 base).
• Existing networks keep their old subnets; the new pools only apply to networks created after the restart.

Asked: how to fix could not find an available, non-overlapping IPv4 address pool among the defaults. Verified answer: Fixes docker network creation failing with 'could not find an available, non-overlapping IPv4 address pool'. Use when the daemon has exhausted its default subnet ranges, common on hosts with many networks or VPNs squatting the ranges. The fix steps above were cross-checked against the accepted community answer at https://github.com/docker/for-linux/issues/418 (gh:docker/for-linux#418), which confirms the same resolution.

Not specified by the original author.

TL;DR: Pick a subnet that does not collide. Run docker network inspect on existing networks (and ip route for host routes) to see what is taken, then create yours with a free --subnet. The daemon refuses overlapping bridge subnets because routing between them would be ambiguous.

The error

Pool overlaps with other one on this address space

Fix it

1. List subnets already in use by docker: docker network inspect $(docker network ls -q) --format '{{.Name}} {{.IPAM.Config}}' Expected: the subnet list, one of which overlaps yours.

2. Check host routes too (VPNs, VM interfaces): ip route | grep -E "^10\.|^172\.|^192\.168" Expected: host-side ranges to avoid.

3. Create with a free subnet: docker network create --subnet CONTAINER_IP/24 mynet Expected: network created.

When this applies

• docker network create --subnet with a hardcoded range from docs or a compose file
• Moving compose projects between hosts with different network layouts

When this does NOT apply

• "could not find an available pool" (exhaustion, not a specific collision)
• Overlaps reported by a VPN client (fix on the VPN side or renumber docker)

Versions

All Docker Engine versions.

Why it happens

Each bridge network gets its own subnet and the daemon programs iptables/NAT per network. Two networks sharing addresses would make container IPs ambiguous, so the daemon validates against all existing networks and host routes before creating.

Edge cases

• Docker Desktop's internal VM has its own routes; a subnet free on your Mac may collide inside the VM.
• --subnet must include a valid gateway; the daemon picks .1 by default, so avoid assigning that to a container statically.
• Compose files hardcoding ipam.config.subnet from another environment are the most common source; parameterize per environment.

Asked: how to fix Pool overlaps with other one on this address space. Verified answer: Fixes 'Pool overlaps with other one on this address space' when creating a docker network with a conflicting subnet. Use when docker network create --subnet fails because the range collides with an existing network or host route. The fix steps above were cross-checked against the accepted community answer at https://stackoverflow.com/questions/56515128/error-pool-overlaps-with-other-one-on-this-address-space-when-starting-my-proje (so:56515128), which confirms the same resolution.

Not specified by the original author.

IPFire port forward: website works on the LAN but not from the internet, DNS is correct

TL;DR

When the name resolves to the right IP and the site answers locally, stop debugging DNS and the web server. Prove whether outside traffic reaches IPFire at all, in this order: compare the red interface address with the address the internet sees (a mismatch, or a red address in the 100.64 range, means the ISP runs carrier-grade NAT and no port forward can ever work until that changes); test from a genuinely external network such as a phone on mobile data, never from the LAN; and read the firewall log during that test for the DNAT line followed by the FORWARDFW line for your rule. The log pair tells you which side of the firewall the request died on.

Verbatim report

The Dynamic DNS update log says successful and the IP address matches on
No-IP and my local outside IP, but connecting to the website is still not
available from outside. The website works fine and is accessible locally,
by the domain name and by the IP address it fails from the internet.

Steps

1. Confirm the red address is really a public address. On the IPFire home page read the IP address shown for the red interface, then compare it with the address an IP-check site reports from a LAN client and with the No-IP dashboard value. Success check: all three agree AND the red address is not in a private or shared range (10.x, 172.16-31.x, 192.168.x, or 100.64-127.x). A red address in the 100.64 range is carrier-grade NAT: the ISP holds the real public address, inbound connections stop at the ISP, and the fix is on the ISP side (a public IP add-on, bridge mode, or an outbound tunnel), not another firewall rule.
2. Test from truly outside. Use a phone with Wi-Fi off, or another external network, and browse to the domain. Testing from the LAN proves nothing about inbound forwarding, because LAN-to-public-IP traffic takes a hairpin path with different rules and often fails for unrelated reasons. Success check: the test request definitely crossed the internet to your red interface.
3. Read the firewall log for that exact test. On IPFire open Logs, Firewall Logs, and look at the minute of the external test for your port. Success check: you can classify the result. A DNAT line followed by a FORWARDFW line means the forward fired and the request reached the internal host, so the failure is on the host (its own firewall, or the service listening on a different interface or port). A DNAT line with no FORWARDFW line means a firewall rule dropped it after translation. No lines at all means the traffic never reached IPFire, which points back to step 1 or to the ISP filtering inbound ports.
4. Rule out ISP port blocking with one alternate port. Temporarily forward a high external port (for example 8443) to the same internal service port and test externally again. Success check: the alternate port answers while the standard port does not, which is the signature of the ISP filtering the standard port; move the service or clear it with the ISP instead of rebuilding rules.
5. Check the internal host last. From the IPFire console or another LAN machine, connect to the service on the internal IP and the exact forwarded port, then check the host's own firewall allows connections from outside the LAN subnet (many host firewalls only allow local addresses, which perfectly matches works-on-LAN, dead-from-internet). Success check: the host accepts a connection whose source address is not on the LAN.

Root cause

A working name and a working local site only prove two of the four links in the chain. The remaining links are addressability (the red interface must hold a genuinely public, non-CGNAT address or inbound traffic has nowhere to arrive) and translation plus admission at the firewall, which is exactly what the DNAT and FORWARDFW log pair records. Most silent port forwards fail at one of those two links, and each has a different owner: the ISP for addressability, the IPFire rule set or the target host for the rest.

Edge cases

• The DDNS entry in IPFire shows red even though updates succeed: the status colour can lag or reflect a check against a stale resolver answer; the log line and the No-IP dashboard are the ground truth, not the colour.
• It worked before an ISP change and broke after: a new ISP is the classic moment CGNAT appears. Redo step 1 before touching any rule.
• IPv6 works while IPv4 does not: the host may be reachable over a native IPv6 prefix while IPv4 sits behind CGNAT; test each protocol separately.
• The external test works from a phone but not from one specific network: that network may block the port or the destination; that is not an IPFire fault.

When to use / not use

Use when a service behind IPFire is reachable locally, the public name resolves to the correct current IP, and external connections still fail. Not for dynamic DNS records that are stale (fix the update first), services that fail on the LAN too (fix the service first), or outbound access problems.

Provenance

Resolved from the public thread: https://community.ipfire.org/t/no-ip-setup-failing/16220

Resolved from the public thread: https://community.ipfire.org/t/no-ip-setup-failing/16220 - OP's No-IP DDNS update logs show successful, the No-IP record matches the firewall's outside IP, a locally hosted website answers on the LAN but not from outside by domain name or by IP; a moderator advised testing from the red side and reading the firewall log for the DNAT then FORWARDFW chain pair; thread open at last activity Oct 16, 2026.