Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[openvpn] ERROR: could not find an available, non-overlapping IPv4 address pool among the defaults to assign to the network #418

Closed
1 task done
brylie opened this issue Aug 25, 2018 · 11 comments

Comments

@brylie
Copy link

brylie commented Aug 25, 2018

  • This is a bug report

Description of the issue

When running docker-compose up while connected to an OpenVPN proxy, I get the following error:

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

Several other people have experienced this issue, and discussed it on StackOverflow

Context information (for bug reports)

docker-compose version 1.21.2, build a133471
docker-py version: 3.3.0
CPython version: 3.6.5
OpenSSL version: OpenSSL 1.0.2o  27 Mar 2018
Client:
 Version:           18.06.0-ce
 API version:       1.38
 Go version:        go1.10.3
 Git commit:        0ffa825
 Built:             Wed Jul 18 19:09:56 2018
 OS/Arch:           linux/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.06.0-ce
  API version:      1.38 (minimum version 1.12)
  Go version:       go1.10.3
  Git commit:       0ffa825
  Built:            Wed Jul 18 19:07:55 2018
  OS/Arch:          linux/amd64
  Experimental:     false

Steps to reproduce the issue

  1. connect to an OpenVPN proxy
  2. run docker-compose up in a project
  3. rage quit

Observed result

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

Expected result

Docker compose should be able to find an IPv4 address pool

Additional information

OS: Kubuntu 18.04

@wanjohi
Copy link

wanjohi commented Sep 21, 2018

From what I've read, and testing with vpn and docker, this seems to be the issue push "redirect-gateway". Which causes this:

--redirect-gateway [local] [def1]
(Experimental) Automatically execute routing commands to cause all outgoing IP traffic to be redirected over the VPN.
This option performs three steps:

(1) Create a static route for the --remote address which forwards to the pre-existing default gateway. This is done so that (3) will not create a routing loop.

(2) Delete the default gateway route.

(3) Set the new default gateway to be the VPN endpoint address (derived either from --route-gateway or the second parameter to --ifconfig when --dev tun is specified).

When the tunnel is torn down, all of the above steps are reversed so that the original default route is restored.

Add the local flag if both OpenVPN servers are directly connected via a common subnet, such as with wireless. The local flag will cause step 1 above to be omitted.

Add the def1 flag to override the default gateway by using 0.0.0.0/1 and 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of overriding but not wiping out the original default gateway.

Using the def1 flag is highly recommended, and is currently planned to become the default by OpenVPN 2.1.

@Dowwie
Copy link

Dowwie commented Mar 7, 2019

Same experience with Debian Stretch

@dennybaa
Copy link

This is has been a while around, even in ubuntu 16.04 I was experiencing it.

@cpuguy83
Copy link
Collaborator

Docker tried to automatically assign a /24 to a network and it could not find an available one.

You need to manually select a subnet as part of your network options for the service.

You can do this either as an option on network create or tell docker about the default addresss pools, which is a daemon level option. moby/moby#36396

This is not a bug.

@thaJeztah
Copy link
Member

Let me close this per the discussion above, but feel free to comment after I closed

@myspotontheweb
Copy link

myspotontheweb commented May 10, 2019

My recommended work-around is to create a network utilizing an unused private address range on your machine:

docker network create localdev --subnet 10.0.1.0/24

Configure docker compose to use this as an external network. Either adding the following to the compose file or the override file as shown:

$ cat docker-compose.override.yml
version: '3'
networks:
  default:
    external:
      name: localdev

@aratic
Copy link

aratic commented Jan 27, 2020

@myspotontheweb 's answer solved my problem, while I'm using ExpressVPN, a commercially hosted VPN vendor, seems that tunnel occupied the default 172 subnet of docker, thus any container got better to specify a dedicated subnet

@oviniciusfeitosa
Copy link

oviniciusfeitosa commented Feb 17, 2021

Docker unable to access from VPN

  • Reset your networks to set correct subnet ip
docker network prune

Using Docker Compose + OpenVPN

Set the content below inside your docker-compose file:

networks:
  default:
    driver: bridge
    ipam:
      config:
        - subnet: 10.10.1.0/24

@KES777
Copy link

KES777 commented May 20, 2022

@cpuguy83 This is a bug. If route 192.168.0.0/16 exists on the system this does not mean that 192.168.129.0/28 is busy on this host. See detailed here

I can not assign network manually because when I run same compose file with different project name docker-compose -p proj2 it tries to use that assigned manually network and fail.

@robbie-cahill
Copy link

In the latest docker version, I no longer get this error. Instead when i'm connected to VPN, docker-compose simply hangs after the Attaching to <my container> output. If I disconnect VPN, start the container and reconnect I can work around it.

The previous error ERROR: could not find an available, non-overlapping IPv4 address was more helpful, I had to do some debugging to figure out my issue was VPN related. Now it just hangs with no output.

@KES777
Copy link

KES777 commented Sep 6, 2022

@cipher-code: your local IP address 127.0.0.1 is overlapping with default route 0.0.0.0/0.

Is is OK to prohibit assign 127.0.0.1 to your host?

(eg. Docker should not restrict usage of 10.0.0.1/24 locally if your system has route to 10.0.0.0/8 network)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests