Guides

IP Transit

Public IPv4 addresses from a location of the platform, at the speed you pick, used by the virtual machines of your own Proxmox VE host or by the services of any Linux server, at home, at the office or elsewhere: every port, TCP, UDP and ICMP, in and out, with the address as source.

What it is

Each location is a machine of the platform with addresses from its provider. Your Proxmox VE host dials a WireGuard tunnel out to it, and everything sent to your addresses comes down that tunnel to a bridge without physical port, vmbr1, where each VM has its public address on its own interface, as if it sat in a datacenter. The rest of your network does not change, and nothing has to be opened on your router.

On a Linux server that is not Proxmox VE (a VPS, a dedicated server, a Raspberry Pi), the addresses go on the server itself instead, on an interface named ifl-ips: its own services listen on them, and what it sends from them leaves through the tunnel. See host mode.

The path of a packet

internet ──▶ location (transit machine) ══ WireGuard ══▶ your Proxmox VE host
                                                          │ vmbr1, gateway 100.127.255.1
                                                          ▼
                                               VM: 203.0.113.10/32

1. Order a location and a speed

In the dashboard, open Network → IP Transit. Each location card says where it is, the speeds it sells, whether an IPv6 prefix comes with it, how many IPv4 addresses it has left, and its price from the cheapest speed. Order opens a dialog where you pick:

a speed tier: its speed (both ways), the traffic included each month, what happens past it, and its monthly price with one IPv4 address;
how many IPv4 addresses to start with, from one up to what the location allows and has left: each one beyond the first costs the location's price for an extra address.

The dialog adds it up, line by line, with VAT, before anything happens. Every address you asked for is yours at once, or the order fails as a whole if the location ran out meanwhile.

It is paid ahead. The dialog says what you pay now, a whole month from the moment you order, then what each month costs, VAT included, and how it is paid: from the workspace's credits when they cover it, otherwise the credits pay what they can and the card on file the rest. Without a card, you finish on the payment provider's page: the addresses wait for you there, reserved but not routed, for 30 minutes, then go back to the pool. Back on the page, it confirms the payment and the setup command can be made. You need the admin or owner role.

Several servers at one location? Once you have IP Transit somewhere, its card offers Order another: each order is its own tunnel, with its own setup command, addresses, speed, traffic, invoices and reverse DNS, up to ten per location. The address limit of a location counts per order. Give each a short name (web-1, or click the name on its card later) to tell them apart; unnamed, they show as Transit 1, Transit 2.

Paying for it

Each month runs from the day you ordered: ordered on the 2nd, it is paid until the 2nd of the next month, then invoiced again that day, in advance: the tier and each extra address at the price they had when you chose them, plus the traffic beyond the allowance of the month that just ended on tiers that bill it. It is paid from your credits first, then your card. The subscription card says Paid until the last day covered.
Adding addresses or moving to a faster tier pays the difference until your next renewal first; the change applies once it is paid.
A slower tier, an address given back or cancelling applies at once, and the unused part of what you paid, prorated to the second with its VAT, goes back to your credits (a Refund line in the credits history). A month left unpaid is written off on cancel.
Every payment has its numbered invoice, with VAT and a PDF, in Settings → Billing.

When a month cannot be paid, the addresses keep working for a week and the workspace's billing contacts are told by mail. Still unpaid, the subscription is suspended: the location stops carrying your addresses, which stay reserved for two more weeks; then it is cancelled and they go back to the pool. Adding credits pays the month by itself, or use Pay now on the card (credits first, then the card or the payment page): traffic flows again within a minute, without running anything on the host.

2. Run one command on the host

The order shows a command, once. Paste it in a root shell on the Proxmox VE host (Proxmox VE 8 or 9) or the Linux server (Debian, Ubuntu and their kin, with systemd):

On the host, as root

curl -fsSL https://infraflow.app/transit.sh | bash -s -- ift_…

It finds what it runs on: on Proxmox VE it sets up a bridge for your VMs, anywhere else it puts the addresses on the server itself. Add --mode host or --mode bridge to choose. It installs WireGuard if needed, then:

