On Sun, 2011-01-23 at 19:38 -0500, Justin M. Streiner wrote: > 2. Create a static NAT to an unused address on their outside network and > use that as the tunneled host. I have reason to believe that won't work > either.
That's typically what we do, and it works just fine if I understand you correctly. You can also policy-NAT so only access towards that specific tunnel uses this translation, falling back to some generic global otherwise. Assuming that Company A could use 192.0.2.240/28 and Company B is 198.51.100.0/24: access-list PNAT_Host_01 permit ip host 10.20.30.40 198.51.100.0 255.255.255.0 access-list PNAT_Host_02 permit ip host 192.168.1.1 198.51.100.0 255.255.255.0 access-list PNAT_Host_03 ... ... static (inside,outside) 192.0.2.240 access-list PNAT_Host_01 static (inside,outside) 192.0.2.241 access-list PNAT_Host_02 static ... ... access-list All_PNAT_Hosts permit ip 192.0.2.240 255.255.255.240 198.51.100.0 255.255.255.0 crypto map IPsec_Outside 50 match address All_PNAT_Hosts crypto map IPsec_Outside 50 ... ... > 3. Land this VPN on Company A's external router (a Cisco 2801), rather > than the ASA. That should allow them to use the NAT'd outside interface > on the firewall as a tunneled address without problems. The router might > need a code/license upgrade to handle the IPSEC, but the more I think > about it, the more this seems like the least kludgey solution. This might give you one advantage compared with 2 though; any IPsec-related problems on the ASA (e.g. incompatibility with the other end) that tears down the tunnel also tears down the Xlates, so even if the tunnel could be established instantaneously again all existing Xlates through the tunnel are dropped. -- Peter _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
