How to Lock Down IKE and IPsec Ports to Known VPN Peers

When Check Point disclosed CVE-2026-85102 and CVE-2026-85103 in September 2026, its interim workaround for site-to-site VPN was blunt: disable the implied rules for VPN and manually allow UDP/500 and UDP/4500 only from specific peer addresses. That advice generalises to any perimeter firewallFirewall🌐Security system that monitors and controls network traffic based on predetermined rules. that terminates IPsecIPsec🌐A suite of protocols that authenticates and encrypts IP traffic at the network layer, used for site-to-site tunnels between gateways and for many remote-access VPNs. IKE handles the negotiation; ESP carries the protected packets. tunnels, and it is worth doing on a normal day, not only during an incident. This guide walks through the reasoning, the change, and how to confirm it worked.

Why the VPN listener is usually open to the world

IPsec uses two UDP ports for the control plane: 500 for IKE and 4500 for IKE and ESP encapsulated in UDP when NAT traversal is in play. On most firewall platforms, enabling a VPN feature automatically permits inbound traffic to those ports from any source. Check Point calls these implied rules; other vendors have equivalents under names like system policies, auto-generated rules, or service policies. The idea is convenience: an administrator should not have to remember to open the ports the VPN needs.

The cost of that convenience is that the IKE daemon is reachable by every host on the internet. That is unavoidable for remote-access VPN, where clients connect from hotel Wi-Fi and home networks with changing addresses. It is completely avoidable for site-to-site VPN, where every legitimate peer is another gateway with a known, static public address. Leaving the listener open to everyone when you know exactly who should be talking to it is unnecessary exposure of the pre-authentication certificate-parsing code that the explainer on why VPN certificate parsing is pre-authentication attack surfaceAttack Surface🛡️The sum of all points where an unauthorized user could attempt to enter or extract data from a system: exposed services, interfaces, accounts, and integrations. Reducing attack surface means removing reachability, not just patching. describes.

Step 1: build the peer list

Before touching policy, produce an authoritative list of every remote gateway your firewall should negotiate with. Sources to reconcile:

• The VPN community or tunnel definitions on the firewall itself. Each peer object has a public IP addressIP Address🔐A unique numerical identifier assigned to every device connected to the internet. or a resolvable name.
• The other side's documentation. Partner organisations and cloud VPN endpoints sometimes have more than one public address, and some cloud providers announce ranges rather than single hosts.
• Historical logs. Pull the last 30 days of successful IKE negotiations and list distinct source addresses. Anything that has been negotiating successfully but is not in the tunnel definitions needs an explanation.

Watch for peers behind dynamic addresses. If a branch office sits behind a consumer connection with a changing IP, source filtering will break that tunnel. Those peers need either a static address, a different transport, or an explicit exception with its own risk acceptance.

Step 2: decide what happens to remote-access clients

If the same gateway also serves remote-access VPN, you cannot restrict UDP/500 and 4500 to the site-to-site peer list without cutting off every road warrior. Options, in rough order of preference:

1. Separate the roles. Terminate remote-access VPN on a different gateway or interface from site-to-site tunnels, so each listener can have its own policy.
2. If separating is not possible, restrict what you can. Keep the remote-access listener open but confirm the site-to-site peers are pinned, so a future site-to-site-only bug has a smaller blast radiusBlast Radius🛡️The full set of systems, data, and access an attacker can reach after compromising a given asset. Ranking assets by blast radius rather than by how exposed they are pushes high-reach systems like a firewall management console to the top of the priority list..
3. Accept the exposure explicitly and compensate with faster patching and monitoring. This is the honest position for many organisations, and it is better than pretending the filter helps when it does not.

Check Point's advisory is clear that its workaround is for site-to-site VPN. The same is true for any vendor: source filtering protects tunnels between known gateways and nothing else.

Step 3: replace the implied rule with explicit ones

The mechanics vary by platform, but the shape of the change is constant.

• Disable the automatic or implied rule that permits IKE and NAT-T from any source. On Check Point this is a global property setting; on other platforms it may be a per-interface service policy or a default rule you delete.
• Add an explicit rule near the top of the policy that allows UDP/500 and UDP/4500 to the gateway's external address from each peer in your list, and only those peers. Group the peer addresses into a single object so the rule stays readable and future peers are added in one place.
• Make sure the rule is positioned above any broad deny and that logging is enabled on it. You want a record of every negotiation attempt, successful or not.
• If your platform requires it, add the matching rule for ESP (IP protocol 50) from the same peers. Many deployments use NAT-T exclusively and never see raw ESP, but check your tunnel configuration before assuming.

Do this during a maintenance window and have the peer administrators reachable. A typo in a peer address will drop that tunnel, and the failure will look like a dead peer rather than a firewall rule.

Step 4: verify from both directions

A policy change that is not tested is a change that will fail at an inconvenient time.

• From a host that is not in the peer list, attempt an IKE negotiation against the gateway's external address and confirm it gets no response. Do this from outside your network, not from a lab segment that might match an internal allow rule.
• From each configured peer, confirm the tunnel re-establishes after you bounce it. Check that Phase 1 (IKE SA) and Phase 2 (IPsec SA) both complete; a tunnel that stays up on cached keys can mask a broken rule until the next rekey.
• Review the firewall log for drops on UDP/500 and 4500. In the first days you will likely see scanning from unrelated addresses; that is the traffic you just stopped from reaching the IKE daemon. You should not see drops from configured peers.
• Add a monitor. A synthetic tunnel check or a simple alert on IKE drops from a known peer address will catch the case where a partner changes their public IP without telling you.

What this does and does not buy you

Pinning IKE to known peers removes the internet-wide scanning population from the VPN daemon's input. For a pre-authentication bug like CVE-2026-85103, that changes the attacker from "anyone" to "someone who has already compromised a partner gateway or can spoof its address on a UDP flow," which is a much smaller set. It is not a fix, and Check Point presents it as a mitigation to buy time until the hotfixHotfix🛡️An out-of-cycle software update that addresses a specific urgent defect, usually a security flaw, on an existing release line without waiting for the next scheduled version. Hotfixes are typically numbered and cumulative on that line, but each covers only the issues named in its notes, so a later one may be required. is applied. The piece on why live patchingLive Patching🛡️Applying a security fix to running software on an appliance or server without a full upgrade or reboot, often delivered automatically by the vendor. It shortens the exposure window but typically covers only supported releases and does not replace the full fixed release. perimeter appliances covers less than it seems goes through why the patch still matters even after the filter is in place.

It also does nothing for the remote-access listener, nothing for a management server that is reachable by other means, and nothing for a peer gateway that has itself been compromised. Treat the change as one layer, keep the patch schedule short, and revisit the peer list whenever a tunnel is added or retired.