makes the tunnel's key pair on the host: only the public key is sent, the private key never leaves it;
writes /etc/wireguard/ifl-transit.conf and starts it at every boot;
on Proxmox VE, creates vmbr1 in /etc/network/interfaces (between two marker lines, so the Proxmox web interface lists it when you create a VM), routes your addresses to it, and sends what they emit into the tunnel (the host's own traffic keeps its usual route). If vmbr1 already exists on your host for something else, add --bridge vmbr2 at the end of the command;
installs a timer that fetches your addresses every minute: adding or removing one in the dashboard needs nothing on the host.

Running it again updates everything in place. Lost the command? Make a new one on the IP Transit page; the old one stops working. One host carries one transit: run on a host that already has another one, the command stops and asks you to uninstall it first (or use another server). To remove everything it set up:

On the host

/usr/local/sbin/infraflow-transit --uninstall

3. On a Linux server: host mode

In host mode the addresses sit on the dummy interface ifl-ips, which the tunnel brings up: no network file of the server is touched. Traffic to them arrives on the server, and what the server sends from them leaves through the tunnel; the server's other traffic keeps its usual route. Make your services listen on the address, or on all of them:

On the server

# check that it leaves with it
curl --interface 203.0.113.10 https://ifconfig.me

# nginx
listen 203.0.113.10:80;

# Docker: publish a port on the address
docker run -d -p 203.0.113.10:80:80 nginx

Docker works as is: a published port answers from the container's own address, and the connection mark set when a connection comes in through the tunnel sends its replies back the same way. Use on the server, next to each address, shows these lines for it. Protect the server as you would any server on the internet: every port of the address reaches it.

3. On Proxmox VE: give an address to a VM

Attach the VM's network device to vmbr1, and give it the address with a /32 mask and 100.127.255.1 as gateway. Use in a VM, next to each address on the IP Transit page, shows these values with copy buttons, and the snippets for Debian, Ubuntu and Windows.

A VM with cloud-init, on the host

qm set <vmid> --net0 virtio,bridge=vmbr1 \
  --ipconfig0 ip=203.0.113.10/32,gw=100.127.255.1 \
  --nameserver "1.1.1.1 9.9.9.9"

Ubuntu: /etc/netplan/60-transit.yaml, then netplan apply

network:
  version: 2
  ethernets:
    ens18:
      addresses: [203.0.113.10/32]
      routes:
        - to: default
          via: 100.127.255.1
          on-link: true
      nameservers:
        addresses: [1.1.1.1, 9.9.9.9]

With an IPv6 prefix, a VM takes an address of it (2001:db8:10:20::2/64) with fe80::1 as gateway. Your VMs are on the internet, every port of them: protect them as servers in a datacenter, with the Proxmox VE firewall on their network devices or their own.

Check, in the VM

ping -c 3 1.1.1.1
curl -4 ifconfig.me   # prints 203.0.113.10

Speed and traffic

The location's machine holds your tunnel to your tier's speed, both ways: downloads to your addresses and uploads from them. The traffic of both directions is counted every 30 seconds and adds up over the month (UTC); the subscription card shows it against your allowance, with a bar. Past the allowance, depending on the tier:

throttled: the tunnel runs at the tier's reduced speed (10 Mbit/s unless the operator says otherwise) until the month ends, at no extra cost;
billed: the speed stays, and each TB beyond is charged at the tier's price, to the byte, with the month's invoice.

Change speed moves you to another tier from now: the new speed applies within a minute (once paid, for a faster one). The traffic already counted this month stays. Add IPs adds as many addresses as the location allows and has left; your host picks them up within a minute of the payment.

Traffic graphs and usage alerts

Traffic, under each subscription, draws what reaches your addresses from the internet and what they send: bandwidth in bits per second, packets per second, over the last hour (by the minute), day (by 5 minutes), week (by the hour) or 30 days (by 4 hours), for the whole tunnel or one address at a time. Hovering a point shows its figures and, by the hour, the highest rate seen in it. Below, what each address moved this month, and the months before.

It is counted on the location's machine, every 30 seconds, before its firewall: a flood that a blackhole or a deny rule drops still shows, though it never reaches your line. Minutes are kept two days, hours 35 days, months a year. The same series is in the API:

Traffic of one address over a week

GET /v1/orgs/{org}/transit/subscriptions/{id}/traffic?range=7d&address=203.0.113.10

Usage alerts send IP Transit traffic is high (transit.traffic_high) through the workspace's notifications, webhooks, Discord, Slack and the phones that asked for it: once a month when the month's traffic (in and out, as your allowance counts it) reaches a number of GB, and when the average rate, either way, holds above a number of Mbit/s for 5 to 60 minutes; that one is said again only after the rate went back under.

Firewall and emergency blackhole

Firewall, under each subscription, filters what comes in from the internet on the location's machine, before it enters your tunnel: what it drops never takes room on your line. Up to 50 rules, in order: allow or deny, by protocol (TCP, UDP, ICMP or any), destination port or range (22, 8000-8100), source address or network (198.51.100.0/24), source country (CN, RU: placed with DB-IP's free database, refreshed monthly, right for about 98% of addresses), for one address or all of them. The first rule that matches decides; anything no rule matches gets through. Answers to connections your addresses opened always get back, so a final deny any does not break their updates. Drag a rule, or use its arrows, to reorder; the machine applies a saved list within 30 seconds.

