Your Vendor Asked For a Static IP for Whitelisting. What To Send Them.

Somebody in procurement or security has asked you to supply the IP address your system will connect from, so they can add it to a whitelist. This is the practical version of that request: what they are actually going to put in a firewall rule, what they will check before they accept it, the answers that get rejected, and how to verify your own address before you put it in writing.

If you are earlier than this — you do not yet have a stable outbound address and want to know the options — read A fixed outbound IP for vendor and API allowlisting first. That guide is about getting one. This one is about handing one over.

What they are going to do with it

Whatever the email says, the thing on the other end is almost always one of three: a firewall rule, an API-gateway allow-list, or a field in a vendor portal. All three take an IPv4 address or a CIDR range. They do not take a hostname, they do not take "our AWS account", and the ones that appear to take a hostname usually resolve it once and cache the answer for longer than you would like.

The rule they write is a default-deny: your address is permitted and everything else is refused. That has one consequence worth internalising before you reply. The day your address changes, you are not degraded. You are off. There is no partial failure, no warning, and the error your side sees is usually a timeout or a 403 with nothing useful in it.

What to send

Send four things. Most people send one and then spend a week on email.

• The address itself, as a single IPv4 address, or as a CIDR if you genuinely have a range. Write it as 203.0.113.7 or 203.0.113.0/29, not as "our IP".
• Whether it is dedicated to you. Say so explicitly. Many security reviews ask, and the answer "it is a shared egress from our proxy provider" changes the decision at some vendors and disqualifies you at others.
• Who announces it. If the address comes from an address block with an ASN behind it, name the ASN. It lets them verify the whole claim in a public routing database without taking your word for anything.
• Whether it will change, and what happens if it does. If you cannot promise it will not change, say that now rather than at the outage.

A reply that contains all four is usually approved the same day. A reply that contains only the number generates a follow-up asking for the rest.

The answers that get rejected

"It is our office IP." Most business broadband is a dynamic lease. It can hold for a year and change during a router swap. If you are going to do this, get static addressing from the ISP in writing first, and understand that it ties the integration to that building.

"Here is the AWS/GCP/Azure published range." Handing over your cloud provider's whole published range means the vendor is permitting every customer of that provider, which is close to permitting the internet. Reviewers who understand this refuse it; reviewers who do not, accept it, and it fails a later audit.

"We will use a proxy service." Fine, but check whether the address is dedicated or from a shared pool before you say it. On a shared pool, anybody else on that pool inherits your access to the vendor, and your access can be taken away by somebody else's behaviour. See dedicated IP vs shared proxy.

A hostname. Offer it as an extra if you like, never as the answer. If they accept a hostname, ask how often they re-resolve it; the answer is often "at config load", which means never.

Verify it before you put it in writing

This is the step people skip, and it is the one that costs a day. The address you think you egress from and the address a remote server sees are different facts, and they diverge for boring reasons: a second default route, IPv6 winning over IPv4, a proxy in the middle, split tunnelling, or a NAT you forgot about.

Check it from the machine that will actually make the calls, not from your laptop:

curl -4 https://api.ipify.org

Then check it a second way, because one lookup service can be wrong or cached:

curl -4 https://ifconfig.co
dig -4 +short myip.opendns.com @resolver1.opendns.com

If those three disagree, stop and find out why before sending anything. If your traffic can leave by more than one path, whitelisting one of them produces an integration that works until it does not.

And check IPv6 separately. curl -6 https://api64.ipify.org will tell you whether you also have a v6 egress address. If you do and the vendor only whitelisted v4, your client may prefer v6 and be refused — a failure that looks completely unrelated to the thing you just configured.

A short checklist for the reply

• The address, as a bare IPv4 address or CIDR
• Dedicated or shared — stated, not implied
• The ASN that announces it, if there is one
• Whether IPv6 is in play, and its address if so
• Your change process: who tells them, and how far in advance
• A contact who will actually answer if the rule needs to change

Where TunnelNet fits

We give you a dedicated static IPv4 address out of 23.187.152.0/24, a block announced to the internet by our own autonomous system, AS396500. Your traffic leaves from that address, whatever the machine is and wherever it sits — a VPS, a rack, an office, a box behind CGNAT. Nothing migrates; a WireGuard tunnel attaches the address to the machine you already have.

That gives you clean answers to all four questions above: the address is a single IPv4 address, it is assigned to you and nobody else, it is announced by a named ASN that your vendor's security team can look up, and it does not change when you redeploy.

It is $20/month on TunnelNet Full. If the integration is one somebody pays you for, TunnelNet Business at $100/month is the same address with a written one-business-day support commitment, onboarding done with a person who verifies the source address on the wire before you file it, and our measured availability published. Same network; the difference is what we commit to in writing.

Two things we will say plainly, because you are the kind of reader who would find out: we have no uptime SLA yet and will not offer one until we have six months of measured history — 2027-03-10 at the earliest, and outbound port 25 is blocked on our egress path. The uptime page has the rest, including the incidents we caused ourselves.