Thread Info
  • Replies 20 replies
  • Subscribers 14 subscribers
  • Views 64773 views
  • Users 0 members are here
Options
Suggested

FW Log "Could not assocate packet to any connection" when IPS enabled

splarksop

Clean install of SFOS 17 beta. Used the router Wizard at install time and left all protection types unticked in the wizard.

Created a simple FW rule allowing LAN to WAN port 80 and 443 with an Intrusion prevention policy

 

Can browse the web without issue, but FW log is full of Rule 0 "Could not associate packet to any connection"

 

In the log screenshot below you can see several allow hits on my FW Rule,  then several blocks on rule 0  for the same source/destination and port.

This repeats through the logs extensively for both port 443 and 80. 

 

 

If I set intrusion prevention policy to none, this deny goes away. Setting ANY IPS policy, even custom rule with a single signature configured to allow the traffic  then this invalid traffic appears all through the FW log.

 

  • in reply to Billybob

    Hi Billybob,

    I changed my MR7 XG while trying to see the current value, thought the command might display the previous value. but no.

    How do you get the previous value?

     

    Ian

     

    Update: changed the XG v17b setting, restarted it, started new browser to new sites, still the same error message.

    XG115W - v20.0.1 MR-1 - Home

    XG on VM 8 - v20 GA

    If a post solves your question please use the 'Verify Answer' button.

  • in reply to rfcat_vk

    Yeah, my testing shows the same errors too. Raising the connection timeout slowed the flood to every 6 hours instead of the default 3 hours.

    Typing show advanced-firewall will show the current value. They will have to adjust the verbosity rate at which the packets are being logged but of course I could be wrong and this is some other firewall settings problem.

     

     

  • The problem with NetFlix is still valid for Beta 2. :-(

    Any new ideas how to solve this?

     

    //Update:

    I did some testing since I'm able to reproduce the problem with Netflix streaming with http/80.

    This is the behavior I was able to reproduce on beta 1 and beta 2:

    - Update/reboot the system with the beta firmware

    - Start Netflix streaming

    - Streaming stops with an error after approx. 45 minutes

    - Log is full of "Could no associate...." errors with the source IP of the streaming client (Amazon FireTV stick in this case)

     

    The workaround I found:

    - Open the related FW rule and disable ANYTHING in the box "Web Malware and Content Scanning" ...

    - ...AND set the "Web policy" to NONE in the "Advanced" box.

     

    Afterwards it's working again without any problems. 

    So I guess it has something to do with the "Web" component, which might run into a problem after some time?!

    It seems to work if you make sure that the FW rule won't use the "Web" component at all.

     

    Although you might not notice any problems during normal web surfing, I think this is a serious bug in v17.

     

    Best Regards and a nice weekend :)

    DomNik

  • in reply to DomNik

    Hi,

    Thank you for the feedback.

    The logs 'Could not associate packet to any connection.', is generated in following case:

    • In case appliance receives any packet, which does not have an already established connection. Hence no associated conntrack is found for that particular packet.
    • The connection from the appliance has timed out, but client is still retrying by re-transmitting packets with old connection id.
    • This invalid log reason, is not due to any error in appliance or configuration issue. Rather it occurs due to network packets received by appliance for which it has no related connection.

    Invalid traffic logging can be turned OFF, to avoid logging these packets frequently.

    Earlier this logging was disabled by default, which could be the reason of not noticing these logging.We have enabled "Invalid traffic" logging in SFOSv17 with factory default configuration.

     

    Regards,

    Deepti

  • in reply to deeptibhavsar

    I know we are reaching the end of the beta and you guys are trying to wrap up and tie loose ends but the problem is not what the logic behind the logs is. We want to know why they are generated in such huge numbers and how to fix the problem. Turning off a chattering logging subsystem is not the answer. I explained the problem in a little more detail in the other thread https://community.sophos.com/products/xg-firewall/sophos-xg-beta-programs/sfos-v170-beta/f/sfos-v170-beta-feedback/96650/numerous-could-not-associate-packet-to-any-connection-messages-in-the-firewall-log/351500#351500 

    Regards

  • in reply to deeptibhavsar

    Thanks for your reply deepti.

    I don't think that the logging is a problem when we know what is the reason for it.

    But in my case Netflix streaming is broken when the web scanning features are enabled for the streaming device and its firewall rule.

    Greets

    DomNik

  • in reply to DomNik

    Broken netflix is an unfortunate side effect of using webfiltering. You will have to create exceptions to get that working if you want your streaming devices to use web filtering. https://community.sophos.com/kb/en-us/125061

    Usually netflix or other streaming services will look like they are working when looking at the logs (although they are not working) and don't generate invalid packets in the logs.

  • in reply to Billybob

    Hi Billybob,

    thanks for your reply. I already have a correct Netflix setup which was working with v16 (http scan active, custom web policy for ad blocking BUT with exceptions for the Netflix IP ranges and media streams).

     

    Today I found another problem pointing in the same direction:

    Playstation network downloads onto a PS4 are not working anymore.

    These downloads have the same behavior as Netflix: They separate a download of 43GB into a large number of http/s requests with a size of 16MB each.

    After some time the Firewall doesn't seem to be able to manage them anymore and simply starts to block everything with the given log entry.

    (The download URLs for dl.playstation.net are configured to skip HTTPS decryption and Content/Malware Scanning).

     

    --> These problems do occur with v17 only (not with v16), so I don't think that my setup is not correct anymore. v17 seems to be unable to handle high amounts of http requests from one source/device.

    Is there a way to increase the session/connection/whatever count? Are there any configuration changes from v16 to v17 under the hood? 

     

    Greets

    DomNik

     

    Update:

    The awarrenhttp.log logs errors like this when the problem occurs:

    1507829232.415270765 [ 6381/0x7fe5d9458000]       scanner.c:930   check_range_reqs parse_byterange failed to parse range header bytes=3502309376-3509452799 (3502309376,2147483646)

    1507829232.870765995 [ 6382/0x7fe5d9caf400]       scanner.c:930   check_range_reqs parse_byterange failed to parse range header bytes=3502309376-3509452799 (3502309376,2147483646)

    1507829232.873659905 [ 6381/0x7fe5d9458000]       scanner.c:930   check_range_reqs parse_byterange failed to parse range header bytes=3502309376-3509452799 (3502309376,2147483646)

    1507829232.877429294 [ 6381/0x7fe5e40e5000]       scanner.c:930   check_range_reqs parse_byterange failed to parse range header bytes=3502309376-3509452799 (3502309376,2147483646)

  • in reply to DomNik

    We made changes to Range Requests for v17.  I am pretty sure this issue is separate from the "could not associate packet to any connection" issue.

    Can you please open a separate thread with the same information.  Also let me know whether you are running 32-bit or 64-bit OS (or what hardware if you don't know).

  • in reply to Michael Dunn

    We have confirmed the Range Request issue.  We have problems when the range is for part of the file larger than 2GB.  Tracked in NC-22752.

    Workaround is to create an exception for the destination, do not perform malware scanning.

    Confirmed this is a separate issue from "could not associate packet to any connection".

Unfiltered HTML