Routing issues (Docker on Proxmox) from one container to another

Hi,
I´m using a Proxmox host with a docker installation as a VM. The ports 80 and 443 from the proxmox are redirect to docker vm. In docker I´m using traefik as a reverse proxy. Behind traefik I´ve got a nextcloud and a collabora container. Both containers have their public dns names and I could reach both from outside (traefik does his job well). But the containers can´t communicate from one container to another with their FQDN.

From Nextcloud-CT to Collabora-CT I could resolve the dns name with the public ip address. But with traceroute I could see that it goes via docker host to proxmox host and not to the other container.

> traceroute doc.XXX.de
traceroute to doc.XXX.de (XXX.XXX.XX.XX), 30 hops max, 60 byte packets
 1  172.18.0.1 (172.18.0.1)  0.060 ms  0.019 ms  0.022 ms
 2  server.XXX.de (XXX.XXX.XX.XX)  0.092 ms  0.065 ms  0.051 ms

Is there any chance to use public dns names from one container to another?
Thanks and bye,
cntrlc

Docker doesn’t care if the url uses a public fqdn, or a service name within the same container network or directly uses the published ports on the node.

May I ask what the traceroute ouput is supposed to illustrate? As I understand your VM runs in a natted network on the PVE host (therefore the forwarded ports)… Of course Traceroute will stop at the PVE host.

Are you sure the PVE NAT and your WAN-Router can handle NAT-Loopback/Hairpinning. Some ISP default routers do not support it.

Ok, let me explain. PVE host has public ip address - let me say 1.1.1.1 and a private ip address 192.168.0.1. Docker host runs at a private subnet and has the ip address 192.168.0.10. The both docker container for nextcloud and collobora have dns entries with the public ip address of the PVE host - 1.1.1.1. So the traceroute is right - it resolve the dns name to the public ip address of the PVE host. But it reroute it from container to docker to container.
Now to the nextcloud/collobora problem: the FQDN have to be reachable under this FQDN from one docker container and from external. I could only configure one URL and this have to be the FQDN.

Sorry, I couldn´t explain it better …

I am not able to get a clear understanding of the context the issue happens in, which is a precondition to think things thru.

I hope someone else will be able to make sense of the provided details and provide guidance.