Citrix ADC ICMP Counters

This article contains information about the newnslog Internet Control Message Protocol (ICMP) counters and its brief description.

Using the Counters

Log on to the ADC using an SSH client, change to SHELL, navigate to the /var/nslog directory, and then use the ‘nsconmsg’ command to see comprehensive statistics using the different counters available. For the detailed procedure refer to Citrix Blog – NetScaler ‘Counters’ Grab-Bag!.

The newnslog ICMP counters

The following table lists the newnslog ICMP counters with a simple description of the counter.

newnslog Counter

Description

icmp_cur_ratethreshold

This counter tracks the limit for ICMP packets handled every 10 milliseconds. Default value is 0 and has no limit.

This is a configurable value using the set rateControl command.

icmp_tot_rxpkts

This counter tracks the ICMP packets received.

icmp_tot_rxbytes

This counter tracks the bytes of ICMP data received.

icmp_tot_txpkts

This counter tracks the ICMP packets transmitted.

icmp_tot_txbytes

This counter tracks the bytes of ICMP data transmitted.

icmp_tot_rxEchoReply

This counter tracks the ICMP Ping echo replies received.

icmp_tot_txEchoReply

This counter tracks the ICMP Ping echo replies transmitted.

icmp_tot_rxEcho

This counter tracks the ICMP Ping Echo Request and Echo Reply packets received.

icmp_port_unreach

This counter tracks the ICMP Port Unreachable error messages received. This error is generated when there is no service running on the port.

icmpgen_port_unreach

This counter tracks the ICMP Port Unreachable error messages generated. This error is generated when there is no service running on the port.

icmp_unreach_needfrag

This counter tracks the ICMP Fragmentation Needed error messages received for packets that must be fragmented but Don’t Fragment is specified in the header.

icmp_err_threshold

This counter increment when the ICMP rate threshold is exceeded. If this counter continuously increases, then you must first ensure that the ICMP packets received are genuine. If they are genuine, then you must increase the current rate threshold.

icmp_err_dropped

This counter tracks the ICMP packets dropped when the rate threshold is exceeded.

icmp_err_badchecksums

This counter tracks the ICMP Fragmentation Needed error messages received with an ICMP checksum error.

icmp_err_pmtu_dfonfrag

This counter tracks the ICMP Fragmentation Needed error messages received that were generated by an IP fragment other than the first one.

icmp_err_pmtu_invalbodylen

This counter tracks the ICMP Fragmentation Needed error messages received that specified an invalid body length.

icmp_err_pmtu_notcpconn

This counter tracks the ICMP Need Fragmentation error messages received for TCP packets. The state of the connection for these packets is not maintained on the NetScaler appliance.

icmp_err_pmtu_noudpconn

This counter tracks the ICMP Need Fragmentation error messages received for UDP packets. The state of the connection for these packets is not maintained on the NetScaler appliance.

icmp_err_pmtu_invalseqno

This counter tracks the ICMP Fragmentation Needed error messages received for packets that contain an invalid TCP address.

icmp_err_nextmtu_inval

This counter tracks the ICMP Fragmentation Needed error messages received in which the Maximum Transmission Unit (MTU) for the next hop is out of range. The range for the MTU is 576-1500.

icmp_err_mtulkup

This counter tracks the total number of MTU lookup on destination IP address information received on a Need Fragmentation ICMP error message failed.

icmp_err_bignxtmtu

This counter tracks the ICMP Fragmentation Needed error messages received in which the value for the next MTU is higher than that of the current MTU.

icmp_err_pmtu_unknownproto

This counter tracks the ICMP Fragmentation Needed error messages received that contain a protocol other than TCP and UDP.

icmp_err_pmtu_cksum

This counter tracks the ICMP Fragmentation Needed error messages received with an IP checksum error.

icmp_err_pmtu_nolink

This counter tracks the ICMP Fragmentation Needed error messages received on a Protocol Control Block (PCB) with no link. The PCB maintains the state of the connection.

icmp_err_pmtu_disabled

This counter tracks the ICMP Need Fragmentation error messages received when the PMTU Discovery mode is not enabled.

Related:

Firewall Rule Stopped Hitting

I need a solution

I am using the SEP Cloud Console, Client version 14.2.4559.1100.

I created a rule last week to block and not log all ICMP traffic (that is not explicitly allowed by a previous rule) which has been working until tuesday of this week.

Starting on tuesday I saw a high number of firewall events from “Block All IP Traffic” that is all ICMP traffic

The rule is All Applications, All Hosts, All Traffic from the following Protocol: ICMP, All Adapters, and All the time.

0

Related:

