In my scenario, there are no site to site terminations. Both sides are simply configured with a dynamic crypto map.The problem is when a client (presumably only the first client), tries to issue a connection through the RTRA. What happens is the isakmp (500) and udp-encap (4500) is sourced and destined for those corresponding ports. Since there are no PAT translations, similar to this the router preserves the source UDP ports. The return traffic is destined to udp/500 and udp/4500. So it appears that the crypto in the RTRA, listening on those ports, intercepts the traffic.
I'm going to play with some things tonight. One thought that seems far fetched is that since the ASA and RTRA have the same psk, that somehow the ASA is actually building a phase 1 SA back to RTRA (since its outside interface is the PAT address and the ASA is definitely building a good SA). The other thought I have is statically creating 2 pat entries to source the 500 and 4500 udp packets from a different port. This has just got my curiosity. On Fri, Jan 8, 2010 at 2:46 AM, Kingsley Charles <[email protected]> wrote: > Hi Paul > > I am not clear on your site to site VPN terminations. But you have asked, > how do we enable both site to site VPN and PAT on the same interface. > > The PAT will affect only the outgoing VPN connections not the incoming. > > Hence we can configure the access-list that is associated with the NAT rule > to deny the VPN traffic first and then "permit ip any any". We can also use > route-maps with NAT rule to do the same. > > > > With regards > Kings > > On Fri, Jan 8, 2010 at 7:21 AM, Paul Stewart <[email protected]> wrote: >> >> This seems like something I should know how to work around. I have >> the following lab configuration >> >> WinXP <----> RTRA <-----> ASA <----> RTRB (just to ping) >> >> I can connect to the ASA via L2TP/IPSEC. This also works with NAT >> enabled on the router (using UDP/4500). However, when I enable a >> crypto MAP on the router, I can no longer connect via L2TP/IPSEC. I >> get an error like the following. >> >> *Jan 6 13:15:55.219: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC >> packet has invalid spi for destaddr=1.1.1.2, prot=50, >> spi=0x30B03570(816854384), srcaddr=1.1.1.1 >> >> 1.1.1.2 is the IP Address of RTRA >> 1.1.1.1 is the IP Address of the ASA >> >> I am NATTING the pc to 1.1.1.2 in an overload manner. When I apply a >> crypto map to RTRA's interface with an IP address of 1.1.1.2. Things >> no longer work. I can see that the NAT translation are source and >> destined to UDP/500 and UDP/4500 and from the above error, my >> conclusion is that ther router thinks these incoming packets are meant >> for it and not the PC it is natting for. If I change my PAT to >> 1.1.1.5, an IP address not bound to the interface with the crypto, >> things begin working again. >> >> So my question is how do we PAT on and address that is also listening >> for ISAKMP/UDPENCAP/ESP sessions? The interesting thing is this seems >> to work if I enable L2TP on the RTRA and PAT through the ASA. Or >> should we just always PAT to an address that is not listening for VPN >> sessions. >> _______________________________________________ >> For more information regarding industry leading CCIE Lab training, please >> visit www.ipexpert.com > > _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