Rule	Matches	Does
1	TCP 22 from 198.51.100.0/24	Allow: SSH from the office
2	TCP 22 from anywhere	Deny: SSH from anywhere else
3	UDP 1000-2000 from anywhere	Deny
4	Anything from RU	Deny: a whole country

Blackhole drops everything sent to one address, on the machine, for 15 minutes to 24 hours or until you lift it: for a flood that would fill your line, while your other addresses keep working. The operator can blackhole an address too, with a reason; only the operator lifts that one. Each blackhole, lift and end is announced as ().

Reverse DNS

The reverse DNS (PTR record) of an address is set by the operator at the provider, on request. Next to each address, the pencil asks for a name: point the name's A or AAAA record to the address first, mail servers check both ways. For an IPv6 prefix it names the address your host uses (…::2 for a VM, …::1 in host mode).

The request shows as pending on the address until the operator decides, and you are told by mail. Approved, the address shows its name; rejected, it shows the operator's reason and Request again. One request waits at a time per address; withdraw it to ask for another name.

It checks and repairs itself

Connected only says the tunnel shook hands lately: it says nothing of traffic. So every minute, before anything else, the host checks what the script set up and puts back what went missing, whatever removed it: the tunnel (restarted when it is gone), the bridge or the addresses, IP forwarding, its INFRAFLOW-HOST chain first in FORWARD and DOCKER-USER (a Docker restart puts its own rules first, and its DROP policy eats what goes from the bridge to the tunnel), the policy rules and table 8420. Every repair is written to the journal:

On the host

journalctl -u infraflow-transit-sync -n 50

Then it looks whether traffic gets through: whether what went into the tunnel since the last minute got answers, and on a server in host mode, a ping from your first address through the tunnel, every five minutes at most. The location's machine does the same for each address towards its provider: its gateway answers, its interface is up, what it sends gets replies.

The card then says more than Connected: traffic flows, idle, partly out or nothing gets out, with the reason in plain words. What fixed itself is listed for a day (“Docker blocked forwarding on your host: fixed automatically”); what could not comes with the command to run on the host. A problem on the machine's side is the operator's, who sees it too. Broken for ten minutes, the IP Transit is broken notification goes out once, to the channels and phones that asked for it in the workspace's notification settings. A host set up before these checks keeps showing Connected alone: run the setup command again to get them.

From the CLI and Terraform

Everything the IP Transit page does can be done from a terminal with the CLI, signed in with an API token (Settings, API tokens; the admin role to order and change). What costs money or cannot be undone shows the price first and asks, unless --yes; --json prints what the API answered. A subscription is named by its label, its id or the start of its id.

Terminal

