Docker DNS issue | Pterodactyl® | Page 1

south barn Oct 21, 2024, 10:50 PM

#

I managed to install everything and wings is running fine with out any issues (I see the green heart and theres no server side or client side errors with wings or the nodes) but when I try to start my bungee cord proxy server I see it says the following.

21:42:25 [INFO] Attempting to Jenkins download module reconnect_yaml v1879
21:42:25 [WARNING] Failed to download: UnknownHostException : ci.md-5.net @ sun.nio.ch.NioSocketImpl:567

When I try to connect I also get a TCP Shield error saying [SEVERE] Caused by: java.net.UnknownHostException: google.com. Now because of this on my main dedicated server I ran curl google.com and it worked fine but when I did docker ps and then entered the container shell to run the same command I get an error saying it cant resolve the domain. This means that for some reason theres a networking issue with docker but not with my main machine.

I also checked the fire wall and ensured ports for 25565 are open for both TCP and UDP but still for some reason dns queries and such from the docker container do not work while it works fine from my main machine where should I look to resolve this issue?

haughty crypt Oct 21, 2024, 11:26 PM

#

south barn I managed to install everything and wings is running fine with out any issues (I...

https://pterodactyl.io/panel/1.0/troubleshooting.html#containers-don-t-have-internet-probably-a-dns-issue

south barn Oct 22, 2024, 3:46 AM

#

haughty crypt <https://pterodactyl.io/panel/1.0/troubleshooting.html#containers-don-t-have-int...

That does not do anything all it did was suggest I change my dns server. I ran resolvectl status then saw the dns ip and then changed my config file from the original cloud flare dns to the one the command above yeilded and I still have the same issue where my docker container's DNS does not work.

haughty crypt Oct 22, 2024, 4:09 AM

#

Did you restart Wings and then the server after changing DNS servers?

dim valeBOT Oct 22, 2024, 4:09 AM

#

Simple! 😘

systemctl restart wings

south barn Oct 22, 2024, 4:17 AM

#

haughty crypt Did you restart Wings and then the server after changing DNS servers?

of course restarted wings and restarted each server including the proxy which still gets the same error

haughty crypt Oct 22, 2024, 4:34 AM

#

Please show the relevant section of your Wings config.yml file (before and after) and the commands/results that showed you what DNS server your host machine is using.
Additionally, run docker container inspect (server_uuid) and look under DNS to make sure it's using the new ones you configured.

south barn Oct 22, 2024, 6:12 AM

#

@haughty crypt Ok I did everything you asked I even tried manually restarting the docker containers but it is still giving the same errors when I restart my proxy server. Firstly, here is my dns server.

root@ns5030372:~# resolvectl status
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (enp8s0f0)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 2001:41d0:3:163::1
       DNS Servers: 2001:41d0:3:163::1 213.186.33.99

Link 3 (enx76eab294ad83)
    Current Scopes: none
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 4 (enp8s0f1np1)
    Current Scopes: none
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 5 (docker0)
    Current Scopes: none
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 6 (pterodactyl0)
    Current Scopes: none
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 106 (veth8e4e21f)
    Current Scopes: none
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 112 (veth41297e4)
    Current Scopes: none
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

#

Now here is the latter half of my config that shows the dns server.

docker:
  network:
    interface: 172.18.0.1
    dns:
    - 213.186.33.99
    name: pterodactyl_nw
    ispn: false
    driver: bridge
    network_mode: pterodactyl_nw
    is_internal: false
    enable_icc: true
    network_mtu: 1500
    interfaces:
      v4:
        subnet: 172.18.0.0/16
        gateway: 172.18.0.1
      v6:
        subnet: fdba:17c8:6c94::/64
        gateway: fdba:17c8:6c94::1011
  domainname: ""
  registries: {}
  tmpfs_size: 100
  container_pid_limit: 512
  installer_limits:
    memory: 1024
    cpu: 100
  overhead:
    override: false
    default_multiplier: 1.05
    multipliers: {}
  use_performant_inspect: true
  userns_mode: ""
  log_config:
    type: local
    config:
      compress: "false"
      max-file: "1"
      max-size: 5m
      mode: non-blocking
throttles:
  enabled: true
  lines: 2000
  line_reset_interval: 100
remote: https://panel.example.com
remote_query:
  timeout: 30
  boot_servers_per_page: 50
allowed_mounts: []
allowed_origins: []
allow_cors_private_network: false
ignore_panel_config_updates: false

#

Then I ran the docker ps to view my containers.

root@ns5030372:~# docker ps
CONTAINER ID   IMAGE                               COMMAND                  CREATED         STATUS         PORTS                                                                NAMES
c12272fb842c   ghcr.io/pterodactyl/yolks:java_21   "/__cacert_entrypoin…"   3 minutes ago   Up 3 minutes   myIP:25565->25565/tcp, myIP:25565->25565/udp   270edfff-bb65-43f8-bf23-a4c94034793z
ea1f4ad31563   ghcr.io/pterodactyl/yolks:java_21   "/__cacert_entrypoin…"   3 minutes ago   Up 3 minutes     myIP:25570->25570/tcp, myIP:25570->25570/udp   da3dae2e-2bf8-4e37-8d0c-d90097cb98dz

Then I inspected each and scrolled down to the DNS section and saw it was correct.

           "Dns": [
                "213.186.33.99"
            ],

haughty crypt Oct 22, 2024, 6:27 AM

#

You could try Google's DNS, 8.8.8.8 and 8.8.4.4

south barn Oct 22, 2024, 7:16 AM

#

haughty crypt You could try Google's DNS, 8.8.8.8 and 8.8.4.4

I guess but I doubt thats the problem when I the dns server I am currently using works fine. What are other possible reasons for DNS and running curl commands would not resolve inside a container while working fine on the main machine?

south barn Oct 22, 2024, 3:44 PM

#

anyone have a solution?

haughty crypt Oct 22, 2024, 4:36 PM

#

Perhaps it's not DNS after all; are you able to reach IP addresses directly from inside the container?

south barn Oct 22, 2024, 4:45 PM

#

haughty crypt Perhaps it's not DNS after all; are you able to reach IP addresses directly from...

I dont think so if curl fails to resolve a domain? But I am not totally sure.

haughty crypt Oct 22, 2024, 4:46 PM

#

If you can resolve IPs directly, but not domains, you've confirmed it's a DNS issue.

If you can't resolve IPs either, it's a larger network issue.

south barn Oct 22, 2024, 4:47 PM

#

Ok let me try and if I cant curl ip's what should my next step be?

haughty crypt Oct 22, 2024, 4:50 PM

#

Double checking everything related to networking and firewalls for anything unusual. If it's a cloud machine, contact the host, say you can't get an Internet connection inside Docker containers, and ask if there are any special network settings they require.

south barn Oct 22, 2024, 4:55 PM

#

haughty crypt Double checking everything related to networking and firewalls for anything unus...

I can send you the main iptables if you would like to see them. I dont have ufw downloaded but I do have persistent-iptables downloaded but I cant seem to find any issues with my the tables when i looked

haughty crypt Oct 22, 2024, 4:58 PM

#

You can start ruling things out one at a time as well.

Rule out firewall by creating a temporary policy allowing all traffic

iptables -I FORWARD -j ACCEPT

Create a Docker container, see if it has internet
Create a Docker container on the pterodactyl_nw network and see if it has internet
Check your host machine's mtu, if it's not 1500 change the Wings one to match it, delete pterodactyl_nw and restart Wings

dim valeBOT Oct 22, 2024, 4:58 PM

#

Simple! 😘

systemctl restart wings

south barn Oct 22, 2024, 5:13 PM

#

haughty crypt You can start ruling things out one at a time as well. - Rule out firewall by c...

Why do you suggest I manually create a new container and then create a pterodactyl container instead of test the ones I already have? Is it because messing with current containers could cause corruption or something? Also what exactly do you mean by changing my hosts MTU?

📎 message_3.txt

south barn Oct 22, 2024, 6:10 PM

#

@haughty crypt I verified and no I can not resolve ips or domains inside the container so its not a plain DNS issue. Also I am fairly sure I have all of those ACCEPT statements do you see an issue with my other docker and forward chains in the ip tables I showed above? I did not change anything but I assume something has to be wrong.

haughty crypt Oct 22, 2024, 6:44 PM

#

There's no need to delve into iptables rules until you've verified you can't rule out the firewall. Run iptables -I FORWARD -j ACCEPT, see if the problem persists. If not, you can get rid of that rule by restarting the machine.

#

ip link show should typically show what mtu is set to for each interface.

south barn Oct 22, 2024, 7:01 PM

#

haughty crypt There's no need to delve into iptables rules until you've verified you can't rul...

What do you mean there is no reason to look into ip tables? Ip tables is where rules like iptables -I FORWARD -j ACCEPT would go which means we are devoling into ip tables. Also I have persistent-iptables installed so restarting will not remove said rule but I could always just manually delete it if that does not help. Also let me know if you see any issues with MTU's

root@ns5030372:~# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp8s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether d8:43:ae:89:70:f0 brd ff:ff:ff:ff:ff:ff
3: enx76eab294ad83: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 76:ea:b2:94:ad:83 brd ff:ff:ff:ff:ff:ff
4: enp8s0f1np1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether d8:43:ae:89:70:f1 brd ff:ff:ff:ff:ff:ff
5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
    link/ether 02:42:ba:11:9a:7e brd ff:ff:ff:ff:ff:ff
6: pterodactyl0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
    link/ether 02:42:67:74:8e:eb brd ff:ff:ff:ff:ff:ff
118: veth7bdb5c4@if117: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master pterodactyl0 state UP mode DEFAULT group default
    link/ether b2:cb:08:03:a3:29 brd ff:ff:ff:ff:ff:ff link-netnsid 1
120: vethb30b3a3@if119: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master pterodactyl0 state UP mode DEFAULT group default
    link/ether 9e:70:86:fd:05:84 brd ff:ff:ff:ff:ff:ff link-netnsid 0

haughty crypt Oct 22, 2024, 7:03 PM

#

I mean there's no reason to spend time assessing settings in the firewall when you can rule out the firewall as an issue in the space of seconds. I'm un-familiar with persistent-iptables, I assume you're right about that and would have to manually delete it.

mtu is the standard 1500, so that shouldn't be the issue.

south barn Oct 22, 2024, 7:18 PM

#

haughty crypt I mean there's no reason to spend time assessing settings in the firewall when y...

Wtf? How did that actually just fix it lmao. Also yea persistent-iptables is nice since it saves all of the edits you make to your fire wall. But how did adding that accept just make everything work when the before and after forward tables looks the same I dont understand. Do you see what the difference is also thanks a bunch cause its working now!

#

Chain FORWARD (policy DROP)
target     prot opt source               destination
DOCKER-USER  all  --  anywhere             anywhere
DOCKER-ISOLATION-STAGE-1  all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ufw-before-logging-forward  all  --  anywhere             anywhere
ufw-before-forward  all  --  anywhere             anywhere
ufw-after-forward  all  --  anywhere             anywhere
ufw-after-logging-forward  all  --  anywhere             anywhere
ufw-reject-forward  all  --  anywhere             anywhere

root@ns503037:~# iptables -L FORWARD --line-numbers
Chain FORWARD (policy DROP)
num  target     prot opt source               destination
1    DOCKER-USER  all  --  anywhere             anywhere
2    DOCKER-ISOLATION-STAGE-1  all  --  anywhere             anywhere
3    ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
4    DOCKER     all  --  anywhere             anywhere
5    ACCEPT     all  --  anywhere             anywhere
6    ACCEPT     all  --  anywhere             anywhere
7    ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
8    DOCKER     all  --  anywhere             anywhere
9    ACCEPT     all  --  anywhere             anywhere
10   ACCEPT     all  --  anywhere             anywhere
11   ACCEPT     all  --  anywhere             anywhere
12   ufw-before-logging-forward  all  --  anywhere             anywhere
13   ufw-before-forward  all  --  anywhere             anywhere
14   ufw-after-forward  all  --  anywhere             anywhere
15   ufw-after-logging-forward  all  --  anywhere             anywhere
16   ufw-reject-forward  all  --  anywhere             anywhere
17   ufw-track-forward  all  --  anywhere             anywhere

#

It just looked like it duplicated my accept statements in the same location i dont see why this fixed anything but ill take it lol

#Docker DNS issue