Public names not found - certificate problem ISA 2004

If you have DNS server in-house, check the ip address of your mx record mail.domian.com, if it is pointing to your Netgear, amend its ip to the correct one. Also, make sure you have rules created for HTTPS in ISA since you are requesting from ISA to open SSL port 443 traffic. Check those then try again.

Hi mcse2007,

Thanks for answering! I just wanted to confirm what I am looking for with DNS.

On the internal domain of domain.local I have a DNS server (the built in one from SBS). I do not have any mx records internally that I can see - perhaps you could let me know where exactly I should be looking for them?

Could I perhaps create one? Would I need to create a new primary zone to put that record in since our internal domain is domain.local not domain.com?

I will double check the SSL rules as well. They seem to work OK for everything else apart from the mail.domain.com address which I think would work it the Netgear didn't get so confused about what it should serve up :)

Thanks again and I look forward to seeing your next reply.

With your SBS you will not have an explicit MX record.

Go to the properties of your SBS OMA Web Publishing Rule.  On the Public Name tab, you should have the FQDN of your server listed (it sounds like there isn't one listed), and this name should match the name that is specified on your certificate.  And the certificate is specified under the properties of the SBS Web Listener.

BTW, adding a DNS entry for mail.domain.com to point to your internal IP is not a bad idea.  I'm assuming that your current internal domain name is domain.local.  If you're not familiar with the concept, it is often called Split-DNS.  If I'm correct about your current structure, you can create this split-DNS by adding a forward lookup zone for domain.com, then add host (A) records for the subdomains you want to point to your internal IP address.  The goal here is that users can enter the same web address (e.g. mail.foo.com) whether internal or external to the LAN and get routed appropriately.  In other words, external users enter mail.foo.com and are directed to the external IP, and internal users enter mail.foo.com and are directed to the internal IP.  One last note about the (A) records, you might want to create one for "www" that points the IP address of your web site hoster if you have a web site that is hosted by somewhere else.

Hi Citacomp - again thanks for taking the time to reply.

On the Public name tab I have mail.domain.com. I think the problem is when we try to resolve mail.domain.com we get the public IP address. When we attempt to reach this address from our internal domain.local, our Netgear Router appears to grab the connection and say "that IP is my public IP, therefore this connection must be for me" resulting in an attempt to reach mail.domain.com on port 80 (for example) hitting the Netgear on port 80 - the configuration page.

Thus we don't get a certificate back.

At least, this is what I think is wrong - and I have been wrong on more than one occasion in the past!

Hence my idea for the split DNS - though I'm not sure I did it right. I should create a new primary zone of domain.com and put a host record for mail.domain.com as being 192.168.1.x where x is the actual exchange server?

Is that correct?

Well I guess it was wrong! I created a primary zone called domain.com, added a Host (A) record for mail and it appears to work OK as far as pinging and using IE are concerned.

Is this just an issue with the way that ISA BPA looks this stuff up? Should I have restarted once I updated the DNS entries (I did ipconfig /flushdns)?

"Well I guess it was wrong! I created a primary zone called domain.com, added a Host (A) record for mail and it appears to work OK as far as pinging and using IE are concerned."

Sorry - I should mention that running the ISA BPA over the server again and got exactly the same errors as I got before I created the new Primary Zone.

Sound like your understanding is pretty much correct.  Since your internal domain is domain.local, without split-DNS in place when you do a lookup for mail.domain.com, your SBS basically says, "I'm not authoritative for this domain," so it forwards the DNS query on to your ISP's DNS servers.  Eventually the mail.domain.com name gets resolved back to your public IP address, which is the external IP of your Netgear router.  Since it doesn't sound like you are forwarding port 80 to your SBS the Netgear tries to respond (and most likely has the function to allow configuration from an external connection turned off), so that is the source of the message you see when you try to access mail.domain.com internally.  Also, ISA does not allow connections that start on the internal side to go outside the network and then come back to access the server.  It knows that internal connections should come to it's internal IP address and not its external one.  BTW, that last bit assumes that you are using SBS/ISA with a dual NIC configuration.

---"I should create a new primary zone of domain.com and put a host record for mail.domain.com as being 192.168.1.x where x is the actual exchange server?
Is that correct?"
Yes, that is correct.

You could try restarting the DNS server (or the entire SBS) but I'm not sure exactly what is happening with the ISA BPA.  On my server, if I change the certificate to one that doesn't match what's listed under Public Names, in ISA BPA I get the message, "The name of the certificate attached to the SBS OMA Web Publishing Rule Web publishing rule does not match the public name.  The certificate was issued to xxx.com, and the set of public names is publishing.xxx.local;."  (in this case xxx.com was a test certificate I had created, while publishing.xxx.local is what is listed under Public Names)  It looks like ISA BPA is not able to read the values that you have entered in Public Names.  In my tests this is independent of whether you have the DNS zone created for domain.com or not.

The question would be if this is a problem just with the BPA or is something wrong with the firewall rule.  You could try changing the value under Public Names, saving, then changing it back and saving again to see if this makes a difference (or you could delete the name then recreate it).  You could also try rerunning the CEICW.  When you select "Enable Firewall" and choose your settings, this recreates the SBS ISA firewall rules, so any changes you have made to them will be lost (any other rules you have created will be left alone).  I would export your ISA configuration before doing this just in case.  Another possibility might be to actually look at the exported .XML file for your ISA configuration and examine it to see if you can find something wrong with the data, edit, and re-import, but this would probably be more work than you want to invest.

Just to be clear, besides having this message in ISA BPA, is there currently impact on functionality that you have observed?

Wow - what a comprehensive reply - much appreciated!

I'll go through this in order if I may (comments inline)

>Sound like your understanding is pretty much correct.

First time for everything :)

