Coordinating Firewall Changes with Partners

"What's your IP?" It is the first thing a partner's network team asks. The answer that comes back is very often the wrong one. Every transfer between two organizations crosses at least two firewalls, and you control only one of them. The other belongs to a partner whose network team you have never met. They have your address in a rule they wrote a long time ago. They will find out that you changed it at the same moment their overnight job fails. Firewall problems with partners are rarely technical mysteries. They are coordination failures: the right change made on one side without the matching change on the other.

This article is the operational etiquette that prevents them. It covers the allowlist exchange that opens a new connection and the address-change notice that keeps an old one working. It covers maintenance notices in both directions and the shared connection sheet that makes every conversation start from the same facts. It also covers a way to test a rule change in daylight without touching the nightly feed. It is written for an administrator who has just been told "the partner needs our IP." That administrator is not yet sure which IP that is. I was that administrator once, and I gave them the wrong one.

This is the closing article of our Firewalls, NAT, and File Transfer series. It assumes the earlier articles' vocabulary — NAT, egress, allowlist, passive range. It applies that vocabulary to the half of the problem that lives on somebody else's network. That is the half you cannot log into.

Two Firewalls, One Feed

Picture a nightly feed: your job host pushes files to a partner's SFTP server. The path is your job host, your firewall (which applies source NAT), the internet, their firewall (which applies destination NAT and an allowlist), their server. For the feed to work, four addresses must agree:

• Your egress address — the public address your firewall stamps on the connection as it leaves. This is what the partner's allowlist must contain. It is not your job host's address, which is private and meaningless to them.
• Their service address — the public address your job connects to, which their firewall forwards to the real server. This is what your egress rule must contain.
• Their egress address, if they also connect to you; and your service address, if you host anything for them.

The single most common partner firewall mistake is confusing the first two categories. A partner asks "what is your IP?" Someone answers with the job host's 10.0.20.30, which the partner dutifully allowlists. Nothing works, both sides insist their firewall is correct, and both are right. The NAT types article explains why the private address never leaves your building. Here the point is that the exchange must name which kind of address is being asked for.

The Shared Connection Sheet

A connection sheet is a single document, shared with the partner, that records every fact both firewalls depend on. It is the antidote to "I think it was 203-something." One sheet per partner, one row per flow, kept where both sides can read it, and updated as part of every change. The template below fits in a wiki page or a spreadsheet; copy it as is.

Two fields deserve emphasis. The egress address row must list every address a connection might leave from. That includes a firewall pair, a NAT pool, a cloud region's outbound addresses. A partner who allowlists one of two will see the feed fail on whichever nights the other is used. Our high-availability series covers why redundant firewalls produce this. The server identity row matters because address changes and key changes travel together. A job that trusts a recorded host key will refuse a new server at a new address until someone updates it. See host keys and known_hosts. The sheet is a cousin of the flow inventory in our documenting transfer flows series. It is written to be shared outside the organization, so it contains nothing you would not show a partner. The sheet will not tell you when it is stale. The last-verified row will.

The Allowlist Dance

Opening a new partner connection has a fixed choreography, and skipping a step is where the week disappears. In order:

1. Find your own egress address. Do not guess. Read it from your firewall's NAT rule for the job host. Or ask the partner what source address appears in their firewall log when you attempt a connection — the log never lies. If you have more than one, list them all.
2. Send the partner a precise request. Addresses, port, protocol, and direction, in one message their network team can paste into a change ticket. The template below is enough.
3. Ask for theirs in the same shape. Ask for the service hostname and address, port, protocol, and passive range if FTP or FTPS. Ask for their server's identity (host key fingerprint or certificate details) so you can verify it on first contact.
4. They add their rule first. Until the partner's allowlist contains your address, nothing you do can succeed.
5. You add your egress rule and test in layers. Start with a bare TCP test to the port, then a login with a test account, then a test file. These are the same layers the troubleshooting playbook uses when something fails.
6. Both sides record it in the connection sheet, with the date and who tested.

Subject: Firewall allowlist request - nightly invoice feed (Example Corp -> Partner)

Please allow inbound TCP port 22 (SFTP) to sftp.partner.example.com
from the following source addresses. These are our firewall's public
egress addresses; connections may arrive from either.

    203.0.113.5
    203.0.113.6

Direction: we connect to you. We do not require inbound access from you.
Requested by: Alex Rivera, transfers@example.com
Test plan: once in place, we will upload PING-<date>.txt with the
xfer-test account and ask you to confirm receipt.

