cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1290
Views
0
Helpful
8
Replies

CISCO ASA Translate IP address on ASA to LAN IP - Access from VPN Remote partner

Hey folks.

I could use a hand.  I'm trying to setup a VPN tunnel for monitoring from a remote partner.  I'm getting the Tunnel established, but I'm having a conceptual problem.  I have internal LAN addresses that will be monitored from the remote partner.  I want to translate LAN IPs to translated addresses on the ASA that will be used for communication between our HQ and the Remote partner over the VPN.  I want the LAN IP to translate going out using the Translated IP and talking to the Remote IPs.  Then I want the Remote IPs to talk to the Translated IPs coming in and translating to the LAN IPs. I'm not quite sure how to configure NAT to accommodate my design, or if it's even possible.  I'm rusty at this and could use assistance.  Logically, this is how it looks:

LAN IP                     Translated IP                          Remote IPs

192.168.8.109 -> 192.168.71.109 ->  |Tunnel| -> 10.216.27.192/27 and\or 206.210.91.138

192.168.8.109 <- 192.168.71.109 <- |Tunnel| <- 10.216.27.192/27 and\or 206.210.91.138

Translated IPs only exist on the ASA

How would I configure my NAT?

nat (inside,outside) source static obj-192.168.8.109 obj-192.168.71.109 destination static obj-Remote-IPs obj-Remote-IPs

Would my access list source be that of my LAN IP, or the Translated IP?

Any assistance is appreciated,

Jeff

8 Replies 8

Jacob-Harris
Level 1
Level 1

Try:

nat (inside,outside) source static obj-192.168.8.109 obj-192.168.71.109 destination static obj-remotenets(10.216.27.192/27) obj-remotenets(10.216.27.192/27) description Purpose of NAT

somewhat dependant on your SW version, but any ACL's you are also apply should be applied with real IP addresses, not the natted internal ip addresses, and the normal remote address.. example

access-list inside-out extended permit tcp  obj-192.168.8.109 obj-remotenets eq domain log

Thanks Jacob.

So it looks like I'm pretty close?

I have object groups created for everything; LAN-IPs, XLATE-IPs, REMOTENET-IPs.

I assume I can nat (inside,outside) source static LAN-IPs XLATE-IPs destination static REMOTENET-IPs REMOTENET-IPs ?

And for my access-list VPN_S2S_PARTNER extended permit tcp object-group LAN-IPs object-group REMOTENET-IPs ?

If this all looks good, I'll head down the path for testing in my lab.

My lab is 8.4(2) and my production (unsupported) is 8.2(5)  Is this going to be a major problem?

Jeff,

Sorry I read your first post wrong.. when saying access list, you're referring to the crypto access list for the vpn...

This access list should be:

access-list cryptomap extended permit ip object-group XLATE-IPs object-group REMOTENET-IPs

However if you are going to apply security ACL's to limit ports etc, they need to be in this format:

access-list inside-out extended permit tcp object-group LAN-IPs object-group REMOTENET-IPs eq domain log

Can't recall if the 8.2/8.4 codes are impacted... i'm thinking it was around 8.1 that had the nat issue.. but i'm running 9.x code now.

Give it a try in your lab.

Thanks Jacob.

Looks like this is going to be an issue.  8.2 does nat differently.  I'm going to have issues with this code.  Any tips you can give me for 8.2?

Hey Jeff,

Assuming the VPN is up and you can pass interesting traffic, your nat config should look something like this:

After you test this, see if you can run a packet-tracer on the traffic you're trying to send.. this should give you good info.

object network LOCAL-192.168.8.109
 host 192.168.8.109
object network LOCAL-192.168.8.111
 host 192.168.8.111
object network LOCAL-192.168.8.113
 host 192.168.8.113
object network LOCAL-192.168.8.122
 host 192.168.8.122
 
object network LOCAL-192.168.8.109-NAT
 host 192.168.71.109
object network LOCAL-192.168.8.111-NAT
 host 192.168.71.111
object network LOCAL-192.168.8.113-NAT
 host 192.168.71.113
object network LOCAL-192.168.8.122-NAT
 host 192.168.71.122
 
object network REMOTE-206.210.91.138
 host 206.210.91.138
object network REMOTE-10.216.27.192-27
 subnet 10.216.27.192 255.255.255.224
 
object-group network REMOTE-VPN001-ALL
 network-object object REMOTE-206.210.91.138
 network-object object REMOTE-10.216.27.192-27
 
nat (inside,outside) source static LOCAL-192.168.8.109 LOCAL-192.168.8.109-NAT destination static REMOTE-VPN001-ALL REMOTE-VPN001-ALL
nat (inside,outside) source static LOCAL-192.168.8.111 LOCAL-192.168.8.111-NAT destination static REMOTE-VPN001-ALL REMOTE-VPN001-ALL
nat (inside,outside) source static LOCAL-192.168.8.113 LOCAL-192.168.8.113-NAT destination static REMOTE-VPN001-ALL REMOTE-VPN001-ALL
nat (inside,outside) source static LOCAL-192.168.8.122 LOCAL-192.168.8.122-NAT destination static REMOTE-VPN001-ALL REMOTE-VPN001-ALL

Hey Jacob.

I see the tunnel come up. And I can see in the logs where my pings are getting through and are bringing up the tunnel.  I'm not getting responses back though.

Since I'm creating the lab work for the remote end, do I need similar NAT statements for the remote side?

nat (inside,outside) source static REMOTE-VPN001-ALL REMOTE-VPN001-ALL destination static LOCAL-192.168.8.113 LOCAL-192.168.8.113-NAT

Like this?

Or on the remote end, do I need to flip-flop the LOCAL and NAT?

Thank you so much, for taking the time to assist me.  I think I'm almost there.

Jeff,

It sounds like there is either a misconfiguration on the other side, or there is a missing route on the far side.  If you are only seeing 1 way traffic in your vpn statistics the tunnel is not fully operational. 

The NAT is only implemented on one side of the vpn not both.

Your VPN configuration on the Local side should include the NATed object group as a source, and the real remote as a destination.  The remote side should have the real remote IP's as the source and the NATed local ip's as a destination.

Please check your routes also.

Hey Jacob.

I still need a hand.  Maybe I'm not explaining this correctly.

So I have the VPN tunnel established.

I have my crypto map with the matching access-list for the devices communicating locally and on the remote end.

My internal LAN with the "REAL" addresses assigned are for 4 devices 192.168.8.109,192.168.8.111, 192.168.113, 192.168.8.122.

The remote LAN via the tunnel should be 10.216.27.192 255.255.255.224 and host 206.210.91.138 255.255.255.255

What I'm trying to accomplish is:

My internal LAN with real addresses from above, are translated one-for-one to 192.168.71.109, 192.168.8.111, 192.168.113, 192.168.8.122

These would then be the addresses that communicate with the remote LAN.

So they would ping from 10.216.27.193 to 192.168.71.109, and that would then translate for connectivity to 192.168.8.109

And vice-versa:

I would ping from 192.168.8.109 to 10.216.27.193, the ASA would then translate to 192.168.71.109 and communicate with the remote LAN 10.216.27.193.

Maybe I'm just not understanding?

Thanks,

Jeff

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card