05-03-2012 12:22 PM
So I'm having issues getting data to come across this site to site tunnel. The remote site needs us to NAT the destination network because they have an overlap. I hope this makes sense.
Remote Endpoint - A.A.A.A
Remote LAN - 156.30.x.x
Local Endpoint - B.B.B.B
Local LAN - 10.0.202.183 which is NAT'd to 192.168.10.45 because that overlaps on their side
Details are below. Thanks for the help.
My ASA info.
tunnel-group B.B.B.B type ipsec-l2l
tunnel-group B.B.B.B ipsec-attributes
pre-shared-key *****
crypto map L2L-map 1 match address outside_1_cryptomap
crypto map L2L-map 1 set pfs
crypto map L2L-map 1 set peer B.B.B.B
crypto map L2L-map 1 set transform-set ESP-3DES-SHA
static (outside,inside) 192.168.10.45 10.0.202.183 netmask 255.255.255.255
access-list outside_1_cryptomap extended permit ip host 10.0.202.183 156.30.x.x 255.255.255.248
sho crypto ipsec sa output -
Crypto map tag: L2L-map, seq num: 1, local addr: 66.196.49.130
access-list outside_1_cryptomap extended permit ip host 10.0.202.183 156.30.x.x 255.255.255.248
local ident (addr/mask/prot/port): (10.0.202.183/255.255.255.255/0/0)
remote ident (addr/mask/prot/port): (156.30.x.x/255.255.255.248/0/0)
current_peer: B.B.B.B
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 3483, #pkts decrypt: 3483, #pkts verify: 3483
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#send errors: 0, #recv errors: 0
local crypto endpt.: A.A.A.A, remote crypto endpt.: B.B.B.B
path mtu 1500, ipsec overhead 58, media mtu 1500
current outbound spi: 166C0F34
current inbound spi : 0002F40E
inbound esp sas:
spi: 0x0002F40E (193550)
transform: esp-3des esp-sha-hmac no compression
in use settings ={L2L, Tunnel, PFS Group 2, }
slot: 0, conn_id: 21278720, crypto-map: L2L-map
sa timing: remaining key lifetime (kB/sec): (8210/10842)
IV size: 8 bytes
replay detection support: Y
Anti replay bitmap:
0xFFFFFFFF 0xFFFFFFFF
outbound esp sas:
spi: 0x166C0F34 (376180532)
transform: esp-3des esp-sha-hmac no compression
in use settings ={L2L, Tunnel, PFS Group 2, }
slot: 0, conn_id: 21278720, crypto-map: L2L-map
sa timing: remaining key lifetime (kB/sec): (8496/10842)
IV size: 8 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
sho crypto isa sa output -
5 IKE Peer: 216.203.80.118
Type : L2L Role : initiator
Rekey : no State : MM_ACTIVE
05-08-2012 03:32 PM
Mate ,
as per your descreption :
Local LAN - 10.0.202.183 which is NAT'd to 192.168.10.45
if the lan at your side is 10.0.202.183 then you should be using a nat like this :
access-list NAT_WHEN_THROUGH_VPN permit ip h 10.0.202.183 <156.30>
static (inside,outside) 192.168.10.45 access-list NAT_WHEN_THRUGH_VPN
and the crypto map should be using the translated ip address :
access-list crypto permit 192.168.10.45
i assumed that the ip on the inside is : 10.0.202.183 and the other side sees this one as 192.168.10.45 .
hope that this helps .
MOhammad.
05-09-2012 09:11 AM
That sounds about right. The remote site is trying to ping/hit 10.0.202.183 which is what I'm trying to NAT to 192.168.10.45 (server) because they have an IP conflict. I'll implement the changes you said and see what happens.
05-09-2012 11:51 AM
Hi there,
Please try this,
access−list policy−nat extended permit ip host 10.0.202.183 156.30.x.x 255.255.255.248
static (inside,outside) 10.0.255.0 access−list policy−nat
access-list outside_1_cryptomap extended permit ip 10.0.255.0 255.255.255.0 156.30.x.x 255.255.255.248
----------------------
Likewise from your remote-land's remote desitination (i.e. Local Lan) has be as follows
access-list outside_2_cryptomap extended permit ip 156.30.x.x 255.255.255.248 10.0.255.0 255.255.255.0
Hope that helps.
thanks
Rizwan Rafeek
Message was edited by: Rizwan Mohamed
05-09-2012 02:28 PM
Well I don't know if that is the same as the above person, but we'l see. Here's hoping.
05-09-2012 02:33 PM
The remote side is trying to ping 10.0.202.183 since they already have a 192.168.10.45 on another VPN tunnel. That's what I'm trying to figure out on the NAT side.
05-09-2012 04:24 PM
"they already have a 192.168.10.45 on another VPN tunnel."
If you believe this IP "192.168.10.45" already in use then, natting this IP "192.168.10.45" is no good at all.
You can find another subnet available, so lets take subnet for an example "10.0.255.0 255.255.255.0".
So, based on this subnet, I will edit my above answer.
check it out.
thanks
Rizwan Rafeek
05-24-2012 07:40 AM
Sorry, this was confusing. Basically my local lan IP that needs to be accessible over this tunnel is 192.168.10.45 and I need to translate that to 10.0.202.183 for the remote endpoint to hit because the remote endpoint has another tunnel up that is using 192.168.10.45 address. So if the remote side pings 10.0.202.183, the 192.168.10.45 server on my local lan will respond. I hope that makes sense.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide