- Products
- Learn
- Local User Groups
- Partners
- More
AI Security Masters E7:
How CPR Broke ChatGPT's Isolation and What It Means for You
Blueprint Architecture for Securing
The AI Factory & AI Data Center
Call For Papers
Your Expertise. Our Stage
Good, Better, Best:
Prioritizing Defenses Against Credential Abuse
Ink Dragon: A Major Nation-State Campaign
Watch HereCheckMates Go:
CheckMates Fest
Hi everyone,
I have a question about NAT in a VPN tunnel. So far I don’t have any experience with this in a Check Point environment.
Current situation: There is already an existing VPN tunnel, and we want to make a server on our side available to the remote side, but have it hidden behind a different IP address using NAT.
How should the NAT rule be configured in Check Point for this? And what happens first: the decryption of the VPN traffic or the NAT processing?
Remote Server -> Remote GW — VPN Tunnel—> CP GW -> local Server
NAT Rule:
src: any| dst: nat ip | dst Port | Transl src: orig | transl dst: IP local srv | transl dst Port : 443.
??
Thanks in advance!
best regards,
Roman
Hey Roman,
Technically, decryption will happen first, then NAT, Make sure to enable nat inside vpn community if its needed. Rule itself may look like below:
Src: Remote network (or “Any” if you prefer)
Dst: NAT IP (the external-looking IP you want the remote side to hit)
Port: 443 (or any port)
Translated Source: Original
Translated Destination: Real internal server IP
Translated Service: original (or mapped to 443 if different)
| Original Src | Original Dst | Service | Xlated Src | Xlated Dst | Xlated Svc |
|---|---|---|---|---|---|
| Remote LAN | 10.10.10.10 (NAT IP) | 443 | Original | 192.168.50.20 (Real server) | 443 |
Hey Roman,
Technically, decryption will happen first, then NAT, Make sure to enable nat inside vpn community if its needed. Rule itself may look like below:
Src: Remote network (or “Any” if you prefer)
Dst: NAT IP (the external-looking IP you want the remote side to hit)
Port: 443 (or any port)
Translated Source: Original
Translated Destination: Real internal server IP
Translated Service: original (or mapped to 443 if different)
| Original Src | Original Dst | Service | Xlated Src | Xlated Dst | Xlated Svc |
|---|---|---|---|---|---|
| Remote LAN | 10.10.10.10 (NAT IP) | 443 | Original | 192.168.50.20 (Real server) | 443 |
Hi Andy!
Thank you for the very detailed reply! I’ll try to set it up and test it tomorrow.
best regards,
Roman
Great! Message me directly if you are allowed to do remote, we can use zoom, I use my free account for that, since teams has lots of restrictions these days.
Hi Andy! Ok, thanks for your offer! We have a technical meeting with the application developers today – they need to explain to us in detail the technical requirements and what exactly they need from the tunnel. I’ll get back to you 🙂
best regards,
Roman
Sounds good.
In case debug is needed, below is easiest:
vpn debug trunc
vpn debug ikeon
-generate traffic
vpn debug ikeoff
Look for iked* and vpnd* files in $FWDIR/log dir
Extra tip for encryption domains, make sure you add real ip and nat ip that is assigned to your network in your local encryption domain. Add remote NAT ip range to remote peer encryption domain. (depends if remote peer also is natting)
what the the_rock states is true, other way around is first NAT then encryption (from local to remote peer)
Yes sir! Definitely always a good idea to add natted IP in vpn domain as well.
Hi @Lesley Ok, this is roughly how I imagined it. I’m waiting for confirmation from the DevOps team and then I will test it. Many thanks for your tip.
best regards,
Roman
Hi!
Thank you very much for your support!
Our application developers have finally tested the tunnel.
Everything worked well, and I learned something new.
Thanks!
Glad you got it working.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 8 | |
| 8 | |
| 4 | |
| 3 | |
| 3 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 |
Tue 28 Apr 2026 @ 06:00 PM (IDT)
Under the Hood: Securing your GenAI-enabled Web Applications with Check Point WAFThu 30 Apr 2026 @ 03:00 PM (PDT)
Hillsboro, OR: Securing The AI Transformation and Exposure ManagementTue 28 Apr 2026 @ 06:00 PM (IDT)
Under the Hood: Securing your GenAI-enabled Web Applications with Check Point WAFTue 12 May 2026 @ 10:00 AM (CEST)
The Cloud Architects Series: Check Point Cloud Firewall delivered as a serviceThu 30 Apr 2026 @ 03:00 PM (PDT)
Hillsboro, OR: Securing The AI Transformation and Exposure ManagementAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY