1 Webserver, 8 Sites, 2 Subnets? How can I make this work?

[JayInJersey]

We currently run a webserver that has 6 sites on it...all off one NIC...all using unique IPs...all on the same Subnet. The server is at a hosting provider.

We are adding 2 additional sites to it and need to add 2 more IP addresses. Our hosting provider set us aside some more IPs and connected a different NIC to THAT subnet.

The question I have is how do I configure this to work.

I tried just adding the IP addresses statically to the second NIC, but when I applied it, it stopped answering ALL hits. I think it has to do with the gateways being different on each of the NIC's but I can't figure out why.

If I leave off the gateway on NIC 2 I can't ping the address.

I setup NetMon on NIC 2 and I can see that my pings ARE reaching the card on then new subnet from our corporate network. It just appears that the new card has no DG to get out to the internet (which in all actuality it doesn't as I can't set the DG on NIC 2 without losing all net communication. )

Any ideas here?

[cluberti]

Unfortunately, a Windows machine on multiple subnets can create issues. You could try a second NIC in the machine, but there's no guarantee that it will work properly. It should, but no guarantees.

[JayInJersey]

It has a second NIC...that's what I'm having trouble configuring.

Let me try and give a better picture.

Internet --- Nic A --BOX-- Nic B --- Internet

Nic A is on Subnet A with DG for A

Nic B is on Subnet B but has no DG configured (When I set it, all network connectivity STOPS)

Nic A can ping the Internet and all nodes on Subnet A

Nic B can ping all nodes on Subnet B and RECIEVE pings from the Internet but it cannot send the pings back.

I feel there has to be some sort static route from Nic A to Nic B or from Nic A to DG B or from Nic B to DG A, but my expertise is NOT in routing.

Thoughs?

[GrofLuigi]

...but my expertise is NOT in routing.

Thoughs?

Same here, but you could play with ROUTE.EXE in prompt. Example: type "route print" in command box.

GL

[cluberti]

The problem ultimately boils down to the fact that Windows doesn't work well with multiple default gateways - which is a pain when you need two NICs for two separate networks. What's happening is all outbound traffic is going to attempt to go through the NIC with the default gateway set - you can somewhat avoid this using the route command, but again, it isn't going to work very well.

It would be better to get a device that understands multiple connections (used to recommend Nexland devices before Symantec bought them) in front of the web server, and have it do the routing to and from the web server. That way the web server itself won't need to understand how to route on multiple subnets.

[nmX.Memnoch]

Why not just use the host-header option in IIS and use one of the existing IP addresses? You just can't do this with SSL sites.

Basically, you point the new domain name to one of the existing IP addresses. Then in IIS you configure the host-header information for the existing site, then configure a new site with the same IP address, using another host header.

What happens from there is that when a client connects to IIS, IIS checks to see which hostname was used (sitea.com or siteb.com) to determine which content to serve to the client.

[JayInJersey]

Why not just use the host-header option in IIS and use one of the existing IP addresses? You just can't do this with SSL sites.

From what I've been told by our web designers (and from what I've gathered on SSL sites) we need to use separate IP addresses in order to obtain SSL certs.

If it is possible to get a cert that covers ALL addresses at the one IP...I'd love it.

I'm figuring there HAS to be a way or our location provider whouldn't have given us addresses on the second network.

Any ideas on what I need to route to what?

[nmX.Memnoch]

Why not just use the host-header option in IIS and use one of the existing IP addresses? You just can't do this with SSL sites.

From what I've been told by our web designers (and from what I've gathered on SSL sites) we need to use separate IP addresses in order to obtain SSL certs.

If it is possible to get a cert that covers ALL addresses at the one IP...I'd love it.

The SSL cert should be based on the hostname (site1.company.com, site2.company.com, etc), not the IP address.

However, as i mentioned you can't use the host header options in IIS for SSL sites. You can, however have multiple SSL sites running on one IP, as long as they're using different ports (not something that's recommended unless it's an internal administrative site or intranet though).

I'm figuring there HAS to be a way or our location provider whouldn't have given us addresses on the second network.

