SMF 2.0.9 and IIS 8.5 URL-rewrite 2.0

[DeAurion]

Hi Everyone,
I am struggling with something and I could really use some help about now. Hopefully I am posting in the relevant section, if not - my apologies!

The issue I am having comes from trying to run a SMF instance on IIS 8.5 behind another IIS 8.5 server using url-rewrite 2.0 to "route" the requests to the internal server.

This is the structure of the setup:
Top domain: hxxp:mydomain.com [nonactive]
Forum url: hxxp:forum.mydomain.com [nonactive]

The top domain points to the external IP of the first IIS server. Let's just assume that IP is 111.222.233.244 and the local IIS server's IP is 192.168.5.55.

The public IIS server rewrites the incoming requests e.g. ( "hxxp://" is really http://)
          "hxxp://forum.mydomain.com/index.php"  -> "hxxp://192.168.5.55/index.php"

Using a rule like:
          hxxp://forum.mydomain.com/(.*)

Into the new url: 
          hxxp://192.168.5.55/{R:1}

Outgoing requests are changed by the rule filter:
         (.*)192.168.5.55(.*)

Into, basically the reverse of the rule above:
         {R:1}Forum.MyDomain.com{R:2}

Upper/lower case is set to "ignored" in the matching dialogs.

The outgoing rule applies the following content/tags:
         A, Area, Base, Form, Head, IFrame, Img, Input, Link, Script

On the local network the local DNS server points "Forum.MyDomain.com" directly at 192.168.5.55. Meaning the request is not subject to the rewrite locally. The SMF is setup to use hxxp://forum.mydomain.com as "forum url". The SQL server is set to "localhost", the latest free MySQL server release running on the same server as the forum (192.168.5.55).

The forum works flawlessly when browsed on the local network but it seems the url-rewrite causes some problems when used from the outside. Everything appears normal at first glance, all images and links are working and pages load quickly. However, users cannot make posts and admins are unable to pass the "second password challenge".

When someone tries to make a post from an external point, this is the error message:
Your session timed out while posting. Please try to re-submit your message.

When admins try to access the admin functions the second password challenge gives the following error:
Unable to verify referring url. Please go back and try again.

I have played with the "local cookie", "database driven session" and "subdomain independent cookies" settings but they do not affect the messages, on or off. I left them 0, 1, 1 for now. I even tested dropping the database's "session table" along with errors and online users as some post on here suggested, even though that should be irrelevant since everything is working when the url-rewrite is not in play. No change.

So, finally. Can someone please tell me what am I breaking in the session/url verification with the rewrite and how can I avoid it? This kept me up half the night!

If I can do the "redirect" in any other way than an url-rewrite (in expectation that it will cause less problems) I am open for suggestions but obviously I am not out to replace IIS or the general structure of the servers.

Thankful for any help!

/DeAurion

[Phphelp]

I'm interested to hear what the solution is to this. I run the Forum off IIS as well, but I don't have any crazy rules that rewrite the URL into an IP Address. (Which I'm sure is most likely the issue).  Internally, you should be able to browse on hxxp://192.168.5.55/, you'll probably get the same results as externally.

[DeAurion]

Thank you for your answer Phphelp! Yes, the forum works normally when accessed without the Url-rewrite rule, e.g. from an internal IP.

I speculate that the forum has some security feature where the IP and/or URL is hashed and then compared at some verification stage. This would lead to a mismatch if the url is rewritten. But I am at a loss on how to verify this is indeed the case or circumvent such an arrangement. Even if possible, I probably would not want to since it seems likely it would undermine the security of the forum in general.

Any help or insight is greatly appreciated!

[Kindred]

what is your FORUM actually configured to use as the URL?

[DeAurion]

Hi Kindred, if it is the field "Forum URL" then it is "hxxp://forum.mydomain.com" with "hxxp" being "http" of course. All the names and URLs are really lower case letters. I capitalized in original post for readability.

[Kindred]

well, that is your problem...

hxxp://forum.mydomain.com redirects to an IP address... this confuses the system and is wrong (as far as SMF is concerned)

the Forum URL in your settings should be the FINAL DESTINATION of the target.  in other words, if you are trying to use an IP as your final destination and are bouncing all calls which attempt to access hxxp://forum.mydomain.com to instead bounce to an IP address, then you need to use that IP address as your forum URL.

[DeAurion]

Thank you for trying to help me Kindred!

I remember trying to change this URL already late one night in pure desperation and I did it again now, following your suggestion. To ensure I understood correctly, this was what I entered in "forum URL": hxxp://192.168.5.55

The result is a little unexpected (even though I do not know what this field is used for). When someone tries to log into the forum they are redirected to hxxp://192.168.5.55 (as in it shows up in the address field). This IP is not public of course. (If it was exposed, I would not need the "url-rewrite", I could just setup new a DNS record).

This "redirect" to a local IP results in a page not found error, as it does not exist. But If the user then returns to the original url, "hxxp://forum.mydomain.com he will find himself logged in.

Regardless, the original problem persists, it is not possible to post and admins cannot pass the second password challenge. With the same messages as before even after the change to the "forum url" field.

Perhaps I was not very clear in the original explanation, hxxp:forum.mydomain.com [nonactive] points at the "final" external IP. The Url-rewrite is to an "internal" address.

[Illori]

maybe if you were not hosting your forum on your personal computer this would not be an issue. hosting on your own machine can be a security risk if you dont know what you are doing.

[Kindred]

basically, you seem to be trying to game the system -- and trying to do something that the forum is not intended to do.

your forum URL *MUST* be the final destination URL.
If you don't want users to see the IP, then you need a DNS/domain name at that location -- you can not point a redirect from one location to another location and expect the forum to continue to work properly, if your forum is set up to be used at the first location.

[DeAurion]

Thank you Kindred for responding.

I agree, it is apparent that it is not working. But with a fairly "technical" explanation of why, I might be able to determine what rewrite rule can be applied that does not break whatever validation is performed.

Exposing an internal website to external traffic is a fairly common scenario for web applications and is usually possible if the rewrite is correct.

I should mention that I have done this before with the SMF forums. I cannot recall which version from top of my head but it was in recent time so I suspect it was the same version. It might have been on an older version of IIS however and only god knows what MS is doing between releases. It may have to do with which tags are subject to the rules or how query strings are handled.

[DeAurion]

Hi Illori,
The forum is hosted on a dedicated virtual machine, which is actually one of the reasons for the need of the rewrite. I do not want to expose the VM directly.

[LiroyvH]

Wouldn't setting the public IIS instance up as a reverse proxy to the internal one would have solved all your problems without going through all kinds of rules...?

[DeAurion]

I very much appreciate your help CoreISP!

The public IIS instance is indeed setup as a reverse proxy. I do not know how other webservers implement reverse proxy (I expect it is something similar) but IIS relies on URL-rewriting. And running the reverse proxy setup creates the rewrite rules I described above.

I have tested entering the rules manually as well as allowing IIS to configure the rules with identical results.

I have not had time to play more with the settings, but after taking a closer look at the page source I think this is down to how the "new" IIS URL-rewrite works compared to the old version. In combination perhaps with how SMF reads the variable "smf_scripturl" and the return value of <a href="hxxp://forum.mydomain.com/index.php?action=helpadmin;help=securityDisable_why" onclick="return reqWin(this.href);"

I will try to do some experimentation tomorrow.