>Since it doesn't sound like you are forwarding port 80 to your SBS the Netgear tries to respond (and most likely has the function to allow configuration from an external connection turned off), so that is the source of the message you see when you try to access mail.domain.com internally.  

We are forwarding port 80 and external configuration is disabled.

>Also, ISA does not allow connections that start on the internal side to go outside the network and then come back to access the server.  It knows that internal connections should come to it's internal IP address and not its external one.  BTW, that last bit assumes that you are using SBS/ISA with a dual NIC configuration.

We are using a dual nic, but I didn't know about the routing - so thank you

>Yes, that is correct.

Twice in one day - it's a miracle ;)

>You could try restarting the DNS server (or the entire SBS) but I'm not sure exactly what is happening with the ISA BPA.  

Restarting DNS made no difference. I will restart the SBS at the end of the day (GMT)

>On my server, if I change the certificate to one that doesn't match what's listed under Public Names, in ISA BPA I get the message, "The name of the certificate attached to the SBS OMA Web Publishing Rule Web publishing rule does not match the public name.  The certificate was issued to xxx.com, and the set of public names is publishing.xxx.local;."  (in this case xxx.com was a test certificate I had created, while publishing.xxx.local is what is listed under Public Names)  It looks like ISA BPA is not able to read the values that you have entered in Public Names.  In my tests this is independent of whether you have the DNS zone created for domain.com or not.

Indeed. If I change the certificate, the new certificate is reported as being issued, however ISA BPA says that Public Names are not found.

>The question would be if this is a problem just with the BPA or is something wrong with the firewall rule.  You could try changing the value under Public Names, saving, then changing it back and saving again to see if this makes a difference (or you could delete the name then recreate it).

Changing the name made no difference.

>You could also try rerunning the CEICW.  When you select "Enable Firewall" and choose your settings, this recreates the SBS ISA firewall rules, so any changes you have made to them will be lost (any other rules you have created will be left alone).  I would export your ISA configuration before doing this just in case.

I exported the configuration to the XML file and reran the CEICW. Again, unfortunately no joy.