I would go back and ask them if you can get a block of IPs on the same subnet as the previous IPs. This way you won't have to deal with the multi-gateway issues.

[Mr Snrub]

The best solution is to have a collection of PRIVATE IP addresses on the ONE subnet on the IIS server, one per site, then use a perimeter firewall to NAT the private IP addresses to public IP addresses.

Then your server has 1 default gateway, needs only 1 NIC and has no issues with multiple SSL-enabled sites.

Move the networking problem to the perimeter, make it someone else's problem, and do not connect servers onto the Internet directly.

A server should never, ever required a public IP address on one of its interfaces.

[nmX.Memnoch]

That's the ideal solution but when you're renting a server from a hosting provider they rarely, if ever, set them up that way. That's not to say that you can't get them to do it upon request, but of course that's going to cost you extra per month.

[Mr Snrub]

That's the ideal solution but when you're renting a server from a hosting provider they rarely, if ever, set them up that way. That's not to say that you can't get them to do it upon request, but of course that's going to cost you extra per month.

A hosting provider that gave that level of "service" I would kick into touch - I would consider my payment to them to offload the networking overhead (admin, bandwidth and redundant connectivity).

If they attempted to extend the service by adding a second NIC and configuring it in a way that doesn't work then that would shatter my faith in them.

To also allow direct connections with the servers from the Internet, having public IPs on the servers themselves is just plain nuts - "carrier class" firewalls with many interfaces can cope with Internet-speed and throughput traffic and have high availability, offloading the issue of securing every single server against (typically DDoS) attacks.

[nmX.Memnoch]

If they attempted to extend the service by adding a second NIC and configuring it in a way that doesn't work then that would shatter my faith in them.

I agree with that 100%. There really shouldn't be any reason to use the 2nd NIC at all. I suspect they're just trying to get extra money by making them pay for the additional connection...sneaky indeed.

To also allow direct connections with the servers from the Internet, having public IPs on the servers themselves is just plain nuts - "carrier class" firewalls with many interfaces can cope with Internet-speed and throughput traffic and have high availability, offloading the issue of securing every single server against (typically DDoS) attacks.

Unfortunately, they all see hardware firewalls as additional hardware to what you're paying for (namely, the server). And as such, they'll consider it as another service they provide...for a fee.

I agree that connecting it directly to the internet isn't the best option, but when it's your only option you should be making sure that IIS is configured correctly (for starters, IUSR_ should only have access to the web root, and no write access to what it does have access to), keep on top of all patches that apply and don't do things on the server that you shouldn't (again, no web browsing on your servers). And if you have any administrative sites (Sharepoint Admin Site, etc) they should be limited by username and IP addresses. Securing IIS under Server 2003 isn't all that difficult.

Again, I agree with you that you shouldn't connect them directly to the internet...but all too often people either don't understand that or don't want to pay the extra associated cost(s). The hosting provider we use for some personal sites charges an additional $99/month for a SnapGear SME550. While it's a decent box the 35Mbit/s throughput would hinder our 100Mbit/s connection...which we also pay extra for. This particular box is currently running FreeBSD, but it was running Server 2003 for over a year without any problems at all, which I attribute to a (mostly) proper configuration.

[Mr Snrub]

Securing the server isn't so much of an issue and my main concern - a lot of issues come about from attacks aimed at the HTTP port on server anyway, so the server still has to take the hit of working out who has access to what and not falling over if it encounters something nasty.

My issue is with the "other" junk flying around, and the fact that the server is going to be consuming resources handling filtering the traffic for ports other than that aimed at the port it actually runs a public service on.

I'm not talking about basic SYN floods, but more complex DDoS-style attacks which if the server has to handle would be guaranteed to impact its performance.

But then, we live in a world where people put SQL servers directly on the Internet without protection too - and that I can't fathom at all :/

I guess my expectations may be a little high as I built a hosting solution a few years ago for a bank...

[nmX.Memnoch]

Hehe...yeah, I definitely know what you mean. Unfortunately we don't live in a perfect world though...