I2061: Remote binding with multi-homed systems | Knowledge Base

Home > Knowledge Base > FreeProxy Knowledge Base > I2061: Remote binding with multi-homed systems

Home

Download

Knowledge Base

User Page

Hi Guest

IP: 18.221.129.19

Knowledge Base

I2061: Remote binding with multi-homed systems

Summary
Product: FreeProxy
Versions: 3.92 onwards
Note: 2061
Date reported: 09 March 2006

Issue Detail
Using remote binding with multi-homed systems.

The terms "local" and "remote" binding are used in FreeProxy documentation and in the control centre to describe the binding of an IP address to a route. In the case of "Local Binding", FreeProxy will only accept messages which are addressed to the IP address to which you have bound the FreeProxy "Port". In the case of "Remote" binding, FreeProxy will send IP packets encoded with with the bound IP address as configured for that port.

There is a subtley here, however. The underlying TCP/IP stack binds to an IP address not a network card. Herein lies possibly different behaviour to what you might expect.

Solution
Here is behaviour observed when testing the remote binding.
On the system running FreeProxy are 2 network cards (as per IPCONFIG /all).

Card1: 192.168.100.100
Card2: 192.168.100.103

They both have MAC addresses in the form 00-00-33-nn-nn etc but for this explanation, call the MACs Card1 and Card2. Both the local and remote binding were set at Card1: 192.168.100.100

Using the 2 network card property pages, traffic was observed on both Card1 and Card2 ! This binding would theortically have restricted the traffic to Card1 only. But not so. A network monitor then showed that there was traffic on both network cards for outbound (to the internet) traffic. Comfortingly enough, all outbound traffic, from both cards, had the IP address of 192.168.100.100 as configured in the control centre port; thus proving that the outbound traffic was bound to the IP address but not necessarily the network card.

According to Microsoft technical article 175767: Expected Behavior of Multiple Adapters on Same Network behaviour of this setup is undefined and can cause unexpected results similar to that observer above. Its worth reading.

So when can this work correctly ?

You have to remember that the application layer (Winsock) does not provide a means to bind to a network card, only to an IP address. The routing table will determine which network interface to use. However this is based solely on destination IP address and not source IP address. The Source IP address is the one selected in FreeProxy.

If your 2 or more network cards are internet facing with internet IP addresses, then the bind will bind the IP address you select to packets leaving FreeProxy. Once in the IP stack, the routing table determines the NIC depending on the destination IP address.

Code:

225.221.17.1 -> NIC1 -> internet
^
|
225.221.18.1 ----+ NIC2 -> internet

Now here is where binding has its place: The IP packet leaving your computer will have the bind IP address as the source IP. And here is where is does not work: you have no control over the NIC it will select to send the IP packet. When I say no control I mean you cannot route the packet by a rule based on the bound (source) IP address. In the example above, IP packets will correctly have the IP address as bound however all packets will be routed via one NIC

If you are using local internet addresses, such as those from the 192.168.x.x range, and you have a NAT type router facing the internet, then binding will have to effect.

Code:

192.168.1.1 ---NIC1 -- router -> 225.221.17.1 -> internet
^
|
192.168.2.1 ---+ NIC2-- router -> 225.221.18.1 -> internet

In the example above because the routing table is set up to direct all internet traffic to NIC1, all internet traffic will be seen as 225.221.17.1 regardless of the binding.

Here is another article on this topic

So in summary:
1. All packets of the outbound traffic will be encoded with the IP address as configured in remote binding.
2. You cannot bind to a network card.

Rectified
Remote binding implemented in build 1620 onwards

Hand-Crafted Software.

MemHT Portal is a free software released under the GNU/GPL License by Miltenovik Manojlo