Three things go wrong here more than anything else. Someone supplies a private address. Someone supplies a hostname, which the partner's firewall resolves once and forgets. The rule quietly points at the wrong address after the next DNS change. Give addresses, with the hostname only as a label. And someone forgets the second egress address, so the feed works four nights out of seven. I have been that someone. The full onboarding process around these steps — accounts, folders, contracts — is in the partner onboarding runbook.

Meridian Parts onboarded a new logistics partner in under two weeks, after three earlier onboardings that had each taken more than a month. The difference was one email. The transfer administrator sent the request above almost verbatim: both egress addresses, the port, the protocol, the direction, and a test plan. It was in a shape the partner's network team could paste straight into their change ticket. The partner replied with theirs in the same shape, passive range included. Their rule went in on the Wednesday. The transport test passed on the Thursday, and the synthetic file was confirmed before lunch. Nobody had to ask "which IP?" because the message had already said which.

If the partner receives your connections on an FTP or FTPS service, one more exchange is required. In that case, you need their passive range so your egress rule can allow it. They need to know your firewall will not run an FTP helper against their encrypted control channel. Their server must therefore announce its public address itself. That conversation is easier when both sides have read the article on helpers. That conversation is a good moment to ask whether they would accept SFTP instead. It is a cheap question, and every so often the answer is yes.

Address Changes on Either Side

Addresses change: a new internet provider, a firewall replacement, a move to a hosted gateway, a cloud migration. Every change on your side breaks every partner rule containing the old address, and every change on theirs breaks yours. The change is trivial; the coordination is the work. The sequence that never breaks a feed is add, overlap, cut over, confirm, remove:

1. Notify early. Two weeks' notice is a reasonable minimum for partners with a change process; some need a month. Send the notice to the technical contact on the connection sheet, not to whoever last emailed you.
2. Ask them to add the new address alongside the old one. Never "replace." During the overlap both addresses work, so the cutover date can slip without consequence.
3. Cut over on the announced date, during your change window and outside both sides' freeze periods.
4. Confirm with the agreed test procedure, and watch the first live run. The daytime test passes and the two o'clock job is the one that matters.
5. Ask them to remove the old address only after the first successful live run, and update the sheet.

Subject: Notice of IP address change - Example Corp transfer egress

What is changing: our outbound (egress) addresses for all transfer
connections to you.
    Current:  203.0.113.5, 203.0.113.6
    New:      198.51.100.40, 198.51.100.41
Effective: the second Tuesday of next month, during our 10:00-12:00 window.
Requested action: please ADD the new addresses to your allowlist now,
keeping the current ones. We will confirm cutover by email and ask you
to remove the old addresses one week after the first successful run.
Not changing: hostnames, ports, protocol, accounts, host keys.
Rollback: if the first run after cutover fails, we revert to the current
addresses, which is why both must remain allowed during the overlap.
Contact: transfers@example.com / on-call phone on the connection sheet.

Say explicitly what is not changing. A partner who reads "address change" may assume a new server, host key, or certificate and start updating things that did not need updating. When those are changing too, say so in the same notice and give the new fingerprint or certificate details up front. That way, the first connection to the new address is verified rather than blindly accepted. Migrations that change several of these at once are covered in partner coordination in migrations.

When the change is on the partner's side, be the partner you would want. Acknowledge the notice. Add the new address on receipt rather than the night before. Confirm when it is in. Update your connection sheet and your partners address set in the same ticket. A silently ignored change notice is the most common cause of "it worked yesterday" tickets that turn out to be nobody's fault. Nobody's fault is the hardest kind to close.

Maintenance Notices

Firewall maintenance — firmware, rule cleanups, hardware swaps — does not change addresses, but it does interrupt connections. A nightly job that runs during the window fails just as surely. A maintenance notice is shorter than a change notice. It needs only what is affected (all transfer connections, or one service) and when (start and end, with time zone). It also needs what a partner will see (connections refused or timing out) and what they should do (retry after the window; nothing else). Finally, it needs who to contact if it overruns. Firmware does not read maintenance notices.

Timing is the substance. Look at the connection sheet's schedule column and place the window where no feed runs and, above all, nowhere near a partner's cutoff. A file that misses a processing deadline because your firewall was rebooting is a business problem, not a technical one. The cutoff times and deadlines article explains why those deadlines are less flexible than they look. Ask partners for their maintenance calendars in return. Put both sides' freeze periods on the sheet so nobody schedules a firewall change on the last day of the quarter.

Testing a Rule Change Without Breaking the Nightly Feed

The nightly feed is the thing you must not break, so never let it be the test. A rule change — yours or the partner's — is tested in daylight, with a test account, and with the old path still in place. The method:

