| Author |
Message |
Vic
Guest
|
 Posted:
Mon Jan 03, 2005 11:01 pm Post subject:
front-end OWA server |
|
|
This is good recommendation, but our DMZ is a sepereate subnet that can
route to the internal network (DMZ 192.168.100.xxx/Internal 192.168.50.xxx).
So all devices in the DMZ subnet could use NAT to an external IP address.
This is why we would like to keep the front-end OWA server on the DMZ.
"Andy David - Exchange MVP" <adavid@pleasekeepinngcheesebucket.com> wrote in
message news:4eldt0l9cftehbd7v61m41qdf6kpkdje5i@4ax.com...
| Quote: | Put OWA back behind the firewall. Use ISA or other simliar products in
the DMZ and reverse proxy OWA out.
On Fri, 31 Dec 2004 09:36:31 -0800, "Vic" <macanas@gmail.nospman.com
wrote:
I have setup a front-end OWA server to allow remote users to read their
mail
remotely (obviously). The problem I encountere is as follows; the OWA is
on
a DMZ and can be accessed from the internal network. When connecting to
the
OWA server from the outside (public ip) I cannot even connect to the
site.
Here is what our network looks like:
Internet
|
***Router***
|_____DMZ-----OWA Front-End (Using NAT IP 208.xxx.xxx.xxx
ext/192.168.xxx.xxx int)
| Other Web Servers
***Firewall***
|
Internal Network (Win2k3)
1 Exchange2k3 Ent. Server
2 Win2k3 DC's
|
Clients, etc.
When connecting internally to the OWA using (https://owa/exchange), I can
connect but cannot authenticate to the using any account allowed OWA
access.
When I bring the server back out of the DMZ and into the internal
network,
authentication works just fine.
Here is a list of ports that have been opened on the Firewall:
a.. For Exchange Communication:
a.. Port 80 for HTTP
b.. Port 443 for SSL
c.. Port 691 for Link State Algorithm routing protocol
b.. For Active Directory communication:
a.. Port 389 for LDAP (TCP and UDP)
b.. Port 3268 for Global Catalog Server LDAP (TCP)
c.. Port 88 for Kerberos Authentication (TCP and UDP)
Can anyone please help?
Thanks,
Vic
|
|
|
| Back to top |
|
 |
Skipster
Guest
|
| Posted:
Tue Jan 04, 2005 3:53 am Post subject:
RE: front-end OWA server |
|
|
Vic
Is the OWA server part of the same domain as the exchange server? and from
looking at your diagram I am not sure why you opened up all those ports on
your firewall. Depending on the type of router that you are using you should
be able to go to https://owa/exchange from the LAN subnet and be able to
authenticate. You should not have to route through the firewall to make this
request so the firewall should not be the issue with not being able to
authenticate. When an internal client goes to https://owa/exchange your
router should forward the request to this server, there shoudl be no NATING
going on with this traffic. All the NATING should be happening on your
firwall facing the internet and the internet facing the DMZ interface. It
sounds like you have NAT going on with the DMZ subnet and the local LAN
subnet and this can be your issue when trying to authenticate.
"Vic" wrote:
| Quote: | This is good recommendation, but our DMZ is a sepereate subnet that can
route to the internal network (DMZ 192.168.100.xxx/Internal 192.168.50.xxx).
So all devices in the DMZ subnet could use NAT to an external IP address.
This is why we would like to keep the front-end OWA server on the DMZ.
"Andy David - Exchange MVP" <adavid@pleasekeepinngcheesebucket.com> wrote in
message news:4eldt0l9cftehbd7v61m41qdf6kpkdje5i@4ax.com...
Put OWA back behind the firewall. Use ISA or other simliar products in
the DMZ and reverse proxy OWA out.
On Fri, 31 Dec 2004 09:36:31 -0800, "Vic" <macanas@gmail.nospman.com
wrote:
I have setup a front-end OWA server to allow remote users to read their
mail
remotely (obviously). The problem I encountere is as follows; the OWA is
on
a DMZ and can be accessed from the internal network. When connecting to
the
OWA server from the outside (public ip) I cannot even connect to the
site.
Here is what our network looks like:
Internet
|
***Router***
|_____DMZ-----OWA Front-End (Using NAT IP 208.xxx.xxx.xxx
ext/192.168.xxx.xxx int)
| Other Web Servers
***Firewall***
|
Internal Network (Win2k3)
1 Exchange2k3 Ent. Server
2 Win2k3 DC's
|
Clients, etc.
When connecting internally to the OWA using (https://owa/exchange), I can
connect but cannot authenticate to the using any account allowed OWA
access.
When I bring the server back out of the DMZ and into the internal
network,
authentication works just fine.
Here is a list of ports that have been opened on the Firewall:
a.. For Exchange Communication:
a.. Port 80 for HTTP
b.. Port 443 for SSL
c.. Port 691 for Link State Algorithm routing protocol
b.. For Active Directory communication:
a.. Port 389 for LDAP (TCP and UDP)
b.. Port 3268 for Global Catalog Server LDAP (TCP)
c.. Port 88 for Kerberos Authentication (TCP and UDP)
Can anyone please help?
Thanks,
Vic
|
|
|
| Back to top |
|
|
Vic
Guest
|
| Posted:
Tue Jan 04, 2005 4:29 am Post subject:
Re: front-end OWA server |
|
|
The OWA server sits on the DMZ with an internal address off 192.168.100.xxx
NATING to an external address of 208.xxx.xxx.xxx so it can be accessible
from the internet. The internal network is on a 192.168.10.xxx subnet and is
routable with the DMZ network for security purposes. Also the OWA server is
part of the domain in which the main Exchange server resides. When the OWA
server is on the DMZ it is accessible from any of the internal subnets, but
when entering a username and password authentication fails. The next phase
would be to open the SSL (443) port so the OWA site can be accessible from
the internet. That is we still stand.
Vic
"Skipster" <Skipster@discussions.microsoft.com> wrote in message
news:89528C39-8392-4E9E-A29C-E5858C575FB0@microsoft.com...
| Quote: | Vic
Is the OWA server part of the same domain as the exchange server? and from
looking at your diagram I am not sure why you opened up all those ports on
your firewall. Depending on the type of router that you are using you
should
be able to go to https://owa/exchange from the LAN subnet and be able to
authenticate. You should not have to route through the firewall to make
this
request so the firewall should not be the issue with not being able to
authenticate. When an internal client goes to https://owa/exchange your
router should forward the request to this server, there shoudl be no
NATING
going on with this traffic. All the NATING should be happening on your
firwall facing the internet and the internet facing the DMZ interface. It
sounds like you have NAT going on with the DMZ subnet and the local LAN
subnet and this can be your issue when trying to authenticate.
"Vic" wrote:
This is good recommendation, but our DMZ is a sepereate subnet that can
route to the internal network (DMZ 192.168.100.xxx/Internal
192.168.50.xxx).
So all devices in the DMZ subnet could use NAT to an external IP
address.
This is why we would like to keep the front-end OWA server on the DMZ.
"Andy David - Exchange MVP" <adavid@pleasekeepinngcheesebucket.com
wrote in
message news:4eldt0l9cftehbd7v61m41qdf6kpkdje5i@4ax.com...
Put OWA back behind the firewall. Use ISA or other simliar products in
the DMZ and reverse proxy OWA out.
On Fri, 31 Dec 2004 09:36:31 -0800, "Vic" <macanas@gmail.nospman.com
wrote:
I have setup a front-end OWA server to allow remote users to read
their
mail
remotely (obviously). The problem I encountere is as follows; the OWA
is
on
a DMZ and can be accessed from the internal network. When connecting
to
the
OWA server from the outside (public ip) I cannot even connect to the
site.
Here is what our network looks like:
Internet
|
***Router***
|_____DMZ-----OWA Front-End (Using NAT IP 208.xxx.xxx.xxx
ext/192.168.xxx.xxx int)
| Other Web Servers
***Firewall***
|
Internal Network (Win2k3)
1 Exchange2k3 Ent. Server
2 Win2k3 DC's
|
Clients, etc.
When connecting internally to the OWA using (https://owa/exchange), I
can
connect but cannot authenticate to the using any account allowed OWA
access.
When I bring the server back out of the DMZ and into the internal
network,
authentication works just fine.
Here is a list of ports that have been opened on the Firewall:
a.. For Exchange Communication:
a.. Port 80 for HTTP
b.. Port 443 for SSL
c.. Port 691 for Link State Algorithm routing protocol
b.. For Active Directory communication:
a.. Port 389 for LDAP (TCP and UDP)
b.. Port 3268 for Global Catalog Server LDAP (TCP)
c.. Port 88 for Kerberos Authentication (TCP and UDP)
Can anyone please help?
Thanks,
Vic
|
|
|
| Back to top |
|
|
Skipster
Guest
|
| Posted:
Tue Jan 04, 2005 4:57 am Post subject:
Re: front-end OWA server |
|
|
why are you nating or filtering ports from the internal LAN subnet on the DMZ
to the internal local LAN subnet?
"Vic" wrote:
| Quote: | The OWA server sits on the DMZ with an internal address off 192.168.100.xxx
NATING to an external address of 208.xxx.xxx.xxx so it can be accessible
from the internet. The internal network is on a 192.168.10.xxx subnet and is
routable with the DMZ network for security purposes. Also the OWA server is
part of the domain in which the main Exchange server resides. When the OWA
server is on the DMZ it is accessible from any of the internal subnets, but
when entering a username and password authentication fails. The next phase
would be to open the SSL (443) port so the OWA site can be accessible from
the internet. That is we still stand.
Vic
"Skipster" <Skipster@discussions.microsoft.com> wrote in message
news:89528C39-8392-4E9E-A29C-E5858C575FB0@microsoft.com...
Vic
Is the OWA server part of the same domain as the exchange server? and from
looking at your diagram I am not sure why you opened up all those ports on
your firewall. Depending on the type of router that you are using you
should
be able to go to https://owa/exchange from the LAN subnet and be able to
authenticate. You should not have to route through the firewall to make
this
request so the firewall should not be the issue with not being able to
authenticate. When an internal client goes to https://owa/exchange your
router should forward the request to this server, there shoudl be no
NATING
going on with this traffic. All the NATING should be happening on your
firwall facing the internet and the internet facing the DMZ interface. It
sounds like you have NAT going on with the DMZ subnet and the local LAN
subnet and this can be your issue when trying to authenticate.
"Vic" wrote:
This is good recommendation, but our DMZ is a sepereate subnet that can
route to the internal network (DMZ 192.168.100.xxx/Internal
192.168.50.xxx).
So all devices in the DMZ subnet could use NAT to an external IP
address.
This is why we would like to keep the front-end OWA server on the DMZ.
"Andy David - Exchange MVP" <adavid@pleasekeepinngcheesebucket.com
wrote in
message news:4eldt0l9cftehbd7v61m41qdf6kpkdje5i@4ax.com...
Put OWA back behind the firewall. Use ISA or other simliar products in
the DMZ and reverse proxy OWA out.
On Fri, 31 Dec 2004 09:36:31 -0800, "Vic" <macanas@gmail.nospman.com
wrote:
I have setup a front-end OWA server to allow remote users to read
their
mail
remotely (obviously). The problem I encountere is as follows; the OWA
is
on
a DMZ and can be accessed from the internal network. When connecting
to
the
OWA server from the outside (public ip) I cannot even connect to the
site.
Here is what our network looks like:
Internet
|
***Router***
|_____DMZ-----OWA Front-End (Using NAT IP 208.xxx.xxx.xxx
ext/192.168.xxx.xxx int)
| Other Web Servers
***Firewall***
|
Internal Network (Win2k3)
1 Exchange2k3 Ent. Server
2 Win2k3 DC's
|
Clients, etc.
When connecting internally to the OWA using (https://owa/exchange), I
can
connect but cannot authenticate to the using any account allowed OWA
access.
When I bring the server back out of the DMZ and into the internal
network,
authentication works just fine.
Here is a list of ports that have been opened on the Firewall:
a.. For Exchange Communication:
a.. Port 80 for HTTP
b.. Port 443 for SSL
c.. Port 691 for Link State Algorithm routing protocol
b.. For Active Directory communication:
a.. Port 389 for LDAP (TCP and UDP)
b.. Port 3268 for Global Catalog Server LDAP (TCP)
c.. Port 88 for Kerberos Authentication (TCP and UDP)
Can anyone please help?
Thanks,
Vic
|
|
|
| Back to top |
|
|
Vic
Guest
|
| Posted:
Tue Jan 04, 2005 5:41 am Post subject:
Re: front-end OWA server |
|
|
Makes total sense to me what you are telling me....to my network manager it
doesn't! So I am trying to only forward the needed ports from the DMZ to the
internal network.
"Skipster" <Skipster@discussions.microsoft.com> wrote in message
news:902A0C96-61DC-47D5-AB2D-DC34A17DCC8F@microsoft.com...
| Quote: | why are you nating or filtering ports from the internal LAN subnet on the
DMZ
to the internal local LAN subnet?
"Vic" wrote:
The OWA server sits on the DMZ with an internal address off
192.168.100.xxx
NATING to an external address of 208.xxx.xxx.xxx so it can be accessible
from the internet. The internal network is on a 192.168.10.xxx subnet
and is
routable with the DMZ network for security purposes. Also the OWA server
is
part of the domain in which the main Exchange server resides. When the
OWA
server is on the DMZ it is accessible from any of the internal subnets,
but
when entering a username and password authentication fails. The next
phase
would be to open the SSL (443) port so the OWA site can be accessible
from
the internet. That is we still stand.
Vic
"Skipster" <Skipster@discussions.microsoft.com> wrote in message
news:89528C39-8392-4E9E-A29C-E5858C575FB0@microsoft.com...
Vic
Is the OWA server part of the same domain as the exchange server? and
from
looking at your diagram I am not sure why you opened up all those
ports on
your firewall. Depending on the type of router that you are using you
should
be able to go to https://owa/exchange from the LAN subnet and be able
to
authenticate. You should not have to route through the firewall to
make
this
request so the firewall should not be the issue with not being able to
authenticate. When an internal client goes to https://owa/exchange
your
router should forward the request to this server, there shoudl be no
NATING
going on with this traffic. All the NATING should be happening on your
firwall facing the internet and the internet facing the DMZ interface.
It
sounds like you have NAT going on with the DMZ subnet and the local
LAN
subnet and this can be your issue when trying to authenticate.
"Vic" wrote:
This is good recommendation, but our DMZ is a sepereate subnet that
can
route to the internal network (DMZ 192.168.100.xxx/Internal
192.168.50.xxx).
So all devices in the DMZ subnet could use NAT to an external IP
address.
This is why we would like to keep the front-end OWA server on the
DMZ.
"Andy David - Exchange MVP" <adavid@pleasekeepinngcheesebucket.com
wrote in
message news:4eldt0l9cftehbd7v61m41qdf6kpkdje5i@4ax.com...
Put OWA back behind the firewall. Use ISA or other simliar
products in
the DMZ and reverse proxy OWA out.
On Fri, 31 Dec 2004 09:36:31 -0800, "Vic"
macanas@gmail.nospman.com
wrote:
I have setup a front-end OWA server to allow remote users to read
their
mail
remotely (obviously). The problem I encountere is as follows; the
OWA
is
on
a DMZ and can be accessed from the internal network. When
connecting
to
the
OWA server from the outside (public ip) I cannot even connect to
the
site.
Here is what our network looks like:
Internet
|
***Router***
|_____DMZ-----OWA Front-End (Using NAT IP 208.xxx.xxx.xxx
ext/192.168.xxx.xxx int)
| Other Web Servers
***Firewall***
|
Internal Network (Win2k3)
1 Exchange2k3 Ent. Server
2 Win2k3 DC's
|
Clients, etc.
When connecting internally to the OWA using
(https://owa/exchange), I
can
connect but cannot authenticate to the using any account allowed
OWA
access.
When I bring the server back out of the DMZ and into the internal
network,
authentication works just fine.
Here is a list of ports that have been opened on the Firewall:
a.. For Exchange Communication:
a.. Port 80 for HTTP
b.. Port 443 for SSL
c.. Port 691 for Link State Algorithm routing protocol
b.. For Active Directory communication:
a.. Port 389 for LDAP (TCP and UDP)
b.. Port 3268 for Global Catalog Server LDAP (TCP)
c.. Port 88 for Kerberos Authentication (TCP and UDP)
Can anyone please help?
Thanks,
Vic
|
|
|
| Back to top |
|
|
Skipster
Guest
|
| Posted:
Tue Jan 04, 2005 6:01 am Post subject:
Re: front-end OWA server |
|
|
Does your network manager not trust the server that is the OWA server in the
DMZ subnet? I cant think of a reason why you wouldnt. What ports are you
allowing from the router to the server on the DMZ? it should only be http or
https or both. If these are the only port open on the router NATING to the
server on the DMZ, then you dont really need to cut of the OWA server on the
DMZ from the local LAN subnet. I would however get a device like ISA server
that can do some deep application layer filtering so you can look inside the
http or https request to the OWA server to make sure it is legit traffic and
not some crap that can be tunneled through https or http.
You need to ask you IT manager why he is doing it this way? the ports you
need to open up on your firewall so the OWA server can talk to AD on the
local LAN are *many* and it kinda blows away the security concept behind
using a DMZ. I mean if i have to open up 10 ports so my OWA server on a DMZ
can talk to OWA then this defeats the purpose of the security concept. I mean
why bother?
"Vic" wrote:
| Quote: | Makes total sense to me what you are telling me....to my network manager it
doesn't! So I am trying to only forward the needed ports from the DMZ to the
internal network.
"Skipster" <Skipster@discussions.microsoft.com> wrote in message
news:902A0C96-61DC-47D5-AB2D-DC34A17DCC8F@microsoft.com...
why are you nating or filtering ports from the internal LAN subnet on the
DMZ
to the internal local LAN subnet?
"Vic" wrote:
The OWA server sits on the DMZ with an internal address off
192.168.100.xxx
NATING to an external address of 208.xxx.xxx.xxx so it can be accessible
from the internet. The internal network is on a 192.168.10.xxx subnet
and is
routable with the DMZ network for security purposes. Also the OWA server
is
part of the domain in which the main Exchange server resides. When the
OWA
server is on the DMZ it is accessible from any of the internal subnets,
but
when entering a username and password authentication fails. The next
phase
would be to open the SSL (443) port so the OWA site can be accessible
from
the internet. That is we still stand.
Vic
"Skipster" <Skipster@discussions.microsoft.com> wrote in message
news:89528C39-8392-4E9E-A29C-E5858C575FB0@microsoft.com...
Vic
Is the OWA server part of the same domain as the exchange server? and
from
looking at your diagram I am not sure why you opened up all those
ports on
your firewall. Depending on the type of router that you are using you
should
be able to go to https://owa/exchange from the LAN subnet and be able
to
authenticate. You should not have to route through the firewall to
make
this
request so the firewall should not be the issue with not being able to
authenticate. When an internal client goes to https://owa/exchange
your
router should forward the request to this server, there shoudl be no
NATING
going on with this traffic. All the NATING should be happening on your
firwall facing the internet and the internet facing the DMZ interface.
It
sounds like you have NAT going on with the DMZ subnet and the local
LAN
subnet and this can be your issue when trying to authenticate.
"Vic" wrote:
This is good recommendation, but our DMZ is a sepereate subnet that
can
route to the internal network (DMZ 192.168.100.xxx/Internal
192.168.50.xxx).
So all devices in the DMZ subnet could use NAT to an external IP
address.
This is why we would like to keep the front-end OWA server on the
DMZ.
"Andy David - Exchange MVP" <adavid@pleasekeepinngcheesebucket.com
wrote in
message news:4eldt0l9cftehbd7v61m41qdf6kpkdje5i@4ax.com...
Put OWA back behind the firewall. Use ISA or other simliar
products in
the DMZ and reverse proxy OWA out.
On Fri, 31 Dec 2004 09:36:31 -0800, "Vic"
macanas@gmail.nospman.com
wrote:
I have setup a front-end OWA server to allow remote users to read
their
mail
remotely (obviously). The problem I encountere is as follows; the
OWA
is
on
a DMZ and can be accessed from the internal network. When
connecting
to
the
OWA server from the outside (public ip) I cannot even connect to
the
site.
Here is what our network looks like:
Internet
|
***Router***
|_____DMZ-----OWA Front-End (Using NAT IP 208.xxx.xxx.xxx
ext/192.168.xxx.xxx int)
| Other Web Servers
***Firewall***
|
Internal Network (Win2k3)
1 Exchange2k3 Ent. Server
2 Win2k3 DC's
|
Clients, etc.
When connecting internally to the OWA using
(https://owa/exchange), I
can
connect but cannot authenticate to the using any account allowed
OWA
access.
When I bring the server back out of the DMZ and into the internal
network,
authentication works just fine.
Here is a list of ports that have been opened on the Firewall:
a.. For Exchange Communication:
a.. Port 80 for HTTP
b.. Port 443 for SSL
c.. Port 691 for Link State Algorithm routing protocol
b.. For Active Directory communication:
a.. Port 389 for LDAP (TCP and UDP)
b.. Port 3268 for Global Catalog Server LDAP (TCP)
c.. Port 88 for Kerberos Authentication (TCP and UDP)
Can anyone please help?
Thanks,
Vic
|
|
|
| Back to top |
|
|
Vic
Guest
|
| Posted:
Tue Jan 04, 2005 6:18 am Post subject:
Re: front-end OWA server |
|
|
I see your point and I concur....manager doesn't. Now just got to run it by
him again and again so he can understand that the firewall is becoming
"swiss cheese" with all these ports open. By the way, the ports are being
opened at the Firewall not the router. The ISA server is my next
recommedation.
"Skipster" <Skipster@discussions.microsoft.com> wrote in message
news:27D28BE7-EC56-4859-B0C1-16922D29BB6D@microsoft.com...
| Quote: | Does your network manager not trust the server that is the OWA server in
the
DMZ subnet? I cant think of a reason why you wouldnt. What ports are you
allowing from the router to the server on the DMZ? it should only be http
or
https or both. If these are the only port open on the router NATING to the
server on the DMZ, then you dont really need to cut of the OWA server on
the
DMZ from the local LAN subnet. I would however get a device like ISA
server
that can do some deep application layer filtering so you can look inside
the
http or https request to the OWA server to make sure it is legit traffic
and
not some crap that can be tunneled through https or http.
You need to ask you IT manager why he is doing it this way? the ports you
need to open up on your firewall so the OWA server can talk to AD on the
local LAN are *many* and it kinda blows away the security concept behind
using a DMZ. I mean if i have to open up 10 ports so my OWA server on a
DMZ
can talk to OWA then this defeats the purpose of the security concept. I
mean
why bother?
"Vic" wrote:
Makes total sense to me what you are telling me....to my network manager
it
doesn't! So I am trying to only forward the needed ports from the DMZ to
the
internal network.
"Skipster" <Skipster@discussions.microsoft.com> wrote in message
news:902A0C96-61DC-47D5-AB2D-DC34A17DCC8F@microsoft.com...
why are you nating or filtering ports from the internal LAN subnet on
the
DMZ
to the internal local LAN subnet?
"Vic" wrote:
The OWA server sits on the DMZ with an internal address off
192.168.100.xxx
NATING to an external address of 208.xxx.xxx.xxx so it can be
accessible
from the internet. The internal network is on a 192.168.10.xxx
subnet
and is
routable with the DMZ network for security purposes. Also the OWA
server
is
part of the domain in which the main Exchange server resides. When
the
OWA
server is on the DMZ it is accessible from any of the internal
subnets,
but
when entering a username and password authentication fails. The next
phase
would be to open the SSL (443) port so the OWA site can be
accessible
from
the internet. That is we still stand.
Vic
"Skipster" <Skipster@discussions.microsoft.com> wrote in message
news:89528C39-8392-4E9E-A29C-E5858C575FB0@microsoft.com...
Vic
Is the OWA server part of the same domain as the exchange server?
and
from
looking at your diagram I am not sure why you opened up all those
ports on
your firewall. Depending on the type of router that you are using
you
should
be able to go to https://owa/exchange from the LAN subnet and be
able
to
authenticate. You should not have to route through the firewall to
make
this
request so the firewall should not be the issue with not being
able to
authenticate. When an internal client goes to https://owa/exchange
your
router should forward the request to this server, there shoudl be
no
NATING
going on with this traffic. All the NATING should be happening on
your
firwall facing the internet and the internet facing the DMZ
interface.
It
sounds like you have NAT going on with the DMZ subnet and the
local
LAN
subnet and this can be your issue when trying to authenticate.
"Vic" wrote:
This is good recommendation, but our DMZ is a sepereate subnet
that
can
route to the internal network (DMZ 192.168.100.xxx/Internal
192.168.50.xxx).
So all devices in the DMZ subnet could use NAT to an external IP
address.
This is why we would like to keep the front-end OWA server on
the
DMZ.
"Andy David - Exchange MVP"
adavid@pleasekeepinngcheesebucket.com
wrote in
message news:4eldt0l9cftehbd7v61m41qdf6kpkdje5i@4ax.com...
Put OWA back behind the firewall. Use ISA or other simliar
products in
the DMZ and reverse proxy OWA out.
On Fri, 31 Dec 2004 09:36:31 -0800, "Vic"
macanas@gmail.nospman.com
wrote:
I have setup a front-end OWA server to allow remote users to
read
their
mail
remotely (obviously). The problem I encountere is as follows;
the
OWA
is
on
a DMZ and can be accessed from the internal network. When
connecting
to
the
OWA server from the outside (public ip) I cannot even connect
to
the
site.
Here is what our network looks like:
Internet
|
***Router***
|_____DMZ-----OWA Front-End (Using NAT IP
208.xxx.xxx.xxx
ext/192.168.xxx.xxx int)
| Other Web Servers
***Firewall***
|
Internal Network (Win2k3)
1 Exchange2k3 Ent. Server
2 Win2k3 DC's
|
Clients, etc.
When connecting internally to the OWA using
(https://owa/exchange), I
can
connect but cannot authenticate to the using any account
allowed
OWA
access.
When I bring the server back out of the DMZ and into the
internal
network,
authentication works just fine.
Here is a list of ports that have been opened on the
Firewall:
a.. For Exchange Communication:
a.. Port 80 for HTTP
b.. Port 443 for SSL
c.. Port 691 for Link State Algorithm routing protocol
b.. For Active Directory communication:
a.. Port 389 for LDAP (TCP and UDP)
b.. Port 3268 for Global Catalog Server LDAP (TCP)
c.. Port 88 for Kerberos Authentication (TCP and UDP)
Can anyone please help?
Thanks,
Vic
|
|
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in