Reverse Proxy, Exchange publush

[Alexander_Lario]

Good day,

I am trying to publish a Microsoft Exchange server using ReverseProxy Check Point ver. – R80.40.
• Stand scheme:

• Mobile Access portal address: https://sslvpn.infopark.uno

• ReverseProxy rules:

Cannot connect from Outside_PC using Microsoft Outlook.

• Logs:

Do I understand correctly that when creating application Outlook_Anywhere in Reverse_Proxy, the necessary rules should be created automatically?

[_Val_]

Yes and no.

Yes - for Mobile Portal configuration, there is nothing to add

No - you still need corresponding network security rules for the connectivity required.

[Alexander_Lario]

Thanks for your reply. The only rule that currently exists is this rule - allow everything.

 

[_Val_]

Please make sure you looked into sk110348

[Alexander_Lario]

Yes, I know about this sk. I also know about the Mobile Access Administration Guide R80.40.

[_Val_]

By "know" you mean, "I read through and did not find a solution"?

What is the error on the client side? Any logs/errors on Exchange server? Are you using OWA or something else? What HTTPS logs above say?

[Alexander_Lario]

These guides didn't help me.

What is the error on the client side?

I'am using an "Exchange" connection type.

 An error after connection attempt:

 Any logs/errors on Exchange server?

I record traffic using wireshark which is installed to Exhange machine at the time of connection. I don't see any attempts to access Exchange from the IP addresses of the external workstation or the internal ip address of the Check Point.

Are you using OWA or something else?

Yes, we can try to connect to OWA through external IP address of Check Point. Connection attempt failed from the Outside_PC station.

What HTTPS logs above say?

These are logs at the time of connection from the workstation Outside_PC with Outlook.

 

[PhoneBoy]

It's not clear why the PC is not connecting.
What troubleshooting have you done?
Might want to start here: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut... 

[Alexander_Lario]

I looked at debug - arrival of Reverse Proxy requests to Reverse Proxy apache. There it was seen that requests were coming to autodiscover.infopark.uno. I added autodiscover.infopark.uno and mail.infopark.uno to ReverseProxy rules.

This is what the rules look like now:

After that, it was possible to connect using Outlook from Outside_PC. 

I removed all access rules from firewall and NAT:

This is a great victory. I have spent a lot of time on this task. Thank you so much for your help.

However, I think there are some difficulties.
Now I can open /owa and/ecp via https://mail.infopark.uno/owa , /ecp. This is the problem because these things have to be
published through the SSL portal.

Do I understand correctly that there is no way I can deny direct access to /owa and/ecp now?

[PhoneBoy]

That’s correct, you don’t have any user level access control with Reverse Proxy features.

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

[anstelios]

I believe your Mobile Access Portal URL on SmartConsole and the External Server Name on the Reverse Proxy rule should not be the same.

You should change  the External Server Name on the Reverse Proxy rule to something different than https://sslvpn.infopark.uno (like https://extmail.infopark.uno) that should of course resolve to the same IP (Checkpoint's external IP)

[Alexander_Lario]

I changed External Server Name on the Reverse Proxy rule:

nslookup from Outside_PC:

Ping from Check Point gw:

but no positive effect. I still can't see any logs with wireshark on Exchange machine.

Check point GW logs at the time of the request:

[Alexander_Lario]

I can go to https://mail.infopark.uno/owa , the OWA Exchange page opens,

I can go to https://mail.infopark.uno/ecp , the ECP Exchange page opens.

reverseproxy logs are visible at the time of connection:

But attempts to connect using Outlook are still unsuccessful.

[_Val_]

So it is probably not your FW that is at fault.