Multiple interfaces -- multiple gateways

[AppleEater]

Hey,
This is a rather strange situation, I know, but this is how the chips fall, and I am trying to work with what I am given. I believe this to be an unsolveable problem with Teamspeak in general, but I figured I would ask anyway.

Anyways, here is my situation

I have two interfaces on this server of mine (at my office), lets call them IF1 and IF2.

IF1 has an ip (on lan) of 172.20.50.152, and a default gateway of 172.20.50.2 (main router)
IF2 has an ip (on lan) of 172.20.50.157, and a default gateway of 172.20.50.3 (backup router)

Each router has a different public IP, 69.*.*.34 and 69.*.*.36. Both routers have the ports forwarded correctly. When I start the server, it picks (seemingly at random) one of the interfaces to bind to, and thus one default gateway, and consequentially, users can only connect on one public IP. For instance, Teamspeak starts up and chooses (?) IF1. Since IF1 has a gateway of 172.20.50.2, that is what teamspeak wants to use. So, if someone uses 69.*.*.34 to connect to my teamspeak, everything is happy, since thats where my teamspeak is bound. However, if they try to connect with 69.*.*.36 (bound to 172.20.50.3, IF2's gateway), it times out. This is not a network setup issue, as other services (like Web) are available on both addresses, as they should be. I have tried with BoundToIp1= and BoundToIp1=172.20.50.152 and BoundToIp2=172.20.50.157, and both approaches have met with failure. Could someone with extensive knowledge of Teamspeak AND networking see if they can tell me how I could correct this? Thanks in advance!

EDIT: Also, another detail: From the LAN, I can connect with either 172.20.50.152 OR 172.20.50.157, so they're working locally, but I think Teamspeak is trying to send traffic to 172.20.50.3 from IF1.

EDIT EDIT: In accordance with forum rules, here is my info
OS: Windows Server 2003
Teamspeak version: Beta 2.0.22.3 (also didn't work with latest "stable release")
That is really all *relevant* information, thanks in advance!

EDIT EDIT EDIT (lol): Also, I would normally submit some packet captures with this, but I cannot get WireShark (formerly Ethereal) to work on this server

EDIT EDIT EDIT EDIT (yeah, I know): Okay, I used a different packet capture tool, and it shed some (very little) light about the issue. Here is a flowchart of the connection from WAN to 69.*.*.34 when the server is only working on 69.*.*.36

WAN->69.*.*.34
69.*.*.34->172.20.50.2 (not an actual step, but anyway)
172.20.50.2->172.20.50.152 (server, everything good so far)
172.20.50.157*->172.20.50.2 (notice server replies from INCORRECT interface, although it goes to correct gateway)
And thats it, the reply from the TS server never makes it, and connection times out. Any ideas?

[Judas]

What subnets are definied for each of the 2 "networks" you are using?

The problem you are describing sounds like the 2 subnets are overlapping or actually identical (except for the default gateway).
Towards my understanding, this is bound to cause unpredictable problems. The IP address of your second interface seems to be in the same subnet as the IP address of your first interface. Hence when ignoring the interface and just looking at the IP, there are 2 possible gateways to choose from and thats where things start to go very wrong.

There are basicly 2 correct soltuions for this problems but both do require changes in the network.

a) separate the 2 subnets completely and if required, setup a router for connecting the 2 subnets again (making them accessible)

b) The backup router has to be offline and only switched on when the first one fails. It will have to use the same IP (external) as the orriginal router.. hence it's only a replacement for emergencies.

I personally would got for solution a)
As long as you only have 1 server, you won't even need a router. Just put the second interface in a completely different subnet ie. 172.20.51.* (255.255.255.0)
that way there shouldn't be any confusion of gateways.

If you require every computer having access to both gateways it will get more complicated though. Not only would you have to setup a router on the computer with the ts server running on, but you also might have to update the routing table of every computer with a static entry telling each computer where to find the router establishing the connection to the other subnet.

I doubt that there is another way to solve the problem as overlapping subnets are simply wrong (as soon as you are expecting traffic from the WAN). I'm actually amazed that your webserver seems to be working correctly on both WAN IPs.

[AppleEater]

Well, the whole point of the two network interfaces on the same physical network and subnet was to add redundancy, and it works perfectly. I have never heard of anything advising against one server having two addresses on the same subnet. All other network-based applications work flawlessly, so I imagine this is a problem with Teamspeak's coding. Separating the subnets is not an option, it just isn't (I already have a very intricate subnet system setup, and separating servers into different subnets isn't part of the plan. As I stated earlier, all other applications work flawlessly, so it must have something to do with the way teamspeak routes stuff. It isn't an "overlapping" subnet, it is only one subnet, and on any other application there would be no problem having two default gateways on the same subnet, as the application would send out packets on the interface it received them (logically), which is not what Teamspeak appears to be doing (it receives a packet from IF1, but it responds with IF2... bad programming if you ask me).

[Judas]

I never said that you can't have more than 1 IP address on a server in the same subnet. However, when different IP addresse in the same subnet use different gateways and therefor have different WAN IPs in the end, and what this is still supposed to be the same server, it does get complicated.

I agree that Teamspeak should reply from the address it got contacted on and according to your examination, it isn't doing that. Yet I'm not entirely sure whether the next step (sending data to the wrong gateway) has much to do with teamspeak as I am not sure whether teamspeak can influence the routing directly.

All i can suggest is that you will systematically use the BoundToIp1 and BoundToIp2 settings in the server, trying to figure out what exactly does go wrong and why.
An assumption is, as you have stated, that Teamspeak does pick on prefered ip/interface at startup and will use that for sending all the traffic.

I was also thinking about messing with the routing table, but as far as I understand it, you can only set routes based on destinations, not on the source in windows. Most probably you'd need some full-featured software router to sort out the mess again.

It remains to be seen what your tests for all possible combinations will show and hopefully, we'll get some feedback from the devs on this issue. I doubt that there will be any fix for TS2, should it turn out that it is indeed a TS problem. But it might be valuable input for TS3 which does seem to get done somewhen.

[AppleEater]

Yes, I will likely have to get some kind of software based routing solution, and define some kind of rule that if traffic is bound for 172.20.50.2 that it is SNAT'd with a source of 172.20.50.152, and the same for the other gateway/interface. Shouldn't be that hard *wishes his server ran Linux*.