Exoscale BYOIP: using your own IP addresses at Exoscale

Exoscale publishes nothing about bringing your own IP addresses. On 15 October 2026 we read its documentation, its FAQ and its pricing page, and none of them mentions customer-owned addresses. The documentation describes only Exoscale's own. Every instance is provisioned with "a native IPv4 address, leased from a global pool and intrinsically tied to the Compute instance". Elastic IPs add static addresses that Exoscale creates for your organization, five by default, attached to instances within one zone.

Private Connect, Exoscale's dedicated link into your private networks, is not a way round this. Its FAQ asks whether Exoscale can advertise your IP range to your routers over BGP, and answers: "No, Private Connect is a pure Layer 2 connection to your router. No routing is done inside of Exoscale."

The tunnel route

A network that can announce the block does so, and a GRE or WireGuard tunnel carries its traffic to your Exoscale instance and back (how the tunnel works). The instance keeps the native IPv4 address Exoscale gave it, and that address is the outer end of the tunnel. The leased block arrives inside the tunnel. You configure its addresses on the tunnel or loopback interface, and the instance answers on them as if they were local. Exoscale's network sees only traffic between two public addresses.

• Use the native address for the tunnel. Exoscale says Elastic IPs work natively for incoming traffic only, and outgoing traffic still uses the instance's native address as its source. A manual Elastic IP partly gets around that: Exoscale's how-to on using an Elastic IP as traffic source binds an application to one. For a tunnel, the native address is still the simpler end, so point the far end at the native IPv4 address, not at an Elastic IP.
• Replies go back through the tunnel. Add a policy route so that traffic from the block leaves through the tunnel. Sent straight out, it would carry a source address Exoscale never assigned to the instance, and networks filter such traffic.
• Open the security group. Exoscale denies all ingress by default. Add an ingress rule from the far end's address for GRE, which security groups offer as a protocol alongside TCP, UDP and ICMP, or for WireGuard's UDP port. Egress stays open until you create the first egress rule. After that, allow the tunnel out too.
• Set the MTU. 1,476 bytes for GRE, around 1,420 for WireGuard, with MSS clamping if the instance routes the block on to containers or virtual machines.
• Any size. A tunnel delivers fewer than 256 addresses, down to a single one, which BYOIP never does.

Where RTM Networks fits

We lease /24s and larger from our own RIPE NCC address space, and sell blocks in the RIPE NCC, ARIN and APNIC regions. Every lease includes the ROA, the route object, PTR records and a Letter of Authorization whenever you need one (lease IPv4). If Exoscale agrees to announce a block, we create the ROA for the ASN it names and sign the letter of authorization. Until then, we announce the block ourselves and deliver it to your instance over GRE or WireGuard, in any size down to a single address (GRE and WireGuard tunnels). Tell us the zone and how many addresses you need. Other providers: BYOIP guides.