Router wipes host header info when port forwarding

[feakbeak]

Goal:
Run two websites on my home network, behind my router, that each have their own domain name using my one IP address from Comcast without having to type port numbers in for the URL.

Setup:
I'm running IIS6 on a Windows Home Server behind my D-LINK DI-624 router. I have the router configured to forward WAN requests to the router on port 80 to go to the Windows Home Server. On the Home Server I have my two websites configured with these web identities.

Site1: IP - (All Unassigned), Port - 80, Host Header - www.site1.net
Site2: IP - (All Unassigned), Port - 81, Host Header - site2.homeserver.com

Results:
Site1 works fine using the domain name. Site2 does not work properly and instead I get a "Bad Request (Invalid Hostname)" error message. If I swap ports on the sites, the reverse happens, basically whichever port is not on port 80 won't work.

Hypothesis:
Researching this issue I found common causes of this are browsers sending HTTP 1.0 requests that don't support the host header info or that IIS is not receiving the host headers in the HTTP requests, i.e. they are getting stripped out somewhere along the way.

I know my browser was using HTTP 1.1 so I investigated the latter and upon reviewing the IIS logs it would seem the host header info is getting ripped out before it gets to IIS. My entries look like this when I try to hit Site2.

2009-07-29 03:35:51 68.40.123.123 60491 192.168.0.100 80 HTTP/1.1 GET /home/default.aspx?gotodefault=true 400 - Hostname -
2009-07-29 03:35:54 68.40.123.123 60492 192.168.0.100 80 HTTP/1.1 GET /favicon.ico 400 - Hostname -

I'm assuming the Hostname should have an entry with the requested domain. I'm far from a networking guru but my guess is that the HTTP host headers are getting stripped out by my D-LINK router when it does the port forwarding.

Questions:
1. Can anyone confirm if routers typically do this as part of port forwarding?

2. I'm considering upgrading my router anyway, are there routers that preserve the host header info through port forwarding? I've tried Googling but haven't had much luck finding info about this topic.

3. I have another router-turned-wifi-bridge running the DD-WRT firmware. That firmware seems rather robust, does anyone know if that supports preserving host header info through port forwarding?

4. Are there any other solutions that would be relatively easy to implement that would achieve my stated goal?

Thanks in advance for your time.

 

[drebo]

What you are trying to do is not going to work. Additionally, you even told the router to port forward port 81 on site2.homeserver.com. In order to access that, you need to specify port 81 in the URL. The reason you are getting a "bad request" is because your IIS is configured to look for www.site1.net on port 80, and unless it sees that, you'll get the default website (or bad request if it doesn't exist). Basically, the bottom line is that what you're trying to do isn't really going to work with your current knowledge set. Someone with much more networking experience could probably get it to work, but the simplest solution is just to use the :81 on one of your domains. It's really not that big of a deal.

There's a general rule when dealing with NAT: ALGs (application-layer gateways) don't really work. I run into it with SIP all the time. The NAT router tries to rewrite the packet headers to account for NAT, and it doesn't work. It's far easier to have the server and client use the built-in methodologies of the protocol in question to accommodate for NAT. So, what you'd want to do is ignore this "host header" field and just forward port 80. Then configure IIS to look at whichever port. IIS can handle multiple websites on a single IP and port if you specify different hosts for it. It looks to me like you're expecting your router to rewrite the host, and it's not going to work.

 

[spidey07]

Just forward port 80 to the web server and use host headers to make two separate sites on port 80 on one IP. Much more straight forward and used all the time for hundreds of websties on a single server.

 

[Crusty]

/agree

Virtual Hosts are the way to go if you need more than 1 site on a single server.

 

[spidey07]

And one more thing - for the most part NAT won't rewrite anything for HTTP at the application layer, there isn't any need to. Other protocols like FTP, H323, SQLNET, etc it can/does but not HTTP unless you are doing some funny stuff, and then you'd be looking at a L7 or application switch/content switch/load balancer, etc.

 

[feakbeak]

Thanks for the responses.

On my router, I am only forwarding port 80 from the WAN to my one web server (the Windows Home Server box). So all HTTP requests coming in are going to be my web server just fine. On the web server I defined my two websites with their respective host header information, one running on port 80, the other on port 81 and I'm letting IIS direct the requests to the proper site...

Oh wait, I think I realized what I'm doing wrong. I thought IIS would read all the HTTP requests and then redirect them to sites on other ports internally. But if I am following you all correctly, only the host header info should differ in my web identities. So instead of how I had them in my original post, I should be using this:

Site1: IP - (All Unassigned), Port - 80, Host Header - www.site1.net
Site2: IP - (All Unassigned), Port - 80, Host Header - site2.homeserver.com

Does that sound right or am I hopelessly lost?

Thanks again

 

[spidey07]

Nope, now you're getting it. Do exactly that. And repeat as many times as you wish for however many sites you wish.

 

[RebateMonger]

Yup, that's how it's done. Your only problem now will be if your ISP decides to block inbound TCP Port 80. But I don't believe that Comcast does so.

 

[feakbeak]

RebateMonoger, no Comcast isn't that annoying. I've been running a webserver for years at home - just that I now have a need to put a second one up.

Changing that one port number in IIS did the trick. I was so close, yet so far away... frequently seems to be the way it goes with these things. Thanks again all for your time and assistance.