This document provides information on how to troubleshoot untranslated
packets in front of the LocalDirector.
There are no specific requirements for this document.
This document is not restricted to specific software and hardware
The information in this document was created from the devices in a
specific lab environment. All of the devices used in this document started with
a cleared (default) configuration. If your network is live, make sure that you
understand the potential impact of any command.
For more information on document conventions, refer to the
Cisco Technical Tips
Packets may be found in front of the LocalDirector with the source IP
address of the real IP address of the servers instead of the virtual address.
These packets belong to sessions opened by external clients to the
LocalDirector's virtual addresses, and they are usually packets belonging to a
normal TCP connection termination (FIN) or connection reset (RST) sequence.
Because these packets are just part of a closing session, no connectivity
issues are experienced.
This become more visible in configurations where the servers use a
private IP address, the virtual uses a public address, and the gateway is a
firewall and not a router. In this case, a message might be logged by the
firewall advising that an unexpected source IP address has been received from
the internal network.
In order to understand the reasons for this behavior, a brief
description of the LocalDirector's architecture is provided in this section.
When a client opens a connection to a virtual address, an identifier
for the flow is entered into the translation table. These entries contain all
the information about the flow in order to track it and make the necessary
manipulations to the next packets. These entries have a life cycle and when the
TCP session has come to an end, they are normally removed to avoid waste of
In practice, the LocalDirector keeps looking at the session traffic and
when it sees specific session termination packets, it removes the entries from
the translation table.
The LocalDirector removes the translation entries when it either sees a
standard connection termination (FIN) or a connection reset (RST).
In some scenarios, depending on the topology implemented, network
delays, the implemented TCP stacks, and the applications, retransmission of
some late packets of a closing session arrive to the LocalDirector when the
entry in the translation table has already been removed. In this case, the
LocalDirector bridges these packets untranslated, causing the symptoms
described at the beginning of this document.
An in-depth analysis of this situation always requires that a
simultaneous sniffer trace be taken on the front and on the back of the
LocalDirector. By backward following a TCP session that ended with an
untranslated packet, it is possible to clearly see the cause of this behavior.
Once the cause is determined, the next step is to consider whether this
is causing an issue or not. Very few packets will actually be seen in this
state, and they do not actually cause a problem beyond the possible generation
of a reset packet back to the sender. The worst case may be warning messages
logged by the firewall.
If this issue is affecting your network, these are possible solutions:
The delay command causes the the
LocalDirector to keep the translation entry for five more minutes (this value
cannot be changed) in the translation table after a standard TCP connection
termination or a connection reset have been seen. Adding this command allows
the LocalDirector to correctly translate late packets, but may consume
excessive LocalDirector resources (especially in very loaded environments).
This happens because of the increased time the translation entry must be kept
The secure command causes the LocalDirector
to block all the traffic going through the LocalDirector that do not have an
entry in the translation table. This must be considered in case the internal
servers need to contact devices beyond the LocalDirector in the local network.
A typical example might be a DNS server used by the internal servers for
reverse lookup of a client IP address requesting content.
If the gateway is a router and not a firewall, an ACL might be applied
on it to block the untranslated packets.
For more information about the delay and
secure commands, refer to the
command descriptions for the release version you are using.