infraflow transit locations
infraflow transit order --location warsaw --count 2 --tier "1 Gbit/s" --label web-1
infraflow transit list
infraflow transit setup web-1          # a new setup command, the old one stops
infraflow transit add-ips web-1 --count 1
infraflow transit remove-ips web-1 203.0.113.10
infraflow transit tier web-1 "100 Mbit/s"
infraflow transit health web-1
infraflow transit cancel web-1

The Terraform provider manages subscriptions as infraflow_transit_subscription: changing ip_count, tier or label updates it in place, changing location orders a new one and cancels the old one, and destroying it cancels it. The setup command is in the state, sensitive, once the order is paid.

main.tf

provider "infraflow" {}  # INFRAFLOW_TOKEN, INFRAFLOW_API_URL, INFRAFLOW_ORG

data "infraflow_transit_locations" "all" {}

resource "infraflow_transit_subscription" "web" {
  location = data.infraflow_transit_locations.all.locations[0].id
  ip_count = 2
  tier     = "1 Gbit/s"
  label    = "web-1"
}

output "setup_command" {
  value     = infraflow_transit_subscription.web.setup_command
  sensitive = true
}

Both order through POST /v1/orgs/…/transit/orders with an Idempotency-Key header: an order sent again with the same key, after the network failed, gets the first order back instead of being ordered and paid twice. One subscription is read with GET /v1/orgs/…/transit/subscriptions/….

The Terraform provider is a preview: it is not on the Terraform Registry yet, and its tests run Terraform against a simulated API rather than this one. Build it from terraform-provider-infraflow and read the plan before applying: an apply spends money.

Troubleshooting

Symptom	Cause	Fix
The page says Waiting for setup	The command has not run, or failed	Run it again as root and read its last lines
Connecting, never Connected	Outbound UDP to the location is blocked	wg show ifl-transit must show a latest handshake; allow UDP out to the endpoint the page shows
Connected · nothing gets out	The card says why	Run the command it shows on the host; on the machine's side, the operator is told
Connected, but the VM reaches nothing	The VM's gateway is not on-link, or the bridge is wrong	In the VM, ip route must show default via 100.127.255.1 onlink; its device must be on vmbr1
The VM goes out with your home address	The policy routing is missing	ip rule must show from the address lookup 8420: systemctl restart wg-quick@ifl-transit
Pings work, websites hang	MTU: large packets are lost

Routers and Windows

The setup command is for Linux. For a router or a Windows machine, open Routers and Windows on the subscription card: the API writes the whole setup from your addresses and the location's key, step by step, for:

Device	What the addresses become	Tunnel
MikroTik RouterOS 7	Addresses on the router (a bridge without ports), a routing table and a rule per address for what leaves from them	WireGuard or GRE
pfSense 2.7+	The first address on the tunnel interface, the others as virtual IPs, 1:1 NAT to your servers, replies back through the tunnel	WireGuard or GRE
OPNsense 24+	The same, with a far gateway	WireGuard or GRE
Windows (WireGuard for Windows)	Host mode: the addresses on the machine, and everything it sends leaves through the tunnel	WireGuard only

Keys. Each device makes its own WireGuard key pair (RouterOS when the interface is created, pfSense and OPNsense with their Generate button, WireGuard for Windows with an empty tunnel). Paste its public key in Your device's public key: the private key never leaves the device, and the platform never generates or stores one, so none can leak from it. The configurations leave a placeholder where the device already has its key. One tunnel has one key: pasting a new one replaces the key the setup command registered, and the host that used it stops carrying traffic.

GRE instead of WireGuard

Some routers speak GRE better than WireGuard. On the subscription card, Routers and Windows switches the tunnel to GRE, with your router's public IPv4. The location then sends your addresses in GRE packets (IP protocol 47) to that address, from its own public IPv4, which the page shows. It switches within 30 seconds; a Linux host set up with the command follows within a minute by itself (its tunnel stays ifl-transit, brought up by infraflow-transit-gre.service rather than wg-quick).

