VeryCloud Remote Transit IP: architecture, tunnels, and implementation choices

Introduction

Remote Transit IP delivers BGP transit at a distance via an L3/L2 tunnel between the VeryCloud network (AS198825, Telehouse 3 Paris) and your infrastructure, wherever it's hosted. Concretely: you keep your servers where they are, but you announce your IP prefixes via VeryCloud, which routes them on the Internet over its multi-homed backbone (2 Tier 1 FR + FranceIX peering and major European IXs).

Useful for:

• Protecting home hosting servers behind Netrix Anti-DDoS
• Keeping your own IPv4/IPv6 prefixes when changing hoster
• Adding multi-homing redundancy to existing infra
• Testing BGP in a lab with real transit

Prerequisites

• A VeryCloud customer account with an active Remote Transit IP plan
• A public IP on your side (static, or dynamic with DDNS if you're tunneling)
• Hardware or software capable of building a tunnel (Linux, OPNsense, Cisco, Arista, Mikrotik...)
• A public or private AS for your side (a private AS 64512-65534 works if you don't have your own)
• Your IPv4/IPv6 prefixes (up to 10 by default, 25 with the option)

Step 1: Overall picture

   Your servers                         Internet
   ┌────────────┐                          │
   │ 192.0.2.0/24, ─┐                      │
   │ 2001:db8::/48  │     Tunnel           │
   │ AS65000        ├─────────────────┐    │
   └────────────────┘   (GRE/VXLAN/   │    │
                        WireGuard)    ▼    │
                                   ┌──────────┐
                                   │ VeryCloud│
                                   │ AS198825 │◄─── Netrix Anti-DDoS
                                   │ TH3 Paris│
                                   └────┬─────┘
                                        │
                                  Tier 1 + FranceIX

Client side: you encapsulate your traffic in the tunnel, and you establish a BGP session on top of that tunnel with a VeryCloud router. That session announces your prefixes and receives a default route (or full table as an option).

Step 2: The 4 possible transports

Recommendation per case:

• VPS / dedicated server with fixed public IP → GRE
• Behind a residential ISP box (Bbox, Livebox...) → WireGuard or VXLAN (proto 47 often blocked)
• Mikrotik → EoIP if you stay Mikrotik on both sides (VeryCloud supports it)
• Need to extend an L2 broadcast → VXLAN

Step 3: Tunnel addressing plan

VeryCloud provides a tunnel addressing plan typically /30 (IPv4) and /127 (IPv6):

Tunnel IPv4: 169.254.X.0/30
  - VeryCloud side: 169.254.X.1
  - Client side:    169.254.X.2

Tunnel IPv6: 2a0e:XXXX:XXXX::/127
  - VeryCloud side: 2a0e:XXXX:XXXX::0
  - Client side:    2a0e:XXXX:XXXX::1

These IPs are only for the BGP session, not for your production traffic. Production traffic goes through the prefixes you announce.

Step 4: BGP addressing plan

Step 5: Prepare your order

When ordering Remote Transit IP, VeryCloud asks for:

1. Tunnel type: GRE, VXLAN, EoIP, or WireGuard
2. Client endpoint: your fixed public IP (otherwise discuss DDNS / reservation)
3. BGP sessions: v6 included by default, v4 or v4+v6 +€19.99/month
4. Prefixes: your IPv4/IPv6 resources (RIPE / ARIN / APNIC) or rented prefixes
5. Received routes: default route included, full BGP table optional +€9.99/month

After order, the team gets back within 24h with a technical email containing: client-side tunnel config, addressing plan, ASN, peer-IPs, and MD5 password if chosen.

Step 6: RPKI and IRR

Before even bringing up the tunnel, prepare:

• RPKI ROAs on your prefixes via your RIR (RIPE NCC, ARIN, etc.) — authorize AS198825 to announce your prefixes
• route(6)-objects in your RIR's IRR database — many operators filter on IRR
• AS-SET if you have multiple underlying ASNs

Without ROAs and IRR, your announcements will be filtered by a big chunk of the Internet, and Remote Transit IP becomes useless.

Step 7: Verification with the Looking Glass

VeryCloud publishes a Looking Glass at https://lg.verycloud.fr/ (check exact URL in commercial doc). There you can:

• See if AS198825 receives your announcements
• Test a ping or traceroute from the VeryCloud backbone to a given IP
• Verify the BGP paths used

It's your first troubleshooting tool once the session is up.

Step 8: Roadmap for the rest

Once your Remote Transit IP is delivered, the typical production chain is:

1. Bring up the tunnel (GRE/VXLAN/WireGuard) and verify ping on tunnel IPs
2. Configure BGP (BIRD / FRR / Cisco / Arista...) and establish the session
3. Announce your prefixes (network statement + route-map filter)
4. Receive the default route and verify traffic exits via VeryCloud
5. Test from outside: ping from outside to your prefixes
6. Harden: MD5, max-prefix, GTSM, RPKI
7. Monitor: alerting on session DOWN

Each step has its dedicated tutorial.

Troubleshooting to anticipate

Tunnel comes up but BGP doesn't establish — often a firewall dropping TCP/179 on the internal tunnel IPs. Check iptables/conntrack.

Abnormal latency — depends on the physical path between you and Paris (TH3). Expect ~5-10ms in France, ~25-40ms elsewhere in Europe.

MTU and fragmentation — a tunnel adds headers. Effective in-tunnel MTU: physical MTU - 24 (GRE) or 50 (VXLAN) or 80 (WireGuard). See dedicated tutorials.

Prefixes not announced on the Internet — check your RPKI ROAs and IRR route-objects. Almost always there.

Useful commands

# See your AS announcements from outside
whois -h whois.radb.net AS65000

# Verify an RPKI ROA
rpki-client -d /var/db/rpki-client

# See routes received by AS198825 on your prefixes
# -> VeryCloud Looking Glass

Conclusion

Remote Transit IP = opening a clean door to the Internet via AS198825 without moving your servers. One tunnel + one BGP session, and you inherit the VeryCloud backbone, Tier 1 multi-homing, and Netrix Anti-DDoS. Complexity is in the details: ROAs, IRR, MTU, security. The 9 following tutorials of this pack cover them.

Going further: pick between GRE, VXLAN, WireGuard based on your constraint; configure BIRD or FRR; harden the BGP session with RPKI and MD5.

Resources

• RFC 4271 — A Border Gateway Protocol 4 (BGP-4)
• RFC 2784 — Generic Routing Encapsulation (GRE)
• RFC 7348 — VXLAN
• RIPE NCC — Manage ROAs
• VeryCloud — Remote Transit IP