How to Troubleshoot Netcup VPS & Root Server Networking: AS197540 MTR, IPv6 fe80::1, MTU & VNC Recovery

If a syntax error in /etc/netplan/, a botched /etc/ssh/sshd_config edit, or an overly broad ufw/nftables rule cuts off SSH access, do not reinstall the server. Netcup’s Server Control Panel (SCP) provides two hardware-level out-of-band recovery mechanisms that operate completely independently of your guest OS network stack.

Your fastest option is the SCP "Screen" tab (HTML5 VNC Console), which attaches directly to the emulated QEMU VGA display and PS/2 keyboard of your running KVM instance. Even if eth0 is completely down (DOWN), you can log in on tty1 with your local console password, inspect journalctl -u systemd-networkd, or run sudo ufw disable. When using the VNC console on a German or US keyboard layout, avoid typing complex passwords blindly into the username prompt; test special characters at the login line first or use SCP’s virtual clipboard paste button. If you disabled local password login or the guest kernel failed to mount root (initramfs prompt), boot the SCP Rescue System instead and chroot into /dev/vda1:

• ▪ SCP "Screen" Tab (HTML5 VNC Console): Attaches directly to the emulated QEMU VGA display and PS/2 keyboard of your running KVM instance. If your root/sudo user has a local console password set, you can log in directly on tty1, run ip -br link, or flush firewall rules (sudo ufw disable).
• ▪ SCP "Media / Rescue System" Tab (Live Debian Netboot): If you disabled local password authentication or the guest kernel fails to boot (initramfs drop), activate the Rescue System in SCP. It boots your VM into a clean, networked Debian Live RAM disk and displays a temporary root SSH password in SCP, allowing you to mount /dev/vda1 and repair any file via chroot.

# 1. After activating Rescue System in SCP and connecting via SSH as root:
lsblk -f

# 2. Mount your primary Linux root filesystem (typically /dev/vda1 or /dev/vda2; /dev/sda1 on older SCSI profiles)
mkdir -p /mnt/sysroot
mount /dev/vda1 /mnt/sysroot

# 3. If your system uses a separate /boot or /boot/efi partition, mount it as well:
# mount /dev/vda15 /mnt/sysroot/boot/efi

# 4. Bind-mount virtual kernel filesystems and enter the chroot environment
for dir in /dev /dev/pts /proc /sys /run; do
  mount --bind "$dir" "/mnt/sysroot$dir"
done
chroot /mnt/sysroot /bin/bash

# 5. Inside chroot: inspect logs, fix /etc/netplan or /etc/ssh/sshd_config, or disable ufw
journalctl -b -1 -u systemd-networkd --no-pager
sshd -t
ufw disable

# 6. Exit chroot cleanly, unmount, and deactivate Rescue System in SCP
exit
umount -R /mnt/sysroot
sync

NAME    FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
vda
├─vda1  ext4   1.0         8b14c9a2-41e0-4d91-9b1a-7c30e192a401  192.4G    18% /mnt/sysroot

Two Netcup-specific Layer-2/Layer-3 pitfalls account for the vast majority of post-reboot and IPv6 connectivity failures.

First, when upgrading Debian (11 -> 12) or Ubuntu (22.04 -> 24.04), systemd-udevd predictable interface naming (net.ifnames=1) evaluates the PCI slot topology of the QEMU virtio-net adapter and frequently renames it from eth0 to ens3 (or enp0s3). If /etc/netplan/01-netcfg.yaml or /etc/network/interfaces hardcodes eth0 without matching the adapter’s hardware MAC address (match.macaddress), systemd-networkd waits for a non-existent eth0 device at boot and leaves the server offline.

Second, Netcup routes your dedicated /64 IPv6 subnet (e.g., 2a03:4000:xx:xxxx::/64) across the hypervisor bridge using the static link-local router address fe80::1. Unlike residential ISPs that broadcast continuous SLAAC Router Advertisements (RA), Netcup’s hypervisor bridge expects you to configure your /64 addresses statically with accept-ra: false and an explicit default route via: fe80::1 with on-link: true. If accept-ra: true is left enabled without a static fe80::1 route, IPv6 works for 10 to 15 minutes after reboot and then silently drops once the initial router lifetime expires.

# 1. Check exact interface name (eth0 vs ens3), operational state (UP/DOWN), and MAC address
ip -br link show

