Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 26 subscribers
  • Views 402 views
  • Users 0 members are here
Options
Suggested
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

Inconsistent Web Filtering / Firewall Rule Application

Lonnie Thibodeaux

Sometimes there are issues with an application's ability ability to get updates for that application (application will not download the updates). I have seen this in various applications...Quickbooks, Adobe, Veeam Endpoint for example.
Usually this is due to restrictions present in web filtering.
Typically in my XG I have an Internal to WAN FW Rule that has Scan HTTP, Intrusion Prevention (LAN to WAN), Web Policy (Default Workplace Policy), and Rewrite source address (masquerading) set.

In order to attempt resolve the inability to download the application updates I do the following:

  • Get the Source IP of the endpoint attempting the application update.
  • Use the Log viewer to get the URLs being accessed by that endpoint
  • Create a IP host for that endpoint
  • Create a FQDN host (and / or group) for the destination URLs being accessed.
  • Create a FW Rule from LAN to WAN
    • Source Zone: LAN
    • Source networks or devices: IP Host with IP of the trouble endpoint
    • Destination Zone: WAN
    • Destination Networks: FQDN Host (or group) for the destination URLs
    • Rewrite source address (masquerading) set
    • No other options set on this rule.
    • Apply rule to top of LAN to WAN group.

Test the download for the application on the endpoint.
Immediately starts downloading application updates.
To re-verify, cancel the download, disable the rule specifically created for the endpoint.

So here is the issue and my question...after disabling the rule, the application does process the download successfully.,
The application download did not work until I created and applied that rule, and now it works after I disable it. This makes NO sense.
Seems that the rule is still being applied even though it is disabled, or it internally created an opening in the FW that remains even after it is disabled.

Can someone provide an explanation?

Much appreciated
Lonnie



This thread was automatically locked due to age.
Parents
  • 0

    Just providing an update. Nothing new to report at this time, other than I had another workstation with the same software that needed to be updated. The updates were downloaded and processed without incident (The bypass rule I created remains disabled so there should be no affect).

    @Emmanuel, to answer your question about the reason 'according to the XG'. I have gone back thru the logs for the workstations on the date I originally had the problem, and I cannot find any entry for Firewall rules or Web Filter where anything was blocked....edit...In looking at logs for Firewall there are a few instances of Denied for that workstation on FW Rule 0. Description 'Could not associate packet to any connection'.  I have been told in the past to not worry about Denials on FW Rule 0, as that is some sort of internal processing and does not affect outgoing connections. Some of  destination address on those seem to be for avast or akamai, so I am guessing it has to do with internal AV processing on the XG.

    Next time it happens I will attempt to make a better diagnosis.

    Thanks
    Lonnie

Reply
  • 0

    Just providing an update. Nothing new to report at this time, other than I had another workstation with the same software that needed to be updated. The updates were downloaded and processed without incident (The bypass rule I created remains disabled so there should be no affect).

    @Emmanuel, to answer your question about the reason 'according to the XG'. I have gone back thru the logs for the workstations on the date I originally had the problem, and I cannot find any entry for Firewall rules or Web Filter where anything was blocked....edit...In looking at logs for Firewall there are a few instances of Denied for that workstation on FW Rule 0. Description 'Could not associate packet to any connection'.  I have been told in the past to not worry about Denials on FW Rule 0, as that is some sort of internal processing and does not affect outgoing connections. Some of  destination address on those seem to be for avast or akamai, so I am guessing it has to do with internal AV processing on the XG.

    Next time it happens I will attempt to make a better diagnosis.

    Thanks
    Lonnie

Children
No Data