"Mick2767" <(E-Mail Removed)> wrote in message
news:8B82C9CF-43ED-49BA-9A43-(E-Mail Removed)...
> 2 Nics in Windows 2003 server one private one public- odd issue
>
> I am at a new client who has A windows 2003 server acting as their default
> gateway with 2 Nics. One nic is private and plugs into hub, one is public
> and plugs into router. There is no firewall.
Might not be true. If this is a Cable or DSL connection then the "router"
really isn't a router, but is actually a NAT Box,...which effectively makes
it a "firewall". Now we could all argue all day as to how good a firewall
that makes,...but none-the-less it would be functionally a "firewall"
because machines behind any NAT Device are not directly exposed to the
Internet, except for 1-to-1-NAT situations.
> There is one https web site
> that no workstation can get to, but from the dual NIC server you can get
> there.
Why does the server have two Nics? Are they running RRAS/NAT on the box?
This would create two "firewalls" because it would also be a NAT
Device,...so now you would have two firewalls when you thought you have none
and you would most likely have a Back-to-Back DMZ between the Server and the
"router".
> the Dual NIC server private IP for DG. Does anyone have any idea where in
> the server I could look to see what is going on I also connected to other
> https sites OK.
Does the Server run any type of "proxying" service on it? Are their proxy
settings in the Client machine's browser? Does the https site run on some
port other than 443? If the answer to these three questions are all
"yes",..then that is your problem. Most proxy server sytems are hardcoded to
allow https *only* on port 443 due to the security risk of running https on
a non-standard port. The Server itself may get to the site because it may
not have to use the "proxying services" that the clients are required to
use.
The relevant portion of the following article/link is this paragraph:
"Security Considerations
CONNECT is really a lower-level function than the rest of the HTTP methods,
kind of an escape mechanism for saying that the proxy should not interfere
with the transaction, but merely forward the data. This is because the proxy
should not need to know the entire URI that is being accessed (privacy,
security), only the information that it explicitly needs (hostname and port
number). Due to this fact, the proxy cannot verify that the protocol being
spoken is really SSL, and so the proxy configuration should explicitly limit
allowed connections to well-known SSL ports (such as 443 for HTTPS, 563 for
SNEWS, as assigned by the Internet Assigned Numbers Authority)."
Tunneling SSL Through a WWW Proxy
http://muffin.doit.org/docs/rfc/tunneling_ssl.html