- CheckMates
- :
- Products
- :
- CloudMates Products
- :
- Cloud Network Security
- :
- Discussion
- :
- Cloudguard in azure trying to send traffic to inco...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What about fw monitor -e "accept host(227.237.5.164);"
Any difference if you tried turning off sxl?
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)! 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thats also my understanding based on how NAT is configured.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Lesley, that is the confusing thing, it's not the address of the gateway or anything defined in the environment.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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