Resolve IP Address Conflicts Between Internal Docker Network of SCG-Managed Devices or SCG Policy Manager

Summary: If the IP address of a device managed by a Secure Connect Gateway (SCG) is on the same subnet as the IP address of the docker0 virtual network interface of the Docker containers running on the gateway, or the bridge between the Docker containers, network communications between the client device, and the gateway fail. This behavior is also true of Secure Connect Gateways that have an IP address in the same subnet as the IP address of the docker0 network interface on the Policy Manager for the Secure Connect Gateway. This article contains a solution to resolve this network conflict. ...

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.

Symptoms

From the managed device with an IP address on the same subnet as the virtual network adapter docker0 or the Docker bridge between the containers:
  • Attempts to add a device to a gateway fail
  • Gateway does not respond to ping requests 
  • Gateway does not respond to telnet requests 
  • No evidence of communication attempts appears in gateway logs 
Similarly, from the SCG with an IP address on the same subnet as the virtual network adapter docker0 on the Policy Manager for Secure Connect Gateway:
  • Attempts to connect a gateway to a Policy Manager fail.
  • From Gateway, Policy Manager does not respond to ping requests. 
  • From Gateway, Policy Manager, does not respond to telnet requests over port 8443. 
  • No evidence of communication attempts appears in gateway or Policy Manager logs. 

Cause

The Docker instance running on the Secure Connect Gateway and the Policy Manager use the IP address 172.17.0.1 for the internal network interface, docker0. Devices on the same subnet conflict with the docker0 network interface in the context of the Docker containers running on the Secure Connect Gateway and the Policy Manager for Secure Connect Gateway. There is no other sign of this network conflict as it does not affect communications between other devices on the same subnet outside of the gateway or the policy manager.

If a device to be managed by the gateway should happen to have an IP address on the same subnet as the Docker instance on the gateway, there is a network conflict that prevents the device from any communications with the gateway.

In the context of the Policy Manager, if a Secure Connect Gateway to be managed by a Policy Manager server should have the same IP address as the docker0 interface, a network conflict exists, and the gateway cannot communicate with the Policy Manager.

Resolution

Note: The solution is to modify the IP address of the docker0 interface so that it is not on the same network as devices that are managed by the Secure Connect Gateway, and for the Policy Manager, so that the docker0 interface does not have an IP address on the same subnet as the Secure Connect Gateway. The procedure below applies to the docker0 network interface on both the Secure Connect Gateway the Policy manager for the Secure Connect Gateway (SCG) 5.x and Policy Manager for SCG 5.x.
 
  1. Log in to the Secure Connect Gateway or Policy Manager for Secure Connect Gateway using SSH or virtual machine console, as root.
  2. Confirm the IP address of the docker0 virtual network adapter:
# ifconfig
Output appears substantially similar to that shown below (hardware address omitted):
docker0  Link encap:Ethernet  HWaddr <removed> 

               inet addr:172.17.0.1  Bcast:172.17.255.255  Mask:255.255.0.0 

               UP BROADCAST MULTICAST  MTU:1500  Metric:1 

               RX packets:0 errors:0 dropped:0 overruns:0 frame:0 

               TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 

               collisions:0 txqueuelen:0 

               RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
  1. If you have a device that is using that same subnet in the IP address, that device cannot communicate with the gateway.
To make changes:
# cd /etc/docker
  1. Read the file to see the original contents before editing. It looks substantially similar to this:
# cat /etc/docker/dockerdCfg.json 
{ 
  "hosts" : ["unix:///var/run/docker.sock","tcp://0.0.0.0:2375"], 
  "insecure-registries" : ["127.0.0.1:9443","localhost:9443"] 
} 
  1. Back up the file you are about to edit:
cp dockerdCfg.json dockerdCfg.json.<year.month.date>
  1. Edit the file with vi:
# vi /etc/docker/dockerdCfg.json 
{ 

  "hosts" : ["unix:///var/run/docker.sock","tcp://0.0.0.0:2375"], 
  "insecure-registries" : ["127.0.0.1:9443","localhost:9443"],
  "bip": "10.10.10.1/24"  

} 

Note the following:

1. A comma must be inserted at the end of the 2nd line, after 9443"]
2. The bip line should be typed exactly as you see it, with an IP address and subnet mask of your choosing, with a subnet that does not conflict with any devices on your network that will be managed by the gateway.
3. The bip line sets the IP address of the internal docker network interface identified as "docker0".
3. For readability, the first quote mark on the bip line should line up with the previous line and quote mark.

After edits are complete, run:

# systemctl restart docker

Run ifconfig again to verify the IP address of the docker0 network adapter. 

----

The remaining steps below should not be necessary in most cases. If after completing the above steps, you still do not have connectivity, continue with the steps below.

The SAE to SRS Network Bridge

In this section, we will modify the Docker bridge between the sae and srs containers.

Change BridgeSubnet value in esrshost.conf, modify this file below command:
vi /etc/esrshost.conf

Now we will change BridgeSubnet value with the desired IP address.
See the example below:

IpAddress=xx.xx.xx.xxx
MacAddress=xx:xx:xx:xx
TimeZone=US/Central
HypervisorType="VMware Virtual Platform"
OperatingSystem="SUSE Linux Enterprise Server xx SPx"
Environment=INTPROD
HostName=linux
Version=x.xx.xx.xx
BridgeSubnet=172.28.0.1/29
OSPatchVersion=x

Ensure to Save the above file, you can use.

List the bridges:

docker network ls

# docker network ls
NETWORK ID     NAME             DRIVER    SCOPE
aa670bac1703   bridge           bridge    local
1521cf7b980b   host             host      local
b246dde1c191   none             null      local
d0dc3ac05fc4   sae-srs-bridge   bridge    local

Now we will modify the sae-srs-bridge by disconnecting it, removing it, and replacing it.

Disconnect the sae-srs-bridge in both directions:
docker network disconnect sae-srs-bridge esrsde-app
docker network disconnect sae-srs-bridge saede-app
docker network disconnect sae-srs-bridge esrsalert-app

Remove the bridge:
docker network rm sae-srs-bridge

Recreate the bridge with the desired IP address:
docker network create --driver bridge --subnet <new IP address>/<subnet mask> --opt com.docker.network.bridge.name=sae-srs-bridge sae-srs-bridge

See the example below:
docker network create --driver bridge --subnet 172.28.0.1/29 --opt com.docker.network.bridge.name=sae-srs-bridge sae-srs-bridge

Or, to use default IP, define by name only, example:
docker network create --driver=bridge sae-srs-bridge

Once the network bridge has been created, connect each container to the sae-srs-bridge:
docker network connect sae-srs-bridge esrsde-app
docker network connect sae-srs-bridge saede-app
docker network connect sae-srs-bridge esrsalert-app

Verify your work with the following command:
docker network inspect sae-srs-bridge

Review the output by checking on the following fields:

 "Config": [
                {
                    "Subnet": "172.18.0.1/29"
                }
            ]
        },

 "IPv4Address": "172.18.0.2/29",

run ifconfig again to verify the IP address assigned to docker0.

When the edits are complete, restart the Docker containers:

# systemctl restart docker

Test the new configuration by adding a device to the gateway that previously could not communicate with the gateway. Then open a browser to connect to the gateway. Navigate to Device Management > View to confirm that the new device has been registered.

Additional Information

The Policy Manager for Secure Connect Gateway has only one container, the Policy Manager.

If you encounter the following error:
unable to configure the Docker daemon with file /etc/docker/dockerdCfg.json: the following directives are specified both as a flag and in the configuration file: bip: (from flag: 172.17.0.1/24, from file: 192.168.48.1/24)
This is a configuration conflict, Bridge IP is already defined in /etc/sysconfig/docker;

In the file /etc/sysconfig/docker, remove flag:
--bip=172.17.0.1/24
From file:
/etc/sysconfig/docker 
## Path           : System/Management
## Description    : Extra cli switches for docker daemon
## Type           : string
## Default        : ""
## ServiceRestart : docker
#
DOCKER_OPTS="--config-file /etc/docker/dockerdCfg.json --bip=172.17.0.1/24"

Affected Products

Secure Connect Gateway, Secure Connect Gateway, Secure Connect Gateway - Virtual Edition
Article Properties
Article Number: 000197558
Article Type: Solution
Last Modified: 16 شعبان 1447
Version:  9
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.