# 2. Check bound IPv4 and IPv6 addresses
ip -br addr show

# 3. Check IPv4 and IPv6 routing tables and confirm fe80::1 neighbor reachability
ip -4 route show
ip -6 route show
ip -6 neigh show dev "$(ip -4 route show default | awk '{print $5; exit}')"

eth0             UP             52:54:00:4a:8b:1c <BROADCAST,MULTICAST,UP,LOWER_UP>
default via fe80::1 dev eth0 proto static metric 1024 onlink pref medium
fe80::1 lladdr aa:bb:cc:dd:ee:ff router REACHABLE

network:
  version: 2
  renderer: networkd
  ethernets:
    primary_nic:
      match:
        macaddress: "52:54:00:4a:8b:1c"
      set-name: "eth0"
      dhcp4: true
      dhcp6: false
      accept-ra: false
      addresses:
        - "2a03:4000:61:a1b2::1/64"
      routes:
        - to: "::/0"
          via: "fe80::1"
          on-link: true
      nameservers:
        addresses:
          - 46.38.225.230
          - 46.38.252.230
          - 2a03:4000:0:1::e1e6
          - 1.1.1.1

Netcup operates autonomous system AS197540 (netcup GmbH), peering at major European and international internet exchanges (including DE-CIX Frankfurt, VIX Vienna, and AMS-IX Amsterdam) alongside upstream Tier-1/Tier-2 transit providers (such as Anexia AS42473, Arelion/Telia AS1299, NTT AS2914, and Cogent AS174).

When investigating suspected packet loss or elevated latency between your Netcup server and an end-user ISP, a one-way ping or traceroute is insufficient because BGP internet routing is almost always asymmetric: outbound packets from Nuremberg to a residential user might exit via DE-CIX peering, while return packets from the user’s ISP might enter via a congested transit handoff in Frankfurt or Vienna. Always collect a 100-packet report using mtr -rwzc 100 in both directions (Server -> Client IP and Client -> Server IP).

When reading mtr output, pay close attention to the difference between Control Plane Policing (CoPP) and genuine forwarding-plane packet loss. High-capacity core routers prioritize hardware ASIC packet forwarding over generating ICMP TIME_EXCEEDED replies on their management CPU. If Hop 3 shows 65% loss but Hop 4, Hop 5, and the final destination show 0.0% loss and steady Avg/StDev latency, that intermediate router is simply rate-limiting ICMP diagnostic replies. Real packet loss only exists when loss begins at a specific hop and persists across every subsequent hop all the way to the final destination.

sudo apt update && sudo apt install -y mtr-tiny

# 1. Run 100-packet IPv4 MTR report with ASN lookup (-z) and wide hostnames (-w)
mtr -rwzc 100 -4 1.1.1.1

# 2. Run 100-packet IPv6 MTR report to verify IPv6 transit health
mtr -rwzc 100 -6 2606:4700:4700::1111

# 3. If ICMP is deprioritized by an intermediate router, run TCP SYN MTR on port 443
sudo mtr -rwzc 50 -T -P 443 1.1.1.1

Start: 2026-11-06T20:50:12+0000
HOST: netcup-rs1000-nue                         Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS197540 gw-nue1.netcup.net                 0.0%   100    0.3   0.4   0.2   1.8   0.2
  2. AS197540 core-nue-fra.netcup.net            0.0%   100    2.6   2.7   2.5   4.9   0.3
  3. AS???    de-cix.fra.cloudflare.com          0.0%   100    2.9   3.0   2.8   6.1   0.4
  4. AS13335  one.one.one.one                    0.0%   100    2.8   2.9   2.7   3.5   0.1

When a service port (such as HTTPS 443, WireGuard 51820/udp, or a custom API port) appears unreachable from the outside world, three layers can be responsible: the daemon is bound only to 127.0.0.1 instead of 0.0.0.0/[::], the guest OS firewall (ufw/nftables/iptables) is dropping the packet, or the Netcup SCP Stateful Firewall is dropping the packet upstream on the hypervisor bridge before it ever reaches your VM’s virtual network card.

