- Products
- Learn
- Local User Groups
- Partners
- More
The State of Ransomware Q1 2026
Key Trends and Their Impact
Good, Better, Best:
Prioritizing Defenses Against Credential Abuse
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
CheckMates Go:
CheckMates Fest
Hello All,
i've deployed a test instance of CloudGuard R81.20 - Build 043 into azure. It's managed via my on - premise management and that works fine.
What is confusing me is that i've added a subnet to the vnet it's in, associated the routing to it as per this https://community.checkpoint.com/fyrhh23835/attachments/fyrhh23835/CloudNetworkSecurityforum-board/3... and stuck a webserver behind it.
If I ssh onto the gateway it can ping the webserver. However, with the tiny policy deployed with two sample nat rules, it's trying to send the traffic somewhere totally different.
My test web server sits on 10.99.102.4 and the nat rules are simply redirecting https on port 83 and ssh on port 9922 sent to the gateway into the web server instead.
however snopping the traffic on the external facing interface it's sending it somewhere totally different and for the life of me I cannot think why. I cannot trace 227.237.5.164 in the config.
11:14:05.634811 IP 81.96.174.209.60445 > 227.237.5.164.https: Flags [S], seq 2402835880, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
11:14:07.392929 IP 81.96.174.209.60444 > cloudguardtestfw.mit-ml-dev: Flags [S], seq 974277547, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
11:14:07.392958 IP 81.96.174.209.60444 > 227.237.5.164.https: Flags [S], seq 974277547, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
11:14:11.402384 IP 81.96.174.209.60444 > cloudguardtestfw.mit-ml-dev: Flags [S], seq 974277547, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
11:14:11.402457 IP 81.96.174.209.60444 > 227.237.5.164.https: Flags [S], seq 974277547, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
11:14:19.409562 IP 81.96.174.209.60444 > cloudguardtestfw.mit-ml-dev: Flags [S], seq 974277547, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
the routing is simple
cloudguardtestfw> show route
Codes: C - Connected, S - Static, R - RIP, B - BGP (D - Default),
O - OSPF IntraArea (IA - InterArea, E - External, N - NSSA),
IS - IS-IS (L1 - Level 1, L2 - Level 2, IA - InterArea, E - External),
A - Aggregate, K - Kernel Remnant, H - Hidden, P - Suppressed,
NP - NAT Pool, U - Unreachable, i - Inactive
S 0.0.0.0/0 via 10.99.100.1, eth0, cost 0, age 25579
S 10.99.99.0/24 via 10.99.101.1, eth1, cost 0, age 25579
C 10.99.100.0/24 is directly connected, eth0
C 10.99.101.0/24 is directly connected, eth1
S 10.99.102.0/24 via 10.99.101.1, eth1, cost 0, age 25579
C 127.0.0.0/8 is directly connected, lo
Any thoughts ? It's perplexing me
Many thanks
Ian
Hi,
what is the IP configured on the object of the CloudGuard GW ? if it's the Public IP your configuration won't work.
The GW doesn't know that IP (network wise) because Azure is doing the NAT towards your GW (like a 3rd party router in front of the GW).
It only knows its Private External and Internal IP addresses.
you need to have a the NAT rule like this:
Any > GW Private External IP (Create a Host with this IP) > 83 ----- NAT------- Any > Server > 443
Hey Ian,
What do you see if you do zdebug for that IP? fw ctl zdebug + drop | grep 227.237.5.164
Alternatively, you can also do fw monitor -F just for that IP as dst
example -> fw monitor -F "0,0,227.237.5.164,0,0"
Andy
Thanks for the reply;
fw ctl zdebug + drop | grep 227.237.5.164 returns nothing
fw monitor -F "0,0,227.237.5.164,0,0" returns nothing
fw tab -t connections -u -f
shows this
12:08:50 5 N/A 3 10.99.100.4 > N/A LogId: <max_null>; ContextNum: <max_null>; OriginSicName: <max_null>; : -----------------------------------(+); Direction: 1; Source: 81.96.174.209; SPort: 62126; Dest: 227.237.5.164; DPort: 83; Protocol: tcp; CPTFMT_sep_1: ->; Direction_1: 0; Source_1: 81.96.174.209; SPort_1: 62126; Dest_1: 10.99.100.4; DPort_1: 83; Protocol_1: tcp; FW_symval: 2050; LastUpdateTime: 7Jan2025 12:08:50; ProductName: VPN-1 & FireWall-1; ProductFamily: Network;
12:08:50 5 N/A 3 10.99.100.4 > N/A LogId: <max_null>; ContextNum: <max_null>; OriginSicName: <max_null>; : -----------------------------------(+); Direction: 0; Source: 227.237.5.164; SPort: 443; Dest: 81.96.174.209; DPort: 62126; Protocol: tcp; CPTFMT_sep_1: ->; Direction_2: 0; Source_2: 81.96.174.209; SPort_2: 62126; Dest_2: 10.99.100.4; DPort_2: 83; Protocol_2: tcp; FW_symval: 2054; LastUpdateTime: 7Jan2025 12:08:50; ProductName: VPN-1 & FireWall-1; ProductFamily: Network;when i do a monitor against my laptop sending the incoming traffic, I don't see the nat, that just appears in the log view and tcpdump.In fact i don't seem to see anything from eth1 (the internal interface) at all.
fw monitor -e "(host(81.96.174.209) and not tcpport(22)), accept;" -p all
[vs_0][fw_1] eth0:i9 (IP Options Strip (in))[44]: 81.96.174.209 -> 10.99.100.4 (TCP) len=52 id=6051
TCP: 62343 -> 83 .S.... seq=f36cb279 ack=00000000
[vs_0][fw_1] eth0:i10 (Stateless verifications (in))[44]: 81.96.174.209 -> 10.99.100.4 (TCP) len=52 id=6051
TCP: 62343 -> 83 .S.... seq=f36cb279 ack=00000000
[vs_0][fw_1] eth0:i11 (fw multik misc proto forwarding)[44]: 81.96.174.209 -> 10.99.100.4 (TCP) len=52 id=6051
TCP: 62343 -> 83 .S.... seq=f36cb279 ack=00000000
[vs_0][fw_1] eth0:i12 (fw VM inbound )[44]: 81.96.174.209 -> 10.99.100.4 (TCP) len=52 id=6051
TCP: 62343 -> 83 .S.... seq=f36cb279 ack=00000000
[vs_0][fw_1] eth0:I13 (fw SCV inbound)[44]: 81.96.174.209 -> 10.99.100.4 (TCP) len=52 id=6051
TCP: 62343 -> 83 .S.... seq=f36cb279 ack=00000000
[vs_0][fw_1] eth0:I14 (fw offload inbound)[44]: 81.96.174.209 -> 10.99.100.4 (TCP) len=52 id=6051
TCP: 62343 -> 83 .S.... seq=f36cb279 ack=00000000
I can't see where the address is coming from.
What about fw monitor -e "accept host(227.237.5.164);"
Any difference if you tried turning off sxl?
Andy
Your tcpdump shows: internet -> 227.237.5.164:443
Your NAT config wants internet -> 227.237.5.164:83 and then nat to 10.99.102.4:443
I assume 227.237.5.164 belongs to CloudGuardTest?
So either you test incorrect or NAT should be the other way around. Or i misunderstand?
Thats also my understanding based on how NAT is configured.
Andy
Hi Lesley, that is the confusing thing, it's not the address of the gateway or anything defined in the environment.
Hi,
what is the IP configured on the object of the CloudGuard GW ? if it's the Public IP your configuration won't work.
The GW doesn't know that IP (network wise) because Azure is doing the NAT towards your GW (like a 3rd party router in front of the GW).
It only knows its Private External and Internal IP addresses.
you need to have a the NAT rule like this:
Any > GW Private External IP (Create a Host with this IP) > 83 ----- NAT------- Any > Server > 443
Hi Nir,
you are correct, I had the nat rule for the external azure address not the gateway external facing interface, once i had changed that it's all working as expected. Thank you very much. I think I confused my self as I am using the external address to manage it, so that is what is configured on the object as the primary address.
Re-reading the document I linked to, it does say 'frontend private IP' but I didn't use that as my management is not in the cloud. My fault.
Thanks to you, and everyone else for helping.
Ian
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 4 | |
| 3 | |
| 2 | |
| 1 | |
| 1 |
Tue 12 May 2026 @ 10:00 AM (CEST)
The Cloud Architects Series: Check Point Cloud Firewall delivered as a serviceWed 13 May 2026 @ 11:00 AM (EDT)
TechTalk: The State of Ransomware Q1 2026: Key Trends and Their ImpactThu 14 May 2026 @ 07:00 PM (EEST)
Under the Hood: Presentando Check Point Cloud Firewall como ServicioTue 12 May 2026 @ 10:00 AM (CEST)
The Cloud Architects Series: Check Point Cloud Firewall delivered as a serviceAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY