Configuring NAT on IPSEC

ciscodude111 · ‎08-23-2011

hello all...

I am trying to configure traffic to the wan using the IPSEC fw and NAT. Below is the network diagram:

My configuration as such

version 7.2(4)30

interface e0/0

nameif outside

ip add 195.87.3.250 255.255.255.0

security 0

no shut

interface e0/1

nameif inside

ip address 172.31.2.250 255.255.255.0

security 100

no shut

access-list to_customer extended permit ip 172.31.2.0 255.255.255.0 host 173.209.111.20

access-list policy-nat extended permit ip 172.31.2.0 255.255.255.0 host 173.209.111.20

static (inside, outside) 1.1.1.0 255.255.255.0 to_customer policy-nat

global (outside) 1 173.209.111.20

nat (inside) 1 0.0.0.0 0.0.0.0

route outside 0.0.0.0 0.0.0.0 195.873.250

-------------

---then comes the part where we build the vpn

crypto isakmp policy 20

authentication pre-share

encryption 3des

hash sha

group 2

lifetime 28800

crypto ipsec transform set ESP-3DES-SHA esp-3des esp-sha-hmac

crypto map outside_map 12 match address to_customer

crypto map outside_map 12 set peer 173.209.111.21

crypto map outside_map 12 set transform-set ESP-3DES-SHA

crypto isakmp enable outside

-----------------------------------------------

The problem is, the NAT is not happening. I am expecting the 172.31.x.x addresses to be converted into 1.1.1.0/24 addresses but nothing.

Secondly, there are other IPSEC VPN on this port too. Some VPNs went down after this new VPN was inserted.

I dont understand why.

Please do assist.

Thanks

cadet alain · ‎08-23-2011

Hi,

you're doing a site-to-site vpn between your ASA and the Juniper router so usually it is to communicate between 2 LANs via the public internet. Why are you tunneling traffic destined for your vpn peer? I don't think it will work.

Furthermore you should exempt traffic going through IPSec tunnel from being natted with a nat(inside) 0 command else your tunnel won't work. I'm not sure about ASA but on routers if routing fails then there is no nat.

You should get rid of this:

static (inside, outside) 1.1.1.0 255.255.255.0 to_customer policy-nat

and in your crypto map you must match traffic that is permitted by a crypto acl, don't forget there must be a mirror config on the vpn peer concerning this crypto acl.

Regards.

Alain.

Don't forget to rate helpful posts.

Jon Marshall · ‎08-23-2011

Alain

Furthermore you should exempt traffic going through IPSec tunnel from being natted with a nat(inside) 0 command else your tunnel won't work.

Unfortunately not every customer will allow private IPs on their network so you do have to NAT your own IPs before sending the traffic. Also it may be that the customer is already using the 172.31.2.0/24 addressing so again you would have to NAT.

I agree that nat exempt is more usual but if the VPN is to a 3rd party you often have to improvise

Jon

cadet alain · ‎08-23-2011

Hi Jon,

Thanks for the info I didn't know that but then how is it going to work with NAT ? Is there extra config to put on the VPN/NAT device?

Regards.

Alain

Don't forget to rate helpful posts.

Jon Marshall · ‎08-23-2011

Alain

Yes, the 2 main things are -

1) the NAT setup for your ip addresses

2) your crypto map acls must use the natted IPs at both ends.

if you only need to NAT your IPs because the 3rd party won't accept private IPs and i have had a few of these then it is relatively simple. Where it really becomes a pain is if you have overlapping IPs at either end. Then you need to NAT both ends traffic.

To further complicate it when you have overlapping IPs you also need to know whether both ends can initiate a connection or just one end ie.

1) if site A can only intiate connections to site B then you need static NATs at site B but you can use dynamic NAT at site A.

2) if site B can only intiate connections then it's just the reverse of 1)

3) if both sites can initiate connections then you need static NATs at both ends

So as you say, nat exempt is definitely the preferred way and if the VPNs are between your own sites then i would always use it. I would also look to use it with 3rd parties if possible but it often isn't unfortunately.

Jon

cadet alain · ‎08-23-2011

Jon,

Thanks for the infos.

Regards.

Alain.

Don't forget to rate helpful posts.

ciscodude111 · ‎08-23-2011

Thank you but I am not so clear on why we cannot nat before sending it into the IPSec VPN?

Also, any reason why putting IPSec won't work?

Thanks

Sent from Cisco Technical Support iPhone App

Jon Marshall · ‎08-23-2011

Jaspal

You can indeed NAT before VPN and some VPN customers require that. However there are a couple of things wrong/confusing about your config -

global (outside) 1 173.209.111.20

the above global has nothing to do with the VPN but why are you using the remote peer IP address for PAT on your firewall - is this just a typo ?

As for your VPN setup -

access-list to_customer extended permit ip 172.31.2.0 255.255.255.0 host 173.209.111.20

access-list policy-nat extended permit ip 172.31.2.0 255.255.255.0 host 173.209.111.20

static (inside, outside) 1.1.1.0 255.255.255.0 to_customer policy-nat

why are you -

1) using 2 access-lists in the static statement, you only need to use one of the access-lists as they are both doing the same thing

2) The destination IP(s) should not be the IP address of the peer device. It should be the networks you are yrying to reach behind the Juniper device eg.

access-list policy-nat extended permit ip 172.31.2.0 255.255.255.0 10.10.5.0 255.255.255.0

where 10.10.5.0/24 are the devices you want to talk to at the remote end.

Jon

ciscodude111 · ‎08-23-2011

Dear Jon,

thank you...

Yes, the global (outside) was a mix up. OK, let me redo and see.

version 7.2(4)30

interface e0/0

nameif outside

ip add 195.87.3.250 255.255.255.0

security 0

no shut

interface e0/1

nameif inside

ip address 172.31.2.250 255.255.255.0

security 100

no shut

access-list to_customer extended permit ip 172.31.2.0 255.255.255.0 host 173.209.111.20

access-list policy-nat extended permit ip 172.31.2.0 255.255.255.0 173.209.111.0 255.255.255.0

static (inside, outside) 1.1.1.0 255.255.255.0 to_customer

nat (inside) 1 0.0.0.0 0.0.0.0

route outside 0.0.0.0 0.0.0.0 195.873.250

-------------

---then comes the part where we build the vpn

crypto isakmp policy 20

authentication pre-share

encryption 3des

hash sha

group 2

lifetime 28800

crypto ipsec transform set ESP-3DES-SHA esp-3des esp-sha-hmac

crypto map outside_map 12 match address to_customer

crypto map outside_map 12 set peer 173.209.111.21

crypto map outside_map 12 set transform-set ESP-3DES-SHA

crypto isakmp enable outside

-----------------------------------------------

so, now the nat happening is converting the 172.31.x.x range to 1.1.1.x range, right?

I believe the customer on the other end of the vpn has to do a NAT too to translate the 1.1.1.x ip addresses to their 173.xx.xx.xx range.

Thanks Jon!

Marwan ALshawi · ‎08-23-2011

i agree with Jon the config not very clear

anyway

if this ACL to_customer is for VPN interesting taffic then you have to have the source as the NATed IP which is 1.1.1.0

also the destination is it the other end of the VPN peer or a LAN range ? this you need to check it whne a device communicateiwth your server in the range 1.1.1.0
what will be the source IP

assuming the other VPN peer IP

access-list to_customer extended permit ip 1.1.1.0 255.255.255.0 host 173.209.111.20

this is not correct

static (inside, outside) 1.1.1.0 255.255.255.0 to_customer policy-nat

change it to:

static (inside, outside) 1.1.1.0 255.255.255.0 policy-nat

HTH

ciscodude111 · ‎08-23-2011

Dear Marwan,

Thank you for the updates.

ok for the questions.

- the ACL to_customer is VPN. Yes. so. I have to change this to:

