Traffic Mon events after update

After upgrading my m400 to 12.6.3 from 12.6.2, I am now starting to get a couple of new messages in traffic mon.

First one being :
2021-01-14 09:05:37 pxy pxy_send_buffer: -1: 192.xxx.xxx.xxx:50766 -> 31.13.65.1:443 [~!A a] {N}: Failed to send buffer Debug

Second being:
2021-01-13 17:42:39 pxy 0x851c50-715 pxy_is_sndbuf_saturated: output buffer is saturated. snd_cwnd='110', unacked='107', sndbuf='520960', data_in_sndbuf='489900' Debug

I have googled my butt off and have yet to figure t his out. I am going to go ahead and assume that is something with the proxy just don't know which one. the previous guy has set up about 10 different proxies. I'm going to guess that it might not be HTTP proxy as those show their own name when they populate in the traffic log.

It might be something that I am overthinking and overlooking. However, any input would be helpful

Comments

  • Normally, with Diagnostic Logging set to Error, one should not see Debug level log messages in Traffic Monitor or in the log servers.
    As far as I am concerned, these should not be being displayed.

    I am seeing some of these as well.
    https://community.watchguard.com/watchguard-community/discussion/1508/pxy-debug-log-messages

  • Bruce,
    Thanks for the reply!
    I did come across your post in my searches yesterday and after reading I went ahead and submitted a ticket. Still waiting to hear back from WG tech.

  • Did you get an answer? i've noticed these too on 12.6.4

    --
    WatchGuard M4600 (x2 Cluster)
    WatchGuard M200
    Firmware : 12.4.1

  • We too see this events since Fireware 12.6.3 and 12.6.4
    HTTPS sessions will be droped without a known reason
    HTTPS Debug message "failed to send buffer"
    I'll too opened a case

    Did anybody found an answer, cause or solution?

  • Hello together

    There are two issues in one:

    We noticed the Debug Event "failed to send buffer", when HTTPS sites are blocked by Webblocker for categories, which are allowed.

    This Debug event comes every time when a sites is droüüed by Webblocker and is a know "cosmetic" bug :

    Support :

    We also create a Change Request in order to suppress these log messages from the default logging level:

    FBX-21185
    Move pxy_send_buffer debug log to a higher diagnostic level

    Please refer to the attached KB Article:
    -HTTPS-proxy generates "pxy_send_buffer: Failed to send buffer" logs

    But our problem was this :

    FBX-21036
    Proxy denies allowed WebBlocker category

    We got an CSP for 12.5.7 and 12.6.4
    Open a case, if you too have this issue

    I upgrade a system (M400 active/passive cluster) and it works

    regards Markus

  • The usual case with Debug level log messages showing in Traffic Monitor or Log Server when Diagnostic Logging is not set to Debug, is that is is a software bug related to that log message.
    Often the bug is fixed in a later release, especially if someone opens a support incident on it.
    I have opened them many times in the past for these cases, but not for this one.

    Thanks for the update.

  • We have similar problem: HTTPS sites are blocked by Webblocker for categories, which are allowed. Any news?

  • You can open a support incident, and support will provide you with an appropriate CSP if one exists.
    Otherwise, you need to wait for the next official release.

  • I am facing exactly the same problem. A specific request category that is allowed in the policy WebBlocker, gets blocked.
    I have also noticed that when I disable the policy's bebblocker and then I re-enable it, I behaves ok for a few minutes and then it starts to block the outgoing traffic that normally should be allowed.

  • Problem solved with new firmware provided by support.
    We also noticed that the old firmware allows users managed with withelist to access sites they shouldn't have accessed.
    As we updated the firmware a user called saying that a site was not working for him, but he had never been enabled for that site. now everything seems to work fine.

  • edited March 12

    I also applied the patch today. The problem seems to be resolved.

    It was a quick response from WatchGuard :)

    https://watchguard.force.com/customers/wgknowledgebase?SFDCID=kA10H000000bqJBSAY

Sign In to comment.