Updatable Objects in VSX

[net-harry]

Hi,

I have a question regarding updatable Objects in VSX. We needed to use this feature in one VS and had some trouble getting it working.

Initially we did not have DNS configured and followed sk121877 (Package of Updatable Objects is missing on the Security Gateway) to get last_revision.xml on the VSX hosts (vs 0).

However, things did not start working until we, with the help of TAC, created a NAT rule for the external interface of the VS and allowed traffic to Check Point also for that address.

My question is if/why we need to allow traffic from the VS to get Updatable Objects working in VSX? It would seem better if only the host (vs0) had access to Check Point to download updated and that the objects could then be used by any VS.

We are currently running R80.20 JHF 118.

Thanks for your help!

Best regards,

Harry

[PhoneBoy]

I presume the VS itself needs access to the Internet to use Updatable Objects the same way a VS needs access if you’re using many ThreatCloud features.

[net-harry]

Thanks @PhoneBoy  for the information!

Besides creating a rule for the virtual firewall (vs) to access Check Point cloud we also needed to create a NAT rule for the internal address (192.168.196.0/22) to translate to the external IP address of the vs in order to get Updatable Objects working.

Are there any plans to improve this behavior or should it be possible to get this to work in a different way? 

Thanks for your help!

Harry

[PhoneBoy]

Theoretically it should use the external IP.
What’s the main IP of the VS in your case?

[net-harry]

The main IP address (which is also used for the external interface) is 172.21.x.y. We have another external firewall (also Check Point) that does a NAT to a public IP. 

[HeikoAnkenbrand]

Hi @net-harry,

Internet connectivity - make sure there is connectivity to the Internet.

You need the following:

- A route in the direction of the Internet to reach updates.checkpoint.com
- A NAT rule to a public address (if necessary on a VS gateway or your external firewall)
- A rule for https to allow the traffic to updates.checkpoint.com  (if necessary on a VS gateway or your external firewall)
- DNS servers - make sure DNS servers are configured properly (changing DNS configuration in GAIA requires cprestart)

Troubleshooting:

1. DNS server(s) must be configured and reachable from the Security Gateway.
2. If required, Proxy Server should be configured (in SmartConsole) and reachable from the Security Gateway.
3. Run on your Gateway machine: unified_dl UPDATE ONLINE_SERVICES
4. Verify that the response is: Request was completed successfully.
5. Search the last_revision.xml file under $CPDIR/database/downloads/ONLINE_SERVICES/1.0/
6. If it exists, you now have the Online Services package on your Gateway and can run policy installation.
7. If the last_revision.xml is missing, please contact support. We will need to troubleshoot why this file is not downloading properly. 
8. Reboot

[HeikoAnkenbrand]

The following should be checked.

1. Ping updates.checkpoint.com. There should be resolving. (You might not get a reply. It is ok).
2. If there is no resolving, check DNS server configuration and connectivity.
3. Check connectivity using curl_cli:
   # curl_cli  https://updates.checkpoint.com/WebService/services/DownloadMetaDataService?wsdl
4. Check that a proxy server is configured, if needed.

[net-harry]

Thanks @HeikoAnkenbrand for the suggestions!

Please note that the Updatable objects on the vs is currently working for us. I just wanted to check if we made the correct configuration, since ideally I would prefer not to: 

1. Create a firewall rule to access Check Point cloud (e.g. updates.checkpoint.com) from each VS. I had hoped that allowing the VSX host (vs 0) access to Check Point cloud to be enough.
2. Create a NAT on the VS for the internal network (192.168.196.0/22) to the external IP address of the vs to make access to Check Point cloud. I had hoped that the internally used IPs would never exit the firewall (vs).

Best regards,

Harry

[Kaspars_Zibarts]

We got "stung" pretty badly by this too - there is no solution for VSX to use VS0 as a "proxy" in case of updatable objects. You will need individual connectivity from each VS to Checkpoint. Can't agreee more that it's not ideal but it works

[LostBoY]

i am yet to find a solution for this.. if i am using a proxy in vs0 ..does vs2 also uses the same proxy for any outbound update request even though i have created a separate NAT for it in vs2 policy  ?.. for some reason vs2 cant reach the proxy in vs0 in my environment. I am suspecting this might be the issue for me.

i am able to ping and resolve updates.checkpoint.com but not getting last_revision.xml file in VS2 at this location : $CPDIR/database/download/ONLINE_SERVICES/1.0/

however ..this is available in VS0 at the same location

[_Val_]

Each VS has to have access to the updatable objects distribution (updates.checkpoint.com) to fetch the relevant objects. Sharing between different VSs is essentially a potential RFE, as we do not have this functionality at this moment.

[Arne_Boettger]

Hello,

If I understand you correctly, you had to create a NAT rule for the Funny-IP of the VS? This should not be necessary in my experience. But we also managed to "break" the automatic NAT mechanism behind Funny IPs with manual No-NAT rules in the past.

Regarding external connectivity: For us it would also be great if VS0 would be used for this kind of external communication.

Another warning: We had a VS drop nearly all traffic when we used Updatable Objects for the first time. If the VS is NOT able to fetch these objects, the rule transformed into an any-any-drop rule.

[net-harry]

Thank you very much @Kaspars_Zibarts , @_Val_  and @Arne_Boettger  for the information.

I understand now based on your feedback that we do need to allow some traffic from each VS that uses Updatable Objects. Right now we have the following:

1. Access from virtual firewall (vs) to DNS servers for DNS requests
2. Access from virtual firewall (vs) to updates.checkpoint.com for HTTPS requests
3. NAT for internal network (192.168.196.0/22) to virtual firewall (vs) external interface

Regarding the NAT of the internal addresses (192.168.196.0/22) we had to configure it to get the Updatable Objects working, but perhaps it was an order of operations issue. We will test to remove the NAT rule and see if we can get it to work. Could it potentially also be due to that we run an older JHA (118) for R80.20?

Thanks again for your help!

Best regards,

Harry

[Henrik_Noerr1]

like many who already posted we got hit by this as well. Especially the fact, that you cannot verify that it will work before you actually install the policy with the updateable objects. If for some reason the VS cannot download the lists, it will start dropping traffic - It will inform you in the policy install, but it is only a warning, and not a blocking error 😞

Furthermore, since VSs can only use the DNS from VS0 - good luck using dynamic objects and URLF, Captive Portal, etc. if the VSs represent different customers, each with their own dns resolvers.

This has been a limitation long running, I think I read something is in the works for r81 - But then again, that means r82 until stable 😉

Best regards,

Henrik 

[LostBoY]

were you using proxy in this setup ?