IM Inspection rule and IM map

[WILLIAM STEGMAN]

I'm having a problem with vpn traffic that terminates on my ASA version 7.2(1)4

As soon as I turn on a IM inspection rule and configure an IM map to log only, the vpn traffic seems to pass, but while connecting via rdp I get an error "Because of an error in data encryption..." and am then kicked out of my terminal services session. Outlook exhibits similar behavior in that I can make the connection and open outlook, but no message are sent or received. Has anyone seem similar behavior?

thank you,

Bill

some additional info, I ran a capture type asp drop all command and found this in the output

718: 16:29:06.663051 10.4.0.13.3389 > 192.168.8.143.2435: P 1032939902:1032939922(20) ack 1093516375 win 64819

10.4.0.13 is the server I'm trying to rdp into and 192.168.8.143 is my address while connected via vpn. Also ran sh asp drop after first clearing the stats and get this, however I'm not sure if the 2 can be tied together to see where my traffic from 10.4.0.13 is being dropped to 192.168.8.143

Frame drop:

Reverse-path verify failed 302

Flow is denied by configured rule 1911

NAT-T keepalive message 361

First TCP packet not SYN 880

TCP failed 3 way handshake 16

TCP RST/FIN out of order 2

TCP packet SEQ past window 144

TCP Out-of-0rder packet buffer full 396

TCP Out-of-Order packet buffer timeout 73

TCP RST/SYN in window 3

TCP DUP and has been ACKed 480

IPSEC tunnel is down 7

DNS Inspect id not matched 16

[fmeetz]

use VPN filter to rectify this:

A vpn-filter is applied to post-decrypted traffic after it exits a tunnel and pre-encrypted traffic before it enters a tunnel. When a

vpn-filter is applied to a group-policy that governs Remote Access VPN client connections, the ACL should be configured with the client assigned IP addresses in the "src_ip" position of the ACL and the local network in the

"dest_ip" position of the ACL. When a vpn-filter is applied to a group-policy that governs a LAN to LAN VPN connection, the ACL should be configured with the remote network in the "src_ip" position of the ACL and the local network in the "dest_ip" position of the ACL. Caution should be exercised when constructing the ACLs for use with the vpn-filter feature.

The ACLs are constructed with the post-decrypted traffic in mind, however, they are also applied to the traffic in the opposite direction. For this pre-encrypted traffic that is destined for the tunnel, the ACLs are constructed with the "src_ip" and "dest_ip" positions swapped.

Try this link:

http://www.cisco.com/en/US/products/ps6120/products_command_reference_chapter09186a00805fd7f7.html#wp1281154

[WILLIAM STEGMAN]

Interesting work around, but I guess this is a bug? Traffic shouldn't get dropped because of an IM inspection map. I do remember a syslog message once about the length of packets being too long. Is there a way I can look a bit deeper into the cause of that message?

thx