topic Re: Network Feeds and VSX in General Topics

Network Feeds and VSX

Greg_Harbers — Thu, 02 May 2024 02:40:48 GMT

Hi

I have just created a network feed object and went to test that I had defined it correctly. When I tested it, I was shown only the non VSX gateways. this matches up with what is said in here...

https://sc1.checkpoint.com/documents/R81.20/WebAdminGuides/EN/CP_R81.20_SecurityManagement_AdminGuide/Content/Topics-SECMG/Network_Feed.htm being

"Note - The "Select gateway" menu does not show these VSX Virtual Devices: Virtual Systems, Virtual Routers, Virtual Switches."

My question, are network feeds supported on VSX?, ie while we cannot select a VSX gatey to test the feed, if we install the policy it will work?

Thanks

Greg

Re: Network Feeds and VSX

Chris_Atkinson — Thu, 02 May 2024 03:38:10 GMT

External Network Feeds is listed as "NO" in sk79700 but would recommend validating with your SE / TAC as appropriate.

Re: Network Feeds and VSX

jkougoulos — Fri, 03 May 2024 04:50:12 GMT

I had not noticed sk79700 mentioned by Chris and I pushed the policy without using the test feed and it worked, it downloaded the file and started blocking traffic as expected.

Now the question is if we are supported by TAC when we use this feature, if it breaks anything etc. for me is one of the most important features in r81.20.

Re: Network Feeds and VSX

Greg_Harbers — Fri, 03 May 2024 04:55:17 GMT

How long have you had it running in this way? days/weeks/months?

thanks

Re: Network Feeds and VSX

PhoneBoy — Fri, 03 May 2024 05:29:07 GMT

Official VSX support for Network Feeds can best be described as "complicated."

If you have a regular (non-VSX) gateway to test the Network Feed, you can install it to a VSX gateway.
VSX gateways cannot validate Network Feeds at this time.
If you only have VSX gateways, you basically can't use Network Feeds.
This is why the documentation currently says it is unsupported on VSX.

The above was confirmed with R&D.

Re: Network Feeds and VSX

jkougoulos — Fri, 03 May 2024 06:38:03 GMT

Just days. But based on the answer from @PhoneBoy , probably I will have to remove it as we only have VSX

Re: Network Feeds and VSX

jkougoulos — Fri, 03 May 2024 14:50:45 GMT

Hello @PhoneBoy thanks for the feedback, indeed sounds complicated… I will take it as a non supported feature 😞

Since this is a gateway feature, meaning that the connection initiates from the gw, I don’t think that the validation on another non-vsx gateway provides any value in relation to the reachability of the feed.

perhaps the validation is more for the content, which in any case as we talk about a dynamic list is not guaranteed to be always successful even it is validated ok for the first time. So I mean validation for the content should be there always, the initial test on a non-vsx gw does not provide any guarantee.

errors seem to appear in vsx mode correctly in the log files, so I cannot really understand the issue technically, perhaps with the exception that someone needs to dig the log files in the gw to see the error.

Obviously I just see the surface, perhaps there are other complexities under the hood but it is a pity we cannot use this feature.

Re: Network Feeds and VSX

Bob_Zimmerman — Fri, 03 May 2024 15:28:28 GMT

Reachability of the feed is a really simple problem to solve. You have all the firewall logs and so on to tell you about problems, after all. Testing the feed is entirely about confirming the firewall application software can parse the contents.

One of my managements has only VSX firewalls. We were going to use network feeds, but we also don't want to maintain two different feed fetch systems on an ongoing basis, so we ended up using some command line tool which relies on 'fw samp'. I'm not thrilled with this, but at least when troubleshooting we don't have to think about which feed method this particular firewall uses.

Re: Network Feeds and VSX

PhoneBoy — Fri, 03 May 2024 15:29:20 GMT

Back when I brought this issue up with R&D a few months ago, I thought we had agreed that it would be fine to run Network Feeds on VSX subject to the limitations I previously discussed and possibly others.
The documentation never got updated to this fact.
Let me double check this.

