Firebox M400 packet denied even though it matches a policy
In our Firebox FireWare Web UI System Manager in the "Traffic Monitor" we saw the message "Unhandled Internal Packet-00" message, even though we have a policy covering this packet. I saw from other posts where the firewall has a default deny policy where a packet is automatically denied if it does not match a policy. However, we have a policy that matches this packet, so we are confused as to why it was denied.
0
Sign In to comment.
Comments
Can you show the affected traffic logs and your policy?
Make sure the to/from and packet/policy all match the affected traffic...
I was hesitant about posting our policy and traffic logs because we did a security audit, and we found that a lot of countries like China are constantly scanning our open ports; in addition to our staff being targeted by custom phishing attempts. So I asked Watch Guard Technical support, and here is what they said:
"The source traffic was coming from your DMZ. The traffic was attempting to reach your internal server sub net. You have a route in your firewall that points where to find this internal sub net.
One of your policies allows "Any Optional and Any Trusted to Any External"
However, the traffic was going from the Optional Network to the Trusted Network.
I could not find a policy in the firewall that allows the Optional interface, sub net, or host IP in the log provided to be allowed access to query your internal network for DNS.
Then because your internal network is not seen as an "External" IP address, as it is in the separate Private sub net, it is seen as private, and as well as trusted. Since the only way to reach the sub net is through interface 1, which is your default gateway.
To summarize, you do not have a policy that allows your DMZ host machine to send traffic internally to your private network on port 53. Policy #101, your DNS policy does not see the internal sub net as "External" it sees it as "Trusted" and at that point, the firewall does indeed not have a policy to match the traffic too thus it is blocked, as you have already mentioned."
Postings log message where both the source & dest IP addrs are private incurs NO security exposure on your part.
For a log message which has a public IP addr, you can X it out and tell us about its meaning
Also, posting the policy info: packet type, From: & To: info should incur no risk - if there is a public IP addr involved, xxx.xxx.xxx.123 incurs no risk
Hi @Jonathan_2077
--If you're worried about posting the log and config, I would suggest opening a support case. Information in cases is kept securely between you and the tech(s) working your case, and is automatically wiped or anonymized after 60 days.
-James Carson
WatchGuard Customer Support