Skip to content

Hetzner IPv6 differs across three locations

General Discussion by MARIA3 4 replies 183 views
4 #1

I try to make a server up in your Falkenstein location and the IPv6 is configured different than in Nuremberg and different again in Singapore. I use automation with Ansible and now I have make three playbooks for same provider.

  • Falkenstein: Gateway is in the /64 subnet
  • Nuremberg: Gateway is outside
  • Singapore: must request IPv6 block manually

This is not good for automation.

I open ticket #44821 but no clear answer. Can you explain why this difference? Regards

siesta first, deploy later
#2

Technical debt is real and this is why we cannot have nice things.

#3

Ja this is the Networkstackimplementationinconsistency problem nein I have observed this with Hetzner since I deploy there ja the Routingtableconfiguration differs per Datacenterlocation due to Historicalnetworkinfrastructuredecisions nein

  • Frankfurt: Virtualroutingandforwarding with Gatewayaddressinsubnet ja
  • Amsterdam: Provideredgeconfiguration puts Gatewayexternally nein
  • Singapore: Legacyipv6deployment requiring Manualprefixdelegation ja

I have build three Separateansibletemplates for this ja the Configurationmanagementoverhead is unacceptable nein Hetzner must standardize the Networkinterfaceconfiguration across all Points_of_presence ja

My workaround: abstractionlayer in Python detecting location from API ja then applying correct Netplanconfiguration nein but this should not be necessary ja

#4

This inconsistency is a SECURITY NIGHTMARE!!! What if your automation applies WRONG firewall rules to the wrong gateway configuration!!!

You could EXPOSE your machines to the internet with incorrect ip6tables rules!!! I have seen this before!!!

My recommendations:

  • fail2ban on ALL IPv6 addresses immediately!!!
  • ufw or nftables with STRICT default deny!!!
  • Audit every automated deployment MANUALLY until they fix this!!!

What could go wrong: spoofed neighbor advertisements, rogue router advertisements, accidental prefix delegation to attackers!!!

Do NOT trust the provider to fix this soon!!! 👀

airgapped, encrypted, faraday'd, still worried
#5

This networking inconsistency is a symptom of the same organizational dysfunction that causes email deliverability failures.

For what it's worth, I have seen providers with three different mail server configurations across locations because nobody documented the standard. SPF records pointing to different outbound IPs per datacenter. DKIM keys rotated on different schedules. Nightmare for reputation management.

The IPv6 problem is infrastructure-level but the pattern is identical: growth by acquisition without integration. Hetzner probably bought three different hosting operations and never unified the network stack.

Demand a public standardization roadmap or migrate. Vague promises are worthless.

SPF, DKIM, DMARC — holy trinity ✉️

Post a reply

You need an account to reply. Log in or register to join the conversation.

Post reply Preview Save draft