1. Add before you remove. The new rule goes in alongside the old one. If the change is a replacement, the old rule stays until the new one is proven.
2. Test the transport first. From the job host, a bare TCP test to the partner's port: Test-NetConnection sftp.partner.example.com -Port 22. This proves the firewalls on both sides without involving accounts or files.
3. Test the session next. Log in with the test account on the sheet and upload the agreed synthetic file. This is a small text file named so it can never be mistaken for real data, such as PING-Mar14.txt. The partner confirms receipt. Our testing and staging series covers why the test account and file need to exist before the day you need them.
4. Read the logs on both sides. Your firewall log should show the new rule accepting the connection; the partner's server log should show the login. Ask for their line; send yours. One log each side is the difference between "it seemed to work" and "it worked."
5. Watch the first live run. Someone checks the job's result at the scheduled time, not the next morning. A change night deserves a human.
6. Remove the old rule after the first clean live run, and close the ticket with the log lines attached.

The whole daytime sequence, from the job host, fits in three commands and a confirmation email:

PS C:\> Test-NetConnection sftp.partner.example.com -Port 22 | Select TcpTestSucceeded
TcpTestSucceeded
----------------
            True

PS C:\> sftp xfer-test@sftp.partner.example.com
sftp> put PING-Mar14.txt /inbound/test/
Uploading PING-Mar14.txt to /inbound/test/PING-Mar14.txt
sftp> ls -l /inbound/test/
-rw-r--r--    1 xfer-test  partners       28 Mar 14 10:42 PING-Mar14.txt
sftp> quit

(email partner: "PING-Mar14.txt uploaded 10:42 via new egress 198.51.100.40 - please confirm receipt and send the matching log line")

On the receiving side, the same discipline applies to your own server's allowlists. When a partner's new address goes into the firewall's partners set, add it to the server-side IP allow list in the same change. A server such as Sysax Multi Server keeps IP allow and block lists of its own. A partner allowed at the perimeter but still blocked at the server produces a confusing failure. It is a firewall accept followed by a server refusal that costs an hour to read.

When the Partner Cannot Cooperate

Some partners cannot give a stable address. They are behind carrier-grade NAT, their outbound traffic comes from a cloud service whose addresses change, or their staff connect from wherever they happen to be. Some refuse outright to maintain allowlists. In each case, do not respond by opening the service to the world for everyone. Give that partner a rule of their own with a source of any, restricted to a protocol with strong authentication — SFTP with keys rather than passwords. Lean on the server-side defenses described in IP allowlisting and geo-blocking. Record the exception on the connection sheet with the reason, so that a future reviewer does not "fix" it back into an outage.

If the partner hosts the service and cannot give you a fixed address to connect to, ask for the full list or the address block. The service might be behind a load balancer that answers from many addresses, say. Revisit the list or block at every review. A hostname in the sheet and a block in the rule is the workable compromise. Workable is the word for it.

The Partner Firewall Change Checklist

Everything above, in the order it happens. Print it, or put it at the top of the change ticket template.

• Connection sheet exists for this partner and was verified within the last review period.
• Change notice sent to the sheet's technical contact, at least two weeks ahead, stating what changes, what does not, effective date, overlap period, rollback, and contact.
• Partner acknowledged and confirmed their side is in place (their rule first when we connect to them; ours first when they connect to us).
• New rule or address added alongside the old; nothing removed yet.
• Change scheduled inside both sides' change windows and outside both sides' freeze periods and cutoffs.
• Transport test, session test with the test account, synthetic file confirmed by the partner, log lines exchanged.
• First live run watched by a person; result recorded.
• Old rule or address removed on both sides; server-side allow lists updated; connection sheet updated with date and tester; ticket closed with evidence.

The Short Version

Partner firewall problems are coordination problems. Keep one shared connection sheet per partner with every address, port, identity, schedule, contact, and window on it. Exchange egress and service addresses precisely — the address traffic leaves from, the address it connects to. Never give the machine doing the work, never a hostname alone. Always give every address a redundant firewall might use. Change addresses by add, overlap, cut over, confirm, remove, with a notice that says what is not changing. Place maintenance away from cutoffs. Test in daylight with a test account and a synthetic file. Read both sides' logs, and watch the first live run before removing anything. And when they ask "what's your IP?", know which one they mean before you answer.

That closes the series. The rules you exchange with partners are designed in designing transfer-friendly firewall rules. The failures that survive the coordination are diagnosed in the firewall troubleshooting playbook. The same partners will need wider communication skills when a protocol changes rather than an address. For those skills, partner communications in the plain-FTP retirement series is the natural next read.

Frequently Asked Questions