- Products
- Learn
- Local User Groups
- Partners
- More
Introduction to Lakera:
Securing the AI Frontier!
Quantum Spark Management Unleashed!
Check Point Named Leader
2025 Gartner® Magic Quadrant™ for Hybrid Mesh Firewall
HTTPS Inspection
Help us to understand your needs better
CheckMates Go:
SharePoint CVEs and More!
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_AdminGuid...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
External Network Feeds is listed as "NO" in sk79700 but would recommend validating with your SE / TAC as appropriate.
Just to follow up on this after consulting with R&D:
Which means, at the very least, this will be officially supported in the future.
External Network Feeds is listed as "NO" in sk79700 but would recommend validating with your SE / TAC as appropriate.
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.
How long have you had it running in this way? days/weeks/months?
thanks
Just days. But based on the answer from @PhoneBoy , probably I will have to remove it as we only have VSX
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.
Just to follow up on this after consulting with R&D:
Which means, at the very least, this will be officially supported in the future.
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.
Correct, you need a non-VSX gateway to "test" the feed currently.
Once that's done, it can be deployed to VSX gateways.
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.
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).
Hello,
Network Feeds, it is compatible and possible to use it in VSX environments with Gaia R81.20 Take 84?
Cheers.
Im pretty sure its fine, did not see any limitations about it in below link.
Andy
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
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.
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.
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.
It only provides value insofar as the underlying functionality used to test the feed is not available in VSX for whatever reason.
Do we know if this is know supported, as of R82?
Looks like the sk was updated March 17th 2025, but table still says not supported for net feeds for VSX as of R82.
Andy
that's a shame, lets hope its in R82.10
I know official sk says its not supported, but since this is really bugging me, will spin up R82 vsx gw in the lab, connect it to my R82 mgmt and test. Give me couple of hours, will update with the results : - )
Best,
Andy
Buddy,
The SK you share says that 'EXTERNAL Network Feeds' in version R81.20, "Not supported by design'.
So, this cannot be used in VSX environments?
It confuses me a bit.
Is there any difference between 'EXTERNAL network feeds' and 'Ioc Feeds' or is it almost the same thing?
Cheers
Thats right, my bad, correct, says officially NOT supported. However, I will test in the lab shortly. Btw, for difference, see below.
Andy
Curious 😅
Officially CP says it's not supported, but in the 'battlefield' it looks like it does work, Haha.
Must be that if a problem occurs, CP TAC simply won't address it, because the document says it's not supported at the moment. 😵💫
What is a safe and reliable source that can be placed as the Feed URL when setting up this 'Network Feeds' option?
Are there several reliable alternatives?
Thank you.
Thats why the labs exist my friend ; - )
Anywho, stand by, dont do anything for now, I will let you know the results soon. Give me 1-2 hours.
Andy
Just tested it, worked fine, on 9 network feeds. I gave feedback in the sk itself.
Andy
One doubt,
What is the source you use when you configure the Network Feeds?
When you go to create this object in the SMC, there is a ‘section’ that says FEED URL.
What is the most reliable source you use to fill this part of the configuration?
You use this URL for your Network Feeds, right?
https://lists.blocklist.de/lists/
Is this URL reliable and accurate?
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
11 | |
9 | |
8 | |
6 | |
6 | |
6 | |
6 | |
5 | |
5 | |
5 |
Mon 22 Sep 2025 @ 03:00 PM (CEST)
Defending Hyperconnected AI-Driven Networks with Hybrid Mesh Security EMEAMon 22 Sep 2025 @ 02:00 PM (EDT)
Defending Hyperconnected AI-Driven Networks with Hybrid Mesh Security AMERTue 23 Sep 2025 @ 06:00 PM (IDT)
Under the Hood: CloudGuard Network Security for Nutanix - Overview, Onboarding, and Best PracticesMon 22 Sep 2025 @ 03:00 PM (CEST)
Defending Hyperconnected AI-Driven Networks with Hybrid Mesh Security EMEAWed 24 Sep 2025 @ 03:00 PM (CEST)
Bereit für NIS2: Strategische Werkzeuge für Ihre Compliance-Reise 2025Thu 25 Sep 2025 @ 03:00 PM (IDT)
NIS2 Compliance in 2025: Tactical Tools to Assess, Secure, and ComplyAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY