10-27-2016 09:34 AM - edited 03-12-2019 01:27 AM
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
10-27-2016 09:56 AM
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
10-27-2016 10:14 AM
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?
10-27-2016 10:49 AM
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.
10-27-2016 11:13 AM
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?
10-31-2016 12:37 PM
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
10-31-2016 01:39 PM
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.
11-01-2016 05:42 AM
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.
10-31-2016 12:17 PM
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
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