Loading website on port 1433 without using “:1433”

NeghVar

2[H]4U
Joined
May 1, 2003
Messages
2,671
Boss wants me to set up a website so that by typing "https://www.mydomain.com" (no :1433) in the address bar of a web browser, the request will go through port 1433 on a Watchguard Firebox to an apache web server with domain-ssl.conf containing

Listen 443
<VirtualHost *:443>
ServerName www.example.com
ServerAlias example.com
DocumentRoot /var/www/example.com/public_html
ErrorLog /var/www/example.com/error.log
CustomLog /var/www/example.com/requests.log combined
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/example/apache.crt
SSLCertificateKeyFile /etc/apache2/ssl/example/apache.key
SSLCertificateChainFile /etc/apache2/ssl/example/apache.ca-bundle​
</VirtualHost>

Can this be done? If so, how?
 
Reverse proxy? A frontend web server that will relay requests to the "1433" server, if I got it right.
 
As mentioned, reverse proxy is one way to do it. Probably a faster way to do it is to AllowOverride on the root directory on the port 80/443 website, then place an .htaccess file in there with the following:

You could put the redirect straight in the http.conf file, but I prefer to separate it out for ease of future configuration updates.
 
Wait, you want it to go through your firewall on port 1433 without putting that port in the URL?

ASCII Diagram of my understanding:

Client --- 443 ----> ???? --- 1433 ---> Firebox --- 443 ---> Web Server

Am I getting this correct?

Where is the web server? In the DMZ? In your internal Network? Do you have a Load Balancer?

If that is the case, then you would need either a Proxy server outside of your firewall, or a Load Balancer outside your firewall.

Why does it need to be on port 1433? It is possible to run more than one SSL certificate on a web server with named hosting.
 
Redirect 301 would expose the port number in the URL from the start (after the transparent redirect). There are many solutions, it all depends on what OP can accept or not as side-effects and/or additional hardware/software.
 
Redirect 301 would expose the port number in the URL from the start (after the transparent redirect). There are many solutions, it all depends on what OP can accept or not as side-effects and/or additional hardware/software.
True, I was making a number of assumptions; the primary being that the goal was to make it easy to access, not to mask the port # at all.
 
I convinced her to just go with ":1433" Told her that the browser will only support 443 and 80 without the extra port specification. Other options are more costly and impractical. The exact URL can simply be saved as a bookmark. "Is it really worth buying a load balance or reverse proxy server and setting it up just over typing :1433?
I changed Listen and virtual host to 1433
 
I convinced her to just go with ":1433" Told her that the browser will only support 443 and 80 without the extra port specification. Other options are more costly and impractical. The exact URL can simply be saved as a bookmark. "Is it really worth buying a load balance or reverse proxy server and setting it up just over typing :1433?
I changed Listen and virtual host to 1433
If you did the nginx reverse proxy, it wouldn't be more costly. That costs exactly $0 and maybe 5-10 minutes to configure.
 
Yes, if you already have a ":80" port web server serving the "main" site and you just have this :1433 server in the same LAN (or outside), you just need to configure the :80 server to relay ":1433" requests (coming through another domain name also on port 80) to the ... :1433 server.
 
What are you actually trying to accomplish here?

The internal server is setup to listen on port 1433? Is there a reason for that? That's just about the worst port you could possibly pick for a webserver, since it's the standard port for MS SQL. If you're wanting security through obscurity just know that people will scan the heck out of that port if you have it open on the internet.

If you wanted it so that from the Net someone puts in the url and it's redirecting you, then sure you can use a proxy to make 443 redirect your client to reconnect on 1433, but that means you need to still have 443 open outside for that to work. So scanners will get properly redirected to 1433. But all of that is way more complicated than it needs to be. The watchguard itself can do PAT. So when you setup your port forward, make it so that the external IP that's being used to redirect you is setup to redirect the connection from 443 to 1433. If you are using DNS internally then I you might need additional configuration to make it work right if mydomain.com isn't always a public IP, but I'm guessing that's not the case here.
 
If you did the nginx reverse proxy, it wouldn't be more costly. That costs exactly $0 and maybe 5-10 minutes to configure.
And, everyone should have an NGINX reverse proxy infront of their webservers any ways, even if just for security settings to drop bad traffic, then cache if you want it...fastest most secure way to secure any webserver, especially if it is an IIS server. No IIS server should be front facing the Internet!
 
I have many IIS servers facing the internet without issues for decades :) . It's the first time I read IIS shouldn't be facing the internet. For firewalling, filtering etc. I/we just use ... firewalls/routers etc. E.g. no server should be directly (in the real sense) facing the internet without any firewalling, Not only IIS. I have had breaches to Linux servers in the past, so only because a server is IIS is not any more (or less) dangerous than any server software.
 
Back
Top