You can prove which firewall layer is dropping the connection in 10 seconds by running sudo tcpdump -ni any inside the guest while initiating a connection from an external client. Because libpcap hooks into the Linux kernel’s AF_PACKET tap immediately after the virtio-net driver receives an Ethernet frame—before netfilter (iptables/nftables/ufw) evaluates PREROUTING or INPUT rules—any packet that reaches your VM will appear in tcpdump even if ufw drops it microseconds later. Therefore, if tcpdump shows zero incoming SYN packets, the packet was blocked upstream (either in the Netcup SCP Firewall or by an active DDoS scrubbing profile). If tcpdump shows incoming SYN packets arriving on eth0 with no SYN-ACK reply leaving the server, your local guest firewall or socket binding is the culprit.

Finally, if TCP connections establish (SYN -> SYN-ACK -> ACK) but stall immediately when transferring large TLS certificates, Docker image layers, or SSH output, test for a Path MTU Discovery (PMTUD) blackhole using ping -M do (Don’t Fragment). On a standard 1500-byte Ethernet link, the maximum unfragmented ICMPv4 payload is 1472 bytes (1472 + 20B IPv4 + 8B ICMP = 1500) and the maximum ICMPv6 payload is 1452 bytes (1452 + 40B IPv6 + 8B ICMPv6 = 1500):

# 1. Confirm your daemon is listening on 0.0.0.0 / [::] (NOT just 127.0.0.1)
sudo ss -tulnp | grep -E "Local Address|:80 |:443 |:22 "

# 2. Listen for incoming packets on the raw interface while attempting a connection from outside
# -> If tcpdump shows ZERO incoming SYN packets: the Netcup SCP Firewall (upstream) is blocking the port!
# -> If tcpdump shows incoming SYN packets with no SYN-ACK reply: guest UFW / nftables is dropping it!
sudo tcpdump -ni any 'tcp port 443 and (tcp-syn|tcp-ack)!=0' -c 10

# 3. Audit active guest firewall rules (both UFW/iptables and native nftables)
sudo ufw status verbose
sudo nft list ruleset | head -n 45

# 4. Test Path MTU (1472 payload + 20 IPv4 + 8 ICMP = 1500 bytes) with Don't Fragment (-M do)
ping -4 -M do -s 1472 -c 3 1.1.1.1
ping -6 -M do -s 1452 -c 3 2606:4700:4700::1111

PING 1.1.1.1 (1.1.1.1) 1472(1500) bytes of data.
1480 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=2.84 ms

If ping 1.1.1.1 succeeds with 0% loss but apt update or curl https://github.com fails with Temporary failure in name resolution, your IP routing table is healthy and only local DNS resolution is broken. On Ubuntu 24.04 LTS, /etc/resolv.conf should be a symbolic link to /run/systemd/resolve/stub-resolv.conf pointing to the local 127.0.0.53 stub listener managed by systemd-resolved.

When switching a Netcup server from DHCPv4 to a static Netplan configuration, administrators occasionally forget to declare a nameservers: block under eth0. Because DHCPv4 was previously supplying Netcup’s recursive DNS servers (46.38.225.230 and 46.38.252.230), disabling dhcp4 without adding explicit nameservers leaves systemd-resolved with zero upstream resolvers (Current Scopes: none in resolvectl status).

Finally, if you operate a mail server or send transactional notifications from your Netcup server, verify that forward (A/AAAA) and reverse (PTR) DNS records match symmetrically (FCrDNS) across both IPv4 and IPv6.

# 1. Inspect systemd-resolved status and active upstream DNS servers per interface
resolvectl status

# 2. Test direct DNS queries against Netcup's official recursive resolvers & Cloudflare
dig @46.38.225.230 netcup.com +short
dig @1.1.1.1 ubuntu.com +short

# 3. If /etc/resolv.conf was overwritten by a broken script, restore the systemd-resolved symlink
sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
sudo systemctl restart systemd-resolved

# 4. Verify your server's public IPv4 and IPv6 Reverse DNS (PTR) records
SERVER_IPV4=$(ip -4 addr show "$(ip -4 route show default | awk '{print $5; exit}')" | awk '/inet / {split($2,a,"/"); print a[1]; exit}')
SERVER_IPV6=$(ip -6 addr show "$(ip -4 route show default | awk '{print $5; exit}')" scope global | awk '/inet6 / {split($2,a,"/"); print a[1]; exit}')
echo "IPv4 PTR: $(dig -x "${SERVER_IPV4}" +short @1.1.1.1)"
echo "IPv6 PTR: $(dig -x "${SERVER_IPV6}" +short @1.1.1.1)"

IPv4 PTR: mail.example.com.
IPv6 PTR: mail.example.com.