NetScaler Unified Gateway Advanced Authorization Policy Support for UDP/ICMP/DNS Traffic

This article describes change in default behavior with Advanced Authorization policy for UDP/ICMP/DNS traffic sent through NetScaler Unified Gateway. This article is applicable to release 12.0.56.x and later.

Background

With advanced authorization policy, policy is applied on all types of traffic (TCP/UDP/ICMP/DNS) whereas with classic policies, authorization policies are only applied on TCP traffic. So, this results in default behavior change in cases when default authorization action is DENY from session action/vpn parameter. By default with authorization action set to DENY and with no additional policies, UDP/ICMP/DNS traffic is blocked.

Note: If default authorization action is ALLOW, then there is no change in behavior as all types of traffic will be allowed by default. In this scenario, advanced authorization policies provide more granular control for customers to categorically blacklist UDP/ICMP/DNS packets which was not possible with classic policies.

Traffic Behavior

The subsequent sections explain the behavior for each type of traffic.

TCP Traffic

No change in behavior. With default authorization action as DENY, all the TCP packets will be blocked at NetScaler by default. Policies needs to be added and bound to corresponding aaa users/aaa groups to categorically whitelist TCP packets.

UDP Traffic

With advanced authorization policy and default authorization action as DENY, all the UDP packets will be blocked at NetScaler by default. A new policy needs to be added and bound to corresponding aaa users/aaa groups at type UDP_REQUEST to categorically whitelist UDP packets.

For example, if customer wants to allow only the UDP traffic destined to port 2080, then corresponding config looks like below.

add authorization policy authpol CLIENT.UDP.DSTPORT.EQ(2080) ALLOW

bind aaa user user1 –policy authpol –priority 10 –type UDP_REQUEST

ICMP Traffic

With advanced authorization policy and default authorization action as DENY, all the ICMP packets will be blocked at NetScaler by default. A new policy needs to be added and bound to corresponding aaa users/aaa groups at type ICMP_REQUEST to categorically whitelist ICMP packets.

For example, if customer wants to allow ICMP traffic, then corresponding config looks like below.

add authorization policy authpol CLIENT.IP.PROTOCOL.EQ(ICMP) ALLOW

bind aaa user user1 –policy authpol –priority 10 –type ICMP_REQUEST

DNS Traffic

By default, DNS based advanced authorization policies are only applicable to DNS records other than of type ‘A’/’AAAA’. In order to apply this for all types of DNS records, customer needs to run the command “nsapimgr -ys enable_vpn_dnstruncate_fix=1” from NetScaler shell. Please note that nsapimgr command by default does not survive a reboot. To make the command persistent across reboots, configure the same command in the file rc.netscaler under /nsconfig. If rc.netscaler does not exist, then create one and add the command.

with default authorization action DENY, all the applicable DNS record types (as mentioned in the previous paragraph) will be blocked at NetScaler by default. A new policy needs to be added and bound to corresponding aaa users/aaa groups at type DNS_REQUEST to categorically whitelist DNS packets.

For example, if customer wants to allow only the DNS packets that are destined for domains containing keyword “citrix”, then corresponding config looks like below:

add authorization policy authpol CLIENT.UDP.DNS.DOMAIN.CONTAINS(“citrix”) ALLOW

bind aaa user user1 –policy authpol –priority 10 –type DNS_REQUEST

Note: If there are no authorization policies bound, then type of authorization policy is considered as Advanced. If customer’s config has no authorization policies and the box is upgraded, then all the new behavior changes mentioned here will be applicable.

Related:

ISA Server detected a ping-of-death attack from Internet Protocol (IP) address %1.

Details
Product: Internet Security and Acceleration Server
Event ID: 15107
Source: ISA Server H.323 Filter
Version: 4.0.3443.594
Component: ISA Server Services
Message: ISA Server detected a ping-of-death attack from Internet Protocol (IP) address %1.
   
Explanation
A possible ping-of-death attack was attempted against a computer protected by ISA Server. This event occurs when a large amount of information is appended to an Internet Control Message Protocol (ICMP) echo request (ping) packet. If this attack is successful, the computer crashes.
   
User Action
If logging for dropped packets is enabled, you can view details of this attack in the Firewall log in the log viewer. You can use this log to monitor any further intruder activity. To do this, in the console tree of ISA Server Management, click Monitoring. In the Logging tab, edit the log filter to view the relevant details. Take additional steps against intruder activity. For example, you may want to add access rules denying traffic from the source of the intrusion. To do this, in the console tree of ISA Server Management, click Firewall Policy. On the Tasks tab, click Create Access Rule.

Related: