OWA Resolution Question?? 1

[Jpoandl]

Hi,

I have an OWA server with the typical SSL protection using a public IP on the internet.

When I try to attach to the OWA web site from the internet (

https://email.domainname.com/exchange),

the web site opens and I can logon. This is normal...

The problem is when I am connected to the companies internal LAN, and I try to access

https://email.domainname.com/exchange

When, I try this, the IE window times out...and I can not log in.

I have verified that I am resolving to the correct server external IP address by usiing NSLOOKUP. (NSLOOKUP email.domainname.com -- This resolves to the EXTERNAL IP address of my OWA server.)

My question is: Is there a way to allow people to connect to the external OWA web site? (Right now, they can connect to

https://email.internaldomainname.com/exchange)

I can't figure out why I can connect internally using the LAN domain name and I can't connect from internally to the external public domain name?

Thanks for your help...!

Joseph L. Poandl
MCSE 2000

If your company is in need of experts to examine technical problems/solutions, please check out

http://www.NJCOMPUTERNETWORKS.com

(Sales@njcomputernetworks.com)

 

[cvoce]

What are you using to gain Internet access from the workstation on the internal network? What firewalls, ISA Servers, etc are there?

I assume the Exchange Server is on the same local LAN inside the network?

The problem is probably to do with the Firewall getting confused. You are asking for a public address, the Firewall is translating that request (most likely), then getting rerouted back through itself. Very confusing for it.

An easy way, if you have an internal DNS Server, is to have an INTERNAL address for the public domain name for the email server on the internal dns server. Then the users would resolve to the internal IP when inside, and the external IP on the outside.

Failing that, it all depends on how clever your firewall is. Easy to fix in IPTables in Linux... but I guess you're not using Linux.

Sorry I can't be more help

Chris

 

[gkes]

Does internal prompt for login credentials at all? Your post doesn't clearly indicate this.

Just a guess, but this might be a problem with auth type. Internal computers probably have a security association through the domain, but as the servername doesn't match the authentication fails and never rolls over to cleartext. From outside computers, there is no security association at all so it rolls over properly. Make sure that owa is configured to only use cleartext password, and that all other auth types are disabled.

If this isn't it, the exact, complete content of the IE timeout window would be very helpful.

 

[Jpoandl]

Thank you for the responses.

When I am inside to the network LAN and try to hit the owa (external) page, I do not get a logon screen. The IE page times out (as if the server or page does not exist)

My network is connected via T1 to the internet. There is no ISA server. A simple Sonic Wall firewall/router is being used to gain access to the internet. (I also have my ISP providing firewall features as well. Currenly, my internal firewall is off during my testing. The external ISP firewall is configured to allow all traffic outbound and is limiting traffic inbound for SSL web traffic to my OWA server specifically. However, it is the SonicWall that is doing the NAT translation. It converts my public IP to my internal OWA server's IP.)

I think I have ruled out DNS being the problem. This is because I can use NSLOOKUP to see how email.domainname.com resolves. This resolves to the external IP address. And I also see how email.internaldomainname.com resolves. This resolves to the internal IP address. (althought I also see the point you made...)

As a further test, I can NOT connect to the OWA page when I type

https://EXTERNALIPADDRESS/exchange

(ie

https://xx.xx.xx.xx/exchange)

I get the same time out when I specify the exact external IP address (from the internal LAN) and try to connect to OWA. (When I type the interal IP address of the server, it connects as normal)

Therefore, I think you are on the right track concerning the firewall being the problem.

I also realize the WORKAROUND for this problem you are speaking of. FIX and entry in DNS to point email.domainname.com to the INTERNAL IP address (rather than the external) using my INTERNAL DNS server(s).

I will give this a try (again- I've tried this once before by making a new forward lookup zone and placing one entry in it.)

Thanks



Joseph L. Poandl
MCSE 2000

If your company is in need of experts to examine technical problems/solutions, please check out

http://www.NJCOMPUTERNETWORKS.com

(Sales@njcomputernetworks.com)

 

[de1458]

as cvoce stated that this is a firewall issue, if your isp use cisco pix firewall this is a security feature no a bug,
try to connect the exchange svr use

http://<ip>/exchange

or

http://<nbt

name>/exchange interanlly, if you get anything, it is almost certain that this a firewall issue, the differences using ip and nbt name is one thing you should educate your user when you do so internally, or create a dns entry to sub the nbt name

 

[Jpoandl]

Thank you everyone...

The problem was indeed related to either NAT or Firewall issuess when accessing the PUBLIC IP for my OWA server (from inside our LAN).

To resolve the problem, I performed the following steps:

1) Created a new Forward lookup zone on my Windows 2000 INTERNAL DNS servers called &quot;EXTERNALDOMAINNAME.COM&quot; (I already had a forward lookup zone for &quot;INTERNALDOMAINNAME.COM&quot; - this was created automatically when I installed my Windows 2000 domain.)

2) I then created an A record for my OWA server and pointed the record to my INTERNAL OWA IP address.

3) I also created an MX record for this and pointed to my Exchange server (Not sure if this was needed)

Rational as to why this works:

The problem: When users try to access my OWA server from inside our LAN, they were connecting to the EXTERNAL Public IP address for the OWA server. Because the communication started insided the network, the FIRWALL or the NAT translation would get confused (or possibly a defualt security issue) and the OWA web would time out and users could not connect.

The solution: After I implemented the solution, users would resolve OWA to our internal OWA IP address (due to DNS configuration of internal DNS servers). This would iliminate the need to go through the firewall NAT devices. Therefore, the connection is made without a problem


Thanks for everyones help on this. My issue appears to be resolved!



Joseph L. Poandl
MCSE 2000

If your company is in need of experts to examine technical problems/solutions, please check out

http://www.NJCOMPUTERNETWORKS.com

(Sales@njcomputernetworks.com)