Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Muhammad_Ansour
Contributor

CloudGuard AWS

Hi All,

 

I have set up a Cloudguard in AWS in Ingress VPC as below.

 

NLB forwarding by IP Address

NLB -> Cloudguard -> ALB -> servers

 

Currently ports open are 80 and 443.

Public users are able to access the webpage by HTTP, but when users tried HTTPS it will reach up to the warning website security certificate page. After clicking "Continue to This Website (not recommended)" the page can't be reach. We are not using https inspection on the Cloudguard.

I have done tcpdump and there is a 2 way traffic from the NLB and the Cloudguard. I have done zdebug drop, there is no drop for this communication as well.

 

The AWS team have tried connecting directly for NLB to ALB by passing the Cloudguard and the are able to connect using both HTTP and HTTPS from public.

0 Kudos
5 Replies
PhoneBoy
Admin
Admin

My question is: what certificate is presented when you get the error?
0 Kudos
Muhammad_Ansour
Contributor

It's the domain certificate. I will ask them to create a by pass Cloudguard again and check if the certificate is the same. Is that where you are getting at?

 

0 Kudos
Muhammad_Ansour
Contributor

Just to add it shows Certificate(invalid)

0 Kudos
ChristianCastil
Employee
Employee

are you using the Target Group to the Gateways in a different port than 443, because the GW have a web server inside serving 443, you can also automate the proper rules by tagging the balancer...

 

for example, 

 

NLB (443) --> TG GW (1443) --> ALB (443) --> TG WebServers (80)

 

this can be done by adding tags to the Internal LB

 

x-chkp-management : <management-name>

x-chkp-template : <template-name-for-gw>

x-chkp-forwarding : https-1443-443

 

Now my best advise will be use the ALB outside, with that you ensure to present the certificate to your users and decrypt the traffic, with this the GW and Web Server will see clear traffic and use less CPU.

0 Kudos
Muhammad_Ansour
Contributor

Hi,

 

We are using target group 443 and 80.

I haven't make any changes yet, but now I the are drop packets from the command tcpdump icmp and zdebug drop as below:

tcpdump:

.58 = FW external IP

.20 = FW Internal IP to ALB

.168 = ALB IP

15:13:10.923992 In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 72: xx.xx.xx.58 > xx.xx.xx.20: ICMP xx.xx.xx.168 unreachable - need to frag (mtu 1500), length 36

 

zdebug drop

@;7947254;[cpu_3];[fw4_0];fw_log_drop_ex: Packet proto=6 xx.xx.xx.20:443 -> xx.xx.xx.168:59586 dropped by fwmultik_process_f2p_cookie_inner Reason: fwmultik_f2p_cookie_outbound_and_routing failed;

@;7947264;[cpu_1];[fw4_1];fw_log_drop_ex: Packet proto=6 xx.xx.xx.20:443 -> xx.xx.xx.25:53150 dropped by fwmultik_process_f2p_cookie_inner Reason: fwmultik_f2p_cookie_outbound_and_routing failed;

@;7947270;[cpu_1];[fw4_1];fw_log_drop_ex: Packet proto=6 xx.xx.xx.20:443 -> xx.xx.xx.25:53150 dropped by fwmultik_process_f2p_cookie_inner Reason: fwmultik_f2p_cookie_outbound_and_routing failed;

@;7947271;[cpu_3];[fw4_0];fw_log_drop_ex: Packet proto=6 xx.xx.xx.20:443 -> xx.xx.xx.168:59586 dropped by fwmultik_process_f2p_cookie_inner Reason: fwmultik_f2p_cookie_outbound_and_routing failed;

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.