>Another possibility might be to actually look at the exported .XML file for your ISA configuration and examine it to see if you can find something wrong with the data, edit, and re-import, but this would probably be more work than you want to invest.

Actually, it is probably more skill than I have to invest!

>Just to be clear, besides having this message in ISA BPA, is there currently impact on functionality that you have observed?

The reason I started chasing this problem down is that every now and again, our external email will freeze. Internally its fine, however none of our external contractors can get their email on their iPhones, via OWA etc etc.

Looking through the event logs, there was always this error in the log :

Event Type: Error
Event Source: Microsoft ISA Server Web Proxy
Event Category: None
Event ID: 14200
Date:  3/22/2007
Time:  8:01:55 AM
User:  N/A
Computer: <servername>
Description:
ISA Server failed to establish an SSL connection with
publishing.<domain>.local. An existing connection was forcibly closed by the
remote host.

So I thought there might be some kind of certificate issue. Then I ran the BPA and the rest as they say is history.

Thank you for such a comprehensive reply - I hope we are closing in on the problem!
 

Thanks for the comments.  I hope we're closing in on it too!

A few more suggestions:
1) Double check that an (A) record exists for "publishing" in your DNS records for the .local zone which points to the internal IP.
2) Check your HOSTS file for any references to publishing.
3) In ISA Management, delete the SBS web publishing rules and the web listeners (you can find them in the Toolbox on the right-hand side).  You might want to make notes on the properties of the web listeners for comparison to the recreated ones.  Then rerun the CEICW again which will recreate these.

I'm tempted to suggest creating a new certificate to eliminate any problem with the existing one, but without knowing for sure, this could create a bit of work in deploying the new one when it might be unnecessary.

>"We are forwarding port 80 and external configuration is disabled."

So in the router you are forwarding port 80 to the SBS, but when you browse to your public IP you get the Netgear login screen?

Your configuration looks like this correct? (below) (IPs are examples)
            public IP|          192.168.16.x           192.168.24.x
internet----------router-----------------sbs-----switch----lan computers
The router has both an internal and external IP, as does the SBS, using different IP ranges.

Good morning Citacomp :)

>A few more suggestions:
>1) Double check that an (A) record exists for "publishing" in your DNS records for the .local zone which points to the internal IP.

It does

>2) Check your HOSTS file for any references to publishing.

Nothing

>3) In ISA Management, delete the SBS web publishing rules and the web listeners (you can find them in the Toolbox on the right-hand side).  You might want to make notes on the properties of the web listeners for comparison to the recreated ones.  Then rerun the CEICW again which will recreate these.

Have done that this morning - unfortunately we get exactly the same problem.

>I'm tempted to suggest creating a new certificate to eliminate any problem with the existing one, but without knowing for sure, this could create a bit of work in deploying the new one when it might be unnecessary.

I have tried that already, as per the instructions here : http://groups.google.co.uk/group/microsoft.public.windows.server.sbs/browse_thread/thread/86f0768b84b3fce4/247e723102483d25?hl=en&ie=UTF-8&q=ISA+SErver+Error+Event+ID+14200+forcibly+closed+remote#247e723102483d25

It made no difference either

>So in the router you are forwarding port 80 to the SBS, but when you browse to your public IP you get the Netgear login screen?

Precisely

>Your configuration looks like this correct? (below) (IPs are examples)
public IP        192.168.16.x           192.168.24.x
internet----------router-----------------sbs------------------switch----lan computers
The router has both an internal and external IP, as does the SBS, using different IP ranges.

That is correct.

I'm leaning towards the problem being ISA just needs a hefty kick in the n*ts with some steel toecapped attitude adjusters ...

Thank you again Citacomp, your patience is appreciated.

Yes, if somebody invented special computer kicking boots/shoes, they'd make a fortune!

Yeah, I saw that link as well...

One thing that is quite odd is being able to get to the Netgear login screen in that manner.  Do this happen when you browse to the public IP both inside and outside of your network?

