Review this. Each of 46 partner organisations gets a site-to-site VPN into the shared-services network of a logistics platform with static routes per partner and a jump host that partner support staff log into. The per-partner firewall rule set has grown to about 1100 rules and two partners' address ranges overlap and are translated. What would you remove, what would you change, and what would you leave alone?

What is actually required

Partners need to reach a small number of your endpoints, and you need to reach a small number of theirs. Nothing in that statement requires network-layer connectivity between two organisations' address spaces, which is what a site-to-site VPN provides and what every item below is a consequence of.

What I would remove, and why it is safe to

• The jump host for partner staff. A shared host that 46 external organisations log into is a lateral-movement path with a hostname. Whatever it is used for - support access, file drops, a terminal into an internal tool - has a specific replacement: a published web endpoint, a managed file transfer service, or a support portal. Remove the general capability and re-provide the specific one.
• Static routes per partner. They are the reason adding a partner is a change-control event and the reason nobody can say what is reachable. They go with the VPNs they describe.
• Most of the 1100 rules. The set is unmaintainable by construction: nobody can safely delete a rule because nobody knows which partner stopped trading in 2021. Rebuild from the required flows - typically 2 to 4 per partner - rather than auditing what exists. An audit of 1100 rules produces 1100 rules.

The one change that matters

Replace network-level connectivity with service-level connectivity. Each partner gets access to a named endpoint - a private endpoint service, a mutually authenticated HTTPS API, or a managed file transfer - and no route to anything else. The isolation stops depending on firewall rules being correct, because there is no path for a wrong rule to open: the partner's network and yours are never joined.

This also dissolves the overlapping-CIDR problem, which only exists because the address spaces were merged in the first place.

Do it partner by partner, newest first, and stop onboarding anyone onto the VPN pattern today. The 46^th partner is cheap to move; the first is the one with a 9-year-old integration nobody understands.

What I would leave, even though it looks odd

• The two translated overlaps. They are ugly and they work, and both partners will be migrated to endpoints anyway. Re-addressing them now spends months on a path that is being deleted.
• VPN for the two or three partners who genuinely need multi-protocol access - a legacy EDI gateway, a device fleet speaking a non-HTTP protocol. The pattern is not wrong; using it 46 times is. Put those in their own isolated network with no route to shared services.

How I would argue this in the review

With one number and one question. The number: 1100 rules for 46 partners is 24 rules each, and the required flows are 2 to 4 - so roughly 85% of the rule set is unexplained. The question: if one partner is compromised tomorrow, what can the attacker reach? If the answer takes more than a minute to establish, the design has already failed, and that is an argument about evidence rather than taste.

Common weak answers

• "Audit the 1100 rules." An audit of 1,100 rules produces 1,100 rules, because no reviewer will take responsibility for deleting one whose purpose is unknown. Rebuild from required flows instead.
• "Move the VPNs behind a firewall appliance." Adds a device and keeps the property that matters - two address spaces joined, with isolation depending on rules being right.
• "Re-address the overlapping partners first." Months of work on a path that is being deleted.
• "Keep the jump host but add multi-factor authentication." Better, and it leaves 46 external organisations with interactive access to a host inside shared services.