Dual Starlink Enterprise → Peplink B One → Check Point: 1:1 NAT questions

Product Discussion
1

Hi everyone,

I’m looking for some advice on a dual-Starlink setup:

Starlink WAN1 + WAN2 → Peplink B One → Check Point Firewall → LAN

The Check Point should remain the actual firewall (security policy, DHCP and internal routing), while the Peplink handles the two WANs, load balancing and failover.

We initially wanted to use Drop-in/IP Forwarding, but Starlink Enterprise only provides one static public IPv4 per connection. Starlink has confirmed that we cannot obtain an additional/dedicated IPv4 address or configure port forwarding on the terminal, so Drop-in doesn’t appear to be possible.

We’re therefore considering 1:1 NAT on the Peplink to forward each Starlink public IP to the Check Point.

A few things I’d like to confirm from anyone running something similar:

  • Does Peplink 1:1 NAT preserve the original source IP for inbound traffic?
  • Can each WAN use its own public IP for outbound NAT?
  • How does 1:1 NAT behave when an active connection fails from WAN1 to WAN2?
  • Are there any particular issues with IPsec/NAT-T or other VPN protocols?
  • Is 1:1 NAT the recommended approach for this situation, or is there another Peplink configuration we should be considering?

The key requirement is to keep the Check Point as the real firewall while using the Peplink purely to manage the two Starlink WANs.

Thanks!

2

if your using the starlink public IP from each unit you would loose the Public IP if the starlink went down . I use public IP’s from a cloud provider with Fusionhub then forward over the starlink’ using speed fusion. currently im using Oracle cloud infrastructure for fusionhub . will setup a lad and test and replay back with results .Peplink does have nat mapping .

3

Thanks again for the detailed reply and for offering to test and report back — genuinely appreciated, and I think your FusionHub/SpeedFusion approach is a solid fix for people who can take on a cloud dependency.

For my specific case though, I don’t think I can go that route: this deployment can’t have its uptime tied to a third-party cloud provider on top of the two Starlink links. Adding an Oracle Cloud VM and a SpeedFusion tunnel as the thing the public IP depends on would mean I’m now relying on three things staying up instead of two, which works against the whole reason for having dual WAN in the first place.

Also, for context on the underlying issue: I’ve actually run Drop-in mode successfully before on a fiber connection where the ISP handed me a routed /30 — a real subnet with a spare address I could assign to the downstream firewall. Starlink doesn’t do that; the IP they give is on a shared /23 with other customers, not a block I own, so there’s no second address to hand off no matter how it’s configured on the Peplink side. That’s really the core of why Drop-in mode isn’t viable here at all, cloud workaround or not.

Given the no-cloud constraint, I’ll likely go with 1:1 NAT/DMZ on the Peplink directly, treating one Starlink line as primary for inbound and the other as backup, and accept that the firewall won’t literally own the public IP. Appreciate you sharing your setup either way — if you do get a chance to test it, I’d still be curious to see the results for anyone else who finds this thread without the same uptime constraint.