Gateway IPS, AV, AB, Contract updating directly while proxy configured

[Emil_T]

I have proxy configured in gateway's object (HA) Under Topology > Proxy > Use custom proxy.

I can see in traffic logs that most of the traffic coming form gateway indeed goes to the proxy.

But some traffic is still going directly. I see logs to dl3.checkpoint.com and to updates.checkpoint.com.

Why is this happening?

[the_rock]

Are you able to send screenshot of the rule?

Andy

[Emil_T]

Updated in the original post

[the_rock]

Screenshot of the RULE, not the log.

[Emil_T]

.

[the_rock]

Sorry, see it now, not sure why I could not before 🙂

Just wondering, is that layer with fw and urlf/appc enabled?

[Emil_T]

correct. The log in the screenshot is application layer

[the_rock]

Not sure, maybe its by default, TAC can confirm.

[PhoneBoy]

Possibly a bug.
Suggest involving TAC: https://help.checkpoint.com

[D_Riddleberger]

HMMMM Very Interesting. We have an MDS R81.20 and it's the MDS IP Address that seems to be bypassing the proxy every night at 2:30 AM as seen on the adjacent internet facing FW.

Diagram = <MDS> <CP Proxy FW> <Internet FW> <ISP>

Let me dig into the outbound IP's a little more but logs show it's cloudfront.net and I read somewhere that was CP Web Services hosted in AWS

Update#2 the three IP's the MDS is accessing are

DST -

3.167.152.116 - AWS

52.85.12.125 - AWS

13.225.143.28 - AWS

How do we find out what those IP's are used for (ie URLF Updates, etc)

Update #3

Found this one - 3.167.152.116 - AWS = updates.checkpoint.com

[the_rock]

Hey Dan,

What do you get when running below?

[Expert@CP-GW:0]# nslookup updates.checkpoint.com
Server: 8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
updates.checkpoint.com canonical name = updates.g04.checkpoint.com.
updates.g04.checkpoint.com canonical name = d3dzd94mv2pmza.cloudfront.net.
Name: d3dzd94mv2pmza.cloudfront.net
Address: 18.245.104.59
Name: d3dzd94mv2pmza.cloudfront.net
Address: 18.245.104.81
Name: d3dzd94mv2pmza.cloudfront.net
Address: 18.245.104.64
Name: d3dzd94mv2pmza.cloudfront.net
Address: 18.245.104.80
Name: d3dzd94mv2pmza.cloudfront.net
Address: 2600:9000:26c2:9c00:19:dc2f:a580:93a1
Name: d3dzd94mv2pmza.cloudfront.net
Address: 2600:9000:26c2:ba00:19:dc2f:a580:93a1
Name: d3dzd94mv2pmza.cloudfront.net
Address: 2600:9000:26c2:fe00:19:dc2f:a580:93a1
Name: d3dzd94mv2pmza.cloudfront.net
Address: 2600:9000:26c2:3c00:19:dc2f:a580:93a1
Name: d3dzd94mv2pmza.cloudfront.net
Address: 2600:9000:26c2:f800:19:dc2f:a580:93a1
Name: d3dzd94mv2pmza.cloudfront.net
Address: 2600:9000:26c2:d000:19:dc2f:a580:93a1
Name: d3dzd94mv2pmza.cloudfront.net
Address: 2600:9000:26c2:2400:19:dc2f:a580:93a1
Name: d3dzd94mv2pmza.cloudfront.net
Address: 2600:9000:26c2:8a00:19:dc2f:a580:93a1

[Expert@CP-GW:0]#

[D_Riddleberger]

Ok a couple of updates. This environment 'which is highly sensitive' is totally locked down from a Security Policy to L2 and L3 Switches which drops everything from Ping, Traceroute, Tcptraceroute, etc so no 'joy' trying to use those tools for some basic T/S of the network/route paths.

Next, everything that leaves the MDS is either CP 'Well known ports' for GW Policy/Log Mgmt or 80/443 for CP Web Services which 80/443 should be going directly to the proxy and only the proxy. This was verified by using the curl_cli with --proxy_ip:8080 qualifier tests and hcp -r "Connectivity to UC" tests. Those two sets of tests were both successful and go out the proxy as intended.

I also found this sk - https://support.checkpoint.com/results/sk/sk83520 - That lists all Sites used by CP for Web Service(s)/Update

Also confirmed that not only this MDS but also multiple other gateways that need access to the Web for CP updates, all use this same CP Proxy FW and none are having any issues.

Just to be clear all CP Web Services and Updates are working as expected, it's just this MDS seems to want to contact CP every night at 2:40 AM and for an unknown reason, bypasses the proxy and the MDS outbound connections are then dropped on the Egress FW because it's the MDS Source IP and not the intended Proxy Source IP. Otherwise the destination traffic is legit. It's not like the MDS has a some sort of malware trying to establish an outbound connection to 'phone home'. It's trying to reach these three destinations for CP Web Services hosted in AWS

3.167.152.116 - AWS

52.85.12.125 - AWS

13.225.143.28 - AWS

This, as when the MDS traffic reaches the Egress FW it 'should' have 'already assumed' the IP address of the Proxy....