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
- 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.
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.
- Log in to the Secure Connect Gateway or Policy Manager for Secure Connect Gateway using SSH or virtual machine console, as root.
- 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)
- 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
- 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"]
}
- Back up the file you are about to edit:
cp dockerdCfg.json dockerdCfg.json.<year.month.date>
- 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:
In the file
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/24From 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 EditionArticle 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.