a client of mine asked me to implement the extranet  access (with basic
authentication) for his Sharepoint server. I've done this a cople of time
before without to much effort. This time things are a bit different, because
I need to use only the IP address and not an external FQDN. I've read some
messages on newsgroups telling that you couldn't publish a SPS server only
with the IP address and others telling that there is no problem doing so.
I tried to publish the server only with the IP address, but without success.
The SPS server is behind an ISA server and I did the following:
* configured the proxy server
* created a new web site on IIS and modified the security settings according
to Microsoft white paper. On this point in the new web site I specified as
'Host Header Name' the external IP address of SPS server
* on the ISA server I created a destination set with the external Ip address
of the SPS server
* published  the SPS server with the wizard of 'Web Publishing Rules',
specifing to send the original host header name to the publishing server.
* created a index.htm, for testing purpose, that say 'hello world'
* added the external IP address of the SPS server to the ISA server external
NIC (i.e. the NIC connected to Internet)
Then a tested SPS server from the Internet. I can see the 'hello world'
typing http://<IP_address>, but I receive a dashboard error -2147217895 if I
type http://<IP_Address>/<workspacw_name>/

SPS V1, only use FQDN, no workaround for this

From the Esdtranet White paper:

Important You cannot access  the sharepoint  Portal Server computer by typing
its IP address and port number. For example, you cannot use
http:// 172.21.13.45 /workspace_name or
http:// 172.21.13.45:8080/workspace_name.

I've configured the extranet  access for my SPS server using the extranet
tool you find in sharepoint  resource kit, but when I try to access  the site
from extranet I get the host non found message.
My environment  is as follow:
a windows 2000 domain behind an ISA server; the ISA server has two nic
installed, one connected to the internal Lan and the other connected to
Internet. I've published  the SPS server on the ISA server following the
wizard of 'Web Publishing rule' (I know that Microsoft white paper says
that to map the external IP address of the SPS server to its internal IP
address you should use 'Server publishing rule' but that doesn't apply to
ISA server) and I added the external IP address of SPS server to the
external nic of the ISA server, the one connected to Internet. I also added
an entry in the Hosts file of the SPS server that points the internal IP
address of the server to its external FQDN.
The authentication in the extranet site is set to Basic. the proxy settings
are the following

Flags = PROXY_TYPE_DIRECT | PROXY_TYPE_PROXY
Proxy Server = ISA_internal _IP_address:8080
Bypass List = *domain.local;external_FQDN;<local>
where external_FQDN is the external name of the SPS server and domain.local
is the internal FQDN of my windows 2000 domain.

An entry in the DNS panel had been added a long time ago (our DNS is managed
by our ISP) so that the FQDN could be rosolved to an IP address and if I do
a nslookup search the FQDN is resolved correctly to its public IP address.
So everything seems correct. My SPS server has windows 2000 service pack 3
and SPS service pack 2 installed.

We have our share point open via internet.

We don't allow anonymous access  so everyone needs to login.

Now on most internet connections this works, but some external people at
specific sites don't get access. The get the login but whatever they
try, they can't get connected.

I suppose this has to do with the firewall at these sites, but I wonder,
is there anything I can do at our site?

I didn't do anything special on our site apart from setting up the
router to forward the port 80.

What type of authenitcation are you using - NTLM (Windows Integrated) or HTTP
Basic? If it's the former, it is probably being blocked by the firewalls of
those external folks as you suspected. Only way to fix is to either switch to
Basic (make sure you use SSL if you go this route to avoid sending credentials
in the clear) or talk the network administrators at each site that fails to
allow NTLM.

A link..

http://tinyurl.com/3lwlj

This is the firewall.. it has to do with NTLM authentication not being
carried. Your solutions are either HTTPS or basic authentication (basic
can be set on the sharepoint  site)