These log messages refer to the ICMP category.
2.21.1. [ID: 204] Bad ICMP message checksum
- Log Categories
- ICMP,VALIDATE,STATELESS
- Log Message
- Bad ICMP message checksum.
- Default Log Severity
- Notice
- Parameters
- type, code, chksum, calcchksum, pkt
- Explanation
- An ICMP message has a bad checksum.
- Gateway Action
- Allow
- Action Description
- Node
- Proposed Action
- A bad checksum is normally an indication that the packet data has been corrupted, something that will happen spontaneously
when transferred over a physical network medium. This is only a concern when it happens in excess; in this case it may be
a sign of broken hardware inside the network. Try to locate and isolate the misbehaving unit. The ICMPSettings:ICMPValidateChecksum setting can be changed to control the gateway's behavior regarding packets with broken ICMP checksum.
2.21.2. [ID: 387] Bad ICMP message checksum
- Log Categories
- ICMP,VALIDATE,STATELESS
- Log Message
- Bad ICMP message checksum.
- Default Log Severity
- Warning
- Parameters
- type, code, chksum, calcchksum, pkt
- Explanation
- An ICMP message has a bad checksum.
- Gateway Action
- Drop
- Action Description
- None
- Proposed Action
- A bad checksum is normally an indication that the packet data has been corrupted, something that will happen spontaneously
when transferred over a physical network medium. This is only a concern when it happens in excess; in this case it may be
a sign of broken hardware inside the network. Try to locate and isolate the misbehaving unit. The ICMPSettings:ICMPValidateChecksum setting can be changed to control the gateway's behavior regarding packets with broken ICMP checksum.
2.21.3. [ID: 365] ICMP error with embedded trailer
- Log Categories
- ICMP,STATELESS,VALIDATE
- Log Message
- ICMP error with embedded trailer.
- Default Log Severity
- Warning
- Parameters
- type, code, srcip, destip, paylen, encapproto, encapsrcip, encapdestip, encappaylen, encaptrailer
- Explanation
- The embedded IP message inside the ICMP error, was shorter than the full payload of the ICMP error. A portion of the ICMP
payload therefore consisted of "undefined data".
- Gateway Action
- Strip
- Action Description
- The embedded trailer inside the ICMP payload has been zeroed out
- Proposed Action
- The ICMP error was likely generated as a response to a packet containing a trailer of the "undefined data", but the point
is that "undefined data" is a potential information leak and almost exclusively a sign of incorrect network handling. Try
to locate the node producing the trailers if this happens more than once, and see if it can be upgraded. This log message
can be turned off by modifying the IPSettings:LayerSizeConsistency setting, but the current handling cannot be turned off.
2.21.4. [ID: 328] Length of embedded header in ICMP error is[...]
- Log Categories
- ICMP,STATELESS,VALIDATE
- Log Message
- Length of embedded header in ICMP error is invalid.
- Default Log Severity
- Warning
- Parameters
- type, code, srcip, destip, paylen, encaphdrver, encaphdrlen, encappaylen
- Explanation
- An ICMP error message encapsulated an IPv4 header that was too large to be fully contained inside the original message together
with at least the beginning 8 bytes of an L4 header, meaning that the information to forward this message was never even contained
in the original message.
- Gateway Action
- Drop
- Action Description
- None
- Proposed Action
- This packet is severely broken. If the packet sender is one of your network devices, investigate why the unit is sending malformed
packets. This log message can be disabled by the IPSettings:LayerSizeConsistency setting.
2.21.5. [ID: 450] ICMP error with incompatible IP version
- Log Categories
- ICMP,STATELESS,VALIDATE
- Log Message
- ICMP error with incompatible IP version.
- Default Log Severity
- Warning
- Parameters
- type, code, srcip, destip, encaphdrver, encapproto, encapsrcip, encapdestip
- Explanation
- An ICMP error message encapsulated a message with the incompatible IP version encaphdrver.
- Gateway Action
- Drop
- Action Description
- None
- Proposed Action
- This packet is severely broken. If the packet sender is one of your network devices, investigate why the unit is sending malformed
packets. This log message can be disabled by the IPSettings:LayerSizeConsistency setting.
2.21.6. [ID: 134] ICMP error with incompatible IP version
- Log Categories
- ICMP,STATELESS,VALIDATE
- Log Message
- ICMP error with incompatible IP version.
- Default Log Severity
- Warning
- Parameters
- type, code, srcip, destip, encaphdrver, encapproto, encapsrcip, encapdestip
- Explanation
- An ICMP error message encapsulated a message with the incompatible IP version encaphdrver.
- Gateway Action
- Drop
- Action Description
- None
- Proposed Action
- This packet is severely broken. If the packet sender is one of your network devices, investigate why the unit is sending malformed
packets. This log message can be disabled by the IPSettings:LayerSizeConsistency setting.
2.21.7. [ID: 600] ICMP error to fragment
- Log Categories
- ICMP,STATELESS,VALIDATE
- Log Message
- ICMP error to fragment.
- Default Log Severity
- Warning
- Parameters
- type, code, srcip, destip, encapproto, encapsrcip, encapdestip, encapfragid, encapfragoff
- Explanation
- An ICMP error message encapsulated a non-first IP fragment. Encapsulated non-first fragments are dropped since the protocol
specific information required for forwarding does not exist.
- Gateway Action
- Drop
- Action Description
- None
- Proposed Action
- This packet is severely broken. If the packet sender is one of your network devices, investigate why the unit is sending malformed
packets. This log message can be disabled by the IPSettings:LayerSizeConsistency setting.
2.21.8. [ID: 296] Truncated embedded IP header in ICMPv4
- Log Categories
- ICMP,STATELESS,VALIDATE
- Log Message
- Truncated embedded IP header in ICMPv4.
- Default Log Severity
- Warning
- Parameters
- type, code, srcip, destip, paylen, encaphdrver, encaphdrlen
- Explanation
- An ICMP error message did not carry enough data to contain information required to forward the packet. The encapsulated IPv4
header was larger than an ordinary IPv4 header, and the ICMP error did not encapsulate the whole header.
- Gateway Action
- Drop
- Action Description
- None
- Proposed Action
- This packet is severely broken. If the packet sender is one of your network devices, investigate why the unit is sending malformed
packets. This log message can be disabled by the IPSettings:LayerSizeConsistency setting.
2.21.9. [ID: 476] Dropped ICMP error message
- Log Categories
- ICMP,VALIDATE,STATEFUL
- Log Message
- Dropped ICMP error message.
- Default Log Severity
- Warning
- Parameters
- type, code, srcip, destip, flow, rule, user, userid
- Explanation
- An ICMP error of type type and code code has been received by flow flow, but this ICMP error type is prohibited by the configuration.
- Gateway Action
- Drop
- Action Description
- None
- Proposed Action
- If you think the current behavior is incorrect, modify rule rule to use a service with an appropriate ICMP error filter.
2.21.10. [ID: 221] ICMP error to ICMP error
- Log Categories
- ICMP,STATELESS,VALIDATE
- Log Message
- ICMP error to ICMP error.
- Default Log Severity
- Warning
- Parameters
- type, code, srcip, destip, encaptype, encapcode, encapsrcip, encapdestip
- Explanation
- An ICMP error message was received, encapsulating another ICMP error. This is illegal according to RFC 792 (ICMPv4 spec) and
RFC 2463 (ICMPv6 spec) because of the potential to cause a never-ending loop.
- Gateway Action
- Drop
- Action Description
- None
- Proposed Action
- Try to locate the node producing these errors, and see if it can be upgraded or replaced.
2.21.11. [ID: 376] Data in request differs from last request
- Log Categories
- ICMP,STATEFUL,VALIDATE
- Log Message
- Data in request differs from last request.
- Default Log Severity
- Information
- Parameters
- seqno, flow, pkt, user, userid
- Explanation
- The last seen ICMP ECHO REQUEST message did not contain the same data as the previous request message. This is legal but unexpected;
"ping" requests are generally using statically defined data to test various network conditions. Some utilities will routinely
use the first 8 bytes to contain a timestamp, so any change in the first 8 bytes since the last request have been ignored.
- Gateway Action
- Allow
- Action Description
- None
- Proposed Action
- The setting ICMPSettings:ICMP_DataTrack can be updated in order to modify how the firewall behaves with regards to the contents of the ICMP ECHO payload. Setting
it to anything but "Ignore" will cause the firewall to inspect the entire payload of the ICMP packet and report when a difference
has been detected between request and reply. This is mostly intended to aid tracking down some very special network anomalies.
This event may be a false positive if a "flood ping" utility has been used (sending requests faster than replies are being
received). In rare cases this can be a sign of hardware malfunction somewhere in the network, and in equally rare cases this
may be an attempt to relay "secret" data using the ICMP "ping" protocol; Check the sender and destination to see if the traffic
is legal. How to track down the kind of hardware malfunction that can give these symptoms is out of scope for this text, but
as much can be said that the network hardware handles data as changes between ones and zeroes. Problems are more likely to
arise with very few changes during a transfer (mostly ones or zeroes) or lots of changes (alternating ones and zeroes), so
the suggestion would be to begin testing these bit-patterns.
2.21.12. [ID: 286] Data in request differs from last request
- Log Categories
- ICMP,STATEFUL,VALIDATE
- Log Message
- Data in request differs from last request.
- Default Log Severity
- Warning
- Parameters
- seqno, flow, pkt, user, userid
- Explanation
- The last seen ICMP ECHO REQUEST message did not contain the same data as the previous request message. This is legal but unexpected;
"ping" requests are generally using statically defined data to test various network conditions. Some utilities will routinely
use the first 8 bytes to contain a timestamp, so any change in the first 8 bytes since the last request have been ignored.
- Gateway Action
- Drop
- Action Description
- None
- Proposed Action
- The setting ICMPSettings:ICMP_DataTrack can be updated in order to modify how the firewall behaves with regards to the contents of the ICMP ECHO payload. Setting
it to anything but "Ignore" will cause the firewall to inspect the entire payload of the ICMP packet and report when a difference
has been detected between request and reply. This is mostly intended to aid tracking down some very special network anomalies.
This event may be a false positive if a "flood ping" utility has been used (sending requests faster than replies are being
received). In rare cases this can be a sign of hardware malfunction somewhere in the network, and in equally rare cases this
may be an attempt to relay "secret" data using the ICMP "ping" protocol; Check the sender and destination to see if the traffic
is legal. How to track down the kind of hardware malfunction that can give these symptoms is out of scope for this text, but
as much can be said that the network hardware handles data as changes between ones and zeroes. Problems are more likely to
arise with very few changes during a transfer (mostly ones or zeroes) or lots of changes (alternating ones and zeroes), so
the suggestion would be to begin testing these bit-patterns.
2.21.13. [ID: 426] Invalid ICMP type
- Log Categories
- ICMP,STATELESS,VALIDATE
- Log Message
- Invalid ICMP type.
- Default Log Severity
- Warning
- Parameters
- type, code, pkt
- Explanation
- An ICMP message that is not allowed to setup stateful connections, tried to setup a stateful connection. The ICMP message
in itself was allowed by the ruleset, but this particular message does not make sense to handle in a stateful manner.
- Gateway Action
- Drop
- Action Description
- None
- Proposed Action
- A rule to setup a stateful connection is apparently using a service that is not intended to handle a stateful connection.
Either revise the ruleset, or split the used service in two: One for stateful traffic and one for traffic that is not stateful
(allow, NAT and SAT rules are stateful, "fast forward" is non-stateful).
2.21.14. [ID: 496] Mismatching ICMP reply data
- Log Categories
- ICMP,STATEFUL,VALIDATE
- Log Message
- Mismatching ICMP reply data.
- Default Log Severity
- Notice
- Parameters
- seqno, flow, pkt, user, userid
- Explanation
- A received ICMP ECHO REPLY message did not contain the same data as the corresponding ICMP ECHO REQUEST message. This is not
in compliance with the ICMP "ping" protocol.
- Gateway Action
- Allow
- Action Description
- None
- Proposed Action
- The setting ICMPSettings:ICMP_DataTrack can be updated in order to modify how the firewall behaves with regards to the contents of the ICMP ECHO payload. Setting
it to anything but "Ignore" will cause the firewall to inspect the entire payload of the ICMP packet and report when a difference
has been detected between request and reply. This is mostly intended to aid tracking down some very special network anomalies.
This event may be a false positive if a "flood ping" utility has been used (sending requests faster than replies are being
received). In rare cases this can be a sign of hardware malfunction somewhere in the network, and in equally rare cases this
may be an attempt to relay "secret" data using the ICMP "ping" protocol; Check the sender and destination to see if the traffic
is legal. How to track down the kind of hardware malfunction that can give these symptoms is out of scope for this text, but
as much can be said that the network hardware handles data as changes between ones and zeroes. Problems are more likely to
arise with very few changes during a transfer (mostly ones or zeroes) or lots of changes (alternating ones and zeroes), so
the suggestion would be to begin testing these bit-patterns.
2.21.15. [ID: 555] Mismatching ICMP reply data
- Log Categories
- ICMP,STATEFUL,VALIDATE
- Log Message
- Mismatching ICMP reply data.
- Default Log Severity
- Warning
- Parameters
- seqno, flow, pkt, user, userid
- Explanation
- A received ICMP ECHO REPLY message did not contain the same data as the corresponding ICMP ECHO REQUEST message. This is not
in compliance with the ICMP "ping" protocol.
- Gateway Action
- Drop
- Action Description
- None
- Proposed Action
- The setting ICMPSettings:ICMP_DataTrack can be updated in order to modify how the firewall behaves with regards to the contents of the ICMP ECHO payload. Setting
it to anything but "Ignore" will cause the firewall to inspect the entire payload of the ICMP packet and report when a difference
has been detected between request and reply. This is mostly intended to aid tracking down some very special network anomalies.
This event may be a false positive if a "flood ping" utility has been used (sending requests faster than replies are being
received). In rare cases this can be a sign of hardware malfunction somewhere in the network, and in equally rare cases this
may be an attempt to relay "secret" data using the ICMP "ping" protocol; Check the sender and destination to see if the traffic
is legal. How to track down the kind of hardware malfunction that can give these symptoms is out of scope for this text, but
as much can be said that the network hardware handles data as changes between ones and zeroes. Problems are more likely to
arise with very few changes during a transfer (mostly ones or zeroes) or lots of changes (alternating ones and zeroes), so
the suggestion would be to begin testing these bit-patterns.
2.21.16. [ID: 1504] ICMP error response to multicast
- Log Categories
- ICMP,STATELESS,VALIDATE
- Log Message
- ICMP error response to multicast.
- Default Log Severity
- Warning
- Parameters
- type, code, srcip, destip, encaphdrver, encapproto, encapsrcip, encapdestip
- Explanation
- An ICMP error was made in response to a multicast message, or used an otherwise illegal combination of multicast and ICMP.
Historically this has been used for amplification attacks, but is more frequently caused by devices misbehaving when exposed
to multicast traffic.
- Gateway Action
- Drop
- Action Description
- None
- Proposed Action
- If this is a reoccurring issue, try to track down the sender of the ICMP error. The log message can also be disabled by IPSettings:LayerSizeConsistency, but even if there is no underlying malicious attempt, remember that software producing these messages may also be susceptible
for the associated amplification attacks.
2.21.17. [ID: 1503] ICMP error response to multicast
- Log Categories
- ICMP,STATELESS,VALIDATE
- Log Message
- ICMP error response to multicast.
- Default Log Severity
- Notice
- Parameters
- type, code, srcip, destip, encaphdrver, encapproto, encapsrcip, encapdestip
- Explanation
- An ICMP error was made in response to a multicast message. Normally this is illegal, albeit this particular case this is considered
legal. By nature it is a multicast reply, and needs tight control; without, it is a possible vector for amplification "attacks"
against the multicast source.
- Gateway Action
- Allow
- Action Description
- None
- Proposed Action
- Normally nothing needs to be done. ICMP errors are rate limited with ICMPSettings:ICMPErrorPerSecLimit, ICMPSettings:ICMPMaxErrorsPerRule and ICMPSettings:ICMPMaxErrorsPerFlow. In some scenarios, blocking specific ICMP error messages may be an option: Consider using a more restrictive service and
review the ICMP settings, in particular ICMPSettings:IP6PacketTooBig. This log message can be completely disabled by IPSettings:LayerSizeConsistency, but this will also disable many log messages that are of a more severe nature.
2.21.18. [ID: 301] Sequence number in reply is outside expected[...]
- Log Categories
- ICMP,STATEFUL,VALIDATE
- Log Message
- Sequence number in reply is outside expected range.
- Default Log Severity
- Notice
- Parameters
- min, max, seqno, flow, user, userid
- Explanation
- An ICMP reply had a sequence number outside the current window of expected sequence numbers. The sequence number seqno is below the lower bound min of the sequence window. This may occur if a stray message following a less efficient route or a duplicate message.
- Gateway Action
- Allow
- Action Description
- None
- Proposed Action
- When duplicate messages show up and/or messages are received out-of-order in abundance, the network should be examined for
broken hardware or misconfigured equipment. Note that wireless networks often produce this kind of anomalies even when they
are fully functional. The ICMPSettings:ICMP_SeqNoTrack setting can be changed to control the gateway's behavior regarding packets received out-of-order.
2.21.19. [ID: 273] Sequence number in reply is outside expected[...]
- Log Categories
- ICMP,STATEFUL,VALIDATE
- Log Message
- Sequence number in reply is outside expected range.
- Default Log Severity
- Warning
- Parameters
- min, max, seqno, flow, user, userid
- Explanation
- An ICMP reply had a sequence number outside the current window of expected sequence numbers. The sequence number seqno is below the lower bound min of the sequence window. This may occur if a stray message following a less efficient route or a duplicate message.
- Gateway Action
- Drop
- Action Description
- None
- Proposed Action
- When duplicate messages show up and/or messages are received out-of-order in abundance, the network should be examined for
broken hardware or misconfigured equipment. Note that wireless networks often produce this kind of anomalies even when they
are fully functional. The ICMPSettings:ICMP_SeqNoTrack setting can be changed to control the gateway's behavior regarding packets received out-of-order.
2.21.20. [ID: 288] Problem pointer outside of data
- Log Categories
- ICMP,STATELESS,VALIDATE
- Log Message
- Problem pointer outside of data.
- Default Log Severity
- Warning
- Parameters
- srcip, destip, paylen, encapproto, encapsrcip, encapdestip, encappaylen, ptr
- Explanation
- An ICMP "parameter problem" error message was received, but the "problem pointer" inside the error message did not point at
any data contained in the packet.
- Gateway Action
- Drop
- Action Description
- None
- Proposed Action
- This packet is severely broken. If the packet sender is one of your network devices, investigate why the unit is sending malformed
packets. This log message can be disabled by the IPSettings:LayerSizeConsistency setting.
2.21.21. [ID: 507] Problem pointer outside of data
- Log Categories
- ICMP,STATELESS,VALIDATE
- Log Message
- Problem pointer outside of data.
- Default Log Severity
- Warning
- Parameters
- type, code, srcip, destip, paylen, encapproto, encapsrcip, encapdestip, encappaylen, ptr
- Explanation
- An ICMP "parameter problem" error message was received, but the "problem pointer" inside the error message did not point at
any data contained in the packet.
- Gateway Action
- Drop
- Action Description
- None
- Proposed Action
- This packet is severely broken. If the packet sender is one of your network devices, investigate why the unit is sending malformed
packets. This log message can be disabled by the IPSettings:LayerSizeConsistency setting.
2.21.22. [ID: 612] Header length parameter problem
- Log Categories
- ICMP,STATELESS,VALIDATE
- Log Message
- Header length parameter problem.
- Default Log Severity
- Warning
- Parameters
- type, code, srcip, destip, paylen, encaphdrver, encaphdrlen, encappaylen
- Explanation
- An ICMP "parameter problem" message was received, pointing at the encapsulated IP headers length, total payload or possibly
using the general "header length error" code. It appears as if the original packets IPv4 header was too large to be fully
contained inside the original message itself. While this may be a legal ICMP error, the information needed to forward this
packet was never even present in the original packet, and the firewall cannot forward it in an easy way.
- Gateway Action
- Drop
- Action Description
- None
- Proposed Action
- The encapsulated message inside the ICMP error is horribly broken. Judging from the information contained in the ICMP error,
the node at srcip is the one that discovered the broken packet. The rest of the information is not reliable. Examine why this broken packet
have been sent in the first place. If you need to forward this ICMP error, you need to setup a stateless ICMP rule that explicitly
forwards it to its destination destip. You will also need to set the ICMPSettings:ICMPErrorPerSecToSPLimit to a non-null value. This log message itself can be disabled with the IPSettings:LayerSizeConsistency setting.
2.21.23. [ID: 164] IP header version parameter problem
- Log Categories
- ICMP,STATELESS,VALIDATE
- Log Message
- IP header version parameter problem.
- Default Log Severity
- Notice
- Parameters
- type, code, hdrver, srcip, destip, encaphdrver, encapproto, encapsrcip, encapdestip
- Explanation
- An ICMP "parameter problem" message was received, pointing at the encapsulated IP headers version. It appears as if an IP
version hdrver only node is receiving IP traffic of version encaphdrver. While this may be a legal packet, the information needed to forward this packet is incompatible with the module that forwarded
the original IP version encaphdrver packet, and the firewall cannot forward it in an easy way.
- Gateway Action
- None
- Action Description
- None
- Proposed Action
- Examine why IP version encaphdrver traffic is routed to the IP hdrver only node. If possible, upgrade or block IP version encaphdrver traffic to the node. If you need to forward this ICMP error, you need to setup a stateless ICMP rule that explicitly forwards
it to its destination destip. You will also need to set the ICMPSettings:ICMPErrorPerSecToSPLimit to a non-null value. This log message itself can be disabled with the IPSettings:LayerSizeConsistency setting.
2.21.24. [ID: 807] Failed to allocate reassembly buffer
- Log Categories
- ICMP,FRAG
- Log Message
- Failed to allocate reassembly buffer.
- Default Log Severity
- Warning
- Parameters
- pktlen, pkt
- Explanation
- The received packet was fragmented and could not be reassembled because there were no free buffers available to hold the reassembled
packet.
- Gateway Action
- Drop
- Action Description
- None
- Proposed Action
- None
2.21.25. [ID: 805] Reassembled packet exceeds allowed size
- Log Categories
- ICMP,FRAG
- Log Message
- Reassembled packet exceeds allowed size.
- Default Log Severity
- Warning
- Parameters
- maxlen, pkt
- Explanation
- The packet was fragmented and could not be reassembled because it exceeded the maximum allowed size.
- Gateway Action
- Drop
- Action Description
- None
- Proposed Action
- The FragSettings:LocalReass_MaxSize can be used to change the maximum allowed size for locally reassembled packets.
2.21.26. [ID: 806] Failed to reassemble packet
- Log Categories
- ICMP,FRAG
- Log Message
- Failed to reassemble packet.
- Default Log Severity
- Error
- Parameters
- pktlen, pkt
- Explanation
- The packet was fragmented and could not be reassembled.
- Gateway Action
- Drop
- Action Description
- None
- Proposed Action
- None
2.21.27. [ID: 533] Received ICMP error message
- Log Categories
- ICMP,VALIDATE,STATEFUL
- Log Message
- Received ICMP error message.
- Default Log Severity
- Notice
- Parameters
- type, code, srcip, destip, flow, rule, user, userid
- Explanation
- An ICMP error of type type and code code has been received by flow flow.
- Gateway Action
- Allow
- Action Description
- None
- Proposed Action
- If you think the current behavior is incorrect, modify rule rule to use a service with an appropriate ICMP error filter.
2.21.28. [ID: 553] Sequence number in reply is above expected[...]
- Log Categories
- ICMP,STATEFUL,VALIDATE
- Log Message
- Sequence number in reply is above expected window.
- Default Log Severity
- Notice
- Parameters
- min, max, seqno, flow, user, userid
- Explanation
- An ICMP reply had a sequence number above the current window of expected sequence numbers. The sequence number seqno is higher than the maximum value max in the sequence window (and at the same time closer to max than to the lower bound min of the window). Therefore this looks like an illegal reply to a message that hasn't been sent.
- Gateway Action
- Allow
- Action Description
- None
- Proposed Action
- When duplicate messages show up and/or messages are received out-of-order in abundance, the network should be examined for
broken hardware or misconfigured equipment. Note that wireless networks often produce this kind of anomalies even when they
are fully functional. The ICMPSettings:ICMP_SeqNoTrack setting can be changed to control the gateway's behavior regarding packets received out-of-order.
2.21.29. [ID: 422] Sequence number in reply is above expected[...]
- Log Categories
- ICMP,STATEFUL,VALIDATE
- Log Message
- Sequence number in reply is above expected window.
- Default Log Severity
- Warning
- Parameters
- min, max, seqno, flow, user, userid
- Explanation
- An ICMP reply had a sequence number above the current window of expected sequence numbers. The sequence number seqno is higher than the maximum value max in the sequence window (and at the same time closer to max than to the lower bound min of the window). Therefore this looks like an illegal reply to a message that hasn't been sent.
- Gateway Action
- Drop
- Action Description
- None
- Proposed Action
- When duplicate messages show up and/or messages are received out-of-order in abundance, the network should be examined for
broken hardware or misconfigured equipment. Note that wireless networks often produce this kind of anomalies even when they
are fully functional. The ICMPSettings:ICMP_SeqNoTrack setting can be changed to control the gateway's behavior regarding packets received out-of-order.
2.21.30. [ID: 513] Sequence number in request is decreasing
- Log Categories
- ICMP,STATEFUL,VALIDATE
- Log Message
- Sequence number in request is decreasing.
- Default Log Severity
- Information
- Parameters
- min, max, seqno, flow, user, userid
- Explanation
- The sequence numbers in ICMP requests are expected to be monotonically increasing. In this case the sequence number is lower
than (or equal to) the highest sequence number max previously seen in the flow flow. While this is legal, it is still an odd and unexpected behavior. The most likely background is simply that the ICMP session
has been restarted, but this can also be a sign of network disturbances.
- Gateway Action
- Allow
- Action Description
- None
- Proposed Action
- The ICMPSettings:ICMP_SeqNoTrack setting can be changed to control the gateway's behavior regarding packets received out-of-order.
2.21.31. [ID: 143] Sequence number in request is decreasing
- Log Categories
- ICMP,STATEFUL,VALIDATE
- Log Message
- Sequence number in request is decreasing.
- Default Log Severity
- Warning
- Parameters
- min, max, seqno, flow, user, userid
- Explanation
- The sequence numbers in ICMP requests are expected to be monotonically increasing. In this case the sequence number is lower
than (or equal to) the highest sequence number max previously seen in the flow flow. While this is legal, it is still an odd and unexpected behavior. The most likely background is simply that the ICMP session
has been restarted, but this can also be a sign of network disturbances.
- Gateway Action
- Drop
- Action Description
- None
- Proposed Action
- The ICMPSettings:ICMP_SeqNoTrack setting can be changed to control the gateway's behavior regarding packets received out-of-order.
2.21.32. [ID: 232] Truncated ICMPv4 payload
- Log Categories
- ICMP,STATELESS,VALIDATE
- Log Message
- Truncated ICMPv4 payload.
- Default Log Severity
- Warning
- Parameters
- type, code, srcip, destip, paylen
- Explanation
- An ICMPv4 error message did not carry enough data to encapsulate an IPv4 header.
- Gateway Action
- Drop
- Action Description
- None
- Proposed Action
- This packet is severely broken. If the packet sender is one of your network devices, investigate why the unit is sending malformed
packets. This log message can be disabled by the IPSettings:LayerSizeConsistency setting.
2.21.33. [ID: 497] Truncated ICMPv6 payload
- Log Categories
- ICMP,IPV6,STATELESS,VALIDATE
- Log Message
- Truncated ICMPv6 payload.
- Default Log Severity
- Warning
- Parameters
- type, code, srcip, destip, paylen
- Explanation
- An ICMPv6 error message did not carry enough data to encapsulate an IPv6 header.
- Gateway Action
- Drop
- Action Description
- None
- Proposed Action
- This packet is severely broken. If the packet sender is one of your network devices, investigate why the unit is sending malformed
packets. This log message can be disabled by the IPSettings:LayerSizeConsistency setting.
2.21.34. [ID: 536] ICMP error with truncated payload
- Log Categories
- ICMP,STATELESS,VALIDATE
- Log Message
- ICMP error with truncated payload.
- Default Log Severity
- Warning
- Parameters
- type, code, srcip, destip, paylen, encapproto, encapsrcip, encapdestip
- Explanation
- An ICMP error message did not carry enough data to encapsulate a minimal L4 header. The packet has been dropped since the
protocol specific information required for forwarding does not exist.
- Gateway Action
- Drop
- Action Description
- None
- Proposed Action
- This packet is severely broken. If the packet sender is one of your network devices, investigate why the unit is sending malformed
packets. This log message can be disabled by the IPSettings:LayerSizeConsistency setting.
cOS Stream 4.00.03 Log Reference Guide
