[GH-ISSUE #173] DPS network not routable from host #71

New issue

Closed

opened 2026-02-26 04:33:57 +03:00 by kerem · 3 comments

kerem commented

2026-02-26 04:33:57 +03:00

Owner

Originally created by @RomanHargrave on GitHub (Dec 23, 2019).
Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/173

What is Happening

This may be a docker issue; however, that would make little sense as there are many other networks - all of which are reachable from the host.

The network created by DPS is not routable from the host system. While the host bridge device is assigned an IP address and routing entries for the bridge are present on the host, traffic in to the DPS network vanishes, never to be seen again.

This effectively prevents DPS from working in any way, shape, or form.

What is expected

DPS network should be routable, or DPS should not use the DPS network address in resolv.conf

Steps to Reproduce

Start DPS, wait a moment. Check that the DPS network is connected to the DPS container. You should see that DPS is using it's address for the DPS bridge network in resolv.conf instead of it's address on the default bridge network.

Details

Specs:

OS: Debian Buster
Docker Version: 19.03.5
DPS Version: 2.18.1
DPS Log

Network Configurations:

Default bridge

[
    {
        "Name": "bridge",
        "Id": "062e508f6faada9e5df88413aff4d0e69866776fbb69e1c0e3952b2634195327",
        "Created": "2019-12-23T15:01:47.842975472-06:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.17.0.0/16",
                    "Gateway": "172.17.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {},
        "Options": {
            "com.docker.network.bridge.default_bridge": "true",
            "com.docker.network.bridge.enable_icc": "true",
            "com.docker.network.bridge.enable_ip_masquerade": "true",
            "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
            "com.docker.network.bridge.name": "docker0",
            "com.docker.network.driver.mtu": "1500"
        },
        "Labels": {}
    }
]

DPS bridge

[
    {
        "Name": "dps",
        "Id": "19072f964b38b4d465c56e0a14a77a2e7a82fb77dd7d836219a85744a39fcce6",
        "Created": "2019-12-23T14:56:43.768737507-06:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.157.0.0/16",
                    "IPRange": "172.157.5.3/24",
                    "Gateway": "172.157.5.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": true,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            "1b9d95f195ae39ed697506481faf5af5190584a1e71728a71ea32b4a6304b833": {
                "Name": "deployment_memcached_1",
                "EndpointID": "237fec44ae66849ccf3c50e9f8e7790226a1960eafb3743f43e5b7b5e4f08a6a",
                "MacAddress": "02:42:ac:9d:05:00",
                "IPv4Address": "172.157.5.0/16",
                "IPv6Address": ""
            },
            "614ca1870340d9294fa3bf309f3e89a8f2211f67469003ccb95270f6ff2fa5db": {
                "Name": "deployment_portal_1",
                "EndpointID": "195d8255e99321e26a26792e73dcd03c91283d154617b4d8299602e8103b9eb2",
                "MacAddress": "02:42:ac:9d:05:03",
                "IPv4Address": "172.157.5.3/16",
                "IPv6Address": ""
            },
            "7800565aa28c709c1022ff39215e9a9d8ca0cc8fab56845cc73ee6f4d72531f7": {
                "Name": "deployment_api_1",
                "EndpointID": "69b8c81b327a2951084ce1c2ba51d244e6c7c5f809e3c6921ca092e17465a7a0",
                "MacAddress": "02:42:ac:9d:05:02",
                "IPv4Address": "172.157.5.2/16",
                "IPv6Address": ""
            }
        },
        "Options": {},
        "Labels": {
            "description": "this is a Dns Proxy Server Network",
            "version": "2.18.1"
        }
    }
]

Originally created by @RomanHargrave on GitHub (Dec 23, 2019). Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/173 ### What is Happening *This may be a docker issue; however, that would make little sense as there are many other networks - all of which are reachable from the host.* The network created by DPS is not routable from the host system. While the host bridge device is assigned an IP address and routing entries for the bridge are present on the host, traffic in to the DPS network vanishes, never to be seen again. This effectively prevents DPS from working in any way, shape, or form. ### What is expected DPS network should be routable, or DPS should not use the DPS network address in resolv.conf ### Steps to Reproduce Start DPS, wait a moment. Check that the DPS network is connected to the DPS container. You should see that DPS is using it's address for the DPS bridge network in `resolv.conf` instead of it's address on the default bridge network. ### Details **Specs:** - OS: Debian Buster - Docker Version: 19.03.5 - DPS Version: 2.18.1 - [DPS Log](https://github.com/mageddo/dns-proxy-server/files/3996303/dps.log) **Network Configurations:** _Default bridge_ ```json [ { "Name": "bridge", "Id": "062e508f6faada9e5df88413aff4d0e69866776fbb69e1c0e3952b2634195327", "Created": "2019-12-23T15:01:47.842975472-06:00", "Scope": "local", "Driver": "bridge", "EnableIPv6": false, "IPAM": { "Driver": "default", "Options": null, "Config": [ { "Subnet": "172.17.0.0/16", "Gateway": "172.17.0.1" } ] }, "Internal": false, "Attachable": false, "Ingress": false, "ConfigFrom": { "Network": "" }, "ConfigOnly": false, "Containers": {}, "Options": { "com.docker.network.bridge.default_bridge": "true", "com.docker.network.bridge.enable_icc": "true", "com.docker.network.bridge.enable_ip_masquerade": "true", "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0", "com.docker.network.bridge.name": "docker0", "com.docker.network.driver.mtu": "1500" }, "Labels": {} } ] ``` _DPS bridge_ ```json [ { "Name": "dps", "Id": "19072f964b38b4d465c56e0a14a77a2e7a82fb77dd7d836219a85744a39fcce6", "Created": "2019-12-23T14:56:43.768737507-06:00", "Scope": "local", "Driver": "bridge", "EnableIPv6": false, "IPAM": { "Driver": "default", "Options": null, "Config": [ { "Subnet": "172.157.0.0/16", "IPRange": "172.157.5.3/24", "Gateway": "172.157.5.1" } ] }, "Internal": false, "Attachable": true, "Ingress": false, "ConfigFrom": { "Network": "" }, "ConfigOnly": false, "Containers": { "1b9d95f195ae39ed697506481faf5af5190584a1e71728a71ea32b4a6304b833": { "Name": "deployment_memcached_1", "EndpointID": "237fec44ae66849ccf3c50e9f8e7790226a1960eafb3743f43e5b7b5e4f08a6a", "MacAddress": "02:42:ac:9d:05:00", "IPv4Address": "172.157.5.0/16", "IPv6Address": "" }, "614ca1870340d9294fa3bf309f3e89a8f2211f67469003ccb95270f6ff2fa5db": { "Name": "deployment_portal_1", "EndpointID": "195d8255e99321e26a26792e73dcd03c91283d154617b4d8299602e8103b9eb2", "MacAddress": "02:42:ac:9d:05:03", "IPv4Address": "172.157.5.3/16", "IPv6Address": "" }, "7800565aa28c709c1022ff39215e9a9d8ca0cc8fab56845cc73ee6f4d72531f7": { "Name": "deployment_api_1", "EndpointID": "69b8c81b327a2951084ce1c2ba51d244e6c7c5f809e3c6921ca092e17465a7a0", "MacAddress": "02:42:ac:9d:05:02", "IPv4Address": "172.157.5.2/16", "IPv6Address": "" } }, "Options": {}, "Labels": { "description": "this is a Dns Proxy Server Network", "version": "2.18.1" } } ] ```

kerem closed this issue

2026-02-26 04:33:57 +03:00

kerem commented

2026-02-26 04:33:58 +03:00

Author

Owner

@RomanHargrave commented on GitHub (Dec 23, 2019):

Tested with 2.18.2 and still occurring. Details are the same.

@RomanHargrave commented on GitHub (Dec 23, 2019): Tested with `2.18.2` and still occurring. Details are the same.

kerem commented

2026-02-26 04:33:58 +03:00

Author

Owner

@mageddo commented on GitHub (Jan 3, 2020):

@RomanHargrave are you using

"dpsNetwork": true,
"dpsNetworkAutoConnect": true

Your issue is that you can't solve containers hostnames, right?

I tried to simulate the issue but still can resolve containers IPs, I'm using docker 19.03.1, I will try to upgrade docker.

nslookup postgres.dev
Server:		172.157.5.249
Address:	172.157.5.249#53

Non-authoritative answer:
Name:	postgres.dev
Address: 172.157.5.2
Name:	postgres.dev
Address: 172.157.5.2

Try shutdown DPS, disable these flags and disconnect all containers from DPS network

@mageddo commented on GitHub (Jan 3, 2020): @RomanHargrave are you using ``` "dpsNetwork": true, "dpsNetworkAutoConnect": true ``` ? Your issue is that you can't solve containers hostnames, right? I tried to simulate the issue but still can resolve containers IPs, I'm using docker `19.03.1`, I will try to upgrade docker. ``` nslookup postgres.dev Server: 172.157.5.249 Address: 172.157.5.249#53 Non-authoritative answer: Name: postgres.dev Address: 172.157.5.2 Name: postgres.dev Address: 172.157.5.2 ``` Try shutdown DPS, disable these flags and [disconnect all containers](http://mageddo.github.io/dns-proxy-server/latest/en/api/v1/networks/) from DPS network

kerem commented

2026-02-26 04:33:58 +03:00

Author

Owner

@RomanHargrave commented on GitHub (Jan 6, 2020):

I was unable to reproduce again. I'm writing this off as a docker fluke.

@RomanHargrave commented on GitHub (Jan 6, 2020): I was unable to reproduce again. I'm writing this off as a docker fluke.