This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Application Filter - Source and Destination IP mismatch?


I'd think source and destination IP is wrong here.

It took me some time to help a user who reported he cannot download a file, we blocked because I could not find his computer with my query for source IP.

We block executabled here.

Other Application filter blocks look OK, eg. accessing blocked applications:

This thread was automatically locked due to age.
  • App Control and IPS can be applied on both packets (inbound and outbound). And if the pattern match on the packet coming back, it will be shown in the logs as you see. 

    If you request a download, the data of the file is "coming back from the server" (download). Therefore if the firewall cannot find a download request based on the "get", this packet will be allowed but the IPS/app control will detect a download based on the packets coming back. 


  • But, why when I have an application blocked outgoing am I seeing packets incoming to the Mac air. The application should not get past the firewall rule.


    V18.5.x - e3-1225v5 6gb ram with 4 ports - 20w. 
    If a post solves your question use the 'This helped me' link.
  • There are certain apps, they call "Give me a File". But the app control is not seeing the file. So it will allow this packet. But if the packets are coming back with the file, IPS/app can collect the data and see, this is a file download and blocks it. 

    Most likely we are able to block it based on the get request. But sometimes, apps are likely to try to hide this get request. 


  • maybe this is because the file has been "curled"?

    it was not a regular web request.

    > curl -i
    > HTTP/1.1 500 Software caused connection abort
    > Date: Tue, 20 Jul 2021 14:18:06 GMT
    > Cache-Control: no-cache
    > Pragma: no-cache
    > Content-Type: text/html; charset="UTF-8"
    > Content-Length: 0
    > Via: HTTP/1.1 forward.http.proxy:3128
    > Connection: close

    and yes, in advanced view I can see the block a bit faster than by the other approaches.

Reply Children
No Data