[SOLVED] First Connect Fails?

[jstillwa]

So, I imagine this is a fairly simple problem, but as the title suggest, it has very difficult keywords to search for.

Basically, the first connect to our Zimbra server fails. Connecting again brings it up just fine. This is only for the web client and it affects both the web admin and the normal web client. So, you click on your bookmark, it just says "waiting" for the server. Click it again, and it loads up. I've seen this on several computers with several different browsers and can't figure out what its doing. Thoughts?

Thanks,
-John

[uxbod]

Welcome to the forums

su - zimbra
zmcontrol -v

Is the server on a private IP behind a firewall ? Does this happen every single time you go to the URL ? If you perform a dig/nslookup from the command line does it always resolve the IP address ?

Anything in your Log Files - Zimbra :: Wiki ?

cat /etc/hosts
cat /etc/resolv.conf
dig _domainname_ mx
dig _domainname_ any
host `hostname` <- note backticks and not double quotes

[jstillwa]

Is the server on a private IP behind a firewall ? Yes, it's on a 1 to 1 NAT mapping.

Does this happen every single time you go to the URL ? Only the first time. If you close your browser and open it back it, it will hang. As long as the browser session is open, it seems fine. So, a cookie problem maybe?

If you perform a dig/nslookup from the command line does it always resolve the IP address ? Yes.


These results are from the box itself, and not externally.

zmcontrol -v
Release 5.0.4_GA_2101.RHEL5_64_20080321141727 RHEL5_64 NETWORK edition

cat /etc/hosts
127.0.0.1 localhost.localdomain localhost
::1 localhost6.localdomain6 localhost6
10.0.3.23 zimbra-1.liai.org zimbra-1

cat /etc/resolv.conf
; generated by /sbin/dhclient-script
search liai.org
nameserver 10.0.3.10
nameserver 10.0.3.11

dig _domainname_ mx
we are still migrating to zimbra so it is not yet in our mx records

; <<>> DiG 9.3.4-P1 <<>> liai.org mx
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7642
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; QUESTION SECTION:
;liai.org. IN MX

;; ANSWER SECTION:
liai.org. 604800 IN MX 5 gateway2.liai.org.

;; AUTHORITY SECTION:
liai.org. 604800 IN NS ns2.liai.org.
liai.org. 604800 IN NS ns1.liai.org.

;; ADDITIONAL SECTION:
gateway2.liai.org. 604800 IN A 10.0.3.29
ns1.liai.org. 604800 IN A 10.0.3.10
ns2.liai.org. 604800 IN A 10.0.3.11

;; Query time: 0 msec
;; SERVER: 10.0.3.10#53(10.0.3.10)
;; WHEN: Tue Jul 22 09:19:31 2008
;; MSG SIZE rcvd: 135

dig _domainname_ any
; <<>> DiG 9.3.4-P1 <<>> liai.org any
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41589
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 3

;; QUESTION SECTION:
;liai.org. IN ANY

;; ANSWER SECTION:
liai.org. 604800 IN SOA ns1.liai.org. ns1.liai.org. 2008062701 7200 7200 864000 86400
liai.org. 604800 IN NS ns1.liai.org.
liai.org. 604800 IN NS ns2.liai.org.
liai.org. 604800 IN MX 5 gateway2.liai.org.
liai.org. 604800 IN TXT "v=spf1 a mx a:gateway1.liai.org a:gateway2.liai.org a:smtp.liai.org a:webmail.liai.org ?all"
liai.org. 604800 IN A 10.0.3.15

;; ADDITIONAL SECTION:
ns1.liai.org. 604800 IN A 10.0.3.10
ns2.liai.org. 604800 IN A 10.0.3.11
gateway2.liai.org. 604800 IN A 10.0.3.29

;; Query time: 0 msec
;; SERVER: 10.0.3.10#53(10.0.3.10)
;; WHEN: Tue Jul 22 09:20:01 2008
;; MSG SIZE rcvd: 291



host `hostname`
zimbra-1.liai.org

[Bill Brock]

Does this happen if you are outside of your local network and hit the mail server from the WAN? I'm assuming this is possible since you have a 1 to 1 NAT.

Also, try adding the mail server to the hosts file on one machine, so it resolves from there instead of through DNS, and see if you get the same results accessing from that machine.

[jstillwa]

This happens from both the internal and external networks. Adding Hosts entries does not fix it.

Odd, eh?

[y@w]

This happens for us consistently in Firefox 3 on 5.0.4 as well. Not sure about other browsers. What all browsers have you tried it in?

It appears an upgrade *should* fix it according to the last few posts.

[SOLVED] Firefox 3 + Zimbra 5 - TLS Interop issue

[mmorse]

FF3 attempts to use TLS first when making an https connection, but the SslEngine in Java6 does not appear to handle this and simply times out before FF3 falls back to normal SSL.

A switch to JDK 1.5 while running Zimbra 5.0.4/.5, or upgrade to 5.0.6+ (which uses JDK1.5 intentionally) resolves the issue (5.0.8 is current).

We ran JDK1.6 till 5.0.5, and we downgraded for 5.0.6 to avoid 3 Sun bugs:
Bug ID: 6614100 EXCEPTION_ACCESS_VIOLATION while running Eclipse with 1.6.0_05-ea - fixed
Bug ID: 6546278 Synchronization problem in the pseudo memory barrier code - fixed
Bug ID: 6693490 (se) select throws "File exists" IOException under load (lnx) - still open but fix planned

Recent convo on those: Testing JDK 1.6.x with Zimbra 5.0.x (notes this TLS issue is still prevalent in JDK 1.6u7)
While we do have a few customers who have also gone back to JDK1.6 for one reason or another because they have modifications that depend on it, I would run NE with what we build/support - if you must upgrade them please notify support whenever you/they open tickets that it's using JDK1.6

Bug 13487 – Upgrade to JDK 1.6 for 5.0.x series, then Bug 27890 – Downgrade to JDK 1.5.0_15 for 5.0.6

Tools > options > advanced > encryption > uncheck TLS 1.0 if you're really curious to test the difference using FF3 against JDK1.6
Though it's not exactly something you want to have to do on a mass of users & it's enabled by default for a reason.

More: [#JETTY-567] Delay in initial TLS Handshake With FireFox 3 beta5 and SslSelectChannelConnector - jira.codehaus.org

This is filed for tracking/retesting whenever we officially upgrade to JDK1.6: Bug 29631 – delay loading login page when using Firefox 3 over SSL/TLS

Tools > options > advanced > encryption > uncheck TLS 1.0 if you're really curious to test the difference using FF3 against JDK1.6
Though it's not exactly something you want to have to do on a mass of users & it's enabled by default for a reason.

[jstillwa]

Yep, TLS did it. I'll schedule some upgrade time.

Thanks guys/gals/other,
-John