Pardon the noob query or lack of actual technical knowledge in our PA-500 but I've been asked by my supervisor to see what might be blocking some Google services/apps on our new PA-500. I've tried to monitor the IP address (my personal cell phone) and gain some insight via the monitor tab and the traffic and url filtering components of this monitor section and I can't come up with much. Has anyone battled this out there? It must be blocked at a pretty high level because everyone here in I.S. can't connect to these Google services and we're in a filter group that can get to almost anything.
Any ideas as to where to start? Please remember I'm not super fluent in the firewall but can certainly log-in and poke around if anyone has any ideas. Thanks a ton for any help. It is a bit of a big deal since we have a dozen Android tablets for our Home Care department and they need to be able to update apps, etc. As of now, everything seems to be blocked regarding the Play store, calendar and Gmail syncing. On a side note, ESPN alerts are not coming through as well which isn't cool, hehehee!! Thanks again --Kirk
If you cannot find your logs for sessions you know occurred, then go to your policy list and make sure you have logging turned on for the policies.
You are looking in the right place, your traffic and url filtering logs would be where this should show up.
Thanks BLH! I don't actually see anything obvious like that. I've tried to safe-list some of the things I do see but they must not be Google's IPs/domains. This is what I see from my IP (cell phone) and I just don't see anything that is obvious to Google. Could it be blocked before it even gets to this point?
In your screenshot of the traffic log, the traffic you did see is hitting two different security policies - "P-SEC-allowedIP" and "Any-Out". Those are being logged. To check whether or not logging is turned on for a particular security policy, click the name of it to open its settings. In the Actions tab, you will see two check boxes, Log at Session Start and Log at Session End. I would make sure that one of those boxes is checked for any other policies that may be affecting traffic from your phone. If you're not sure which one(s) that might be, check them all. Per the documentation for 7.0, Start should be checked and End is unchecked by default.
Once you're sure everything is being logged, you can filter for your phone's IP address again as the Source in the traffic log, and anything from your phone traversing the firewall to the internet should be shown. I would also do an OR and look for your phone's IP as the destination address as well, in case your requests are going out but the replies are not being allowed back in.
( addr.src in 172.20.6.111 ) OR (addr.dst in 172.20.6.111 )
Add the Action column to your traffic log view, too, and put it right next to Rule. That way you should be able to see what rules your tests are matching, and what the rule did with the traffic (allow, drop, reset, etc.) The Session End Reason field will also tell, e.g. policy-deny.
Keep in mind, too, that security rules are evaluated in order from top to bottom, the first match wins. It is possible a rule higher in the list is taking precedence and blocking your traffic, despite your very permissive IS dept rule applied to that group.
If you really need to dig in, there's always packet capture.
Finally - don't forget to back up your current configuration before you start changing things, and don't forget to do a Commit to make changes take effect before testing.
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!