A multihomed system is a system with multiple IP interfaces. These interfaces can be on the same or on different subnets. Today I want to consider protocols like FTP and NDMP. In both protocols the server accepts a connection from the client and then makes a new connection back to the client. On a multihomed system it is this new connection that causes all the problems.
In both protocols the source IP address is NOT based on the IP address that the client originally connected to. Instead it is based on the interface associated with the gateway that is used to get back to the client.
For example given the following interfaces and routing table
ifconfig -all

Number of interface(s) under IP: 5

%phx_vos#loop.m16: <UP, LOOPBACK, RUNNING> netmask 0xff000000

%phx_vos#enetA: <UP, BROADCAST, RUNNING, NOFORWARDBROADCAST, KEEPALIVE> netmask 0xffffff00 broadcast

%phx_vos#enetZ: <UP, BROADCAST, RUNNING, NOFORWARDBROADCAST, KEEPALIVE> netmask 0xffffff00 broadcast

ready 15:33:51

route print

Default Gateway:
ready 15:33:57
A client with the IP address of connects to, call this connection “A”. To send packets to the module must use the default gateway which is on the network and therefore uses the interface. It uses this interface for ALL traffic to for connection “A”; but the IP address in the TCP header will be, because that is the IP address that the client is connected to in connection A . However, when the module creates a new connection to, connection “B”, STCP will by default choose as the source IP address. It does this because that is the interface that the gateway is attached too. The application can override this but neither FTP nor NDMP do so.
The major consideration is the configuration of firewalls and access lists on routers. If the client firewall or router ACLs is configured to only allow connections from the connection from will fail. The solution is to either create a route to using a router on the subnet (of course the selected router must be capable of reaching or the firewall and router access lists but be reconfigured to allow
You can test this with the following script
connect -name -port N
bind -name -port 0
connect -name -port N
You of course must replace with the actual IP address of the client and with the IP address that the client connects too. The port N should be some port that is open on the client and is allowed by the firewalls and router ACLs.
The first connect will use the default IP address, the second connect will use If the first connect times out (it will take a minute or so) or returns immediately with a connection refused error BUT the second connect works (all you will see is the “stcp:” prompt) you can be certain that there is a firewall or router ACL issue that will need to be resolved.