access-list to_customer extended permit 1.1.1.0 255.255.255.0 host 173.209.111.20

right?

-the device on the end of the VPN is 173.xx.xx.xx ip.

the peer is 213.144.191.21

the server which the packets are mainly for is 213.144.191.25

so, first it will be natted on my side, and i believe it has to be also natted on the customer side too. right?

thanks

Marwan ALshawi · ‎08-23-2011

yes change the ACL of VPN interesting traffic to be same as the one suggested bove ( to_customer )

but for the NATing use the ACL policy-nat not to customer

static (inside, outside) 1.1.1.0 255.255.255.0 policy-nat

ciscodude111 · ‎08-24-2011

Finally, one last question.... the customer end has to also translate this NAT.. basicllay

static (outside, inside) 1.1.1.0 255.255.255.0 173.209.111.0 255.255.255.0

where

173.209.111.0 is their LAN network...

right?

so, finally, the configuration would go as:

version 7.2(4)30

interface e0/0

nameif outside

ip add 195.87.3.250 255.255.255.0

security 0

no shut

interface e0/1

nameif inside

ip address 172.31.2.250 255.255.255.0

security 100

no shut

access-list to_customer extended permit ip 172.31.2.0 255.255.255.0 host 173.209.111.20

access-list policy-nat extended permit ip 172.31.2.0 255.255.255.0 173.209.111.0 255.255.255.0

static (inside, outside) 1.1.1.0 255.255.255.0 policy_nat

nat (inside) 1 0.0.0.0 0.0.0.0

route outside 0.0.0.0 0.0.0.0 195.873.250

-------------

---then comes the part where we build the vpn

crypto isakmp policy 20

authentication pre-share

encryption 3des

hash sha

group 2

lifetime 28800

crypto ipsec transform set ESP-3DES-SHA esp-3des esp-sha-hmac

crypto map outside_map 12 match address to_customer

crypto map outside_map 12 set peer 173.209.111.21

crypto map outside_map 12 set transform-set ESP-3DES-SHA

crypto isakmp enable outside

-----------------------------------------------

In a brief overview:

My lan network ------------------->NAT--------------------------VPN-------------------------> NAT---------------------->customer

172.31.x.x 1.1.1.0/24 1.1.1.0/24 173.209.111.0/24

This is correct?

Thank you

Marwan ALshawi · ‎08-24-2011

Hi

i am a bit confused now

if understand you questions and the diagram

your lan is 172.31.x.x to be nated to 1.1.1.0/24 so the remote sites they acess your network as 1.1.1.0

the remote end VPN IP ( not LAN is 173.209.111.21 )

and the remote destination IP/host is 173.209.111.20 ( assuming the remote end is either a server or source NATed form their end )

base don the above you need the ACL to_customer for VPN interesting traffic

this ACL will be processed after NATing which will be source 1.1.1.0 destination 173.209.111.20

while th epolicy nat ACL is for the NATing

form the other end all what you need to know the IP addres of the VPN peer and the LAN or Private IP the VPN traffic will go to from your site and will be sourced from thier site based on your config it is now ( 173.209.111.20 )

Jon maybe can comment if he has differnt approach to it as he is very experienced in VPNs

HTH

pls rate the helpful posts

ciscodude111 · ‎08-24-2011

Here is the whole scenario in bigger context...the bigger the scene, the bigger the problems..:)

I tried NAT-ing the IP addresses before sending it over the VPN. If i apply the NAT over any interfaces, other VPNs will be effected. Most likely they will go down too. So, option of using NAT on a general interface is out.

So, i thought of creating a new VLAN, separate than the others, and placing it on a free port. However, the problem with this is, that, with our existing licence, we are not allowed to create more than 3 vlans. A new super licence allows up to 20 VLANS.

Creating sub-vlans in ASA is unheard.

Is there other way i can send my IPs, converted into public IPs and sent over the VPN?

What about the other side, does the same apply? Even if their network is running on public IP?

Is it easier to just buy another router, not ASA, and do a nice VPN from there.?

Help!