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> 127.0.0.1 netmask 0xff000000
%phx_vos#enetA: <UP, BROADCAST, RUNNING, NOFORWARDBROADCAST, KEEPALIVE> 172.16.1.50 netmask 0xffffff00 broadcast 172.16.1.255
%phx_vos#enetZ: <UP, BROADCAST, RUNNING, NOFORWARDBROADCAST, KEEPALIVE> 192.168.77.50 netmask 0xffffff00 broadcast 164.152.77.255
ready 15:33:51
route print
Default Gateway: 192.168.77.1ready 15:33:57A client with the IP address of 10.1.1.1 connects to 172.16.1.50, call this connection “A”. To send packets to 10.1.1.1 the module must use the default gateway which is on the 192.168.77.0/24 network and therefore uses the 192.168.77.50 interface. It uses this interface for ALL traffic to 10.1.1.1 for connection “A”; but the IP address in the TCP header will be 172.16.1.50, because that is the IP address that the client is connected to in connection A . However, when the module creates a new connection to 10.1.1.1, connection “B”, STCP will by default choose 192.168.77.50 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 172.16.1.50 the connection from 192.168.1.50 will fail. The solution is to either create a route to 10.1.1.1 using a router on the 172.16.1.0/24 subnet (of course the selected router must be capable of reaching 10.1.1.1) or the firewall and router access lists but be reconfigured to allow 192.168.1.50.
You can test this with the following script
stcp_callssocketconnect -name 10.1.1.1 -port Nsocketbind -name 172.16.1.50 -port 0connect -name 10.1.1.1 -port NYou of course must replace 10.1.1.1 with the actual IP address of the client and 172.16.1.50 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 172.16.1.50. 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.