Infrequently enough to forget, I find the need to redirect all non-SSL requests to SSL… or similarly, force the WWW prefix onto a url when the initial navigation comes in without it.
I instinctively reach for the URLRewrite module due to it’s flexibility, but i’ve found that it can actually lead me astray in these particular scenarios…
Create a separate IIS web site for the “undesirable” url which does a simple HTTP Redirect to the desired path
Especially in the case of SSL, this is definitely the way to go because you’ll also want to enable “Require SSL” … which outright prevents the the non-ssl url from being able to respond with a URLRewrite Rule… i.e. the Require SSL checkbox yields a hard 403 error immediately upon resolving the non-SSL path, no other logic executes… and at this point, the IIS admin console just stares back blankly awaiting orders with no help out of this blind alley.
by creating a site entirely for the non-ssl redirect, we can then set that site’s physical path to something harmless, leaving no doubt the SSL URL is the only way in to our sensitive physical path.
Separate Physical Folder FOR EACH SITE
To be perfectly clear, each redirecting sites’ physical folder will now merely provide containment for its corresponding solitary web.config, yet it is crucial each site is indeed configured with a unique physical path and web.config… this is obvious once considered but can be a momentary point of confusion until one realizes why all the different sites’ settings are overlapping 🙂
Besides opening incoming HTTP ports in the firewall via “Global Rules”, the annoying thing for me to find was also adding an “Application Rule” for “Windows Operating System” on those same ports.
And this guy explains what’s necessary for FTP very nicely…
- in comodo > global settings > application rule – add 20,21 & 5000-6000 as allowed incoming TCP ports on “Windows Operating System”… you will also hopefully get prompted to allow svchost which is responsible for running the ftpsvc
- on internet router – forward ports 20,21 and 5000-6000
- in IIS FTP settings
- require SSL
- firewall support – put external wan address in
- firewall support at *SERVER* level (not site) – set ports 5000-6000
- point ftp site a folder
- create login for ftp and make sure it has access to folder
- filezilla settings
- require explicit ftp over tls
i was having a heck of a time trying to get “net use * http://myhost.com” type WebDAV client mounts to connect… all that would ever work would be http://localhost … nothing i tried would connect to my WAN ip… always something like “System error 5… access is denied”… then i thought, ah what the heck, gotta google it… and sure enough… loaded the trial of WebDrive from South River Technologies simple little gui popped up, hit ok and two seconds later i was sitting on a W: drive in explorer… Right Mouse > New > Text Document worked, so i had write capability… obviously i had to twiddle some bits on the IIS end too but that was mainly just a matter following any typical IIS WebDAV walkthrough guide… cool, $60 for a one off license is reasonable…oh yeah, it’ll also map a drive letter to an FTP Server, Amazon S3 and SharePoint… i leave you with… ahhhhh yes the logo
UPDATE: plain vanilla “net use…” command worked straight away from an XP machine at work… so the security bits somehow weren’t lined up to let me be a WebDAV client on the Windows 7 instance i was testing with as my WebDAV IIS host… moving along…nothing to see here 😉
UPDATE 2: still gotta hand it to WebDrive… plain vanilla “net use” mounted WebDAV drives are running through Microsoft’s “WebDAV redirector” layer (aka the “WebClient” NT Service)… and it does work for small files, but large files (e.g. 250MB) tend to go off in lala land while doing the transfer (i.e. progress bar was useless) and failed consistently… WebDrive has a much more robust caching/chunky upload facility with a slick UI that shows actual progress bar… it did still fail after multiple attempts of my big test file so i had to split up into smaller chunks (e.g. 30MB) but the progress visibility WebDrive provides along with automatic retries is definitely worth something.