I have GP Always-On VPN configured and my test Windows 10 machine connects to the gateway and accesses internal LAN resources fine. MS Outlook 2010 doesn't seem to connect when I am connected via the GP client. Outlook just keeps saying 'Trying to connect to server'. On one occasion, the MS Outlook prompt did appear for me to enter my password. This was done, but it was still saying 'Trying to connect to server'. When I left the machine for some time, Outlook looked it connected, as my mailbox contained the latest emails. Our Exchange mail is hosted externally, as we are part of National Health sector in the UK.
I configured the Windows Defender firewall on my Windows 10 machine to allow the GlobalProtect client through the firewall, but made no difference.
Has anyone else experienced this with MS Outlook connected via GlobalProtect?
I think you would need to look at your security policies AND your traffic logs to help you determine what the issue is, specifically.
The GP software allows the user to connect (and appear) as a local user, in whatever zone (Source Zone or SZ) (trusted/internal/GP) you define. So look for traffic from the SZ to the DZ, matching your Outlook traffic.
I guess... if all other traffic (as you mentioned... Always On is enabled) is working fine, with the exception of this, then I think it is more a security policy/profile than specifically a GP related issue. Presumption is that users are configured for the proper internal DNS/WINS, and dns suffix is registered. (all configurations in the GP gateway section)
Interesting to open a TAC case.
If the FW bytes showed as SENT, but NONE are received, then why do you think this is a FW issue?
While I will agree that other apps are probably working, the question I need to ask is... can you please do a packet capture from the downstream switch to confirm that the traffic from the outlook server did, indeed, make it to the FW (as the response traffic)
I tend to believe that this is a network/routing issue.
This is interesting because we use O365 and I see the same kind of thing. With initial connection, if you start up Outlook right away, about 50+% of the time you will get exactly what you described in the initial post. Then, you close Outlook and open it again and all is well. It is like the routing is just not there initially and has to figure it out. Since we are using O365, the addresses are very dynamic, so I cannot add the routes.
Your insight has helped me understand what is happening and I will have to see what I might be able to get done.
Thanks for the post and your resolution.
Perhaps getting Wireshark on to see how the packets flow and start from there. Using Wireshark helped me to see which IP MS Outlook was connecting to, then I needed to get the IP (and subnet) confirmed by the company hosting our Exchange servers. It sounds like using MS O365 is more complicated, but good luck.
I wanted to hold my comments about this static routing, as I really do not understand why you needed to put in static routes.
I am only presuming that your FW can fwd traffic out its public interface, and let the routing of the Internet get the traffic to the Outlook servers.
The other question that I had... is why ONLY the GP users.
If you needed outlook to work with static routes, this also implies that your internal users could not have had their email working at all.
Again, because it was not a security policy change, but a network/routing change.
Am I simplifying your configuration too much?
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!