A PIX 501 Version 6.3 managing an IPSec tunnel to an ASA 5510 seems to to source NAT on outgoing packets which according to its config it should leave alone. The PIX' config includes:
access-list vcservnet permit ip 10.111.1.0 255.255.255.0 192.168.1.0
255.255.255.0 access-list vcservnet permit ip 10.0.0.0 255.255.0.0 192.168.1.0 255.255.255.0 access-list vcservnet permit ip 10.0.0.0 255.255.0.0 host theasa access-list vcservnet permit ip 10.111.1.0 255.255.255.0 192.168.246.0 255.255.255.0 access-list vcservnet permit ip host 213.168.74.170 192.168.1.0 255.255.255.0 access-list vcservnet permit ip 10.0.0.0 255.255.0.0 192.168.246.0 255.255.255.0 access-list nonat permit ip 10.111.1.0 255.255.255.0 192.168.1.0 255.255.255.0 access-list nonat permit ip 10.0.0.0 255.255.0.0 192.168.1.0 255.255.255.0 access-list nonat permit ip 10.0.0.0 255.255.0.0 host theasa access-list nonat permit ip 10.111.1.0 255.255.255.0 192.168.246.0 255.255.255.0 access-list nonat permit ip host 213.168.74.170 192.168.1.0 255.255.255.0 access-list nonat permit ip 10.0.0.0 255.255.0.0 192.168.246.0 255.255.255.0 [plus more entries for other tunnels]nat (inside) 0 access-list nonat nat (inside) 1 0.0.0.0 0.0.0.0 0 0
crypto map vpnmap 10 ipsec-isakmp crypto map vpnmap 10 match address vcservnet crypto map vpnmap 10 set pfs group2 crypto map vpnmap 10 set peer theasa crypto map vpnmap 10 set transform-set esp-aes-sha esp-aes-md5
But the ASA complains:
%ASA-3-305005: No translation group found for udp src outside:thepix/1024 dst inside:192.168.1.101/1719
UDP packets to port 1719 (H.323 status) of host 192.168.1.101 (a H.323 gatekeeper) are regularly emitted by the machines connected to the inside interface of the PIX, but it would highly surprise me if the PIX itself did so. Therefore I have to assume that the packet came from an inside host and the PIX forwarded it, translating the source address to its own external address.
OTOH, with its RFC1918 destination address the packet could never have made it to the ASA over the open internet; it must have gone through the tunnel. But all the access-list entries defining the tunnel are also in the access-list for "nat 0", so any packet going into the tunnel should be exempt from NAT.
Where's the flaw in my reasoning?
Thanks, Tilman