Server binding to NIC's IP does not work as expected

Shadbolt

I am running Abyss X1 v 2.5 on Windows Pro XP-SP3. This server computer has two Network Interface Cards (NICs), each on a separate subnet.
NIC1 is connected to the Internet through a router. All incoming Port 80 traffic is forwarded to the IP of this NIC. This is the way the incoming requests are received and the web pages served. The Abyss software is "bound" to the IP of this NIC.
NIC2 is connected to another computer to allow the server to be controlled using Windows Remote Desktop Protocol (RDP).
The problem.... HTTP requests arriving on NIC2's IP are being served. Somehow the server software is receiving and honouring requests on NIC2's IP. I thought that binding the server software to NIC1's IP would prevent this.
I wish to stop the server software from listening on or sending anything to NIC2's IP.
Suggestions, please.

loloyd

That is indeed weird and interesting.
If what you describe is accurate, this may well be a bug. In the meantime, I suggest you trap HTTP requests on NIC2 via your favorite firewall software.
Are you sure you have correctly configured your IP bindings in http://127.0.0.1:9999/hosts/host@0/edit/general/advanced/edit ?

Shadbolt

Thank you for the reply.
Between the time when I posted my message and your reply I have been tinkering! I discovered a couple of things that might have caused an unexpected route between my server’s NIC1 and the computer issuing the HTTP requests, but I am not sure of this.
I have checked the binding as you suggested. It shows the NIC1's correct IP.
Here is a summary of what I am observing now. Please note, there is a NAT router between my computer and NIC2 on the web server.
1. With this router NOT blocking Port 80 (or any other traffic), HTTP requests to Port 80 fail with an error message “Fail to Connect”. I think this indicates that the request is getting to the server and is being refused. This is good.
2. However, HTTP requests to the Console on Port 9999 are honoured. This is not what I want and may be the source of my assertion that web traffic is working on NIC2 even though the server is bound to NIC1.
3. With the router programmed to block Port 80, the error message changes to “Network Timeout” indicating to me that the router is stopping the request before it gets to the web server. Even better.
4. To get the performance I want I am blocking Port 80 and Port 9999 in my router. Now the Console requests on Port 9999 on NIC2 go unanswered.
Conclusion. I think a few related suggestions for improvement come out of this experience:
1. There needs to be a way to bind the Console Port to a specific IP, just as one can bind the regular server port.
2. It should be made possible to bind the Console Port to a different IP than that used by the regular server.
3. It should be made possible to turn off the Console Port entirely except for local request to 127.0.0.1
Thanks for your help. I now have things working the way I want them to work.

pkSML

I'm curious why you have two NICs on your server. I have XP Home on my server, so I have to use TightVNC for remote desktop access. It just goes through the regular wires, and I can access my server's desktop anywhere I'm on the net. Why do you have a dedicated network card for RDP?

Shadbolt

Thanks for your interest.
Why am I using a second NIC? Good question, and one I will try to answer.
The second NIC is a component of a security scheme in which I am trying to isolate the Web Server from the rest of my network.
In my network I attempt to keep malware at bay in various ways. Until the recent addition of a web server my Internet connection was entirely “stealthed”, invisible to passing port scanners. Now I am advertising that there is something to be hacked on my IP address, and it’s there 24 hours a day.
So, right from the start I put the Web Server on a separate machine, one that has no other function and is not connected to my other computers. Using one of its Network Interface Cards (NIC1) the Web Server is attached to the LAN side of my DSL modem through a router that has no other job (Router1); the rest of my network has another router (Router2).
The idea is that if the web server catches a virus any malicious activity will be contained and unable to spread to my other computers.
Now that I have built a cage around the web server I still have the problem of how best to control it. I decided to try the Remote Desktop (RDP) feature offered as a part of XP professional. In order for this to work there needs to be a route between the Web Server – the Host in RDP parlance – and the machine at which I sit to control it, the Client (a/k/a Control Computer). The Host (Web Server) listens on TCP Port 3389 for RDP connections.
I have two NICs in the Control Computer also: NIC3 for regular web traffic (through Router2) and NIC4 used only for RDP traffic. NIC4 connects to the LAN side of yet another router (Router3). The WAN side of Router3 is connected to NIC2 on the RDP Host (Web Server). Router3 is configured to allow only traffic on Port 3389 to pass.
So, I have a private circuit between the Web Server and my Control Computer, one that carries only Port 3389 traffic and is open only when communication is initiated by the Control Computer.
The NICs are not bridged, so traffic arriving at the Control Computer on NIC4 stops at that machine.
Only the Control Computer is able to access the Web Server. This is the way I like it.
One step I have yet to implement is to program Router1 so that only Port 80 traffic will pass.
I would appreciate comments.

pkSML

Shadbolt wrote
One step I have yet to implement is to program Router1 so that only Port 80 traffic will pass.
I would appreciate comments.

The only way I know of how to do this is to have custom firmware. That's not exactly easy. The only other solution I know of is to have a Linux box with dual NICs functioning as your router. That's beyond my skill, but I know it's a viable solution for the ubergeeks!

Shadbolt

I have a rather old Netgear router, model RP614v2, running the most recent firmware (5.20_RC3NA, dated 2004-04-23) that has the ability to block ports.
There is a “Block Services” feature that allows ranges of ports to be blocked for TCP, UDP, or both. I have blocked ports 1-3388 and 3390-65535 for both TCP and UDP by adding just two rules. Then one click on blocking “Always” and another click to “Apply” and you have it.
This model is available used here for about $10. As soon as I can find another one I’ll implement Port 80 only pass-through in the Web Server’s route to the Internet.