Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
ibrown
Participant
Jump to solution

Cloudguard in azure trying to send traffic to incorrect destination

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. cloudguard-nat.png

 

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

 

0 Kudos
1 Solution

Accepted Solutions
Nir_Shamir
Employee Employee
Employee

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

View solution in original post

0 Kudos
8 Replies
the_rock
Legend
Legend

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

0 Kudos
ibrown
Participant

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.

0 Kudos
the_rock
Legend
Legend

What about fw monitor -e "accept host(227.237.5.164);"

Any difference if you tried turning off sxl?

Andy

0 Kudos
Lesley
Mentor Mentor
Mentor

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?

-------
If you like this post please give a thumbs up(kudo)! 🙂
the_rock
Legend
Legend

Thats also my understanding based on how NAT is configured.

Andy

0 Kudos
ibrown
Participant

Hi Lesley, that is the confusing thing, it's not the address of the gateway or anything defined in the environment.

0 Kudos
Nir_Shamir
Employee Employee
Employee

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

0 Kudos
ibrown
Participant

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

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.