In most common situations the traffic log should show you this but you may need to add a drop rule at the bottom of your rulebase to log blocked sessions if you don't already have this.
Are you looking for a specific sort of session being blocked?
if you're seeing insufficient data for the corresponding session, it might be that the server is not responding (might be related to it running an access list or is running on a non-default port).
Other possible issues could be that your session is not being NATed properly, the server does not have a proper route back to your device, the upstream router does not have a route back or there may be an arp issue.
insufficient data usually means the PaloAlto sees your syn packet go out, but no packet coming back to complete proper session setup
When you say the server is not responding you mean the ftp server that the user is trying to connect too at the remote site. I put the IP address in a browser and the login information comes up for the ftp site so I assumed it was not being blocked. So its going out and the packet not coming back would that be caused by the ftp server or the PA?
in the GUI under the monitor tab there's a packetcapture menu, this will allow you to set up pcaps on the firewall to see what is going on
as filters it might be good to start out broadly with the server ip as destination and a second filter with the server as source (the filters are session aware but setting an additional filter could help catch rogue packets)
then you can set the receive and transmit stage which will generate 2 separate pcaps
the difference between these is that the transmit stage will only show you packets leaving the firewall and the receive only contains packets arriving on the firewall
correlating these 2 could help pinpoint if a packet is dropped by the firewall or is not being received
to make sure the server is accepting regular FTP connection, do you happen to have an infirewalled external line?
If you are using a browser, and the site has an HTTP server configured as a front-end for the FTP site, it will not yet be FTP. It will likely be web-browsing, and once the login is completed the firewall will see that it is actually FTP and will block it according to your rules.
If instead of a browser, you were to use a native FTP client like Filezilla, you should see the block after the site sends the native FTP "220" response after the TCP handshake.
Hope this helps,
The ftp site is at a vendor facility I have no access to it to see what is going on. We have contacted the vendor and they asked me to see if we have ftp pot 21 blocked I do not see anything that would tell be 100% if it is blocked. I don't know what you are asking "do you happen to have an infirewalled external line?"
With an "unfirewalled external line" I meant to inquire if you have the option available to you to connect a client to a home DSL/cable line or if you can attach it just outside the firewall, this would allow you to easily verify if the ftp connection itself is functional before needing to go into firewall debugging
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!