CapsuleWorkspace access to company's exchange server

[Ilya_Avetisyan]

Hello All,

Spent days in attempts to make Capsule Workspace Mail work and still no luck

I installed it onto Android smartphone and created user certificate in MobileAccess blade. The system sent email with QR code to my domain user and the code was successfully was read by Capsule and everything was setup by proper way. In Capsule UI I can enter into 'Mail' section and read my corporate mail

Now the problem: Capsule Workspace doesn't get new mail and I don't see any new mail notifications although I enabled 'Push Notifications' in SmartDashboard. Moreover, I see tons of rejects by Mobile Access blade with messages below:

'Internal host certificate verification failed, probably because the certificate issuer is not trusted.'

'Error while connecting to server with user iavetisian ErrorCode is:500'

So it seems every time when Capsule tries to check the mail Mobile Access blade rejects its requests and maybe that's why there are no push notifications as well.

I don't have an idea how to fix this and what certificate the system needs (my company's certificate maybe?)

[Biju_Nair]

For push notifications I have couple of suggestions : -

1) Trying using without proxy(if any) for the internet connection for the gateway which has mobile access blade enabled.

2) Ensure http and https access is allowed between the gateway and exchange server.

[Ilya_Avetisyan]

Hi Biju

Thanks fo reply

Http and https protocols are allowed of course. Both Checkpoint gateway and exchange server are able to see each other. Proxy setting is turned off.

It seems there are 2 parts of my problem:

1. Certificate error

2. Push notifications

Now I am trying to solve first one and again there are 3 reasons (as I think) why I see certificate error in logs:

1. CheckPoint gateway doesn't to trust mobile client 

2. CheckPoint gateway does not trust to exchange server (when I read docs about capsule workspace setup there were couple words about callback URL. Am I understand correctly that exchange server must be able to access that link? By other words exchange server is trying to connect to checkpoint gateway by some address like https://CHECKPOINT_ADDRESS/ExchangeRegistration)

3.Exchange server does not trust to CheckPoint gateway

So I completely stuck at that point. Have no idea what to do. Maybe put my company's certificate into CheckPoint repository? Or to put CheckPoint certificate into Exchange server's trusted root cert storage?

[Biju_Nair]

For the certificate you may try to sign a certificate using your internal CA by generating CSR from gateway and upload it to the gateway.

Since it is signed by internal CA I am sure exchange will have no issue to trust it.

Regards,

Biju Nair

Sent from my iPhone

[Jeroen_Demets]

Have you checked this sk? sk109039 - How to troubleshoot Mobile Access Push Notifications

You can try using http instead of https and go from there. You'll find the guidbedit location to change that callback URL.

Also: we had a ticket about this and when I asked whether http was secure enough they wiresharked it and showed that the message itself is not readable so it seemed good enough.

Give it a try?

[Ilya_Avetisyan]

Hi guys!

Thanks for the sugestions

Biju, I think your idea should work. I will try it in any case.

Jeroen, I have read that article. So, I changed https to http by editing the database. I did it just to ensure that communication between the gateway and exchange server is really working but I have got new problem. I see in the logs that exchange server is trying to communicate with the gateway but firewall rule blocks these connections because of address spoofing. I think I am starting to understand what is going on here and I will try to explain

Our gateway is a cluster (active-stanby mode). There are 3 virtual interfaces (virtual IPs) are set up - external, internal (or 'inside') and management. Virtual IP address for inside network (which is default gateway) is 172.16.1.1. But VIP for management is 172.16.5.1 so both inside and management are in 172.16.0.0 range. SIC communication is established using management network. In 'Topology' section of cluster settings for inside network I set 'specific' setting and set 172.16.0.0/16 network object which is logical because we have many networks in 172.16.0.0 range and all of them are 'inside'. For management network I set 'Network defined by IP and mask blah blah (second option)'

For callback URL in the database I set virtual IP of inside interface (http://172.16.1.1/ExchangeRegistration) which is correct. But in logs when the gateway blocks connections from exchange server I see virtual IP from management network (172.16.5.1). So by some reason the system thinks that IP of the cluster not 172.16.1.1 as it should be but 172.16.5.1. I think I must remove management network from cluster topology (I mean remove VIP for management because it useless in my case). It should not ruin the cluster because management server and cluster nodes will still communicate. But I hope it will solve the problem of address spoofing.

I will try all this but 2 weeks later because I am in vacation now and it is bit dangerous to configure the firewall remotely.

[Jeroen_Demets]

I think you are on the right track

Enjoy your vacation

[Ilya_Avetisyan]

Hi guys,

It works!

1. Management VIP was removed from cluster (and push notifications started to work)

2. In the database I decided to keep http instead https

3. I still see certificate problem in the logs (will try to fix it laster)

Many thanks for help