Support dnsname plugin in networks created with internal flag (support isDefaultGateway)

[cfelder]

Currently dnsname plugins don't work when using internal

podman network create --internal

because the cni network is configured with "isGateway": false and "isDefaultGateway": false is hard coded to false in the following line

podman/libpod/network/create.go

Line 175 in e239bfa

bridge := NewHostLocalBridge(bridgeDeviceName, isGateway, false, ipMasq, ipamConfig)

This has the following result:

1. a new cni interface, e.g. cni-podman1 but with no ip address assigned to it
2. a dnsmasq running for that network (running on the host but not reachable from the new cni because of 1)

To resolve this issue it is possible to manually edit the cni network conflist file to use the following config:

"isGateway": true,
"isDefaultGateway": false,

Afterwards name resolution works and routing packets doesn't as expected because of the missing default route. Adding this route in the root container is prohibited (👍 ) as well.

$ ip route add default via 10.88.3.1
RTNETLINK answers: Operation not permitted

Furthermore all cni networks are currently using the same dns zone dns.podman which is problematic when using multiple cni's in one container. It would be better to have different zones for different networks or to allow explicitly setting the name of the zone.

I am not sure you want to change the defaults because of backward compatibility but it would be nice to set isGateway to true and add a isDefaultGateway flag here which is set to false

podman/libpod/network/create.go

Lines 147 to 150 in e239bfa

	if options.Internal {
	isGateway = false
	ipMasq = false
	}

[cfelder]

CC: @Luap99 and thanks for your help on irc.

[Luap99]

I guess this would be a good candidate for a network option after #8457 is merged

[Luap99]

Maybe something like podman network create --opt defaultGateway=false

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@Luap99 Any progress on this? @cfelder Does the suggested fix work for you? Interested in opening a PR to implement it?

[Luap99]

I did more testing and it looks like setting isGateway to true for a internal network is not secure at all. The default route is always added. The isDefaultGateway option doesn't do anything since it defaults to false.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@Luap99 can we close this issue now?

[Luap99]

Yes we cannot support this with the current dnsname architecture. We now print a warning if you create a internal network with the dnsname plugin.

[w4tsn]

Is there any workaround for this? As I understand, it's currently not possible to use dns name resolution for rootful containers in a cni network created as "internal", right?

So how to address a container from another container on the same network but without using pods, if the IP is assigned in an unpredictable way?

I'm asking because I have two rootful containers in an internal network and one of them is supposed to access a port on the other but the name resolution fails and I can't use a fixed IP address because A) the IP address of rootful containers can't be fixed (right?) B) I'm trying to get docker-compose working which in turn allows setting the IP address of those containers which is not supported right now by the podman API socket I guess? I opened an issue about that specifically #10585