Re: Network Feeds and VSX

PhoneBoy — Fri, 03 May 2024 23:08:07 GMT

It only provides value insofar as the underlying functionality used to test the feed is not available in VSX for whatever reason.

Re: Network Feeds and VSX

the_rock — Fri, 03 May 2024 23:17:41 GMT

My educated guess is that TAC might not help you if things break, as sk states external network feeds are not supported. Possibly best effort support, but you should confirm.

Andy

Re: Network Feeds and VSX

PhoneBoy — Wed, 08 May 2024 01:45:21 GMT

Just to follow up on this after consulting with R&D:

R82 will add support for the "Test Feed" option in Network Feeds for a VS.
A future R81.20 JHF will include support for the "Test Feed" option from a VS (PRJ-53794); ETA unknown at this time.

Which means, at the very least, this will be officially supported in the future.

Re: Network Feeds and VSX

jkougoulos — Wed, 08 May 2024 07:46:45 GMT

Thank you very much for the follow up!

So, I guess the workaround for now for us with VSX only, is something like install a non-VSX gateway eg lab/trial edition to test the feed and then push to VSX, until the test feed feature arrives on VS.

Re: Network Feeds and VSX

PhoneBoy — Wed, 08 May 2024 22:38:40 GMT

Correct, you need a non-VSX gateway to "test" the feed currently.
Once that's done, it can be deployed to VSX gateways.

Re: Network Feeds and VSX

ArchVile — Thu, 13 Feb 2025 14:02:17 GMT

Hi PhoneBoy,

I would like to ask if by any chance you have updates about PRJ-53794.

Maybe we can go with "limited support" for some time, but then I'm facing another challenge how to trust the server certificate when using TLS which for certain will be audit requirement. Can we somehow import the certificate as trusted in given CMA? Unfortunately, we do not have regular GW in the CMA.

The other option could be the use of generic data center object, but that requires JSON and we are using flat file format for all other vendors. Also, this option seems to be different as CMA server itself is checking for the updates on the external server and then is updating the GWs/VSs if needed.

Another strange thing I came across when testing both of these features is that they do not affect existing sessions. The session has to be terminated and re-initiated to get blocked. The Connection persistence option has no effect on this. For sure the Rematch is working when tested with regular rule not using network feed OR data center object.

This is crucial as this is intended as SOC automated tool which must block the connection immediately.

Do you think there is any other option to achieve this except the two mentioned?

As always, thank you for your help.

Re: Network Feeds and VSX

PhoneBoy — Fri, 14 Feb 2025 00:00:46 GMT

For an immediate block, use DoS mitigation rules: https://support.checkpoint.com/results/sk/sk112454

TAC will have to comment on PRJ-53794.
As for importing a different CA to trust in this situation, don't know offhand if it's possible (especially if the UI doesn't work).

And yes, the Generic Data Center object operates the way you describe (CMA checks and updates gateways as needed).

Re: Network Feeds and VSX

Matlu — Sat, 26 Apr 2025 02:46:38 GMT

Hello,

Network Feeds, it is compatible and possible to use it in VSX environments with Gaia R81.20 Take 84?

Cheers.

Re: Network Feeds and VSX

the_rock — Sat, 26 Apr 2025 03:37:23 GMT

Im pretty sure its fine, did not see any limitations about it in below link.

Andy

https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_SecurityManagement_AdminGuide/Content/Topics-SECMG/Network_Feed.htm

Re: Network Feeds and VSX

genisis__ — Sat, 26 Apr 2025 08:53:22 GMT

Do we know if this is know supported, as of R82?

Re: Network Feeds and VSX

the_rock — Sat, 26 Apr 2025 10:58:04 GMT

Looks like the sk was updated March 17th 2025, but table still says not supported for net feeds for VSX as of R82.

Andy

https://support.checkpoint.com/results/sk/sk79700