Skip to content

Documentation Improvement: Connecting from Docker Bridge Network Requires ips.allow Update #248

@weklund

Description

@weklund

(Sorry this doesn't really fit in either template, more of a documentation suggestion)

I encountered an issue when trying to connect to the IBEAM gateway from a service running within Docker Compose using a bridge network. My application couldn't reach the gateway, and it took considerable debugging to identify the cause.

Problem:

The default customconfig.yaml provided in the repository (or documentation examples) typically includes 172.17.0.* in the ips.allow list, which covers the default Docker bridge network (docker0). However, if a user creates a custom bridge network (e.g., via docker network create my_bridge_network or implicitly through Docker Compose), this network often gets assigned a different subnet, such as 172.18.0.0/16.

Because the IBEAM gateway restricts connections based on the ips.allow list, connections from containers on this custom bridge network were denied.

Example customconfig.yaml section:

ips:
  allow:
    - 10.*
    - 192.*
    - 131.216.*
    - 172.17.0.* # Default docker bridge
    # - 172.18.0.* # Needed for custom bridge network (e.g., from Docker Compose)
    - 127.0.0.1
    - x.x.x.x
  deny:
    - 0.0.0.0/0 # deny all others

Solution:

The solution was to identify the IP range of my custom bridge network (which was 172.18.0.* in my case) and add it to the ips.allow list in customconfig.yaml.

Suggestion:

While this information might be discoverable, it wasn't immediately obvious. I suggest explicitly mentioning this potential issue in the documentation (perhaps the wiki page covering Gateway Configuration). It would be helpful to advise users that if they are using custom Docker networks (especially bridge networks created via Docker Compose), they need to check the network's IP range (docker network inspect <network_name>) and add the corresponding pattern (e.g., 172.18.0.* or similar) to the ips.allow list in their customconfig.yaml.

This clarification could save other users debugging time.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions