Suppressing "Unhandled Internal Packet" and "blocked sites" errors from DNS

ACOACO
in Firebox - Proxies

I have been trying (unsuccessfully, obviously) to suppress some clutter from the logs and now call upon the gurus here. The solutions must be without the aid of subscription licensing (such as DNSWatch). Why? My reasons.

The problem devices are all wireless.

I am using a DNS-Proxy to prevent a wireless device from accessing specific destinations via name. I also have one IP address in the Blocked Sites list.

In Interfaces > DNS/WINS, the ISP's address is listed as the only DNS SERVER. The ISP takes care of autoconfiguring the modem with DNS server addresses and there are no DNS servers on the LAN side of this universe. DNS Forwarding is enabled for the hardwired devices but disabled for the wireless devices. Why? It seems that enabling DNS Forwarding for the wireless devices causes the DNS-Proxy's Proxy Action's Query Names to be useless even though the action to take is "Drop."

I've suppressed many of the log entries, but not quite all. Yes, I understand that "Unhandled Internal Packet" means the system ran through all the rules and found no final disposition for the packet. All the error messages are msg_id="3000-0148".

Deny  Wireless-1 Firebox 75 udp 20 64 [device] [firebox] 59511 53  (Unhandled Internal Packet-00)
Deny  Wireless-1 Firebox 75 udp 20 64 [device] [firebox] 35006 53  (Unhandled Internal Packet-00)
Deny  Wireless-1 Firebox 75 udp 20 63 [device] 8.8.8.8 60725 53 msg="blocked sites"  (DNS-proxy-00)
Deny  Wireless-1 Firebox 75 udp 20 64 [device] [firebox] 44401 53  (Unhandled Internal Packet-00)
Deny  Wireless-1 Firebox 75 udp 20 64 [device] [firebox] 49748 53  (Unhandled Internal Packet-00)
Deny  Wireless-1 Firebox 75 udp 20 64 [device] [firebox] 43824 53  (Unhandled Internal Packet-00)

Bonus Error

Deny External Firebox 36 igmp 24 1 [firebox] 224.0.0.1 (Unhandled External Packet-00)

That last one has been around for only about forever.

Any help here?

Answers

  • Bruce_BriggsBruce_Briggs

    . IGMP is IP protocol number of 2: add a custom Packet Filter for IGMP. Then add that as a policy, set to Denied, with "Send log message" not selected

    . DNS Forwarding - this causes DNS queries which are sent to a firewall interface to be forwarded to an external DNS server. No policies will be applied to these forwarded DNS packets.

    While you can add a DNS policy for DNS packets To: a firewall interface IP addr, and set it to not log (Unhandled Internal Packet-00) - doing so will make it harder for you or your customer support team to understand why wireless clients can't access the Internet.
    It is better to try to get the wireless clients to use an appropriate external DNS server.
    . For wireless devices - in the Wireless-1 DHCP server settings, make sure that an appropriate DNS server IP addr is specified. Normally if one is not specified, then the one listed on the WINS/DNS tab should be used.
    Not sure why this does not seem to be happening.
    What is the subnet defined on Wireless-1? If it is 192.168.1.0/24, then that may be the cause if some/many wireless clients come in with an IP addr from that subnet, and don't get an IP addr etc. from your DHCP server settings.

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @ACO

    -The firewall will always log blocked sites hits. If you want to deny those in a way that does not log them, create a packet filter, and set the action to deny. Ensure that the "send log message" option under logging is disabled (unchecked) for that policy. You'll also need to remove the IP from the blocked sites list, since the firewall processes those entries first.

    -The unhandled internal packet logs will need a rule to not log as unhandled. You'll need to create a deny packet filter that matches the source(s), destination(s) and port(s) with the action set to deny. The logging option for "send a log message" in logging will need to be unchecked.

    The last bonus error is multicast traffic. It was likely destined elsewhere, but it also hit the firewall because it was multicast. Since the firewall doesn't know what to do with it, it marked it as unhandled and dropped it.
    If you don't want to see that log, you'll need to create a packet filter policy set to deny with logging turned off.

    -James Carson
    WatchGuard Customer Support

  • ACOACO

    Y'all:

    Well, I jiggled a few knobs, readjusted the rabbit ears and replaced a couple of questionable vacuum tubes.

    -Rather than rely upon the ISP modem for DNS servers, I hardcoded them into the Network > Interfaces DNS/WINS DNS SERVERS and disabled DNS Forwarding.

    -In Network > Wireless configuration for Wireless-1, I cleared out the DNS/WINS DNS SERVERS so that it defaults back to the Interfaces configuration.

    The only reason for having to do all this is so that the DNS Proxy I am using will prevent queries for specific names. One name in particular resolves to 40 IP address (that I know of so far). A DNS Filter doesn't allow one to list strings to be denied (or allowed).

    I did use a DNS Filter eventually, but it is to block the devices from backdoor access to 8.8.8.8 directly when all other attempts fail.

    As for 224.0.0.1, the Firebox does not allow certain IP address to be used in the TO or FROM (and presumably other) fields. So that little annoyance will just have to be tolerated.

    And as a result of this frustration, I found a solution to a completely unrelated annoyance that has plagued me for thousands of years.

    The last annoyance on my list (for now) is a bunch of "tcp syn checking failed" messages. It appears to be an inside app that terminated and the outside half is still talking. I may have to shorten the timeout for NAT or something along that line.

  • Bruce_BriggsBruce_Briggs

    Review this:
    Troubleshoot "TCP SYN checking failed" log message and asymmetrical routing
    https://techsearch.watchguard.com/KB?type=Article&SFDCID=kA16S000000XeLhSAK&lang=en_US

    Don't specify an IP addr on your IGMP policy.
    try From: Any-external To: Firebox

  • ACOACO

    Hey, @Bruce_Briggs

    Yeah, I read through that article (again, for the umteenth time). I don't think this is an asymmetrical thing though. It feels like the app on the LAN side is dropping the conversation.

    All the codes are either A or AF.
    All are using HTTPS.
    All are External to Internal.

    At least I have cut down the number of syslog messages from over 1000 per hour to less than 200 per hour (including performance reporting).

    One more example of a cr@p programmer. Write the app for a perfect world. Ignore the unhandled exceptions. Terminate without a graceful shutdown.

    I wouldn't mind suppressing the message. Yeah, I am very much aware that suppressing messages makes troubleshooting more like shooting in the dark. But one could always re-enable logging for the troubleshooting process and then disable the logging once a resolution (if any) is achieved.

    Firewall maintenance is like a game of Whac-A-Mole (but it never ends and you never get redemption tickets regardless of the high score).

Sign In to comment.