Network Feeds and VSX

[Greg_Harbers]

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

[Chris_Atkinson · Accepted solution]

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

[jkougoulos]

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.

[Greg_Harbers]

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

thanks

[jkougoulos]

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

[PhoneBoy]

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. 

[PhoneBoy · Accepted solution]

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.

[jkougoulos]

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.

[PhoneBoy]

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

[ArchVile]

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.

[PhoneBoy]

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).

[the_rock]

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

[PhoneBoy]

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.

[jkougoulos]

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.

[Bob_Zimmerman]

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.

[PhoneBoy]

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