Hi All,
I've been noticing some strangeness with Zimbra Webmail and Sophos's WAF.
Here is a short overview of possible traffic flows:
IPv4 Client --> IPv4 IP on UTM, WAF has some vhost that redirect to different backend servers, one of them Zimbra -> Zimbra WebMail
IPv6 Client --> UTM allows 443,80,25,... -> IPv6 IP of Zimbra Webmail
The oddness of broken Tasks, unableto compose a new e-mail... only happens when using IPv4.
If I force my client to go IPv6 it works fine, after some investigating it seems js.zgz files are corrupt when going over IPv4.
I can replicate the same issue if I place a Apache Reverse Proxy between the IPv6 client and the Zimbra WebMail. I also fixed it using:
Can you please also add this fix to WAF?
Here is some more information on the issue:
![]()
Here you see what is broken, cache disabled via WebDev toolbar to rule out a cached file.
Connection went over IPv4 through Sophos UTM's WAF.
See the notes on the image.
![]()
Forced over IPv6, so bypassing Sophos UTM's WAF.
Everything is fine.
A vanilla Apache RP results in the same scenario as the IPv4 test.
Adding the above mentioned lines fixes it.
I've been noticing some strangeness with Zimbra Webmail and Sophos's WAF.
Here is a short overview of possible traffic flows:
IPv4 Client --> IPv4 IP on UTM, WAF has some vhost that redirect to different backend servers, one of them Zimbra -> Zimbra WebMail
IPv6 Client --> UTM allows 443,80,25,... -> IPv6 IP of Zimbra Webmail
The oddness of broken Tasks, unableto compose a new e-mail... only happens when using IPv4.
If I force my client to go IPv6 it works fine, after some investigating it seems js.zgz files are corrupt when going over IPv4.
I can replicate the same issue if I place a Apache Reverse Proxy between the IPv6 client and the Zimbra WebMail. I also fixed it using:
Code:
# some weird zimbra stuff
AddEncoding x-gzip .js.zgz
AddType application/gzip .js.zgzHere is some more information on the issue:
Here you see what is broken, cache disabled via WebDev toolbar to rule out a cached file.
Connection went over IPv4 through Sophos UTM's WAF.
See the notes on the image.
Forced over IPv6, so bypassing Sophos UTM's WAF.
Everything is fine.
A vanilla Apache RP results in the same scenario as the IPv4 test.
Adding the above mentioned lines fixes it.