Over several years, we have designed and developed our own network stack based on eBPF, which will pave the way for future network functions. On this page, we would like to introduce you to the features and differences compared to the current network stack, and explain how you can switch your cloud servers over to test hcnet. We also explain how you can take part in the beta phase. We are looking forward to your feedback.
We've started migrating Load Balancers on 9 July 2026, and all Load Balancers are running with hcnet since 21 August 2026. So, now it's time to allow you to switch your servers to the new stack, too.
Change your cloud server's network stack
Make sure to read the Known Limitations section down below.
To change your cloud server's network stack to use hcnet, please open your project in the Hetzner Console and do the following:
- Go to Servers on the left menu bar.
- Select the cloud server whose network stack you want to change.
- Select the Networking tab.
- Under Network Stack select "Try new network stack".
If, for any reason you'd like to change back to the current network stack, select "Restore standard network stack". In case something did not work as you expected, please let us know via the feedback box.
Note that both actions will briefly interrupt the connectivity to your server, and if a Firewall is active, existing connections may be dropped.
In the following we'll explain how hcnet is different from the current network stack.
Cloud Firewalls
Cloud Firewalls are stateful and hcnet implements them using eBPF. Whenever you define a Firewall, it is optimized and compiled into a standalone eBPF program. This program is then loaded into the kernel, where it is verified and JIT compiled. Finally, it is attached directly in front of your cloud server's virtual NIC. This makes the Firewalls more efficient.
Given that hcnet uses a new, custom Firewall implementation that is different from the current stack's implementation, the connection tracking behavior may also differ in some details. In practice, we don't expect these to be noticeable though.
Connection tracking
For the Firewalls to be stateful, we have to track connections. This allows packets that are not explicitly allowed by Firewall rules to still be allowed, provided they are a response to a previously allowed packet or related to an active connection. The limit on concurrently tracked connections has been increased from 80,000 connections shared between both IPv4 and IPv6, to 120,000 connections per IPv4 and IPv6 each, at no additional cost.
Another change to the current network stack is that we also improved the behavior for when the connection tracking table is full. Currently, it is not possible to establish any new connections, because packets for new connections are simply dropped. With hcnet, the connection tracking step is skipped in this case, and the packet is evaluated solely based on the Firewall rules. This is a more reasonable fallback that still blocks undesired traffic as expected, while also allowing traffic that does not need connection tracking to still function. However, traffic that relies on connection tracking will be disrupted, as the response packet will most likely be dropped after no Firewall rule or known connection is matched.
As before, connection tracking for a cloud server is only enabled if that cloud server has a Firewall assigned to it.
Fragment tracking
The next change is about fragment tracking. For a fragmented IPv4 packet to be correctly matched by the Firewall, the first fragment must arrive first, so the layer 4 header is known for all following fragments. Otherwise, these unknown fragments will only match Firewall rules which do not rely on these layer 4 information.
No fragment tracking is done for IPv6.
DHCP
Starting with hcnet, DHCP is now processed via a single, custom implementation instead of via two separate servers for public and private interfaces as it is currently the case. Furthermore, unlike the current network stack, where routing to the metadata server is covered by the default route if one exists, hcnet ensures that every public and private interface receives an explicit route to the metadata server. Depending on your DHCP client you may not see each route on every public and private interface.
ICMP
The new network stack provides more precise error reporting using ICMP and ICMPv6. For IPv4 and IPv6 packets leaving your server, the following ICMP/ICMPv6 responses may occur:
| ICMP/ICMPv6 type | ICMP code | ICMPv6 code | Description |
|---|---|---|---|
Echo Reply |
In response to an Echo Request. |
||
Destination Unreachable |
Communication Administratively Prohibited |
Source address failed ingress/egress policy |
In case a cloud server tries to send with a spoofed IP address. |
Reject route to destination |
In case it tries to reach a non-globally-routable destination IP addresses. | ||
Host Unreachable |
N/A | For private network packets with an unknown destination address. | |
Time Exceeded |
In case the TTL field reaches zero. | ||
Neighbor Advertisement |
N/A | In response to a Neighbor Solicitation. |
IPv6 Multicast
The new network stack supports a subset of IPv6 Multicast and now also responds to echo requests for a few well-known IPv6 multicast addresses:
ff02::1: Link-local scope, all hosts.ff02::2: Link-local scope, all routers.
Metadata Server
In addition to being reachable over the IPv4 address 169.254.169.254, the
metadata server is now also reachable over the IPv6 address fe80::a9fe:a9fe.
It is also accessible via all public and private interfaces.
Offloads
Cloud servers will receive packets from the network stack as they appear on the wire. We don't attempt to reassemble incoming packets before they reach your server. This means, that if you are monitoring your cloud server's ingressing packet rate, you could be seeing more packets even though the bandwidth stays the same. If enabled, your server may do GRO (generic receive offload) instead.
Checksum and segmentation offloads on the egress path continue to be supported.
Known Limitations
DHCP
As we are unable to trigger DHCP on your cloud server when you change the network stack, you may not instantly see the dedicated routes to the metadata server when switching to hcnet, depending on the DHCP client in use.
Similarly, when switching back from hcnet to the current network stack, you might notice some stale DHCP routes. In this case, you might experience connectivity issues with the metadata server, when a dedicated route using a private network interface still exists, and the cloud server has a public interface.
This does not affect the DHCP functionality and both issues are resolved once the DHCP lease times out, or the cloud server is rebooted.