Firefox doesn't know specifically about your networking situation. It simply issues connect requests to the TCP stack and that decides where to route it. As far as I know there is no way to bind connect requests to a specific adapter in Firefox. It can be done, the Windows API allows it, but I'm unsure if Firefox includes that flexibility.

When you attempt to connect to an IP with an unbound socket, the TCP stack will first check to see if the IP is a member of any sub-net it is a member of. If not it has to pass the request to a router (or gateway) the choice of gateway (if there's more than one) is dependent on routing table entries and gateway metrics. It is possible to enter routing table entries to make the stack route particular IPs to particular gateways. Otherwise it will choose the adapter that has the priority gateway metric value.

If the server you are attempting to connect to on the 2nd NIC is on the same subnet as the second NIC then it *should* work. If that is not the case and the server is behind a gateway then the most likely reason it can't reach it is because the TCP stack is choosing the gateway on the 1st NIC's subnet. You'd need to add routing table info.

Thanks for the info. I have already modified the routing table and the actual software that I am using is successfully communicating with the servers on the second NIC (10.10.10.1). I have included a screen shot of my current routing table. From what you said above, Firefox does rely on the Windows routing table. However, if I enter the address of 10.10.10.151 on the address line, I get a time out/failure to connect error in Firefox. This is the issue that I am trying to resolve. Any ideas? Thanks. Jim W

That's an odd one. 10.10.10.151 is on the same subnet as your adapter which is 10.10.10.1 so in theory Firefox should have no problems communicating with it, there should be no routing involved, it's a direct connection.

The only answer I can think of is if the web service on 10.10.10.151 is not working correctly. You said that other software is communicating with 10.10.10.151 with no problems? What is the nature of that connection? Is this software specifically binding to the 10.10.10.1 interface and is it communicating with the same service as Firefox is attempting to connect to, or is that another service?

Also is Firefox setup with any kind of proxy server settings? I've been caught out by that one a few times.

Everything on the subnet is used for animated lighting control. The "servers" on the other end of the network are controllers for controlling RGB lighting. The software/ servers communication using a protocol called E1.31 which is a specialized protocol for lighting control. It uses Ethernet as the transport. The controlling software encodes the control signals and addresses them to a specific address (such as 10.10.10.151). The addresses used are setup in the software itself. Other than addressing the data, the software does no routing and has no knowledge of how the signal arrives at its destination. I know that the software, network, routing table, and controllers are all working properly because the software properly controls the lights.

However, I need to be able to "talk" with the controller, via my browser, in order to adjust the controller's settings. And Firefox (and Internet Explorer) will not connect to the controller under this network configuration. If I disconnect the network on NIC 1 (home network and internet connection), then Firefox will connect with the controller on NIC 2 with no problem. That has been the problem that started this question.

I am assuming that Firefox is sending the address request straight to the internet instead of Windows actually routing the request to the proper NIC. But I don't know enough about how Firefox works to correct this. Of course, I am just guessing about how Firefox is routing the address. I could be way off.

I hope this helps in the understanding of my problem.

Thanks for your interest. Jim W

It certainly is an interesting setup. Now you've mentioned that disconnecting NIC1 allows you to connect to the lighting controller (I assume it's some kind of web based administration thing?) and that both FF and IE cannot connect to it when NIC1 is active. I'm also assuming that when NIC1 is active, the E1.31 software is still able to communicate?

The odd thing here is that the network status of NIC1 shouldn't matter, as the controller is on the same subnet as NIC2, that's what's got me scratching my head, and undoubtedly why you are scratching yours too.

The only thing that comes to mind is the Windows Internet Connection settings (or Internet Options) in control panel. Both FireFox and IE can be set to obey whatever is set in those. Other software may or may not pay any attention to them, so if that is the case, the E1.31 software may not be and that's why it can connect regardless. It's worth checking them out in any case. Internet Options>Connections>LAN Settings and make sure nothing is ticked.

I'll keep thinking about how those browsers could be "fiddled" with. If it's not the internet options then it has to be something sitting between the browsers and the tcp stack.

Thanks for your persistence. I was also thinking about the internet options, but that would mean reconfiguring them each time I wanted to talk with something on NIC 2.

I have found the answer, thanks to a friend of mine. I actually don't fully understand the solution, but it works. I added a persistent route to the Windows route table as follows: 10.10.10.0 mask 255.255.255.0 10.10.10.1.

This resolved the issue but I am not sure why. I would have thought that the second line of my original table (in a post above) would have taken care of the issue. In words, I think that line says: for any address starting with 10, and any mask of 255+, route to 10.10.10.1. I would have thought that would take care of it. But by adding the above persistent route, everything now works as I would expect it to.

Thanks for the help and discussion. Obviously this was not a Firefox issue, but it was a route table issue. Jim W

Glad you found the answer. Network issues like that are always a PITA. You should mark your own post as the accepted answer. It stops this thread showing up in "Unsolved Problems" searches.

That route table entry is basically what should have been the default route for that subnet. It should have been in there automatically. Basically if the destination ANDed with the subnet mask is equal to the table entry ANDed with the subnet mask, then it matches and the route is through the specified gateway.