Hi all,

first of all, I hope that I posted at the right place.

I am hosting Linux on Linux (Ubuntu on Ubuntu to be precise) in order to test a client/server application. But I've got some problems with internal networking.

The server and the client are separate VM's (not surprising Smile).

The server has 1 active interface of type 'intnet'. I assign a static IP of 192.168.1.200 (Mask : 255.255.255.0).

My client has 2 active interfaces of type 'intnet'. I assign a static IP to both :
1) 192.168.1.2 (Mask : 255.255.255.0)
2) 192.168.2.2 (Mask : 255.255.255.0)

Using Konsole from the server, I can ping client's first interface, and conversely. No communication is possible between the server and client's second interface.

In my C program, my client binds a socket to each of its interfaces then sends a request to the server. Surprisingly the server receives both requests (coming from 2 distinct addresses, C1 et C2). The server sends the response to these requests but C2 doesn't receive anything.

If my server has a second active interface (192.168.2.200). Things happens the same way but this time C2 receives the response (even if in my server C program I don't bind any socket to this other interface).

These things seems absolutely weird. Am I crazy ?

I suppose I am making a mistake somewhere. But I can't see if it is in my C program of in my internal network configuration.

What do you think of it ?

Thank you.

This problem is a little obscured by the virtualization of it all, but it seems fairly clear to me that, in the first case you describe, the server has no idea how to route a packet to 192.168.2.x, so it should be routed out the default gateway (in the route table, netstat -rn, this appears with the flags UG and a destination of 0.0.0.0). That probably either goes to the Internet (where the Private Network packet will be dropped immediately) or somewhere else that does not get it to your client.

The second scenario does not yield to such a simple analysis, though. How sure are you that the message you received on C2 was actually addressed to 192.168.2.2? Could the server be sending both replies out both interfaces?

If I understand you correctly you are running two internal networks with a total of three interfaces, or you may even have all three interfaces running on the same internal network, but the reason you are getting this network connectivity issue I believe is rather simple. You are using class C private IP addresses, and you are assigning the server interface (We'll call
it S1 from now on) and the client interface 1 (We'll call it C1 from now on) on one internal IP network, while the second client interface (C2) is on a different network. If we look at IPv4 addressing we have Class A, B and C, Class A reservers only the fist octet of the IP for the network designation i.e. 10.0.0.0 the 10 designates that this is a private IPv4 Class A network, we can subnet but that is another discussion. For Class B the first two octets designate the network address so for instance we have 172.16.0.0, then we have Class C which uses 3 octets for the network address, i.e. 192.168.1.0 and so your S1 is on the 192.168.1.0 network as is C1, but C2 is on the 192.168.2.0 network, when you add a second interface to the server and assign it 192.168.2.200 (S2), you place S2 on the same network as C2. This may seem a little confusing but we are mixing physical (in this case virtually physical) internal networking with logical networking the physical network only transports the data to and from based on the physical hardware address of a device (MAC address on network interfaces) where as logical addressing is directed based upon a logically assigned address, IP address in this case. So unless routing is set up using IPtables and/or NAT on your client computer the two distinct networks cannot communicate because the only interface the server is aware of is the one connected to the 192.168.1.0 network so all data out goes to this network, however, there are no interfaces on this 192.168.1.0 network that are listening for data destined for the 192.168.2.0 network, and the server also does not have a specific address on the 192.168.1.0 network that accepts data for the 192.168.2.0 network and forwards it to the right place. However, you might ask "Well data sent out by the 192.168.2.0 interface on the client gets to the server, Why doesn't it get back?" Well the reason the data reaches the server for one of two reasons, though I am not sure which. 1)The routing table on the client computer routes the data for the 192.168.1.0 network out of C1, and when data coming from C2 destined for the server is output the computer routes that data over C1. the other possibility 2)Is that because we are on the same "physical" network when output destined for the server at 192.168.1.200 finds it because there is a device connected to the network with that logical address. I think the first possibility is the more likely of the two. Now you could test this if you set up a third VM that functioned only as a router with two interfaces on this same "physical" network and set one as 192.168.1.x and the other as 192.168.2.x then set it as the default gateway for 192.168.2.0 traffic on the server routing tables, then you network interfaces should work, that is provided I am right about this whole thing. Hopefully I do know what I am talking about having a Bachelors degree in Network Administration, and being a tech geek in general. Good luck let us know what happend no matter what you do.

PS. Adding a second interface on the server connected to 192.168.2.0 would also serve similarly to the third VM as a router, because it would be connected to the same logical network as C2. And any data destined for C2 would be routed over the servers second connection connected to the 192.168.2.0 network.

BTW your server would see the data from C2 as coming from a seperate interface because C1 does not NAT the packets coming from C2 that are routed over the C1 interface