Would it be possible for you to take screenshots of all the property pages (tabs) for one of these publishing rules and for the web listener as well?  I'm reaching here but I could compare them to my own and see if I spot any differences.

One other thing that I thought off for intermittent connection problems is too disable Receive Side Scaling for your network adapters.  This was a problem that occurred after SP2, though you might have already gotten the patch.  Another thing I've seen cause issues is having (IPv4) Large Send Offload enabled in your NIC properties.

>Yes, if somebody invented special computer kicking boots/shoes, they'd make a fortune!

I call dibbs on the patent :D

>Yeah, I saw that link as well...

It was one of the few articles that mentioned that error unfortunately.

>One thing that is quite odd is being able to get to the Netgear login screen in that manner.  Do this happen when you browse to the public IP both inside and outside of your network?

Only internally. With the new split DNS, I no longer get it by using //mail.domain.com but I do get it if I type the actual public IP address. Externally everything works as expected.

>Would it be possible for you to take screenshots of all the property pages (tabs) for one of these publishing rules and for the web listener as well?  I'm reaching here but I could compare them to my own and see if I spot any differences.

Most certainly, I will do that this morning and post a link to rapidshare where I'll put all the pictures in an archive if that's OK.

>One other thing that I thought off for intermittent connection problems is too disable Receive Side Scaling for your network adapters.  This was a problem that occurred after SP2, though you might have already gotten the patch.  Another thing I've seen cause issues is having (IPv4) Large Send Offload enabled in your NIC properties.

I'll track down this setting and disable it. Possibly with extreme prejudice :)

In all seriousness, thanks again mate. Makes a huge differrence to get a fresh set of eyes on the problem.

http://rapidshare.com/files/254101865/ISA_Problems.rar.html

Hope that helps - I'm off to find that setting :)

Receive Side Scaling was already disabled - I've disabled the Large Send Offload to see if that makes a difference too.

Hope the rapidshare upload is good for you.

Have a great weekend by the way ;)

I believe I've only seen the problem with the Large Send Offload setting when using Broadcom NICs, but I don't know if the problem is only confined to them.

I got the file.  Thanks, that worked just fine.
All the screenshots look fine...identical to my own.

Links for information related to this in any way sure are sparse.  About the only other two I came up with are
http://www.eventid.net/display.asp?eventid=14200&eventno=1113&source=Microsoft Web Proxy&phase=1
and
http://support.microsoft.com/kb/328917
...and these aren't really of any help.

> In all seriousness, thanks again mate. Makes a huge differrence to get a fresh set of eyes on the problem.

You're welcome.  Though I hope I can do more than have you jump through hoops while going 'round in circles.  :)

Can you wipe your server and start all over?  I'll give you 5 minutes....... Just kidding, ignore this line.

The error in the Event Log seems to indicate the same thing that the BPA is reporting.

I'm still wondering about the Netgear thing when using the public IP.  I wondering if this is some behavior of that particular device or if ISA is somehow interfering.  Have you tried using Monitoring with ISA to see what is happening when you try to reach this IP or when users have reported problems?

The next question is whether this might be a problem with ISA itself, or just with the configuration?  One more thing I can try...if you can provide me with an exported web publishing rule (.XML file), I could examine the contents and try importing it onto my test server to see if I get the same results from the BPA or not.  You could do the same if you have a test server set up.

Well, that's all I have for now.  I'm afraid I probably won't be able to check in over the weekend, so I hope you have a good one.

>I believe I've only seen the problem with the Large Send Offload setting when using Broadcom NICs, but I don't know if the problem is only confined to them.

Still worth a shot!

>I got the file.  Thanks, that worked just fine.
All the screenshots look fine...identical to my own.

Damnit! Hoped it was wildly different :(

>Links for information related to this in any way sure are sparse.  About the only other two I came up with are
http://www.eventid.net/display.asp?eventid=14200&eventno=1113&source=Microsoft Web Proxy&phase=1
and
http://support.microsoft.com/kb/328917
...and these aren't really of any help.

It is almost as if this error _shouldn't_ happen.

>You're welcome.  Though I hope I can do more than have you jump through hoops while going 'round in circles.  :)

At least I'm following a path through the hoops! Before I was randomly jumping in and out of whichever hoop I could find!

>Can you wipe your server and start all over?  I'll give you 5 minutes....... Just kidding, ignore this line.

Don't joke about this - I'm seriously considering it! The problem might be something to do with the fact that the installation (as I have discovered) was backed up on one server and restored to a different server using Acronis. Whilst normally very reliable, at least as far as I've found, maybe this time it just didn't take properly, or there are issues with ISA / SBS and Acronis that I don't know about.

>The error in the Event Log seems to indicate the same thing that the BPA is reporting.

Well at least we both think that! I had started to worry I was the only one in the world marching in step!

>I'm still wondering about the Netgear thing when using the public IP.  I wondering if this is some behavior of that particular device or if ISA is somehow interfering.  Have you tried using Monitoring with ISA to see what is happening when you try to reach this IP or when users have reported problems?

I am starting to think I might swap that netgear out for a test and see if the BPA still reports the same thing.

>The next question is whether this might be a problem with ISA itself, or just with the configuration?  

As I mentioned earlier - it might be something to do with the imaging that took place.

>One more thing I can try...if you can provide me with an exported web publishing rule (.XML file), I could examine the contents and try importing it onto my test server to see if I get the same results from the BPA or not.  You could do the same if you have a test server set up.

No test server :( But I will export the web publishing rule and post that to rapidshare later on today

>Well, that's all I have for now.  I'm afraid I probably won't be able to check in over the weekend, so I hope you have a good one.

I did have a great weekend thanks. And I hope you did too - though the time difference between our posts means that you could be in Australia, which means this is probably the last help I'll get off you if you aggree with the Australian cricket captain :) I'm UK based btw.

As for 'That's all I have for now' - you've given a lot of assistance and time to this - for which I am very grateful. Your 'all' is far more than I managed, so thanks!

>  It is almost as if this error _shouldn't_ happen.

I've heard about errors due to cosmic rays....perhaps this is one of them.  :)

I'm GMT -7:00, or more specifically, the U.S. (Colorado).  Have no fear, I know very little about cricket.  :)

Thanks for the kind words.

>>I'm still wondering about the Netgear thing when using the public IP.  I wondering if this is some behavior of that particular device or if ISA is somehow interfering.  Have you tried using Monitoring with ISA to see what is happening when you try to reach this IP or when users have reported problems?

>I am starting to think I might swap that netgear out for a test and see if the BPA still reports the same thing.

I swapped the Netgear out for a Draytek and whilst the problem with the BPA persists, I no longer reach the configuration page on the public IP address. If you hadn't told me that ISA refused to allow an internal packet out via the external interface and then back in again, I would have been truly stumped as to why external users could reach the OWA page yet I couldn't internally - so thanks for the heads up!

> Have no fear, I know very little about cricket.  :)

Not dissimilar to our national team then ...

>One more thing I can try...if you can provide me with an exported web publishing rule (.XML file)

Will be available by the time you get to read this :) I'll post the link in the next comment.

http://rapidshare.com/files/255639641/OWA_rule.xml.html

And thanks again!

I'll be downstairs trying to construct a cosmic ray proof enclosure for this server ... ;)

Citacomp, you are a gentleman and a scholar!

I thank you for all of your hard work and I am quite happy to accept the fact that it is a BPA related issue as far as the public names not found issue is concerned.

As for the Netgear and Sonicwall devices ... my experience of Sonicwall is they are dumb, Netgears - well they're a little like me. Not quite smart enough to realise that they're just a little too dumb to do some of the stuff they are trying ;)

Thank you again for all of your help - I hope others find this question and your answer useful!

Kindest regards

> Not quite smart enough to realise that they're just a little too dumb to do some of the stuff they are trying ;)

I think we're all like that at times.... :)

Regards.