Peer-to-peer over VPN connections

rhochmuth

I have a peer-to-peer (both ends are clients and servers) Ice application that runs fine on a LAN. Sometimes when using a VPN connection, in this case the Nortel VPN client, the address that is sent using a callback to the other system, is an address on my private LAN not the "public" address of the VPN connection.

My understanding is the the Nortel VPN is treated like a virtual adapter/interface.

When I hard code the correct VPN address using an Ice config file everything works. So it isn't a problem with Ice. It appears to be a problem with the binding order of hostname to IP address. In the VPN case there are multiple valid IP addresses for the host. Sometimes WIndows chooses badly.

I'm just wondering if anyone has experienced this problem before and has worked out a solution. I'm trying to adjust the binding order on Windows XP, but I haven't figured out how to do this.

--Roland

rhochmuth

I hope I don't embarass myself. I should have mentioned this earlier. Even though what I stated above isn't an Ice issue I suspect that this might be an important consideration for developers using Ice if they suspect that their app will be used over a VPN connection. Since bi-directional sockets are not supported in Ice, at least not without Glacier, the peers need to implicitly open sockets to each other. All the apps that I've developed prior to Ice have used bi-directional sockets and they work fine over VPNs. The result using Ice was unexpected.

It appears that due to the way addresses are assigned using VPN's and the binding that the OS chooses, the callback methods are sometimes not routable since the hostname to IP address binding done by the OS is sometimes the wrong address.

In other words peerA, acting as a client, invokes a method in peerB which is acting as a server. Passed into the method is a callback that peerB uses to invoke a method (callback) into peerA. Next, peerB, acting as a client, attempts to invoke a method in peerA, now acting as a server. Unfortunately, when the proxy is used by peerB the Ice runtime attempts to connect to a non public address and emits an Ice socket exception.

So it looks like I have three options:

1. Glacier.

2. Progromatically shoose the correct address. I've already proved that I can set the endpoint manually in a Ice config file and get the proper results. The problem with the manual approach is that the address changes each time I create a new VPN connection.

3. Configure my networking. For example, modify the binding order. I'm not sure that this is possible.

I'm also wondering about the overhed incurred in the Glacier approach.

--Roland

marc

If you are already in a VPN, Glacier is probabably an overkill.

The algorithm with which Ice determines the local IP address is quite simple:

1. Ice calls gethostname() to get the local hostname.
2. With the returned value, Ice calls gethostbyname() to get the IP address.

The code that is responsible for this can be found in src/Ice/Network.cpp, the function name is getLocalHost().

If this algorithm doesn't work in your case, then I think setting the endpoint programatically (in the code, not in a config file) is the best option. Your VPN vendor should be able to give you an algorithm or API for finding the local VPN IP address.