Ok...I ran your EXACT query through MS copilot and below is what it gave me. Maybe someone else or TAC can provide you better info, but see if any of this is useful to you.
Below is a practical, end‑to‑end runbook for a Check Point Quantum Spark 1600 to keep a BSNL SIP trunk working when the primary ISP link fails—plus an honest explanation of your “keep the primary SIP source IP during failover” requirement (because that part is usually not technically possible without ISP/BSNL changes).
0) Critical feasibility note (very important)
What you want (in one sentence)
When WAN1 fails, you want SIP/RTP to go out WAN2 but still appear to come from WAN1’s public IP 116.74.149.94.
Why that usually can’t work
If traffic exits WAN2 with a source IP that does not belong to WAN2 (116.74.149.94), most ISPs will drop it due to anti‑spoofing/uRPF filtering (and the return path won’t know how to route it back). In other words: a firewall cannot “pretend” to be 116.74.149.94 on a different ISP unless the network upstream is explicitly routing that IP via the backup link.
Also, on Locally Managed Quantum Spark, there are NAT limitations when multiple Internet connections are involved (see below). [support.ch…kpoint.com], [sc1.checkpoint.com]
Therefore, you have only 3 realistic design choices
Option A (Recommended & most common):
Ask BSNL to accept both public IPs (116.74.149.94 and 117.139.107.109) for the trunk (whitelist / bind / register). Then Spark can fail over cleanly, but the source IP changes on failover.
Option B (True “same IP during failover”):
Your ISP(s) must provide IP takeover / routing so that 116.74.149.94 remains reachable via WAN2 during WAN1 outage (e.g., a portable prefix with BGP, static routing of 116.74.149.94 to WAN2, or a Layer‑2 extension). Without that, it won’t work.
Option C (Carrier‑grade workaround):
Use a hosted SBC / SIP proxy (or cloud edge) with a fixed public IP and register BSNL trunk to that. Your site then connects to the SBC over either ISP.
Everything below shows Option A (best practice with Spark) and what is required for Option B.
1) Your parameters (as provided)
- BSNL SIP Trunk Server (cloud):
117.198.215.109
- Primary circuit public IP (WAN1):
116.74.149.94
- Secondary circuit public IP (WAN2):
117.139.107.109
- Requirement: failover WAN1 → WAN2 automatically, keep SIP stable.
2) What firmware/features you should be on
Use SD‑WAN (Locally Managed) for deterministic SIP failover
Check Point states that SD‑WAN is available on Locally Managed Quantum Spark starting in R81.10.10 and it can steer traffic to a primary ISP and use a secondary ISP as backup. [sc1.checkpoint.com], [support.ch…kpoint.com]
VoIP inspection is supported and configurable
VoIP/SIP inspection is supported and configured under Access Policy > VoIP. [sc1.checkpoint.com]
Target: R81.10.10+ to use SD‑WAN steering cleanly. [sc1.checkpoint.com], [support.ch…kpoint.com]
3) High‑level topology (recommended)
- Spark 1600 has two Internet connections configured (WAN1 and WAN2).
- SIP signaling (UDP/TCP 5060 typical) and RTP media (port range from your PBX/vendor) are steered:
- Prefer WAN1
- Fail over to WAN2 automatically based on link probing/quality
SD‑WAN explicitly supports steering traffic per application/service over specific interfaces and includes probing for loss/latency/jitter to decide link choice. [sc1.checkpoint.com]
OPTION A (Recommended): Failover works, but source IP changes (BSNL must accept both IPs)
In the SD‑WAN guide for Spark, Check Point’s SD‑WAN setup requires at least two Internet connections, with configured upload/download speeds and optional “backup” designation. [sc1.checkpoint.com], [support.ch…kpoint.com]
Steps
- Device view → Network/Internet Connections
- Create Internet Connection 1 (WAN1)
- Type: Static
- IP:
116.74.149.94 (plus mask/gateway from ISP1)
- Set correct DNS (ISP or public)
- Create Internet Connection 2 (WAN2)
- Type: Static
- IP:
117.139.107.109 (plus mask/gateway from ISP2)
- In each connection:
- If WAN2 is only for failover (recommended for SIP stability):
5A) Enable/verify SD‑WAN and set probing (link health)
Check Point’s SD‑WAN page describes:
Steps
- Go to Access Policy → Firewall → SD‑WAN
- Confirm SD‑WAN blade enabled
- Configure Global SD‑WAN Probing Settings:
- Probing hosts (use at least two “internet stable” + the SIP server):
- Host 1:
117.198.215.109 (BSNL SIP Server)
- Host 2:
8.8.8.8
- Host 3:
1.1.1.1
- Set interval (e.g., 500–1000 ms) and thresholds for:
- In Smart SD‑WAN prioritization of ISP links, select Prioritize
6A) Create a SIP‑specific Steering Behavior (recommended)
Spark allows user‑defined Steering Behavior objects where you:
Steps
- Access Policy → Firewall → SD‑WAN
- Click Policy tab → Manage Behaviors → New
- Name:
STEER_BSNL_SIP_PRIMARY_BACKUP
- Thresholds (example—tune to your environment):
- Steering Candidates:
- Link Utilization:
- Probing (override global if desired):
- Host 1:
117.198.215.109
- Host 2:
8.8.8.8
- Host 3:
1.1.1.1
- Probing mode: Best (typical) [sc1.checkpoint.com]
- Save
7A) Build the SD‑WAN rule for BSNL SIP traffic
SD‑WAN rules steer traffic by Source / Destination / Application/Service and apply top‑down. [sc1.checkpoint.com], [support.ch…kpoint.com]
Steps
- Access Policy → Firewall → SD‑WAN → Policy tab
- Click New rule near the top (so it matches before generic rules) [sc1.checkpoint.com]
- Create / select objects:
- Source: your PBX IP or Voice VLAN subnet
- Destination: host object
BSNL_SIP_SERVER = 117.198.215.109
- Service: SIP + RTP services (see next section)
- Steering/Behavior:
- Choose
STEER_BSNL_SIP_PRIMARY_BACKUP
- Save/Apply
Check Point documents VoIP setup:
- Access Policy > VoIP
- Enable Use SIP Provider (add the SIP provider’s IP)
- Optional: Disable SIP traffic inspection
Steps
- Go to Access Policy → VoIP
- Toggle VoIP = On [sc1.checkpoint.com]
- Under Off‑premise SIP Provider Service:
- Enable Use SIP Provider
- Add IP:
117.198.215.109
- Enable logging (recommended during testing) [sc1.checkpoint.com]
- Decide on SIP inspection:
- Start with inspection enabled (default behavior)
- If you experience one‑way audio/registration issues, test with Disable SIP traffic inspection
(Doc notes that disabling SIP inspection requires manual RTP port definition and changes SIP UDP timeout behavior.) [sc1.checkpoint.com]
- Ensure SIP service ports match your PBX/trunk:
- Define RTP port range
- Use the PBX vendor’s RTP range (common ranges are 10000–20000, 16384–32767, etc.—do not guess, confirm on PBX)
- If SIP inspection is disabled, RTP must be explicitly allowed. [sc1.checkpoint.com]
9A) Firewall policy rules (allow SIP + RTP)
Check Point notes that VoIP configuration automatically creates rules and NAT forwarding rules depending on topology, but you can also define explicit access rules. [sc1.checkpoint.com]
Steps (recommended explicit approach)
- Access Policy → Policy
- Add rules near the top:
- PBX → BSNL_SIP_SERVER → SIP (UDP/TCP 5060) → Accept → Log
- PBX → BSNL_SIP_SERVER → RTP range → Accept → Log
- If BSNL sends inbound SIP to you (common), add:
- BSNL_SIP_SERVER → PBX → SIP + RTP → Accept → Log
If your trunk is “IP‑bound”, BSNL may only send inbound calls to the IP they have on file—this is why Option A requires BSNL to accept/route to WAN2 IP during failover.
10A) NAT approach for Option A (keep failover working)
Use “Hide behind the gateway” (not static source NAT)
- Quantum Spark NAT control explains hide NAT and warns about turning it off. [sc1.checkpoint.com]
- SD‑WAN guidelines explicitly warn that SD‑WAN does not support ISP link redundancy for outbound traffic in some NAT cases (notably when manual static NAT is involved), and recommends using “Hide behind the gateway” when you need redundancy. [sc1.checkpoint.com]
Do this:
- Keep outbound NAT as Hide internal networks behind the Gateway’s external IP address (default hide NAT). [sc1.checkpoint.com], [sc1.checkpoint.com]
- Avoid manual static source NAT for SIP in this option.
✅ Result: When WAN1 fails, SD‑WAN steers SIP out WAN2 and NAT uses WAN2’s public IP.
11A) Validate failover (testing checklist)
- Place a test call (inbound/outbound) with logging on.
- Physically unplug WAN1 / disable WAN1 connection.
- Watch SD‑WAN Performance tab:
- Confirm PBX re‑registers to BSNL and calls continue.
- Restore WAN1 and confirm traffic falls back (depending on your prioritize behavior).
OPTION B: “Keep source IP 116.74.149.94 even when using WAN2” (only possible with ISP/BSNL support)
4B) What you must arrange upstream (non‑negotiable)
To keep using 116.74.149.94 while the physical path is WAN2, you need routing/IP‑takeover such that:
- 116.74.149.94 is reachable when WAN1 is down (inbound)
- WAN2 ISP will forward/accept packets sourced from 116.74.149.94 (outbound)
Without that, packets will be dropped upstream, regardless of firewall NAT.
5B) Spark constraints that complicate Option B
(1) NAT limitation on Locally Managed Spark with multiple Internet connections
Check Point states: Locally Managed Quantum Spark supports only one static NAT IP address for one real IP address (and behavior is by design). [support.ch…kpoint.com], [sc1.checkpoint.com]
(2) SD‑WAN does not support Alias interfaces (and other limits)
SD‑WAN documentation lists unsupported items including Alias interfaces (and some other interface types). [sc1.checkpoint.com], [support.ch…kpoint.com]
(3) SD‑WAN + manual static NAT redundancy limitations
SD‑WAN planning guidelines warn that SD‑WAN redundancy is not supported for outbound traffic in some manual static NAT scenarios and recommends “Hide behind the gateway” instead. [sc1.checkpoint.com]
Implication:
If you force a fixed public IP via manual static NAT or aliasing, you may lose the “easy” SD‑WAN failover behavior and need routing/PBR/route‑probing approaches.
6B) If your ISP provides IP takeover: recommended approach
Use routing with probing + PBR (instead of SD‑WAN) for deterministic behavior
The SD‑WAN planning guide describes a pattern for Active/Backup ISP links:
- configure default routes with probing and priority
- use Policy Based Routing (PBR) for the server’s traffic so it follows the intended active default route priority [sc1.checkpoint.com]
Steps (high level, because ISP specifics vary)
- Disable SD‑WAN blade if you are moving to pure routing/PBR
(Spark SD‑WAN page shows disabling SD‑WAN via the SD‑WAN blade toggle/slider). [sc1.checkpoint.com]
- Configure two default routes (WAN1 priority better than WAN2) with probing (route monitoring). [sc1.checkpoint.com], [sc1.checkpoint.com]
- Configure PBR rule for:
- Source = PBX (or PBX subnet)
- Destination =
117.198.215.109
- Services = SIP + RTP
- Next hop selection follows probed default route priorities [sc1.checkpoint.com]
- Only if ISP routes
116.74.149.94 through WAN2 during failover:
- Create manual NAT to translate PBX source to
116.74.149.94 (and ensure inbound routing also works)
If you must keep SD‑WAN, note it explicitly does not support Alias interfaces and has NAT redundancy limitations. [sc1.checkpoint.com], [support.ch…kpoint.com], [sc1.checkpoint.com]
Practical recommendation (what I’d implement first)
- Implement Option A using SD‑WAN steering for SIP/RTP with WAN2 as backup (fast, reliable on Spark). [sc1.checkpoint.com], [support.ch…kpoint.com]
- Coordinate with BSNL to allow both public IPs for registration and inbound routing.
- If the business truly requires the same public IP always, pursue Option B with ISP(s) (portable prefix/BGP/static routing). Otherwise, use a hosted SBC.
- PBX IP address (and whether it’s a single PBX host or a voice subnet)
- RTP port range configured on the PBX (exact range)
- Does BSNL require UDP only or UDP+TCP for SIP? Any non‑5060 ports?
- Spark firmware version (R81.10.x exact build) and whether it is Locally Managed or managed by Spark Management / SmartConsole
- ISP1/ISP2 default gateways and subnet masks (or /30-/29 details)
If you share those, I’ll respond with a precise rule set (objects + SD‑WAN rules + VoIP settings + NAT strategy) that matches your environment exactly.