It is not encrypted: what goes through can be read on the way, and anyone able to forge your address as a source can push packets into the tunnel. WireGuard stays the default.
Your router needs a public IPv4 with no NAT in front of it (or a box that forwards protocol 47 to it). IPv6 addresses travel inside the GRE tunnel all the same.
The address has to prove itself: the location sends nothing to an address typed in the dashboard until a device announces it from that very address, with its setup token. The Linux script and the MikroTik scheduler do it; on pfSense and OPNsense the steps give a one-line command to run on the firewall. That way nobody can point a tunnel at someone else's address. The card says Proven once it is.
A dynamic address has to be told: the Linux script does it every minute, the MikroTik steps add a scheduler that does it every five minutes, and any device can POST /v1/transit/host/gre-endpoint with its setup token (without a body, the address it calls from is taken).
One GRE tunnel per public address and location. Packets are 1476 bytes at most (1468 behind PPPoE); speed and traffic are held and counted as with WireGuard, per address too. There is no handshake: the card shows Connected while packets arrive from your side within the last few minutes. Windows cannot end one.

Looking glass

The looking glass runs a ping (5 echoes), a traceroute (30 hops at most) or an mtr report (5 rounds) from a location to a public address or hostname, and shows the output as it comes. Anyone may use it, a few runs a minute; signed in, you get more, and the IP Transit page has one too.

Only public targets are accepted: private, loopback, link-local, multicast, shared (CGNAT) and documentation ranges are refused. A hostname is resolved by the platform, which hands the location the address it picked, never the name. The location runs the tool with fixed counts, as an unprivileged user, and stops it after 30 seconds. Results are forgotten after ten minutes.

Manual setup

Set the host up by hand, without piping a script

Make the key pair on the host and register its public key with the API (PUT /v1/orgs/…/transit/tunnels/…/key, the tunnel's id is in the IP Transit overview). Then write the tunnel with your addresses and the location's key and endpoint, which GET /v1/orgs/…/transit/tunnels/…/config gives ready to paste, with the bridge and sysctl files:

On the host

apt install -y wireguard-tools
umask 077
wg genkey | tee /etc/wireguard/ifl-transit.key | wg pubkey

/etc/wireguard/ifl-transit.conf

[Interface]
PrivateKey = <content of /etc/wireguard/ifl-transit.key>
Table = off
MTU = 1420
PostUp = ip rule add to 203.0.113.10/32 lookup main priority 9990
PostUp = ip rule add from 203.0.113.10/32 lookup 8420 priority 9991
PostUp = ip route replace default dev ifl-transit table 8420
PostUp = iptables -t mangle -A FORWARD -o ifl-transit -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1380
PostUp = iptables -t mangle -A FORWARD -i ifl-transit -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1380
PostDown = ip rule del to 203.0.113.10/32 lookup main priority 9990 || true
PostDown = ip rule del from 203.0.113.10/32 lookup 8420 priority 9991 || true
PostDown = ip route flush table 8420 || true

[Peer]
PublicKey = <the location's key>
Endpoint = 198.51.100.7:51821
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

Append to /etc/network/interfaces, then ifreload -a

auto vmbr1
iface vmbr1 inet static
	address 100.127.255.1/32
	bridge-ports none
	bridge-stp off
	bridge-fd 0
	up ip route replace 203.0.113.10/32 dev vmbr1
	down ip route del 203.0.113.10/32 dev vmbr1 || true

/etc/sysctl.d/90-infraflow-transit.conf, then sysctl --system

net.ipv4.ip_forward = 1
net.ipv4.conf.all.rp_filter = 2
net.ipv4.conf.default.rp_filter = 2

Start it

chmod 600 /etc/wireguard/ifl-transit.conf
systemctl enable --now wg-quick@ifl-transit
wg show ifl-transit

For an IPv6 prefix, add ::/0 to AllowedIPs, the same rules with ip -6, an inet6 stanza with address fe80::1/64 and a route to 2001:db8:10:20::/64 on vmbr1, and net.ipv6.conf.all.forwarding = 1 with net.ipv6.conf.vmbr0.accept_ra = 2. By hand, adding or removing an address means editing these files again: the script's timer is what keeps them in sync.