---
title: My resource is attached to a Private Network but has no IP address on the network
description: This page helps you troubleshoot problems when you have a resource attached to a Private Network, but it has no reserved or configured IP private IP address on the network
tags: resource instance private-network vpc ipv4 ipv6 ip-address IPAM reserved configured old nics
dates:
  validation: 2025-08-07
  posted: 2023-07-05
---
import image from './assets/scaleway-attached-resources.webp'


When you attach a resource to a Private Network, the Private Network's built-in DHCP defines an IPv4 and IPv6 address for the resource on that network. This is managed via Scaleway's [internal IPAM](/vpc/concepts/#ipam).

- [Find out how to attach a resource to a Private Network](/vpc/how-to/attach-resources-to-pn/#how-to-attach-a-resource-to-a-private-network)
- [Find out how to view your resource's IP address on the Private Network](/vpc/how-to/attach-resources-to-pn/#how-to-view-the-resources-ip-address)
- [Find out how to specify the IP address to use when attaching a resource](/ipam/how-to/reserve-ip/)
- [Find out how to run connectivity tests to diagnose connectivity problems](/vpc/troubleshooting/connectivity-tests/)

IP addresses are allocated asynchronously from the attachment of the resource in most cases. The IP will therefore not be immediately returned upon attaching a resource via the API, and there may be a brief delay before it displays in the console, as shown below:

<Lightbox image={image} alt="" />

However, in some cases even after waiting, an IP address may not be set for your resource on the Private Network. Read on below to find out more about this problem, and how to solve it.

## No IP address is displayed and I have not activated DHCP

You may have attached a resource to an "old" Private Network on which you [have not activated DHCP](/vpc/reference-content/vpc-migration/#dhcp-activation-on-pre-existing-private-networks). In this case, no IP address for the resource on the network is configured.

You will need to carry out manual configuration to set the IP address on the resource or [activate](/vpc/how-to/activate-dhcp/) DHCP.

We strongly recommend that you activate DHCP on the Private Network to let us automatically handle IP address management.

Read our dedicated documentation about [VPC migration](/vpc/reference-content/vpc-migration/) for more information about how "old" Private Networks are migrated to the VPC, including DHCP activation.

## No IP address is displayed but I have activated DHCP

This may be because the resource was attached to the Private Network some time ago before the product was integrated with IPAM. Therefore, no address is reserved with the IPAM for the resource on this Private Network.

To fix this problem, **detach your resource from the Private Network, and reattach it.**

### Elastic Metal servers

Note that some manual configuration of the network interface is required for Elastic Metal servers. Follow the steps in our [dedicated documentation](/elastic-metal/how-to/use-private-networks/#how-to-configure-the-network-interface-on-your-elastic-metal-server-for-private-networks).

You can also attach custom resources, such as virtual machines hosted on your Elastic Metal server, to Private Networks, by specifying their MAC addresses upon attachment. Follow the instructions for attaching such a resource in the [Private Networks documentation](/vpc/how-to/attach-resources-to-pn/).

### ArchLinux and Debian Bullseye

DHCP should work out of the box for attached resources running any and all Linux distributions. However, when it comes to **ArchLinux**, we are aware of a problem when it comes to setting a Classless Static Route to our service IP address `169.254.169.254`.

In this case, if you are using `systemd-networkd` and do not have a route to our service IP address `169.254.169.254`, you should try updating and upgrading the packages on your system.

There is also a known [bug](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867625) affecting **Debian Bullseye**, that prevents DHCP clients from correctly applying the default route. For this specific bug, we recommend using another distribution, such as **Debian Bookworm**.