Archived

This forum has been archived. Please start a new discussion on GitHub.

How can one use ICE when localhost connections are blocked?

Hi,

Recent Windows security applications have taken to blocking localhost / loopback network connections which prevents ICE from working correctly - my (non-scientific) investigation suggests that this practice will become even more widespread in coming years. Has anyone else had experience of working around this issue?

According to the FAQ on ports, ICE will always use the loopback interface for its own communication so even if I could find a way to limit my application's use of loopback to one port (by switching to bi-directional connections?) I think that there will still be problems, yes?

I saw a post requesting optional use of shared memory rather than TCP but this was rejected on the basis of there being no performance benefit over TCP. However, maybe there are other benefits? (i.e. if it would solve this problem!)

Background:

I've been using ICE as a link between a C++ application and a C# application (Firefox and KeePass Password Safe 2; my work is a Firefox add-on called KeeFox and a KeePass plugin called KeeICE). I'm using ICE-E as the ICE client in Firefox (because I have to work with the existing Firefox build, my add-on has to be able to static link to the ICE libraries to avoid conflicts with different VC++ runtime versions) and ICE 3.3 in the C# plug-in. While the software currently works only on a Windows machine, I hope to be able to port it fairly quickly to Linux and Mac and maybe even enable cross-machine communication if I can see a secure way to do so.

Thanks,
Chris

Comments

  • benoit
    benoit Rennes, France
    Hi Chris,

    Do you have any references regarding these security applications which are blocking the loopback interface?

    The upcoming Ice 3.4 release won't use anymore the loopback interface internally. We didn't decided yet whether or not we will also include this change in the next Ice-E release.

    A shared memory transport would indeed avoid using the loopback interface but we currently don't have plans to implement this. This might change in the future if there are more demands for it or if someone is willing to sponsor the implementation.

    Cheers,
    Benoit.