I happen to face a very odd situation which made me question my sanity. Knime was running fine since month, updates and extensions got installed. Just recently, though, Knime threw “cannot connect to repository”.
There was no major change in the firewal or any other security setting. No major Windows update was installed either. Still, Knime wasall of a sudden unable to make any call, even via the GET Node, to the internet.
I checked all settings, disabled the firewall, checked all logs, group policies etc… No trace of any block. I then proceede with try & error and found that Nord VPN, despite having split tunneling enabled, which only should enable VPN to these apps, Nord VPN still tunneled all traffic from Knime.
When adding knime to the list of apps to which split tunneling applies, Knime can make calls.
Only after disableing Nord VPN entirely, Knime was able to make calls to the web. Questions are:
What “service” is Knime respectively Eclipse using that causes Knimes traffic to get routed through the VPN?
Why are all calls Knime makes, whenever it’s repositories or regular GET requests to fetch data from a website, failing if split tunneling is not enalbed?
I hope we can get some clarity into this with all of us remaining sane.
My guess would be that when connected to the VPN, there is a corporate firewall at the end of the tunnel that happily replaces any SSL certificates in order to inspect network traffic. You’d recognize this by “PKIX Path building failed” errors in the console view when installing extensions or running e.g. a GET Request node.
If that is the case: to get around this limitation, checkout the below thread (I’d try the knime.ini parameters first, as that is quick to check).
I had the same issue just lately with another app (Cyberduck) which let me to assuem this is either a NordVPN issue with it’s split tunneling feature or a combination of it with the respective apps.
About the assumption of a firewall. It is my own PC and network I have under full control. Not ruling out some odd behavior of Windows, though. The workaround of chaning from https to http worked before in another scenario of a client of mine.
