[SOLVED] Zentyal client can't access mail sites / HTTPS problem?

[christian]

This is not what I meant 
Furthermore (and I still need to investigate this), I suspect something strange when you swing between transparent and non transparent mode because packets still look like "captured" even when running non transparent mode and decide not to use proxy.

Anyway, back tp you point: I'm not sure tracepath will use proxy, thus is testing on port 80 meaningful? (tracerpath uses UDP and HTTP uses TCP  )
 traceroute -T -p port target will use TCP.

But what you show here is that you never go further than Zentyal box as if route to destination was unknown.
What happens when you check the same directly from Zentyal box?

[christian]

Thank you.
FYI, use of proxy, transparent or not, while testing from Zentyal itself is irrelevant.

So it looks like something wrong at FW level because from gateway you can reach this target (meaning route is known and allowed) while machines inside your network can reach further than... I don't know what 

Some questions here:
- what is 222.127.106.205 ? is it the external IP address of your Zentyal server because your ADSL device is not router but bridge. (this is a public IP in Philippines)
- what is 172.16.2.100?
- what is  gw315.kcc IP address?

Well,, what I try to understand is your network design 

[christian]

To not take it the wrong way but you should have described all this long time ago 
and even with your explanations, I don't understand what your network is made off except that you are using VLANs (are you sure about this. I suspect this is not VLAN but just multiple subnets with router in the middle) and 2 Zentyal.

I strongly suggest you post either a drawing or provide clearer explanation... or someone else will understand better than I do and I have to give up 

gw315.kcc is the domain name of kccgw (Zentyal) host which has the ip 172.16.1.1

This is kind of meaningless. It can't be domain name (I grabbed it from tracepath). I suppose you mean that your Zentyal host name is gw315.kcc  Which one, the PROD one or DEV one?
If both PROD and DEV Zentyal connect to internet, how to you handle switch from one to the other, especially with transparent proxy feature? and what's about default gateway?

[solarwindz]

Yes Sir it is VLAN. I am a network administrator, and networking is my expertise. ^_^

But these infos won't help us solve the issue. DEV is on isolated Network.

So all suggestions i got from this forum are excuted on DEV, this is to eliminate any network issue.

Take this DEV diagram, A very simple diagram.

client >> Zentyal >> Internet

Do not think about my Prod. We use our DEV for simulations. ^_^

thanks!

[christian]

OK, cool, let's then discuss real network stuff as this is domain you understand 

<im315.kcc client> (172.16.2.x) <--> (172.16.2.100) <router> (172.16.1.x) <--> (172.16.1.1) <Zentyal DEV gw315.kcc> (222.127.106.205) <--> internet link

Is THAT correct?

Assuming answer is yes  and assuming you have enabled transparent proxy, then HTTPS uses only firewall.
when you trace route from your client to internet, you stop at Zentyal server (internal interface) while Zentyal itself is able to connect to internet.
As you are network expert, we can assume there is not issue with network like missing default route or stuff like this 
Therefore the only solution is that firewall is preventing packets to exit through Zentyal. Do you agree? If yes, then look at firewall rules again (BTW, look at FW log, it may help).

I would say that:
- FW is not configured to allow all internal flow to exit to internet (why not, this makes sense)
- you may have only authorized 172.16.1.0/24 

Sorry, I can't help more than this 

[solarwindz]

Yes Yes Yes!
I got your point Sir, very helpful.

On Firewall (Internal to external), source ANY destination ANY service ANY decision ACCEPT.

Just tried this. Still not working. T_T

client >> Zentyal >> Internet

[christian]

Can you post the result of "sudo traceroute -T -p 443 bbc.co.uk" from im315.kcc?

[solarwindz]

I'm sorry to tell this. traceroute command is no more available in Ubuntu 11.04.
^_^

[christian]

You mix up "no more available" and not in default package list  I'm using it running 11.04  meaning you can just install it 
Anyway, being creative, you can try tracepath instead of traceroute but it will use UDP only if I'm not wrong. I'm sure you know this better than I do.

[solarwindz]

Yes, but tracepath do not have -T command. And i already posted tracepath earlier. wait, let me connect my debian device for traceroute.

[solarwindz]

sudo traceroute -T -p 443 bbc.co.uk
traceroute to bbc.co.uk (212.58.241.131), 30 hops max, 40 byte packets
 1  172.16.1.111 (172.16.1.111)  1.229 ms  1.438 ms  1.649 ms
 2  gw315.kcc (172.16.1.1)  0.236 ms  0.237 ms  0.228 ms
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  *^C

Thanks!

[christian]

Yes, but tracepath do not have -T command. And i already posted tracepath earlier. wait, let me connect my debian device for traceroute.

1 - of course if you use tracepath, syntax is a bit different 
2 - Yes you posted it already but in the meantime you may have changed FW rules isn't it?
is 172.16.1.111 the IP of your router?

Did you also look at FW log?

I really give up now.
There is something wrong between network and FW. Packet are dropped at Zentyal level.
You have to investigate on your side:
- check logs if you don't know where to look at
- stop proxy and  try again
- review settings

but from my side there is nothing else I can do. Sorry for that 

[nicolasdiogo]

to test non-transparent you have to use

tracepath bbc.co.uk/443

443 is the port for HTTPS

[nicolasdiogo]

agree with Christian,

this is a soap-opera!

[christian]

Do you confirm such test really makes sense?

My understanding, although I could be wrong, is that tracepath uses UDP while HTTP (and HTTPS) uses TCP, reason why I suggested to use traceroute with -T option (to force TCP) and -p [port] option to test port 443.

Anyway, issue looks like not related to HTTPS but something with firewall. From Zentyal he his able to reach outside but from inside with "any to any accept", packets are dropped at Zentyal entry level and we have no feedback about firewall log, so I preferred to give up.